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:
- 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.)
- 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
| Rule | Why |
|---|---|
Hub DEPLOY/SRC is GOD — the one writable SoT | No second writable copy ⇒ no competing truth ⇒ no drift |
| Cockpit local sources are read-only reference | Work cannot exist only on the edge; it must reach GOD to exist |
| Sync from GOD before any work | GOD moves constantly (auto-commit, deploys, sibling pushes); cold starts are stale |
| Relay to GOD after work | Short contribution window; nothing accumulates un-upstreamed |
| One seat per task, never simultaneous | Two seats on the same work = drift; the single conductor enforces it |
| Every change carries an origin watermark | Provenance ledger — traceability, attribution, and merge-by-origin |
| External forks: license/CLA + maintainer gate | Legal 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).