D13 Contract

This is the table the runtime builds against. It says, for each log, which kind takes which lifecycle shape, what code the envelope carries, and which refusal atom each condition names.

It is published deliberately ahead of its full verification, so that runtime work can start against a fixed target rather than against a moving one. Every later change to it arrives as a named difference against this table, never as a quiet edit.

The shapes, and what each adopter supplies

The model has four shapes. The runtime has flat kinds that classify under them, and needs no hierarchy of its own to do it. What the family fixes is the shape, the effect and the generic refusal condition; what each adopter supplies is the kind’s name, its code, and the atom each refusal names.

Shape	Effect	Generic refusal
Create	the first row	a create on a subject that already started
Mutate	the record may change	a mutation on a subject that is not live
Retire	the tombstone; `post = pre`; terminal	a retire on a subject that is not live — a second retire is refused, not ignored
Affirm	`post = pre`, carrying the claimed version	not created; retired; or the claim names a stale version

Every adopter carries the same three laws: shape admission, nothing after a committed retire, and a mutation is never the first row. Liveness is read as liveAt inside an occurrence and liveSubjectAt from outside — and the second is the translation the runtime uses: a subject is live exactly when the head of its log is not a retire kind.

Per adopter

Codes in parentheses are unchanged from what the runtime writes today.

Log	Kind	Shape	Envelope code	Refusal	Effect
demand	`CreateDemandOcc`, `CreateWithCycleOcc`	Create	`CREATE`, `CREATE_WITH_CYCLE`	started → demand’s started atom, plus today’s item and cycle arms	as today
demand	the thirteen mutators	Mutate	unchanged	not live by shape, or status not live by domain → demand’s closed atom	unchanged
demand	`DeleteDemandOcc`	Retire	`DELETE`	not started or already retired → closed; started with a live status → not-terminal	tombstone
order	`CreateOrderOcc`	Create	`CREATE`	started → order’s started atom	as today
order	seven mutators, annotate among them	Mutate	unchanged	annotate: not started or retired → closed, at any status	unchanged
order	`DeleteOrderOcc`	Retire	`DELETE`	not started or retired → closed; live status → not-terminal	tombstone
line	`AddLineOcc`	Create	`ADD_LINE`	started → line’s started atom; parent gate; attach arm	as today, born with no internal notes
line	`DetachDemandOcc`	Mutate	`DETACH_DEMAND`	unchanged	drops the demand
line	`RemoveLineOcc`	Retire	`REMOVE_LINE`	not usable → closed; parent gate; a demand still attached → a new atom	tombstone — the demand drop is gone; removal is now two acts
line	`AnnotateLineOcc`	Mutate	`ANNOTATE_LINE`, gaining a notes payload	not started or retired → closed, at any domain state	sets the line’s internal notes, frames the rest
line	the other six mutators	Mutate	unchanged	unchanged	unchanged, and every frame keeps the internal notes
item	`CreateItemOcc`, `UpdateItemOcc`	Create, Mutate	basic through Phase III, no envelope row	exists; not created; retired; unchanged reference refusal on vendor rows	content set, no status field
item	`RetireItemOcc`	Retire	basic through Phase III	not created; already retired	tombstone
staff	`CreateStaffOcc`, `RetireStaffOcc`	Create, Retire	basic through Phase III	exists; not created; retired	fieldless record; tombstone
business affiliate	`CreateBaOcc`, `UpdateBaOcc`, `RetireBaOcc`	Create, Mutate, Retire	basic through Phase III	exists; not created; retired	roles set; tombstone

Two of these rows are renames of kinds the model already had, from a delete-shaped name to a retire-shaped one, because the effect is a tombstone rather than an erasure and the name should say so.

One name is stated here for veto rather than settled. The business affiliate’s retire kind is spelled with the abbreviated form, for consistency with its siblings in the same log. That is a deviation from the fuller name that was proposed, and it is the operator’s to reverse.

The envelope

The kind and reason codes are carried per adopter and keyed by (table, code) — a code is unique within its table, not across the system. The only rule about the code itself is that it is the enum constant’s name, and the reason is the refusal atom’s name verbatim. Nothing derives one from the other.

The outcome is committed or refused, with the refused row written on the entity’s own table in this phase. The reversal and activation columns are null throughout. Effective-time ordering is monotonic. A second retire is refused with the adopter’s closed atom rather than treated as a no-op, and a retry of the same act is the boundary’s duplicate rather than a new refusal.

No new index is needed for tombstone uniqueness, because it follows from terminality, which each root proves as a theorem.

Where a kind may be admitted but the caller cannot bind the subject, the split is drawn on bindability within the caller’s tenant scope — the runtime’s decision, not the model’s. And not created has no runtime referent in this phase: it is an absence, and an absence is not a state a row can be in.

What this table deliberately does not cover

So that nobody searches it for these.

The per-log adoption of the affirm act: the verb and its kind are generic, and each log adopting it is a later one-line fact rather than a row here. The pool-delivery log inside the demand module, whose kinds stay per-kind rather than becoming lifecycle adopters. The inventory-item log, which is off the spine. The card log. And the spine promotion itself.

None of those moves a name, a code, an atom, a shape or a binding in the table above.

Sources

Published from the text of notebooks/domain-ontology/streams/samwise/d13-contract-table.md, which cites the model at commit 793cfe0 on branch jmpicnic/domain-ontology-affirm-kind of Saldubatech/manufacturing-ontologies. Two further adoption roots were added at the branch tip, 4b53f118. The branch is unmerged and the merge onto the integration line is the operator’s own hand.

The table was published from the cut’s text before its verification finished, deliberately, so that the runtime adaptation could start against a fixed target. Its Tier A gate is green with every root satisfiable and the static gates clean; the Tier B soak has not run. The names in it are the operator’s word except the one deviation noted above.

The runtime adaptation is PDEV-1898.