Part 3 of 7 · 6 min

The charter nobody authors

Every project has a founding document, and almost every founding document is fiction within a quarter. Part 3 of the Change Series: a charter computed from live sources, sealed when it matters, and signatures that only count sealed.

Part 2 ended on the question every phase silently leans on. The gates know what must be true to exit a phase. Something has to say what the initiative is for, what it must not touch, and who stands behind it. That something is traditionally called a charter, and the word deserves its bad reputation.

The traditional charter is written once, in week one, by the person with the best prose style. It is approved in a meeting, filed in a drive, and consulted never. By month three it describes a project that no longer exists. The scope moved, two risks materialized, a sponsor changed, and the document kept saying what it said. When an auditor finally reads it, the charter is not wrong so much as fictional, and everybody involved knew.

The diagnosis is the same one this trilogy keeps arriving at. An authored document says what its author believed at the time of authoring. Nothing binds it to the thing it describes.

A projection, not a document

Danubia's decommissioning charter is not stored anywhere, and that is the design.

The charter is a projection: recomputed on every read, folded from the live producers that actually hold the initiative's reality. The initiative object contributes its type, phase, and committee. The scope contributes what is in and what is deliberately out, and the proposal envelope contributes the founding intent.

The intelligence backlog contributes what surfaced since. The build artifacts contribute what is actually under construction, the portfolio contributes capacity, and the dependency ledger contributes what this change waits on. Grounding edges tie the claims to the modeled estate.

Read the charter on Tuesday and it reflects Tuesday. The scope change from Monday is in it, because the charter is a view of the scope, never a paraphrase of it. Nobody updates the charter, for the same reason nobody updates a mirror.

The fold is deterministic, and readers of our Proof Series will recognize the move: it is the derived tie-out, pointed at intent. The same inputs produce the same charter, so there is no author to lean on and no phrasing to negotiate. Completeness is measured against a fixed schema of fields, field by field, rather than asserted in an executive summary. A charter that is sixty percent complete says so, and says which fields are the gap.

The moment it stops moving

A live projection raises the obvious objection. You cannot sign a moving target.

So the platform has one more verb: capture. At the moments that matter, a phase gate, a steering decision, a regulator's request, the current fold is captured as a snapshot. The snapshot is frozen, checksummed, and sealed. The snapshot is what gets signed, and the snapshot never changes again. Snapshots and their signatures are append-only, and the store enforces that with uniqueness constraints rather than good intentions. There is no code path that mutates or deletes either.

The checksum is worth a paragraph, because its scope was a lesson. It binds the charter content together with its full audit context. That context is which initiative, when taken, why, at which phase, with which required signers, in which order. Each of those was once outside the seal, and each absence was an attack. Rewrite the phase from proposed to approved, shrink the required-signer list, or edit the reason after the fact, and every signature still verified. The seal now covers the context, order included, so what you signed is exactly what a reader later verifies.

And the verification is a read-time act, in the pattern our last series made central. Loading a snapshot recomputes the checksum from the stored material and re-verifies every signature against it. A row edited directly in the database surfaces as tamper-evident, per signature, with a banner on the printable version. The seal does not trust its own storage.

Signatures that only count sealed

The signing side carries the same discipline, and one rule does most of the work. A signature counts only if it is sealed. An empty signature blob, or the unsealed fallback a development environment produces, never counts toward quorum, never advances the signing state, and always fails verification. When no signing key can be resolved at all, verification returns false for everything rather than pretending.

Around that rule, the machine is honest about the awkward cases rather than rounding them. A sealed signature from somebody outside the declared quorum yields the state partial, not unsigned. Something is on file, just not against the declared bar, and the verification names which required slots remain open. And a committee where nobody was marked required produces a quorum bar of one signature, which the platform will honestly satisfy. That last behavior is a designer's foot-gun, so we say it here the way we would say it in a demo. Mark your required signers, because the machine enforces the bar you declared, not the bar you meant.

One boundary in the same breath. The seal proves who signed what, when, against which context. It does not prove the judgment was good. Machines hold the record straight, and part 2 of our first series drew that line for good.

The regulator reads it cold

Here is the scene the design is for, and it is Danubia's part 7 scene arriving early.

Eighteen months after the shutdown, a regulator asks for the decommissioning charter as it stood at the graceful-shutdown gate. In the authored world, this request starts an archaeology project: which version, whose drive, and was the approved copy the one that changed after approval?

Here the answer is a snapshot: sealed at that gate, checksummed over its full context, signatures verifying on read. Beside it, the live charter shows what the initiative looks like now, and the difference between the two is itself information rather than embarrassment. The initiative changed after the gate, as initiatives do. The record shows what was known and signed then, and what is true now, as two honest artifacts rather than one blurred document.

One caution we keep for ourselves: a cached charter is a hazard in exactly this scene, a regulator reading a stale copy. So the read cache is off by default, and a capture always invalidates before it folds, so a snapshot can never seal a stale read.

The intent has a spine too

Count what the last two parts built. The initiative moves through a machine whose gates read the record. The intent above it is a projection of the record, sealed into snapshots at the moments that matter, signed with signatures that only count sealed. Spine and intent, both bound to the same live truth.

What neither part explained is how work gets in. Scope changes, risks surface, reports need rebuilding, and every one of those becomes activity somewhere. The next part is about the platform's strictest opinion. All of it enters through one door, and every act at that door visibly writes or visibly refuses.

Part 4: Every act writes or refuses. One door for work, one writer per decision, and the undo that adds rather than erases.

← part 2A unit of change with a spine part 4 →Every act writes or refuses

Model your first domain today.

You send five documents, we model them, and the first cut comes back in days.