0
Docs › Advanced & Fleet Admin

Contribution & Provenance Model

How work flows into LuminalCMS from many seats without ever creating a second source of truth — and how the same mechanism scales to sublicensed forks that contribute improvements back upstream, the way the Linux kernel does.

1. The Core Rule — One Source of Truth

The hub's /var/www/DEPLOY/SRC is GOD: the single authoritative source of truth. Nothing is canonical until it lands here, and every deploy originates here. There is exactly one writable SoT — the hub. Everything else is a contributor.

2. Contributor Cockpits

A "cockpit" is any seat where development happens. Each cockpit is a read-only local reference that relays its writes up to GOD. The discipline is three moves:

  • Sync-first (entry ritual): pull current from GOD before touching anything. GOD moves constantly on its own — 4-hourly auto-commits, phone-home, version stamps, deploys, and sibling cockpits pushing in. A cold start is instantly stale.
  • Work: edit against a fresh reference; actual writes target GOD.
  • Relay (exit): contribution flows up into Hub SRC (commit → push). Keeping local read-only means work cannot exist only on the edge — it must reach GOD to exist at all. Drift is prevented by construction, not by memory.

One seat per task, never simultaneous. A given piece of work lives on exactly one cockpit for its duration. With a single human conductor directing all seats, this enforces itself.

The shape is a star topology — GOD at the center, N contributor cockpits at the edges — mirroring the hub-and-spoke of sites the fleet already runs.

3. Origin Watermarks

Every change is source-stamped with its origin cockpit, so any change is traceable to where it was born. The stamp goes in changelog entries and commit context, so a git log / changelog read is a legible provenance ledger:

  • [DO session] — work done on the hub via SSH-into-DigitalOcean.
  • [Nitonian] — work done on NITON (the local Linux capsule node).
  • [licensee-<name>] — work done on an external sublicensed fork (see §5).

Watermarks are symmetric: every seat stamps, not just one. Add a new cockpit, give it a distinct stamp, point it at GOD.

4. Case One — Internal Cockpits

Today there are two internal seats, both contributing up into the same GOD:

  • DigitalOcean (DO): SSH from the Mac into the hub. Edits land directly on GOD; stamped [DO session].
  • NITON: an older Mac running Linux, booted from the Resurrection Capsule. Its local SRC is a read-only reference; writes relay up to GOD; stamped [Nitonian]. The win is the native Linux terminal (easy copy/paste) and local read snappiness.

The hub itself is not a cockpit — it is the SoT plus the automated pipeline (crons, backups, deploys, milestone snapshots).

5. Case Two — Sublicensed Forks (the ecosystem model)

An external licensee running a fork of LuminalCMS is the same primitive as an internal cockpit: a watermarked, sync-first, relay-to-GOD contributor. The only differences are that we don't control their seat, and a license term plus a review gate stand between their watermark and the mainline. This is precisely the Linux-kernel maintainer-tree model:

  • Origin watermark ≈ Signed-off-by: / the DCO (Developer Certificate of Origin) — per-change provenance; every improvement attributable to its origin fork.
  • Hub SRC (GOD) ≈ the mainline tree; licensee forks ≈ vendor/subsystem trees; watermarked commits flow up through review.
  • Integrate remote improvements = cherry-pick / merge by watermark — the stamp says who and where.

The critical nuance — the watermark enables, the license grants. "Forcing contributions back upstream" needs two things:

  1. Legal right: copyleft alone (GPL) forces a licensee to disclose source to their recipients — it does not force upstreaming to us, nor give us the right to relicense their code to other licensees. That requires a Contributor License Agreement (CLA) or a bespoke contribution covenant. (Not legal advice — confirm with counsel.)
  2. Mechanical means: the watermark + hub topology — already built — which makes identifying and integrating their improvements a solved engineering problem.

Plus a maintainer merge gate: a human reviews licensee improvements for quality, security, and license-cleanliness before they land in GOD. That gate is a feature — it is how the mainline stays trustworthy.

6. The Rules at a Glance

RuleWhy
Hub DEPLOY/SRC is GOD — the one writable SoTNo second writable copy ⇒ no competing truth ⇒ no drift
Cockpit local sources are read-only referenceWork cannot exist only on the edge; it must reach GOD to exist
Sync from GOD before any workGOD moves constantly (auto-commit, deploys, sibling pushes); cold starts are stale
Relay to GOD after workShort contribution window; nothing accumulates un-upstreamed
One seat per task, never simultaneousTwo seats on the same work = drift; the single conductor enforces it
Every change carries an origin watermarkProvenance ledger — traceability, attribution, and merge-by-origin
External forks: license/CLA + maintainer gateLegal right to integrate + relicense; quality/security control on merge-up

Provenance: authored [DO session] 2026-07-05. Model foundations: internal cockpit protocol + repo independence (self-hosted, GitHub-free, multi-remote).