WRL Core 0.1.2 — Frozen Family Extract

This document commits the meaning families of WallRiderLang that the TRVM runtime and the Forge semantic graph have grounded. It freezes which kinds of things exist and what each kind means — not the detailed surface rules, which remain a design draft and may still change.

Status and errata

Status: frozen (families only). Extracted from the Complete Design Draft per the WRL ruling, Phase 1. This is the living Core-0.1.x document; the current revision is 0.1.2.

When the design draft and this document conflict about what is settled, this document wins. The draft remains authoritative for full rationale and forward design.

Part I · Normative — the frozen family extract

§0Architectural rulefrozen

WRL denotes the canonical Forge semantic graph. It is not lowered by compiling surface syntax directly to hand-written interaction-calculus text. The only sanctioned path is:

Forge Semantic IR v1 is a separate gated deliverable. Until it is frozen, no lowering target is normative.

§1The ten construct kindsfrozen · closed set

Every WRL construct is exactly one of these ten kinds. The set is closed.

Of these, Actor, Route, Wall, Period, Film, Hash are additionally grounded by TRVM today (§14). Function, Fragment, Stencil, Derive are frozen as kinds but their detailed semantics remain draft.

§2The four reading lawsfrozen

1. Shape says what a thing is. Bracket shape identifies the kind of object.
2. Line texture says how it moves. Route style identifies the operational guarantee.
3. The colon introduces; the slash bounds. Both families cap at three strokes, ordered by permanence: transient · committed · sealed.
4. Marks for architecture, words for computation. Process notation owns punctuation; expression notation defaults to words.

§3Container / shape-as-kind familyfrozen · 3 members

Frozen invariant: (state) is single-owner and mutable by replacement; {…} is permitted, static structure, distinct from current state. Exact field grammars are draft.

§4Identity / addressing familyfrozen · 4 members

Frozen invariant: executable identity is a hash; human aliases are words and never semantic.

Implementation status of * (0.1.2). The symbol's family role stays frozen as written, but the two meanings are at different maturities and the spec must not imply otherwise:

§5Route / texture familyfrozen · 4 core textures

The reduction relation is defined over exactly these four irreducible textures. All surface sugar canonicalizes down to one of them plus attributes.

Frozen: the set of core textures and their guarantee-roles. Not frozen: label, payload and guard grammar; the sugar table; branch and lane rules.

Surface status (0.1.2). Freezing a texture's meaning-role is not the same as grounding its construct. Only -- is surface-grounded today:

§6Time familyfrozen

• Logical time is superdense: every event carries (period t, microstep m).
• A period is the settle-and-commit unit; same-period events are ordered by microstep.
• Wall-clock enters only through an explicit boundary and is recorded as a signed fact; wall-clock is never replayable state, logical time is.

Frozen: the period/microstep model and the wall-clock-as-fact discipline. Not frozen: the tick surface syntax details.

§7Memory-kind familyfrozen · 5 members

§8Execution-model family — the deterministic reactive floorfrozen

Grounded directly by TRVM's deterministic reduction, ADMIT reducer, persistent fold, and replayable films.

Configuration (frozen shape): the persistent runtime state — world state (owned state cells), monotone claim facts, immutable acceptance receipts, capacity-fault latches, clock state, poses, rotors, numeric faults; plus static topology and policies. Mailboxes, supervisor and behavior tables are Experimental and are not part of the frozen floor.

Two frozen invariants (enforced statically)

1. Single-owner cells — no shared mutable cell.
2. Disjoint deterministic guards — at most one deterministic rule enabled per actor-state; genuine choice must be an explicit scored branch.

Period cycle frozen · 6 phases

For claim-free profiles the first three phases (OBSERVE/ACCEPT/MAP) degenerate to identity but must not disappear from the semantic model: the OBSERVE/ACCEPT/MAP distinction is what determines which claims were seen, which candidate was accepted, whether a retransmission retries an effect, which controls were committed, and whether a same-epoch configuration affects that epoch's reaction.

Canonical ordering is policy-pinned frozen as a family, not a formula

Events and accepted operations are ordered by a total canonical key whose schema and policy identity are part of the semantic artifact. Worker arrival order is never semantic. The current ADMIT profile pins the CandidateKey and the canonical accepted-event ordering; a future mailbox profile may pin a different key. The existence and policy-pinning of the key is frozen; the specific formula is not.

Conflicts narrowed in 0.1.1

Cell-write conflicts are structurally constrained; claim and control conflicts are resolved by explicit, policy-pinned recognition, acceptance and canonical application laws. Concretely:

• single-owner cells remove generic write-write races;
• append and fact-union structures merge deterministically;
• but equivocation, conflicting accepted operations, claim retransmission, receipt divergence, configuration ordering, fault-reset-vs-new-overflow, and capacity failure are not dissolved by ownership — each is resolved by an explicit pinned policy.

Not frozen: the podium/ranking ceiling, scored-branch scoring functions, distributed termination detection.

§8bHistory family — WorldFrame / EventLedger / BuildFilmfrozen · 3 distinct artifacts

"Film" is not one undifferentiated object. Three conceptual artifacts are frozen distinct; their current serialization is the Film v0.6/v0.7 family.

A replay package is frozen as:

ReplayBundle { initial_artifact, initial_state, event_ledger, frames, policy_ids }

Frozen: the three-way distinction and the ReplayBundle shape. Not frozen: byte layouts — they are the Film serialization, a backend concern.

§9Fact-merge familyfrozen · union law only

Replicated {facts} merge by a join-semilattice union that is commutative, associative and idempotent. This is the frozen distributed floor and matches TRVM's proven claim-fact set union.

§10Boundary (wall) familyfrozen · gate / commit / seal

Frozen: the three-tier ordering by permanence, and the no-ambient-authority rule — effects cross named walls only. Not frozen: exact policy grammars.

§11Canonicalization & content-identity familyfrozen

• Meaning is normalized before content addressing. Comments, spacing, alignment, decorative line and route length, and presentation color never affect the semantic hash.
• Identity is content-addressed (#hash); the same normalized graph yields the same hash on every host.
• Builds and expansion are hermetic and host-blind: same source, same canonical bytes.

This matches TRVM's content-addressed objects and the digest / candidate-key discipline used in the ADMIT core.

§12Conformance families frozen

These observable properties are frozen as families of guarantee; their exact test matrices remain draft.

§13What Core 0.1 does NOT freeze

Deferred to later frozen revisions:

• Experimental: the entire expression notation (values, functions, types, generics, numerics), effects / capabilities / entropy, the supervision error ladder, streams and backpressure, actor behavior blocks, evolution and migration, podium / ranking, the static-check catalog, execution profiles.
• Proposed: metaprogramming (fragments, stencils, derives, reflection, sealed compiler tools) beyond their kind-role; modules and builds; build films; foreign functions; and all distributed settlement above fact-union.

0.1.2: "mailboxes" was removed from the Experimental list — the mailbox is no longer merely experimental, it is IR/runtime-grounded and surface-partial (§14b). It is still not promoted.

Promotion path: a family moves from Experimental → Core only after it is surface-grounded (§14b) in a running Forge/TRVM implementation, at which point this file is revised. The steered order for 0.2 is recorded in §16.

Everything in Part II is, by definition, in neither list: it is not Experimental (nothing has been tried) and not Proposed (nothing has been designed to the point of a construct). Part II records the direction these deferrals are being resolved toward, so that a promotion can be judged against something other than convenience.

§14TRVM groundingcorrected 0.1.1

Grounding is stated honestly: grounded = an isomorphic TRVM lowering exists; partial / reserved = the concept is grounded but the WRL language construct is not, or the construct is reserved with no lowering.

0.1.2: the word "grounded" was doing two jobs. §14b now splits it into IR/runtime-grounded and surface-grounded. Every entry in the Grounded table below is surface-grounded.

Grounded

Reserved or partial — NOT a complete grounding

§14bSurface-grounded vs IR-groundedfrozen distinction · new in 0.1.2

0.1.1 used a single word, grounded, for two genuinely different achievements. Conflating them let the Mailbox work read as if it had promoted a route texture, which it had not. 0.1.2 splits the term:

A construct is only eligible for promotion into a frozen Core family when it is surface-grounded. IR/runtime grounding alone is necessary but not sufficient.

Mailbox is the worked example. The mailbox declaration is IR/runtime-grounded: it exists in the canonical IR, the runtime honours it, and the networking battery covers it. It is not surface-grounded: there is no ~~ surface form to write, the formatter cannot emit one, and — decisively — there is no structural edge declaration for it.

Mailbox is not a sixth surface-grounded role. The five world roles (Pulser / Relay / Door / Spinner / Orb) are surface-grounded. Mailbox is IR/runtime-grounded and surface-partial.

The networking track is correct to call Mailbox a sixth IR role — that is exactly what it added, additively, without moving any pre-existing identity. What must not be inferred from it is that WRL now has six surface roles, or that the async route texture was promoted. It did not, and it was not.

§15The document boundarynormative · new in 0.1.2

A world and a run of that world are different documents.

Frozen consequences

1. Run inputs are not world content. periods and [epoch:N] claims are run inputs. Changing them does not move the SemanticArtifactID; the same world can be run by many scenarios.
2. A world formatter emits a world document. It must exclude scenario syntax both semantically (reparsing yields no run inputs) and lexically (the emitted text does not contain scenario syntax at all). The lexical half is load-bearing: a formatter emitting a literal periods 0 would satisfy the semantic half while still writing scenario syntax into a world document.
3. Round-trip laws split in two. The world round-trip preserves the complete canonical world projection; the identity round-trip preserves the canonical artifact bytes and the SemanticArtifactID. Neither subsumes the other.

The world projection is defined by exclusion — every canonical field except the run inputs — and never as a fixed tuple such as (profile, nodes, edges). A fixed tuple silently stops covering any field a later slice adds; §16 adds route semantics, which such a tuple would omit.

15.1 · The two parser mouths

The strict world parser is normative. Parameterizing the parser is sanctioned only as a migration bridge, and only through an unmistakable API — never a boolean flag on one function:

The legacy path's destination is to split a combined document into a world document plus a scenario, rather than to keep parsing it forever.

§16Core 0.2 promotion orderrecorded · new in 0.1.2

The order below is steered, not merely preferred — each step supplies something the next one needs, so reordering them produces constructs that cannot be grounded honestly.

16.1 · == is not "almost free"

It is tempting to read the verified route as nearly grounded, because ADMIT already accepts claims. That reading confuses two different things:

• the declaration == would introduce is authorization structure;
• the frozen texture == denotes an evidence-backed transition.

16.2 · Permission / instance splitapproved

Constraint. Do not introduce a principal-shaped role such as [worker:w1] as part of this work. How principals and writers exist in the role system is a separate question requiring its own sanction; smuggling one in as a side effect of the verified route would freeze a role-system decision that was never ruled on.

§17Surface sugar tierstatus · new in 0.1.2

Sugar is a source-to-source pre-pass that runs in front of the untouched canonical parser.

Status: IMPLEMENTED — CURRENT BATTERY GREEN / IDENTITY-EQUIVALENT / NOT CLOSURE-PROVEN / NOT FROZEN.

The law: no sugar-specific identity

Stated precisely, because the looser phrasing is false:

• A sugared spelling and its explicit twin desugar to the same canonical bytes and therefore seal to the same SemanticArtifactID. Sugar introduces no identity of its own and no privileged path to the seal.
• It is not the claim that editing sugar cannot move an identity. sp*3 → sp*4 is a different program and moves the identity, exactly as the explicit spelling would.

Two required properties, gated by battery

1. Bounded expansion. A one-to-many form must reject an absurd count with a typed diagnostic before allocating the expansion. sp*1000000000 is a diagnostic, not an out-of-memory event.
2. Original-source mapping. A one-to-many expansion must preserve the authored spans, so that diagnostics, completion, semantic diff and editor operations all refer to what the author wrote rather than to generated text.

Generated names are judged by the ordinary seal — a collision between a generated name and an explicit one is a normal WRL_DUPLICATE_ID, not a special sugar rule.

End of Part I. The next gated deliverable is §16 step 2 — the ~~ async route — which requires a canonical logical route declaration distinct from the structural edge declaration.

Part II · Topology extrapolation — non-normative

§D0Status of Part IInon-normative · new in 0.1.2

Part I answers what is settled. Part II answers a different question: what is this language for, such that the settled part is worth having? A frozen core with no stated destination gets extended by whoever asks loudest; writing the destination down turns that into an argument that can be lost.

D0.1 · The reframe that produced Part II

WRL has been evaluated as an actor language — process, mailbox, behaviour loop, supervision tree — and by that measure it is weak: it has no runtime-spawnable process, no user-written behaviour, no supervision floor, and no surface mailbox (§14, §14b). Part I does not hide this.

That measure is not, however, the one this language was built for. What the implemented core actually delivers is unusual and hard: a content-addressed, replayable, statically-checked description of a network of identities, in which the description is a hash and the run is a film. Part II states the destination that follows from taking that seriously:

WallRiderLang is an executable topology language: a notation in which physical, computational, communication, authority, fault, and economic networks can be described over the same durable identities, checked before they run, and replayed exactly after they do.

The prose case for this framing, with the honest scorecard and the ordered list of what is missing, is on the Direction page. What follows here is only the part that has spec consequences.

§D1Multilayer topology over one identitydraft

A layer is a set of connections among the world's identities that answers one question about them: who is next to whom in space, who can message whom, who commands whom, who powers whom, who is blamed when whom fails.

The multilayer-network literature [K14] distinguishes two arrangements, and the distinction is the whole of this section:

Draft rule D1. A WRL world is node-aligned. Layers are aspects of one identity, not replicas of it. There is therefore no inter-layer coupling construct, because there is no pair to couple: d7 in the road layer and d7 in the comms layer are the same d7.

What node-alignment costs. It rules out the honest modelling of an entity that genuinely is several things in different layers — a consortium that is one legal person in the authority layer and three independently-failing datacentres in the fault layer. The draft's answer is that such a thing is three identities and a wall (§10), not one identity in three replicas. If that answer turns out to be unworkable in practice, D1 is wrong; see §D7.

§D2Three connection kindsdraft

Part I recognises exactly one way for two identities to be connected: a route from a writer to a reader, in which the writer's output is delivered to the reader's input and no cell has two writers (§0, §5). That rule is load-bearing and correct for signals. It is not correct for everything a layer might mean.

Two established precedents show what the frozen rule is a special case of:

Draft rule D2. Single-writer-per-cell is not repealed. It is reclassified as a property of a port, and two further port kinds are proposed alongside it:

What this buys. Power buses, shared physical media, contention on a road segment, and summed loads all stop needing to be faked as chains of relays. What it costs. The within-period REACT fixpoint (§8) is currently a single-pass settle over owned cells. Resolved ports still settle in one pass, provided the resolution obeys the laws in §D2.1 below. Acausal connections do not settle by passing values at all: they require solving a system. That is a different execution model, which is what §D4 is for.

Three resolver contracts, and only one of them is a join

An earlier version of the paragraph above said resolved ports settle in one pass "provided the resolution function is associative, commutative and idempotent — the same three laws §9 already demands of fact-merge, which is not a coincidence". The three-law phrasing was borrowed from the CRDT literature because it was nearby, and the borrowing hid a distinction. It is a coincidence, at least in the third law, and reusing §9's laws here quietly forbids resolutions that are correct.

Idempotence exists to make redelivery harmless. That is its entire job. In §9's evidence merge, a replica cannot know how many times a fact will reach it — once, or twice by two paths, or again after a partition heals — so the merge must not be able to tell, and x ⊔ x = x is what guarantees it. Driver-set resolution has no such problem. The set of drivers reaching a terminal is fixed by the topology, the topology is in the sealed artifact, and §D9 makes even a changed topology a deterministic function of the ledger prefix. The multiplicity is known exactly. A law that pays for an unknown you do not have is not free — it is paid for in expressiveness.

The cost of the borrowed law is concrete rather than theoretical. An idempotent resolution cannot distinguish one driver from two — that is precisely what x ⊔ x = x says. So it can never express "two enabled drivers on this bus is a fault", which is an ordinary thing a hardware profile wants to say and a real bus-contention rule.

Dropping idempotence was the right correction and not the whole of it. The first version of this section kept associativity and commutativity, on the grounds that they let the canonical order "be chosen without changing the answer" — and that sentence refutes itself, because §11 already chose the order. If the input is one normatively-ordered map, there is nothing left for those two laws to protect either. They were retained by the same reflex that supplied idempotence: the laws came as a set, so they were kept as a set. Below they are separated by what each one actually buys.

A profile declares which one it is writing — resolver_kind = canonical_map or parallel_fold — and that declaration is checkable against a finite table by §D6.1's validators rather than trusted. The two are not ranked: a parallel_fold is the stronger claim and the weaker expression, and a profile that will never partition a bus of four drivers has no reason to make it.

§D3Route axes are not route texturesdraft

The four frozen textures (§5) are guarantee classes: -- settles this period, ~~ does not, == requires evidence, !! carries failure. That is a small closed set, which is why glyphs work for it.

A recurring proposal is to add textures for domains — a road texture, a radio texture, a money texture. Draft rule D3 refuses this, on the following grounds.

ROS 2 [R] settles a similar question for message transport by exposing seven independent policies — reliability, durability, history, depth, deadline, lifespan, liveliness — any combination of which is meaningful. The general shape of a connection has at least these orthogonal axes:

Eight axes of two to six values each is thousands of combinations. No glyph vocabulary survives that, and the attempt would either explode the textures or — worse — quietly overload them, so that -- means "synchronous" on one page and "physical" on another.

Draft rule D3. Textures stay four and stay timing-and-evidence only. Everything else about a connection is carried by attributes on the relation, validated against the world's profile (§D6). A connection is therefore a named relation with attributes, of which the texture selects only the settlement discipline.

§D4Walls are where the model of computation changesdraft

§D2 ended with a problem: acausal connections need a solver, not a settle pass, and §8's period cycle is a settle pass. Introducing a solver into the period cycle would change the execution model of every world, including the ones that do not want it.

Ptolemy II [P] answers exactly this question. In Ptolemy a director implements a model of computation, and an opaque composite actor carries its own local director which need not match the director of the model containing it. Hierarchy is therefore the mechanism by which one model can contain a differently-scheduled model — discrete event outside, continuous time inside — without either one contaminating the other.

Draft rule D4. WRL already has that construct, and it is the wall (§10). A wall may enclose a sub-world evaluated under a different profile, and the wall is the only place where the model of computation may change. Within a wall, one discipline; across a wall, a declared boundary with declared effects.

Consequence for §10. The boundary-safety law ("undeclared effects cannot cross walls", §12) becomes strictly more load-bearing: it is what stops a solver inside a wall from writing cells outside it. If walls are to carry profiles, boundary safety has to be enforced per profile pair, not globally — an open problem, not a solved one.

§D5Derives seal the answer, not the searchdraft

A topology language that describes a road network will be asked to route vehicles on it, and routing is an optimisation problem. WRL should not contain an optimiser. §13 already lists derives as Proposed; §D5 constrains what a derive is allowed to promise when it wraps one.

The two obvious external engines behave differently, and the difference is the rule:

Draft rule D5. A derive over an external engine seals its inputs, its solver profile, and its result. It does not seal the search. The sealed result must be accompanied by a deterministic checker that re-validates it against the world it came from. The solver is an untrusted oracle; the checker is the trusted part, and only the checker's verdict enters the artifact.

This is why the rule is stated here rather than left to the derive design: it determines what a derive is. A derive whose output cannot be checked more cheaply than it was produced is not admissible under D5, and several optimisation problems have no such checker. Those problems stay outside the language.

§D6Profiles carry domains, not construct kindsdraft

Every world already opens with a profile line (§4), and today exactly one profile exists. The draft's answer to "how does WRL model drones, or circuits, or supply chains" is: a profile, and nothing else.

A profile fixes the vocabulary that the frozen kinds are instantiated with: which roles exist, which relation names are legal, which attributes each relation carries and what they mean, which resolution rules are available, and which model of computation applies inside a wall that declares it. §D6.1 narrows the third of those from functions to finite tables, for a reason that turns out to matter to the whole promotion order.

The sketch below is what a mobility profile might look like. It is not valid WRL, and the conformance suite asserts that it is rejected:

profile wrl.mobility.v1

; one identity, present in five layers by construction (D1)
[drone:d7](battery=82, payload=4){pose, telemetry, command}
[segment:a12](capacity=3){occupancy}
[station:west](range=900){uplink}
[cell:c3](watts=400){supply}
[policy:safety](mode=halt){fault_in}

; road layer  — attributed relation, not a new texture (D3)
[d7] --occupies(cost=1)--> [a12]
; comms layer — asynchronous, does not settle this period
[d7] ~~telemetry~~> [west]
; energy layer — acausal: no writer, flows sum to zero (D2)
[c3] --power--> [d7]
; fault layer  — requires a supervision floor first (§16 step 6)
[d7] !!fault!!> [safety]

Every line of that sketch is currently a diagnostic. The profile name is unknown, the five roles are unknown, ~~ and !! are unpromoted, and relation attributes have no grammar. Reading it as a promise would be a mistake; reading it as a specification of what §16 has to deliver, in order, is the intent.

The profile mechanism cannot wait for expressions

The paragraph above lists what a profile declares, and one item in it is a problem: which resolution functions are available. A function needs a notation to be written in, and the expression notation is ladder step 5, while the profile mechanism is step 3. Stated plainly, that is a cycle in a document whose central claim is that its promotion order is a dependency order. Either step 3 secretly needs step 5 — in which case the ladder is wrong — or step 3 needs less than it says.

Why a table is enough, and not a compromise

The instinct is that a table is the weak version of a function, accepted because the strong version is not ready. For the case that actually motivates resolution, it is the other way round. VHDL's [V] std_logic resolution — the canonical example, and the one §D8's sketch is written against — resolves a nine-valued enumerated type, and its resolution is a 9 × 9 table. Hardware engineers did not settle on a table because they lacked a language to write a function in. They settled on it because for a finite type it is the complete, inspectable, obviously-terminating specification, and a function would be a less direct way of denoting the same object.

The last row of that table is the argument in one line: a resolution rule over a finite type has to be exhaustively checkable, and exhaustive checking over an enumeration is counting. Expressions do not make this easier; they make it a proof obligation instead of a loop.

What the kernel cannot do, said before someone finds out

A restriction that is only advertised by its benefits is a sales pitch. The kernel genuinely cannot express:

• Resolution over an unbounded type. Summing currents on a real-valued acausal net is not a table. That is correctly outside the kernel and lands with the solver wall (§D4), which is ladder step 9 — a solver was always going to be needed there, and routing it through a user-written resolution function would have put a numeric method inside a profile where §D4 cannot see it.
• Derived or computed attributes — cost = length ÷ speed. These wait for expressions at step 5, and until then an attribute is declared and supplied, never computed.
• Conditional constraints — "capacity must exceed 2 when the segment is bidirectional". The built-in validators are unconditional. A profile needing more says so and waits.

Each of those arrives as a strictly additive extension once expressions exist, because the kernel's obligations are the ones an extension must preserve rather than assumptions it may violate: a computed attribute still has to canonicalise, a conditional constraint still has to be total, and a real-valued resolution still has to be replayable. Building the declarative floor first is what makes those requirements explicit before there is a notation tempting enough to skip them.

§D7Falsification conditionsdraft

A design draft that cannot be wrong is not a design draft. Part II is abandoned or substantially rewritten if any of the following turns out to be true:

Conditions 1 and 2 are the load-bearing ones. Both are answerable by building the mobility profile for real, which is why the first genuine test of Part II is a single fleet described across road, communications, dispatch, energy and fault layers, run on TRVM, with routing supplied by an external solver and checked on the way back in.

§D8Relation, not Edgedraft

Sections §D2 and §D3 have been quietly accumulating a debt, and this section pays it. The authored design draft (draft §19) closes the runtime ontology at exactly six entity types — Actor, Value, Edge, Boundary, Fragment, Stencil — and gives the third of them this shape:

Edge { source, destination, label, texture, payload, policy, provenance }

That is a binary directed pair. Every proposal in Part II so far needs something it cannot hold:

The three ways out, and the one taken

Draft rule D8. The runtime ontology keeps six entity types. The third is renamed and broadened:

RelationAllocation                             ; a tagged union — §D8.1 defines it

RelationRevision   { domain, kind, endpoints, orientation,
                     texture?, attributes, policy }

Endpoint { terminal, role }

An allocation names the relation; a revision is its value. The split is the subject of §D8 identity below, and the revision is what replaces the old Edge. There is no stored record joining the two: the current revision of a relation is derived from the ledger, for the same reason cardinality is derived from the endpoints. texture is written texture? because it is genuinely optional — the table's own row says it is absent for an acausal relation, and a record that prints a field it does not always carry is a record that will be implemented wrongly.

payload leaves the relation deliberately. What crossed a connection during a period is an event, and events already live in the event ledger and the film (§10). A relation is the standing fact that a crossing is possible; the payload is the record that one happened. Merging the two is what made Edge simultaneously a topology object and a message envelope.

Two fields, because a name is not a namespace

An earlier draft of this section carried domain alone and let it absorb the old label. That was wrong, and the sketch below shows why in its own syntax: a relation written --drive(domain=digital)--> is carrying two ideas, not one. digital is the namespace that says which profile validates the attributes and what the units mean; drive is the predicate that says what this particular relation asserts. A road relation needs both in the same way — domain=mobility, kind=occupies — and they are not interchangeable. Collapsing them means capacity on a road and capacity on a bus are the same word validated by nothing.

The surface spelling follows the split: a qualified relation is --digital.drive-->, and today's --sig--> is the unqualified form, resolved against the profile's default domain to signal.SignalWire. That is how the frozen syntax survives the generalisation unchanged.

Endpoints carry roles, because a hyperedge without them is ambiguous

A set of participants plus a 2:3 label does not say which two of the five are the two. This is a solved problem: a directed hyperedge in the standard formulation [H] is an ordered pair of disjoint vertex sets — a tail and a head — and the role-aware line of work on n-ary knowledge representation exists precisely because extending binary methods to n-ary relations without recording each entity's role loses information that cannot be recovered. So the role goes on the endpoint, where it is unambiguous, rather than being inferred from a position in a list.

Four roles, and two that were considered and left out. There is no driver role: a driver is a source whose target terminal happens to declare a resolution function, and giving it a role of its own would let the relation and the terminal disagree about whether resolution is in force. There is no resolved role or orientation either, for the same reason and with a precedent behind it — VHDL declares resolution on the resolved subtype of the signal, never on the drivers [V]. Resolution is a property of the terminal being written to. Exactly one object owns that rule.

Endpoint order is presentation, not meaning

endpoints is a set, and this is load-bearing rather than pedantic. The acausal connection in the sketch below joins n1.pin, vcc.pin and r1.pin. There are six ways to write those three terminals down and they are the same circuit. If endpoint order were semantic, two authors describing one physical net would seal two different sem- ids, and the identity would be measuring typing habits instead of topology.

So canonicalisation sorts endpoints by role, then terminal, with roles in the declared enumeration order above. This is the same discipline §11 already applies to sorted-key JSON and to omitted empty port groups — the canonical form decides an order so that the author does not have to have one.

For that sort key to be total, terminals have to be unique within a relation. An earlier draft said "at most once per role", which is the weaker rule and lets a contradiction through:

The hypergraph precedent [H] settles it: a hyperarc is an ordered pair of disjoint vertex sets. Tail and head do not overlap, so the rule is:

This does not outlaw an identity relating to itself, which is an ordinary thing an actor does. A self-loop uses different terminals on the same object — a.out as source and a.in as target — and remains legal, because those are two terminals. What is now impossible is one terminal holding two contradictory positions in a single relation. If a profile has a genuine use for a reflexive terminal, it should declare that as an explicit feature with its own meaning, rather than receive it as an accident of a rule about uniqueness.

The canonical form is a rule, because prose was not enoughdraft · added after a review found the implementation disagreeing with this section

Everything above this heading was stated as prose and tables, and an implementation read it and got the central record backwards. The relation identity kernel shipped endpoints spelled { terminal: "p0", role: "sig_out" } — the object in the terminal slot and the port name in the role slot. It round-tripped every V1 edge exactly, it passed every check on the page, and it had implemented none of this section: no source, no target, endpoint order still semantic, terminals not unique, and an undirected orientation appearing in no table here.

What makes that worth a numbered rule rather than a bug fix is why nothing caught it. The pending register holds model-layer debt at zero, and it was at zero and green the whole time — because a ratchet enforces zero debt among the properties it knows about, and none of these were registered. The obligations below are the missing rows. They restate what the paragraphs above already say, in the form the rest of this page requires of a claim: something a check can falsify.

That second texture rule was, for one version of this section, deliberately not in the list — filed instead as a V2 obligation on the argument that a frozen artifact's edge records no texture field, so inferring one from -- being the only texture V1 lowers would invent a value the artifact does not carry. The argument was careful and it was wrong, in a way worth leaving on the page: a V1 edge does not omit a texture, it elides one, because §5 gives V1 nothing else to mean. That is the same relationship the artifact has to orientation, which the adapter had been restoring throughout without anyone calling it authorship. What the mistake cost is the instructive part — a rule this page states was left with no implementation, so §D8's texture row shipped as one enforced half and one commented half, and a table with a commented row has stopped being a table. The adapter's field map records the correction at the point where it was actually made.

A relation needs a name that survives its value

Everything above describes what a relation is. It does not say how to refer to one, and until D9 that omission was invisible, because a fixed topology never needs to name a relation twice. The moment relations can be attached, revised and retired at runtime, the omission becomes the load-bearing defect in the pair of sections.

The tempting answer is the one the rest of this language already uses: address a relation by the hash of its content, as §11 addresses a world. Applied here it fails twice, and both failures are ordinary rather than exotic.

The second failure is the sharper one, because it is self-inflicted: nothing external went wrong, an authorised operation simply mutated the bytes being used as the identity. That is a category error, not a bug, and it has a standard resolution — separate the thing that persists from the thing that changes.

Where the name comes from, without a cycle

The first draft of this rule left the minting mechanism open and offered two options, one of which was "the creating event's canonical id". That option is not viable, and the reason is worth keeping rather than deleting, because it is a cycle that reads as a reasonable sentence:

relation_id      = H(attach_event)
attach_event_id  = H(operation, arguments…)     ; arguments include relation_id

Canonical event identity is a content address over the operation and its arguments (§D9), and the id being minted is one of those arguments. Neither hash can be computed first. An identity scheme needs an allocation source that is prior to the event, not derived from it:

RelationAllocation =
    InitialRelationAllocation                            ; present at period 0
  | GrantedAllocation { grant_id, local_counter }        ; attached at runtime

InitialRelationAllocation =
    NamedInitialAllocation { world_id, relation_name }   ; IR 2.0, authored
  | LegacyEdgeAllocation  { world_id, kind, src, dst }   ; V1, from the seal

relation_id = H("WRL_RELATION" ‖ "named-initial" ‖ world_id ‖ relation_name)
relation_id = H("WRL_RELATION" ‖ "legacy-edge" ‖ world_id ‖ kind ‖ src ‖ dst)
relation_id = H("WRL_RELATION" ‖ "granted" ‖ grant_id ‖ local_counter)

The cycle is broken because relation_id is a function of the allocation, and the allocation is an ordinary argument of the event. The event id may still be taken over all its arguments with no exception carved out, and the derived id adds no information to that preimage because it is recoverable from one of them. The alternative — defining the event id over a preimage that deliberately excludes the derived relation_id — is also sound, but it makes the sentence "event identity hashes the operation and its arguments" false, and a rule with one silent exception is a rule that will acquire a second.

An allocation that exists before the world runs and one that is handed out while it runs do not arrive by the same route, so they are not the same event:

InitialRelationDeclared   carries an InitialRelationAllocation   ; sealed, period 0
RelationAttached          carries a  GrantedAllocation           ; proposed, at runtime

; both are declared once, in §D8.3's ledger below

A monotonic counter is not an allocation source

The first version of the runtime row said "a claimant-owned monotonic sequence — uniqueness is then local and needs no coordination". That is the standard move, and it is wrong here for the standard reason: a counter is unique per owner, and a claimant identity does not name an owner, it names a role that a failure can leave two processes playing at once.

claimant C, counter at 42, durably recorded
partition; C is restored from that record on two hosts

host A allocates (world, C, 43)  → relation_id X   ; a power line
host B allocates (world, C, 43)  → relation_id X   ; a different power line

Two distinct relations, one id. This is not an exotic failure — it is stale restoration, which is an ordinary consequence of the partitions §D9 is explicitly written to survive, and it destroys the exact property D8.1 exists to provide. The counter must be scoped by something that cannot be duplicated by restoring a snapshot.

AllocationGrant { world_id, allocator_incarnation, namespace_prefix,
                  counter_range, validity, granting_policy_id }

grant_id = H(canonical AllocationGrant)

GrantIssued { grant_id, provenance, offered_evidence }      ; the ledger event

GrantedAllocation { grant_id, local_counter }               ; local_counter ∈ counter_range

Every field left in the grant affects what future allocations are legal — which is §D8.3's own test for what belongs in a value rather than on an event. counter_range is spelled out rather than left as valid_range beside a validity field, because two fields whose names are near-synonyms for different things is how a reader ends up checking the wrong one. granting_policy_id stays in the value for the reason D8.3 gives about semantics wearing a provenance label: the governing policy is not a record of how the grant was obtained, it is a constraint on what the grant permits.

The earlier statement of this rule said the range is valid "within a namespace no two live allocators can hold at once". That named a guarantee and established nothing: mutual exclusion between live processes is precisely what a partition removes, so the rule was asking the failure to solve itself. The version above is narrower on purpose, and separating the four concerns that were bundled into that one sentence shows why the narrow one is enough:

The second and fourth rows together are the reason the record is a grant and not a lease. The five questions any expiring lease has to answer — whose clock; what becomes of work in flight at expiry; is a renewal the same lease or a new one; how is a holder that missed its revocation fenced; what if the fence message is lost — mostly do not arise here. Expiry stops new draws and touches nothing already drawn, so in-flight work needs no rule. A renewal is a different value and therefore a different grant_id, so "same or new" is answered by construction. There is no fence because a stale holder cannot collide with anyone. The only question that survives is the first, and it survives in weakened form: a disagreement about the clock can cause a draw to be refused or wrongly admitted, which is an availability and policy matter, and cannot make two relations share a name.

validity is therefore owed a basis, and it is owed one before grants can be implemented rather than after. The rule stands unamended: expiry still carries no safety weight, and none of these bases changes D8.4-a. What they change is whether a replayer can reach the same verdict about a draw as the original run — and a rule whose admissibility test is unreplayable is one that will be enforced differently on every host without any of them looking wrong. The register carries this as its own property, separately from the rule, because it is a debt against the field rather than a doubt about the law.

Three fixes come with the content address, and the third is the one that was actually missing. grant_id is now named by the allocation. The earlier { world_id, issuer, nonce } form obliged a validator to infer which grant authorised a given allocation by scanning history — which is unambiguous only until an issuer holds two ranges, or a renewal overlaps its predecessor, or a grant is replayed. An allocation now says which grant it came from, and checking it is a lookup rather than a search. world_id can leave the relation preimage for the same reason: it is inside grant_id already, so §D8.5's world-scoping survives without the field being written twice.

This has a consequence worth stating plainly rather than discovering later: under D8.4, attaching a relation during a partition requires a grant obtained before it. That is a real restriction, and it is the honest one — the alternative is not "attach freely", it is "attach freely and discover the collision at merge", which the escrow discussion in §D9 already rejects for bounded resources for the same reason.

What "deterministic" has to mean here

An earlier version of this rule said a nonce "must not be random", which is too strong and misstates the requirement. Draft §21 already specifies /entropy as seeded streams whose seeds are recorded, so a random value drawn through that boundary is replayable. The prohibition is narrower and different:

Recorded entropy passes that law and is still a poor choice, for a reason that has nothing to do with replay: an unpredictable nonce cannot be recomputed by the proposer, so a retried proposal allocates a second relation instead of being recognised as the same one. What an allocation source actually needs is stronger than replayability: the proposer must be able to reproduce the same nonce for a retry of the same proposal, so that proposing twice is idempotent rather than doubling. A grant-scoped counter satisfies that by being held with the pending proposal until it settles; a fresh entropy draw per attempt does not. That is the real argument for the counter, and it is not the argument the first version gave.

"Until it settles" leaves the wrong question open

The sentence above says the counter is held with the pending proposal until it settles. It does not say what happens after it settles the wrong way, and the omission is not cosmetic — the obvious reading is that a rejected allocation returns to the pool, because it was never used for anything. That reading destroys D8.1:

allocation A42 appears in a proposal to attach cable X   → rejected
A42 returns to the pool
allocation A42 appears in a proposal to attach cable Y   → accepted

relation_id(A42) is one stable identity naming two unrelated intents,
and the film contains both

Nothing detects this. Both proposals are individually well formed, the second one is accepted by a rule that has no memory of the first, and a replay reconstructs a world in which one name meant a cable that was refused and later meant a different cable that was not. The refusal is recorded — that is what §D9.1 closure guarantees — so the collision is visible to anyone reading the whole ledger and invisible to every rule that reads a period.

As first written, D8.6 was one sentence doing two jobs of very different standing. One of them a replayer can check from the film. The other one nothing outside the proposer can ever see. Leaving them fused made the whole rule read as unverifiable, which is worse than either half deserves:

AllocationReserved { grant_id, local_counter, birth_key }

; durable, proposer-side, written BEFORE emit — and written ONCE,
; because drawing the counter and binding it are the same fact

D8.6-b being unverifiable is not a weakness in it, because it is not a safety property of the world. D8.6-a is that, and D8.6-a holds whatever proposers do. D8.6-b is a recovery property of a single participant: written the other way round — emit, then record — a crash in the gap leaves an allocation that is live in everyone else's ledger and free in the proposer's own, so the proposer's next honest act re-issues it and manufactures the collision D8.6-a will correctly diagnose and cannot undo. The obligation exists to stop a well-behaved participant from becoming a source of true diagnostics.

An implementation that wants the obligation checked anyway can buy it, and the price should be on the page rather than discovered. The two profiles differ only in what counts as the first observation in D8.6-a; both satisfy it unchanged:

This is not a new mechanism invented for relations. It is the mechanism every other entity in the ontology already has, and writing the four out together shows that the third one was the anomaly:

The world row is the argument in miniature. §D9's central move is that the world identity does not move when the world's structure changes, because identity and configuration are different things. D8.1 applies the same reasoning one level down. A rule that is right for the whole is not obviously wrong for a part.

What the ledger facts have to carry

Three of §D9's eight operations act on a relation, and each becomes expressible only once both ids exist:

RelationAttached { allocation, revision_id,  provenance, offered_evidence }
RelationRevised  { relation_id, expected_prior_revision, next_revision,
                                             provenance, offered_evidence }
RelationRetired  { relation_id, expected_prior_revision,
                                             provenance, offered_evidence }

The allocation on RelationAttached is a GrantedAllocation and nothing else. Relations that were already there when the world was sealed have their own fact, which is not an operation at all:

InitialRelationDeclared { allocation, revision_id }

It has no provenance and no offered_evidence because there was no proposer: the seal is the whole story of how it came to be, and a sem- id already records that story exactly. It is not one of the eight operations, it does not need a grant, and it cannot be refused — by the time any period runs it is already true. What it shares with the three above is the shape of its name: an allocation, and the revision that allocation was born holding.

The last two fields on the operations are §D8.3: provenance records how the operation came to be proposed, and offered_evidence is what the proposer put forward to justify it. Both are arguments of the operation and are therefore covered by the event id. What the checker concluded is not here; it is in the acceptance receipt.

Each still obeys §D9's eight obligations unchanged, and two of them get sharper rather than harder. Canonical event identity is a content address over the operation and its arguments — which now includes a stable relation_id (via its allocation), so two hosts proposing the same revision agree on the event id without having to agree on hashing the attributes first. Conflict rules become statable: two RelationRevised facts in one period naming the same relation_id with different expected_prior_revisions is a detectable conflict, not a race that the smaller hash wins. Without a stable id there is no way to notice that the two facts are about the same relation at all.

One fact, one home — including this one

The first version of this rule wrote history down in three places, and the mistake is instructive because each one looked individually justified: a current_revision field on an instance record (so the active value is cheap to read), a predecessor? field on the revision (so the chain survives a ledger read out of order), and the prior → next pair on the ledger fact (so revision is an edit rather than a coincidence). Three homes for one fact means they can disagree, and nothing said which one wins:

current_revision  = R3
R3.predecessor    = R1
RelationRevised { prior = R2, next = R3 }        ; which of these is true?

This is the defect §D8 rejects one section later for cardinality, committed in the section that rejects it. The rule is the same in both places, so the resolution is the same:

Renaming prior_revision_id to expected_prior_revision is part of the same correction rather than cosmetic. The field is not a record of history — the ledger already is that. It is a precondition: the operation asserts what it believed the current value to be, and is rejected if the fold disagrees. That is what makes two concurrent revisions a detectable conflict instead of a last-writer-wins race, and naming it prior invited exactly the redundant back-pointer that produced the three homes.

Dropping predecessor? buys something beyond tidiness, and it is a property this language should want:

…and provenance was still in the preimage

The paragraph above is true and the record it described was not. The field list inherited from Edge ended in provenance, and provenance is how a value was produced — the same information predecessor? carried, arriving through the door left open by "unchanged" in the migration table. A capacity reduced from 3 and a capacity raised to 1 would still have hashed differently, for a different reason, one line further down the same record. Removing the back-pointer while leaving provenance in the preimage bought exactly nothing.

What makes this unambiguous rather than a matter of taste is that the rule is already written down, and already executable, elsewhere in this toolchain. wrl.js says it of the rounding policy on a named rotor:

/** The build-provenance policy governing a named rotor, or null when exact.
 *  The policy id is provenance only -- it never enters the artifact bytes. */

Two identical rotors seal identically whether one was written exactly and the other rounded under a named policy; the policy id is reported and not hashed. That is the shipped behaviour of the frozen spine, verified by the battery, and §D8's record contradicted it.

The two evidence rows are one distinction, not a hedge, and getting them the wrong way round rebuilds the defect this section exists to remove. Evidence supplied with a proposal is an argument of the operation: it must be inside the event preimage, or the event id fails to cover something the proposer asserted. Evidence produced while deciding belongs to the decision, and §8 already has a home for it — the immutable acceptance receipt, kept deliberately separate from the monotone fact set. Putting checker evidence on the event would be a back-pointer from a proposal to a decision that had not been made when the proposal was hashed.

How far the name reaches

D8.1 says relation_id survives its value. It does not say for how long, and the two allocation preimages answer that question whether or not anyone asks it.

The two are equally scoped and not equally robust, which is worth saying rather than smoothing over. The authored form is world-scoped by inspection of a single hash. The granted form is world-scoped only for as long as world_id remains inside AllocationGrant; remove it there as an apparent tidy-up and every granted relation silently becomes global, with no equation on this page changing. That is a load-bearing field wearing the clothes of bookkeeping, and §D8.4 is where it lives.

world_id is in the preimage on purpose — it is what makes two independently authored worlds unable to mint the same relation id by accident, and what lets a validator check an id against a sealed artifact rather than against a global service. The consequence is that relation identity is world-scoped, and the precise scope is worth stating because two different things are both loosely called "changing the world":

So the scope is exactly one sealed world version, and the boundary that moves it is re-sealing, not running. A relation attached in period 4000 and revised in period 900 000 keeps its name the entire time; the same relation after a redeploy is, absent a migration, a different relation with the same meaning.

Before treating that as a defect, it is worth noticing that it is the existing property of every other name in the language, not a new one that relations introduce. Object ids are already world-scoped in the shipped implementation: the canonical bytes reference an object as a bare name —

"edges": [{"dst": "r0", "kind": "SignalWire", "src": "p0"}]

— and r0 means something only inside the artifact that declares it. Two worlds can both contain an r0 and they are unrelated. Scoping relations the same way is consistency; scoping them globally would make the relation the only entity in the ontology whose identity outlives the world it lives in, and that is the choice that would need an argument.

Stating it now is the point. This is exactly the kind of consequence that is cheap to write down while it is a design and expensive to discover during the first upgrade of a running system, when the discovery arrives as an external ledger whose references have quietly stopped resolving. It is filed against the migration capability at ladder step 9, which is where it will be answered.

The checker the rule asks for is no longer hypothetical, and the reason is that the rule tests itself. Re-sealing is what moves a relation id, and re-sealing needs no new artifact version — so a world re-authored today already produces the break, and the map that is owed can be computed and checked against two V1 worlds. §D8.8 gives the record it produces; three rows of the register run against it, including the one that matters most here, which is that a relation with no counterpart is reported unpaired rather than handed one. Silence is not continuity is a sentence until something fails when it is violated.

There is a second policy, and it is not obviously wrong — it is just a different trade, so it should be recorded as one rather than ruled out:

The domain-stable policy is admissible, but only under a condition this section already has a precedent for. The open-world admission table below seals the namespace rules in the artifact while letting the allocated name appear in the ledger — that is precisely the shape needed here. A registry outside the world may supply relation identity if the artifact seals, by content address, the rules that govern it, so that a replaying host checks the registry's allocation rather than trusting it. A registry that is merely named and believed reintroduces the property D8.4 was written to remove: an id whose uniqueness depends on something no replay can verify.

What it costs the frozen artifact

Nothing today, and the reason is worth stating precisely rather than assumed. The legacy projection above emits {"kind": K, "src": S, "dst": D} and carries no relation id. That remains correct for the frozen corpus, but only because of a property the corpus happens to have:

The uniqueness precondition above is doing double duty, which is the reason to notice it: it is also the period-0 nonce rule. A world whose relations are distinguished by (kind, src, dst) can both be encoded in the V1 artifact family and have its relation ids minted without any new authored syntax, and a world that needs parallel relations fails both at once. That is one condition to check and one condition to explain, rather than two that happen to coincide until they do not.

Cardinality is derived, and therefore never stored

A stored cardinality field can disagree with the endpoints it describes: a record may claim 1:n while holding two sources. That is a second source of truth, and a validator that has to reconcile two sources of truth for one fact will eventually pick the wrong one. Cardinality is computed during validation and canonicalisation:

cardinality(R) = |{e ∈ R.endpoints : e.role = source}|
               : |{e ∈ R.endpoints : e.role = target}|     for directed
               = n-ary                                     otherwise

It is a derived view for diagnostics and profile constraints ("a mobility.occupies relation is 1:1"), never a field, and so never serialised and never part of the hash. This is the same judgement that removed payload: one fact, one home.

Today's route is a specialisation, exactly

The frozen directed route of §0 and §5 is recovered by fixing five of the eight fields:

Elision is necessary and not sufficient

An earlier version of the note above claimed that eliding defaulted fields was enough to preserve every published id. That is wrong, and the gap is not a detail. Here is what a route serialises to today, from the starter world's own canonical bytes:

"edges": [{"dst": "r0", "kind": "SignalWire", "src": "p0"}]

Now remove every defaulted field from the general record — domain, orientation, default texture, empty attributes, policy, and the derived cardinality that was never a field. Three differences survive elision, because none of them is a field that could be elided:

So the compatibility mechanism is not elision but a legacy projection: a normative rule that a relation meeting the frozen profile's exact shape is encoded in the old form. Stated so it can be implemented and tested:

This is a testable claim rather than a promise, and it should be tested before D8 is called structurally closed. The golden test is a round trip with byte equality at the end:

frozen Edge      → canonical bytes  ─┐
                                     ├─ MUST be byte-identical
equivalent Relation → projection ────┘

and every published sem- id, re-sealed, is unchanged

Until that test exists and passes over the full pinned corpus, the correct status for exact compatibility is argued, not demonstrated — which is what falsification condition 4 already says, and this section narrows it from "can defaults be elided" to the sharper question of whether the projection above is total over the frozen corpus.

Why this shape and not another

What it would look like

Not valid WRL. The conformance suite asserts the toolchain does not accept it, and records which capabilities it waits on:

profile wrl.electrical.v1

; the RESOLUTION is declared on the terminal, not on the
; relations that reach it — one object owns the rule (VHDL)
[bus:b0](width=8){drive: resolved(std_logic)}
[driver:u1](enable=true){out}
[driver:u2](enable=false){out}

; two directed relations into ONE resolved terminal.
; domain.kind, not a bare label: `digital` says which profile
; validates it, `drive` says what it asserts.
; under §0 this is a multiple-writer error; under D8 it is
; legal precisely because b0.drive declares a resolution.
[u1] --digital.drive--> [b0]
[u2] --digital.drive--> [b0]

; an acausal relation: three endpoints, all role=terminal,
; no orientation and no texture. potentials equal, flows sum
; to zero (D2). the three may be written in any order —
; endpoints are a SET, so all six spellings seal the same id.
[node:n1]{pin}
[rail:vcc](volts=3.3){pin}
[load:r1](ohms=470){pin}
relation electrical.node acausal {n1.pin, vcc.pin, r1.pin}

The part of this that already runsdraft design · running implementation

Everything above is design. This subsection is not: it records what a working implementation established, and it is here because four rows of the register below stopped saying awaiting because of it. Twelve more rows arrived later, when D8.7 found that this same implementation had round-tripped every V1 edge while implementing almost none of the endpoint model above. Four more arrived after that, when the migration statement in §D8.8 turned out not to need the artifact version it had been filed behind.

The obstacle was that §D8.1 mints a relation's identity from an authored name, and V1 has no way to write one. A frozen artifact's edge is exactly {kind, src, dst}. So an implementation that invented names would have two sources sealing to the same sem- id while producing different relation_ids — and a sealed world that does not determine its own future semantics is the one thing sem- exists to prevent. The resolution is not to wait for a surface. It is LegacyEdgeAllocation: for a world sealed under the V1 artifact family, a relation's name is its frozen edge key, and nothing about that requires new syntax.

The implementation lives in relation-identity.js, which imports wrl.js. The direction is the guarantee, not a convention: the spine has no way to reach the derived view, so no rel- or rev- value can enter a sem- preimage by accident. The suite checks that both pinned fixtures seal byte-identically through the kernel and through sealWorld, because a marker reading non-canonical is a claim and byte equality is a fact.

It also has a consumer. The playground seals with the frozen spine and then derives from the artifact that seal produced, printing each relation's ids and its endpoints by role. That is deliberate on both sides: a derivation nothing renders is one nobody finds out is wrong, and a page that adopted the derived verdict along with the view would have quietly changed V1's frozen error surface for every visitor. The suite requires the page to import the derivation and requires it not to import the verdict — §D8.8.

What the kernel refuses to take on trust

A world-scoped identity is only as scoped as the world id it is scoped to, and the first version of this kernel accepted that id as an argument. Callers passed the one sealWorld had just returned, so it was always right, and it was checked by nothing: an artifact handed over with sem-000…0 beside it minted a full set of relation ids under that name. That is not a bug in a caller. A value whose meaning depends on an unverified claim travelling next to it has no meaning, and the failure mode is silent — every id well-formed, every round trip green, the whole set scoped to a world that does not exist. The kernel now recomputes the id from the artifact's own canonical bytes and treats any supplied sem- as a cross-check to be refused on mismatch. The recomputed path is the only path; there is no faster one to fall back to.

Two smaller refusals follow the same shape, and it is the shape rather than the three instances that matters — a rule the code states and the code can be talked out of.

• The artifact's version is checked before its edges are read. The adapter's constants — directed, solid, signal, the frozen port pairs — are V1's elisions. Applied to an artifact of some later version whose elisions differ, they would not fail; they would produce confident, wrong relations. So an ir_version outside the declared set is refused rather than assumed compatible.
• The declared vocabularies are deep-frozen. The role enumeration is not merely a list, it is the sort key of the canonical form, and the orientation-to-role table is the legality rule. Exported as ordinary arrays, an importer could reverse the first and widen the second, and canonicalisation would obligingly produce a different id for the same relation. A closed enumeration a consumer can reopen is an open enumeration with a comment attached.

Two of seven fields are the name

The interesting result was not planned. §D8.1 says a relation's identity survives its revision changing; tested by mutating one field and observing stability, that is nearly vacuous, since the id is minted from an allocation that need never have touched a revision at all. So the test routes the revision through the V1 projection — the only path by which revision content can reach a V1 identity — mutates every field in turn, and classifies what happened. The result has to be a total partition of the field set: a subset check is how an eighth field that quietly names a relation would get in.

The third row is the one worth reading twice, and its name was chosen after a wrong one. It read no V1 form, which invites the reading that V1 is silent about those four fields. V1 is not silent about them. It says exactly one thing about each, and this contract restores all four on import:

What V1 lacks is not a meaning for these fields but an independently writable representation for any alternative value — they are resolved constants, fixed by the encoding rather than elided from it. So the count still stands, and it is still the price of §D8 stated numerically: four of the seven fields a relation revision carries are pinned by the frozen artifact rather than authored in it, which is why §D8's richer relation is not today's edge plus some unwritten extras. It is a record most of whose interesting content is inexpressible until the artifact version moves. §D8's cost note argued that qualitatively. This is the count.

domain moved into that row, and how it moved is worth recording, because it is the clearest case of why V1-fixed is a different classification from free. It was filed free on the reading that a V1 edge does not write a domain, so changing one could not disturb the id — which is true, and irrelevant: projectability is a question about representability, not only about identity. A V1 edge does not write a domain because it is entirely a signal-domain encoding: its two kinds are the two kinds of that one domain. An electrical relation is therefore not a relation whose domain V1 forgets to mention; it is a relation V1 cannot represent, exactly like an acausal one. The field was classified by what the encoding omits rather than by what the encoding means, and those come apart precisely on the elided fields — which is the same confusion, in the same table, that put texture in the wrong row.

A matched pair falls out of the same seam, and neither half means much alone. The same edge key in two different worlds yields two different relation_ids (§D8.5 — two worlds' relations are not the same relation), while the same relation structure in two different worlds yields the same revision_id (§D8.3 — which world described it is provenance, and provenance rides the event, not the value). Checked separately, either would pass on a build that had accidentally fed both hashes the same input, so they are asserted together on the same edge.

A miscount where there should be a name clash

Writing one relation twice is refused today, and refused for the wrong reason. The block below is a complete world, and its annotation records what the published spine currently says about it:

profile forge.world.core.v1

[pulser:p0](every 2){sig_out}
[relay:r0]{sig_in, sig_out}

; the same relation, written twice
[p0] --sig--> [r0]
[p0] --sig--> [r0]

r0 has 2 signal-wire inputs (a node admits one) is true of the lowered graph and useless to whoever wrote it. There is one input, written twice, and the author is now looking for a second wire that does not exist. Under §D8 the failure is sharper than a miscount: these are two relations whose only available name is the same name, so no later revision could say which one it meant. The kernel reports WRL_DUPLICATE_RELATION_KEY, and the ordering is the substance — the census runs before graphToIr, which is where the controller count lives. The suite asserts both answers, so if the spine ever adopts the better one this annotation goes red and this passage gets corrected rather than quietly outliving its subject.

What the V1 adapter is, permanentlydraft

The kernel above is finished, and it is not the destination. §D8's relation is a record with named instances, general arity, attributes, textures and three orientations, and none of that can live in a V1 artifact. Reaching it takes a new artifact version, and that is the next milestone rather than this one.

So what happens to the kernel? It becomes the import adapter — the one supported path by which a world already sealed acquires relation identity. That is a permanent job, not a scaffold, because worlds sealed under the V1 artifact family keep their sem- ids forever and must remain readable by relation-aware tooling that arrives afterwards. Writing the contract down now, before the richer artifact exists, is what stops the adapter from drifting into a second general relation format: every convenience added to it would be a feature V2 then has to keep bug-compatible.

Where each field comes from

The third column is the whole reason to write the second one down. Every supplied row is a place where V2's importer has to know that the value came from the adapter and not from an author. And two of these rows are here because the first version of this table got them wrong in opposite directions.

domain read artifact.profile_id, which put forge.world.core.v1 in the slot §D8's field table reserves for a profile-declared namespace. A profile declares domains; it is not one. The adapter was reading the nearest available string rather than resolving the value the section describes, and because nothing in V1 round-trips a domain, no test noticed. The correction is a declared map from profile to default domain — which for the one frozen profile is signal, the same value the recovery table below already stated, and which the adapter had been contradicting in the same file.

texture was filed absent — no key at all — with the argument that a missing texture and a texture: null are different claims, and that no V1 world ever considered texture. That argument is sound and was applied to the wrong question. It answers may the adapter invent a value?, when the question is what does this encoding mean? — and a V1 structural edge means -- solid, because §5 gives V1 no other texture to write. Restoring solid is therefore expansion of an elision, exactly like restoring directed, which the adapter had been doing all along without anyone calling it authorship. An encoding elides a value when the value is implied; the two cases are told apart by whether the omitted value is determined, not by whether the bytes contain it.

Filing it absent had a cost beyond the field itself, and this is the part worth carrying forward. It made texture required for directed — a rule §D8.7 states — unenforceable, since the kernel's own relations violated it. So the rule was deferred to V2, and §D8's texture row went into the implementation as one enforced half and one commented half. A table with a commented row is not a table. Both halves are now driven from a single declaration and both are checked, which is only possible because the adapter stopped treating a determined elision as an absence.

Migration is a correspondence, not preserved identity

V2 is an explicit semantic-ID version break: the artifact's canonical bytes change, so every world's sem- moves. And relation_id is minted from the world id (§D8.5) — so every relation id moves with it. There is a tempting fix, and it is wrong.

So a V1 relation and its V2 import are two relations, and saying so is correct rather than unfortunate: they belong to two worlds, and §D8.5 already ruled what that means. What migration owes is not sameness but a correspondence — and, by §D8.2, it has exactly one home. The pairing is a ledger fact, of the same shape as every other lifecycle event:

RelationImported {
  from_world:    SemanticArtifactID   ; the v1 world
  from_relation: RelationID
  to_world:      SemanticArtifactID   ; its v2 import
  to_relation:   RelationID
}

Two properties make it a fact rather than a note. It is derivable: given both sealed artifacts and the mapping above, the pairing is computed, not authored, so it cannot be maintained wrongly by hand. And it is outside the value: neither relation's id, and neither world's sem-, changes because the import happened. A consumer that wants continuity reads the ledger, which is where continuity has lived since §D8.2.

So the two are separated, and the separation is what makes the fact checkable at all:

• The correspondence is structural and derived. It emits pairs — candidates — alongside dropped and added. It asserts nothing about intent, and it is total: a world with no relations mapped against itself reports identity-preserving with all three lists empty, which is the degenerate case a correspondence that fails by returning nothing would be indistinguishable from.
• The RelationImported fact is authored, emitted by an accepted migration operation, and therefore — uniquely on this page — a thing that can be maintained wrongly. Which is exactly why it is the one thing joined against something derived: a fact naming a pair the two sealed artifacts do not produce is refused.

That asymmetry is the general rule underneath the specific fix. Derived values do not need checking against their own inputs; asserted ones do. Merging the two loses the only join that could have caught a wrong assertion, and it loses it by making the assertion unfalsifiable rather than by making it false.

V2, where the fixed fields become writabledraft · new in 0.1.3

Everything above describes a relation model that V1 can be read as an instance of. The field partition ends by naming four fields V1-fixed — domain, orientation, texture, attributes — and the point of that name is that V1 says exactly one thing about each and has no way to say another. The adapter is not withholding an alternative; there is no alternative to write. Making one writable is a new encoding, and this section is its schema.

The shape of the change is smaller than the argument around it. A V1 world writes edges: [{ kind, src, dst }]. A V2 world writes relations, and each entry is { identity_seed, revision } — the canonical revision exactly as §D8.7 defines it, and the preimage its name is minted from, minus one field.

Why the stored preimage is a seed

§D8.1's preimages are all world-scoped: NamedInitialAllocation { world_id, relation_name }. So a V2 relation cannot store its allocation, because world_id is the hash of the bytes that relation is written in — a stored copy would be a value stating what its own container hashes to, before the container exists. Storing some other world's id is worse, because it type-checks: the world's relations would then be minted under a name a different world already owns.

What is stored is therefore the allocation minus its world coordinate, and derivation puts the coordinate back. That subtraction is the whole content of the word seed, and it is also the derivation order:

canonicalise  ->  world_id = hash(bytes)  ->  expand seed into an allocation
              ->  relation_id            ->  revision_id

Three ids are functions of these bytes and none of the three is in them. That is the same rule cardinality obeys, applied to identity rather than to structure, and it has the same justification: a stored copy of a derived value is a second source of truth for one hash, and the copy is the one a reader trusts.

A version is not a profile

The ruling that fixes ir_version at "2.0" says nothing about profile_id, and the tempting move is to mint forge.world.core.v2 alongside it. This encoding does not, because the two coordinates answer different questions: ir_version is how topology is written — edges or relations — and profile_id is what vocabulary it is written in: which domains exist, which kinds, which ports. Bumping them together would mean every new domain forces a new encoding version, and every encoding change invalidates every profile. So V2 is a new encoding over the same forge.world.core.v1 profile, and a wider profile — one declaring electrical, or an acausal kind — arrives later without touching the encoding.

The consequence worth stating is what V2 does not buy on its own. Moving the encoding makes the four V1-fixed fields representable; it does not make an electrical relation legal, because legality is the profile's answer and the profile has not moved. Those are two separate unlocks and this is the first of them.

That sentence was true and unenforced for one slice, which is the more interesting half of the story. The V2 gate checked the version tuple and the container shapes and then stopped, so domain: "banana", kind "WarpTunnel", a terminal naming an object that does not exist, a port called "made_up", two objects sharing an id and role "Alien" all sealed and got real sem- ids. A profile that is only said to govern does not govern. So §D8.14 makes the gate profile-aware, and it does so by deriving the V1 world the artifact describes and handing it to the frozen validator, rather than by restating a registry that could then drift from the one it copies.

What the V1 projection is, and is not, under V2

§D8.8's projection stays normative as the V1 compatibility adapter, and it has no authority over V2 canonical bytes: nothing it returns is hashed, and no V2 field is derived from it. It is called inside the V2 encoder, by §D8.14's world gate, and the distinction between those two sentences is the whole of what that gate is allowed to do — a validator may ask the V1 adapter whether a relation is one this profile defines; a canonicaliser may not ask it what the bytes are. The direction it does not run is the one worth being explicit about: an explicit V2 → V1 downgrade produces a new V1 artifact, with its own sem- id, which is not and never was the id of the V2 world it came from. Nothing here preserves a sem- across an encoding change, and §D8.5 already says why: a relation id is world-scoped, and a claim that two sealed worlds hold the same relation is a migration claim someone has to carry.

Deriving the three ids

The order above is not a style note, it is the dependency graph: each arrow is a value that cannot be computed before the one to its left exists. Both places this can go wrong are places where an implementation is tempted to skip an arrow, and both skips produce ids that look right. Deriving from an artifact that was never canonicalised gives two spellings of one world two sets of relations. Accepting a world_id from the caller instead of recomputing it gives a forged seal real-looking relations — V1 shipped exactly that bug, and worldIdOfArtifact was the repair.

Carrying a V1 world across

A migrated relation does not keep its id, and no amount of care can make it. The world id moved, the world id is in every allocation, so every rel- moves with it. What survives is the rev-, because a revision is standalone — so a relation's structure crosses intact and its name does not.

That is the whole reason the import mints a legacy-edge seed rather than a named-initial one. The tempting alternative is to name each migrated relation so the ids look stable; it does not make them stable, and it costs two things. It makes an import look like authorship, and it collides with the first author who later writes that name deliberately. legacy-edge instead records the true fact — this relation was never named — which keeps the two worlds indexable by the same key and so keeps the correspondence derivable rather than asserted.

Naming a relation

One spelling, and it is a per-route one:

[clock_feed]: [pulser:p0] --sig--> [relay:r0]

A V2 source is a V1 source whose route lines carry a name. That is the whole language change, and it is deliberately the whole language change: every other line — the profile header, declarations, comments, sugar — is handed to the frozen spine untouched, so the surface cannot quietly become a second parser that agrees with wrl.js today and drifts from it later. Names come off the front of their lines without changing the line count, the spine does all the parsing and all the validation, and the names go back on afterwards.

Writing a V2 world back out

A formatter's characteristic failure is not refusing — it is emitting text that its own parser reads back as something else. formatCore has that scar already: it once wrote a [mailbox:m] line that parseWrlCore then refused. The V2 formatter inherits both the lesson and the mechanism. It does not know the route grammar; it asks the frozen formatter for the V1 source, then finds the route lines the way the parser does, by following provenance back to the line each edge came from. Neither direction of the surface contains a copy of the arrow syntax.

The world gate: an invalid world mints no id

Since WRL-P0 the gate reads a profile row — the lowered row delegates to the frozen spine exactly as described below; a static row is checked against its own declaration. §D8.20 is the rule; this section is the lowered half of it.

For one slice the V2 encoder validated the encoding and never the world. It checked the version tuple, the container shapes, the relation record fields and the generic revision vocabulary — all of them questions about how bytes are arranged — and then sealed whatever came out. So every one of these got a well-formed sem-: an object with role "Alien", two objects sharing an id, a terminal naming an object called "ghost", a relation with domain: "banana", one with kind "WarpTunnel", a terminal on a port called "made_up", and two relations onto a controller input that admits one.

An id for an impossible world is worse than a refusal, because a refusal stops. An id exists: it is stable, it compares equal to itself, it can be cited, stored, and paired across a migration, and every consumer downstream treats it as evidence that something legal was sealed. The gate's absence was also invisible from the outside — the encoder did everything it said it did.

What the gate must not be is a second registry. A V2 validator with its own list of roles, ports, domains and kinds is a second opinion about what forge.world.core.v1 permits, free to drift from the profile it claims to enforce, and drifting silently, because nothing ever compares two registries that never meet. So the gate derives: it builds the V1 world the V2 artifact describes — objects as declarations, relations through §D8.8's projection — and hands it to the frozen validator. Every refusal therefore carries the spine's own code, and a profile that widens widens both encodings in the same commit.

Deriving the world also closed a bug of exactly the kind §D8.13 warns about, found only because the derivation made the two answers comparable: the V2 canonicaliser sorted objects by (role, object_id) where V1 sorts them identity-first by (object_id, role). Two total orders over the same set, no field rule able to see the difference, and a private copy of a sort key is exactly what the edge-order bug one slice earlier was. The canonical objects are now taken from the derivation rather than sorted again beside it.

Which encoding is this world written in?

A V2 source was, for one slice, a V1 source whose route lines carry names — and nothing in the text said so. That reads like an economy until you write a world with no routes. Take a profile line and nothing else, hand it to both parsers, and both accept: two different valid artifacts, two different sem- ids, one byte string, and nothing in it that says which one those bytes mean. The id of that world would depend on which function a caller happened to reach for. An identity spine cannot permit that; it is the same defect as a private sort key, arriving through the front door.

So a V2 world declares its encoding, as the second non-comment declaration, immediately after profile. The stripper that removes it is line-preserving — it blanks the line rather than deleting it — for the reason the name stripper is: every line number a diagnostic reports must be a line number in the text the author wrote. And it asks validateProfileHeader where the header block starts rather than counting lines itself, so "the profile comes first" stays one rule with one implementation.

Adoption: naming a migrated world

A migrated relation was never named — that is a fact about its history, and legacy-edge is the record of it. The surface cannot write one (§D8.13) and the authoring boundary refuses to mint one. Left there, the limit is permanent, and the migration is a one-way door out of the language: a world that crossed it runs, seals and compares forever, and can never again be handed to an author as text.

Adoption is the door back. It is an act, not a repair: someone supplies the names. That is the entire design, and each half of it is a consequence already stated elsewhere. The names are the caller's, because a generated name would make §D8.1's forbidden move legal by relocating it one function to the left — and the generated name would then be indistinguishable in the bytes from one an author chose, which is the exact confusion legacy-edge exists to prevent. The structure does not move, because a revision is standalone (§D8.3) and a name is not in it. The identity moves entirely, including for the relations nobody adopted, because the seeds changed, so the bytes changed, so the world id moved, and the world id is in every allocation (§D8.5).

Admission: which parser reads this text

Every rule above is written for a caller who knows what they are holding. A tool does not. It holds a textarea, and the person typing into it may be writing either encoding, may paste one over the other, and is not going to announce which. That is a real question, and §D8.15 already contains its answer: the reason a V2 source declares its encoding is so that it can be asked rather than guessed at.

An admission is that argument used. One entry point, two parsers, and the discriminator comes out of the text — not from a dropdown, a file extension, a last-button-pressed, or a preference. An interface may put starter text into an editor, because text is the input; an interface that decides how existing text is read has made the identity of a world a function of the interface, which is the same defect §D8.15 was written against with a different guess in the blank.

The half that is easy to get wrong is the failure path. A source that declares its encoding badly — ir alone, ir 3.0, the declaration twice — is a source someone meant as V2 and mistyped, and it is usually a perfectly good V1 world apart from that one line. So a fallback would have plenty to seal, and what it would print is a real sem- for a world in an encoding its author did not write. The frozen parser has no ir rule at all: asked, it answers WRL_UNSUPPORTED_FEATURE pointed straight at the declaration, which tells an author to delete the one line in the file that was doing its job. Both outcomes are worse than a refusal, so declared badly and not declared have to be different facts, and only the second one routes.

That last clause is the reason the published playground has no V1/V2 control anywhere on it, and the absence is checked rather than intended. The page reads the encoding off the source on every keystroke, shows the two ids in two labelled rows, and prints the projection beside them; the one-click example that matters most is a well-formed V1 world with a broken declaration, because that is the source a fallback would have handled most convincingly — it would have sealed, printed a real sem-, and given the reader no sign that the encoding they wrote had been overruled.

The runtime projection: what a runtime is handed

A runtime does not read source and does not need to. It needs an artifact it can execute, and §D8.13's downgrade produces one. The temptation is to stop there — hand the runtime the V1 artifact and let it get on with it — and the reason to refuse is that a runtime handed a bare V1 artifact will seal it, get a sem-, and use that sem- as the world. It will be right to. That is exactly what a V1 sem- is for, and nothing in what it was handed says this one is different.

It is different. It is the id of a projection: the bytes this world runs as, not the bytes this world is. Scope anything durable to it — a grant, a birth key, a revision, a ledger event — and the scope moves the moment the encoding does, while the world has not moved at all. The failure is silent in the worst way: every id involved is real, every hash is correct, and the world's own relations end up allocated in a scope that is not the world.

So the handoff is an envelope rather than a return value. It carries both ids, says which is which, and carries the bindings that let a consumer check the answer instead of believing it. A raw downgrade cannot say any of that — not because it is wrong, but because it has nowhere to say it.

One consequence is sharp enough to be worth stating separately, because it is the mistake a careful consumer makes. The bindings are not positional against execution_artifact.edges. The two encodings sort their topology by different keys — V2 by seed bytes, V1 by edge — so binding i and edge i are routinely different relations in the same world. A consumer joins the two lists on legacy_edge, which is why the binding carries it; joining on the index mis-attributes every observation in any world whose two orders disagree, which is most of them.

The projection on the wire: what survives a boundary

Everything above holds inside one process, where an envelope is an object a caller got back from a function it called, and the words derived and not canonical are guaranteed by the fact that the caller watched them be computed. A runtime is on the far side of something — a socket, a file, a language, a repository. Over there those two words are two more bytes in a message, set by whoever wrote the message, and a receiver asked to trust them is in the position §D8.18 was written to get out of.

So a transmitted projection carries no flags and no prose. It carries the semantic artifact — the only value on it that is not derivable from another value on it — and the sender's claims about what that artifact derives to. The receiver recomputes every claim and refuses on any disagreement. Derived stops being an assertion the receiver is asked to believe and becomes a fact it establishes.

Two things are deliberately absent from the record, and the absences do more work than the fields. The execution artifact is not transmitted: it is a function of the semantic artifact, so carrying it would let one message pair one world's semantics with another world's bytes to run, and leave the receiver holding two artifacts and a silent choice about which is real. Omitting it makes that message unrepresentable rather than merely detectable — and the view id, which is transmitted, is the checkable proxy for those bytes. Coincidence is not transmitted either, for the same reason in miniature: it is an equality between two fields that are both present.

It is fair to ask why the claims are shipped at all, given that every one of them recomputes. A record carrying only the artifact would be unfalsifiable: the receiver would derive everything, find no disagreement possible, and learn nothing about whether the sender believed the same things. Shipping a claim you can check is what turns a divergence between two implementations of this rule — which is exactly what a second implementation in a second language will eventually produce — from silence into a refusal.

Clause 7 was added after the rule shipped without it, and the way it was missed is the argument for it. A rotor lane is the one artifact scalar the spine leaves unbounded — every other is capped at the safe-integer limit, and lanes are held as arbitrary-precision integers so that a 64-bit lane is exact. A world carrying such a lane seals correctly, derives correctly, and serialises to bytes holding the integer exactly. Read back with an ordinary JSON parser, that integer becomes a nearby one, and the receiver refuses its own honest bytes. Every step was individually right; the loss happened in the single step that was borrowed instead of written. A protocol whose identity is its bytes cannot be read by something that does not preserve them.

Worth noticing where that surfaced, because it is the good case rather than the bad one. The rounded value did not pass — it tripped the range check on re-serialisation, so the failure was loud. But it was loud in the wrong vocabulary: the receiver reported that a number was out of range, when what had happened was that its reader could not hold a number that was perfectly in range. Refusing a valid world is a much smaller fault than admitting an invalid one, and it is still a refusal of something that should have passed.

Clause 5's sharpest case is the one that changes no identifier anywhere: reorder the bindings. Every id in the message stays real and stays correct, and the message is still refused — because the order of the bindings is itself derived, and a list in the wrong order is a different claim about which relation runs as which edge.

Clause 3 is what makes the rule testable across a boundary rather than only within one, and test/projection-vectors.json is where that lands: a committed set of sources paired with the canonical bytes their projections serialise to. It is the only artifact in this repository that an implementation which cannot run JavaScript can be held to. Notably, no vector states its encoding — §D8.17 already says the source decides, so a reader that needed to be told the family here would be failing that rule before it got to this one.

The profile table: a wider vocabulary without a wider encoding

The header of relation-v2.js argues at length that ir_version and profile_id answer different questions — how is topology written, and in what vocabulary — and that bumping both together would make every new domain a new encoding. Through C.5 that argument had no consequence, because the encoder admitted one profile per encoding and §D8.14 lowered every relation through the frozen V1 projection. So a world that no V1 world corresponds to could not be sealed at all. The first such world arrived from an application: Graphonomous holds a deterministic V2 world with twenty-one roles, one port, a semantic domain and thirty-one directed solid kinds, and nothing in it is a Pulser. It was minting its own world id under its own prefix, and the kernel's validateAllocation was refusing — correctly — to scope a rel- to a world nobody had sealed.

The repair (WRL-P0, 2026-09-03) is a table, not a branch: V2_PROFILES, frozen data keyed by profile_id. What was considered and not done says what the table is. Keying it by ir_version would force every new profile to be a new encoding. Giving each row a deriveWorld function would be code per profile — a branch in a costume, and not freezable or inspectable as data. Deriving schemas and state_schema_ref for a static row from some default would seal a runtime claim into identity for a runtime that does not exist. And widening validateAllocation to a second world-id prefix would let a world nobody sealed scope a rel-; the fix is to seal the world.

The consequence worth stating plainly: a profile now lands as data, and a new domain is a new row. The table has four rows at the time of writing — the lowered forge.world.core.v1 and three static Graphonomous rows, graphonomous.semantic.v0, v1 and v2, one lineage where each successor is its predecessor spread plus a measured delta (v2 is v1 plus exactly one endpoint pair, SUPERSEDES [LAW, LAW]). The reference prints the rows and their counts, read out of the module by the suite. None of this is ProfileSchemaV1 (§D6.1): a static row has no attribute types, no units, no bounded resources and no resolution tables. It is the smallest thing that lets an application's world be sealed by the encoder rather than by the application, which is the property §D8.5 needs and the one the spike was violating.

What D8 owes before it can ship

1. A canonical form that leaves every existing sem- id where it is (the note above).
2. An allocation surface. Shipped. The minting rule is specified (§D8.1) and, for period-0 relations, implemented; the way to write an authored relation name is §D8.12, and the way to write one back out is §D8.13. NamedInitialAllocation now has a surface that emits it, and is still refused at the importer's boundary — a migration may not mint a name, which is the distinction the two writer boundaries exist to keep.
   What an authorability constant is allowed to be named after. This note used to record an autonomous decision — that the kernel's AUTHORABLE_VARIANTS stays [] while the V2 surface carries its own list — on the grounds that the two are answers to the same question about two different encodings. The reasoning was right and the naming was wrong, and the difference matters. AUTHORABLE_VARIANTS makes a claim about every encoding, and once V2 shipped a surface that emits named-initial, the claim that nothing is authorable anywhere was simply false — while the executable consequence, assertAuthorableAllocation, was refusing an allocation that a real surface really does emit. So the global constant now says ["named-initial"], and the per-encoding shares are named for their encoding: V1_AUTHORABLE_SEED_VARIANTS is [] — permanently, because V1 has no field a name could live in — and V2_AUTHORABLE_SEED_VARIANTS is derived as the intersection of the global list with V2's initial variants rather than restated beside it. Each share is a subset of the global list, which is a property the tests check rather than a convention the reader is asked to maintain.
   This item used to also demand a validator enforcing that (kind, src, dst) is unique within a V1 artifact, warning that without it "the first genuine multigraph world silently seals as something it is not." That validator now exists: WRL_DUPLICATE_RELATION_KEY. The warning was also wrong in a detail worth keeping — such a world never sealed silently. It was refused, as a controller miscount, which is arguably worse than silence: a wrong diagnostic sends the author somewhere there is nothing to find.
3. An attribute type system. capacity=3 is meaningless without a unit and a range. This is the same requirement as typed ports (§D2), and neither should ship without the other.
4. Terminal-level validation. Single-writer becomes a property of a terminal rather than a global law, so validation must move with it: an owned terminal with two source endpoints reaching it is still an error, and must still be caught before the seal. A terminal declaring resolved(f) is the one exemption, and the exemption is visible on the terminal.
5. A well-formedness rule per orientation. Roles and orientation can contradict each other and the checker must say so: directed requires at least one source and at least one target and admits no other role; symmetric admits only peer; acausal admits only terminal and carries no texture. Each violation needs its own code.
   These rules now run — §D8.7, with WRL_ENDPOINT_ROLE_ILLEGAL, WRL_INCOMPLETE_ORIENTATION and WRL_ACAUSAL_TEXTURE as the three codes. What remains of this item is the other half of the texture row: texture is required for directed, and no V1 artifact can supply one (§D8.8). It becomes enforceable when the artifact version moves, and not before.
6. A settlement rule per orientation. directed settles by the existing REACT pass — including into a resolved terminal, in one pass, provided the resolution is a pure, total, deterministic function of the canonical driver map with a declared empty value (§D2.1). Algebraic laws are not required: idempotence belongs to §9's join, and associativity and commutativity are priced separately as a parallel_fold opt-in). acausal does not settle by passing values at all and requires a solver wall (§D4). symmetric has no settlement rule yet, which is the honest state of it.
7. A film schema. A relation's attributes are state, and §10 requires every state variable that determines future behaviour to be serialised.

§D9Dynamic topologydraft

Every world on this site has a fixed topology: the objects and routes are what the document says, for all time. That is what makes sem- a meaning. It is also the single largest gap between Part II's thesis and any real fleet — drones are commissioned and retired, a vehicle joins a road segment and leaves it, a lease expires, a delivery is handed from one operator to another. A topology language that cannot describe the topology changing describes a photograph.

Draft rule D9. The sealed artifact is the initial configuration plus the authorised operations. A topology change is an operation applied during a period, recorded in the event ledger, and replayed exactly. The world identity does not move; the configuration at period n is a deterministic function of the sealed artifact and the ledger prefix. This is precisely the structure §10's ReplayBundle already has, extended from claim state to structure.

One boundary, not four

An earlier draft of this section gave each operation its own timing rule: creation took effect next period, retirement at the end of the current one after FILM, boundary changes immediately before the next OBSERVE. Every one of those descriptions named the same instant in different words, and four spellings of one rule is four chances for two implementations to read it differently. There is one rule:

The reason is §8's REACT phase, which settles a cascade to a fixpoint by deterministic microsteps over a fixed configuration. If the configuration could change during REACT, the fixpoint would depend on microstep order and determinism would be lost at exactly the point §10 promises it. So every operation is proposed during a period, ordered canonically at COMMIT, and observed in the next one.

Nothing is lost by refusing the mid-period exceptions, because the thing they were reaching for is a different mechanism. Urgency is a safety question, not a structural one: a fault can suppress an identity's outputs within the current period through the supervision floor (draft §25) without deleting anything. Structural retirement still becomes visible at the next boundary. Silencing an actor now and removing it from the graph are two operations, and conflating them is what made retirement look like it needed its own timing rule.

The eight operations

Reaction rules in a bigraphical reactive system [B] reconfigure a bigraph locally and may create or destroy nodes. That is the general form; the list below is its closed, checkable specialisation. It is closed on purpose — an open set of topology operations is an open set of ways for two hosts to disagree.

The three relation facts above show the fields that distinguish them, not their full field lists. Each also carries provenance and offered_evidence, which are common to all three and are specified once, in §D8.3, rather than restated here. The rule that put them there is the same rule that keeps them from being written down twice.

The ledger grows; the active view does not

Notice that the fourth column has no verb that means delete. Retiring an identity and detaching a relation append a fact; they never remove one. Nothing is ever physically taken out of the replicated store, and the active topology is a derived view:

active_topology(sealed_artifact, ledger_prefix, period)

This distinction is what lets §9's grow-only evidence model survive a non-monotonic world. The set of facts is grow-only and merges by an associative, commutative, idempotent join, exactly as before. The set of active identities and relations rises and falls, because it is computed from the facts rather than stored alongside them. A film from period 40 can still resolve every identity it names — as §10 demands — because the fact that named them is still there, with a retirement fact after it rather than in place of it.

What every operation must answer

An operation is not specified until all eight of these are answered for it. None of them is optional, and each one is a way for two hosts to diverge:

Two valid preconditions can still be a conflict

§D8.1 gave one concurrent-revision example — two RelationRevised facts naming the same relation with different expected_prior_revisions — and that is the easy case, because one precondition is simply stale. The hard case is the common one, and it was not stated:

RelationRevised { relation_id = L, expected_prior_revision = R0, next_revision = R1 }
RelationRevised { relation_id = L, expected_prior_revision = R0, next_revision = R2 }

Both observed the same current revision. Both preconditions are individually valid. They disagree only about the result. Nothing in a compare-and-set rule rejects either one, so the outcome is decided by whichever is applied first — and §8's pinned acceptance law is MIN CandidateKey / first receipt, which is the smaller key winning. That is deterministic and it is exactly what the conflict obligation says is not good enough. A lane closure and a lane reopening, proposed in the same period from the same observed state, must not be settled by a hash comparison.

What is proposed, and what was observed proposing it

Before the table can be written, one word in it has to stop meaning two things. §D8.3 put provenance and offered_evidence onto the event and left the event id a hash over all its arguments — deliberately, since the alternative is a rule with a silent exception. The consequence was not noticed:

revise L: R0 → R1,  evidence = [certificate_A]
revise L: R0 → R1,  evidence = [certificate_A, inspection_report_B]

Two different events. One transition. The second is the first with a supplementary document attached, and under a rule that classifies by event identity the pair is not a retry — so a proposer who adds an inspection report to a pending proposal has manufactured a lifecycle conflict out of an audit trail. That is an evidentiary difference contaminating a structural decision, which is the same category error §D8.3 was written to stop.

TransitionIntentKey = H(operation core, target,
                        expected_prior_revision, next_revision)

RelationBirthKey    = TransitionIntentKey where operation = Attach

ScheduledTransition { intent_key, effective_period }

ProposalEvent       { scheduled, proposer, provenance, offered_evidence }
event_id            = H(canonical ProposalEvent)

Dropping the period from the intent raises an immediate objection, and it has to be answered rather than waved past. A relation may be revised R0 → R1, revised back R1 → R0, and revised R0 → R1 again; the first and third proposals have identical intent keys and are plainly not one intent. They are, however, never compared — the classification table states its own scope in its header, and the scope is one boundary. Two proposals for different boundaries are not a pair. A period-free key is complete inside the scope it is used in, and effective_period is the thing that says which scope a proposal is in.

The allocation burn is not boundary-scoped — it is permanent — so the objection has to be answered again, and differently, there. It answers itself, but the first way I wrote the answer was too strong. It said an attach intent cannot recur, and that is false as stated: a proposal can be emitted any number of times. The exact claim is narrower and is the one the rule needs:

Because that distinction is load-bearing, the burn now binds to a named specialization rather than to the general intent identity by way of a sentence in a paragraph. RelationBirthKey is TransitionIntentKey at operation = Attach, and nothing else. Writing it as its own name makes D8.6's permanent burn visibly narrower than the reusable intent identity a revision uses: a reader who wonders whether revising a relation twice spends two names can see from the type that it does not. Prose that only one operation consumes an allocation would have to be re-derived on every reading, and this page has already shown what happens to facts that live in prose alone.

The schedule may say when, never what

One condition has to hold for any of the above to be sound, and it is easier to state as a rule than to keep as an assumption.

Without D9.4 the split is not merely incomplete, it is unsound. The whole argument for a period-free birth key is that rescheduling changes the schedule and not which relation is being born. An implementation that lets the boundary reach into the meaning — a lease whose rate is read from the period it activates in — falsifies that premise directly: two schedules would then be two different relations wearing one birth key, which is the collision D8.6 exists to prevent, arriving by the one door the split leaves open. The rule closes it by requiring the semantic part to be written down where identity can see it.

Two more things fall out that are worth having on the record. The first is that the conservative rule at the end of this section was already written in terms of "one distinct lifecycle transition" while the table below it was written in terms of events. The prose had the right rule and no defined term behind it; D9.2 supplies the term, and the two stop disagreeing. The second is that this is §8's own move: CandidateKey exists precisely because which candidate and which receipt carried it are separate questions, and the recognition law counts distinct keys rather than distinct arrivals. §D9 needed the same split one level up and had been using one identity for both.

The first version of this table had three deduplication rows — one each for identical attaches, identical revisions and identical retirements — because it was written before there was a word for "the same change". With §D9.2 they are one row, and the row says something the three did not: a retry is recognised by what it proposes, not by arriving byte-identical. Without that, a retried proposal under partition is indistinguishable from a second intent, which is the failure the nonce law prevents from the proposer's side. The two rules are one property approached from each end.

A digest detects divergence; it does not reconstruct a world

The film obligation above asks for a configuration digest per period, and the surrounding sections have been treating that as sufficient. It is not, and the reason is the one D8.2 created: once lifecycle history is only in the ledger, the ledger's references have to resolve, and a ledger of relations references far more than object ids — allocations, revision ids, policy ids, admission evidence, acceptance receipts. A digest proves two replicas disagree. It cannot tell either of them what a revision_id stood for.

This is where a design draft has to be careful, because §10 does not leave the shape open:

ReplayBundle { initial_artifact, initial_state, event_ledger, frames, policy_ids }

; §10: "Frozen: the three-way distinction and the ReplayBundle shape.
;       Not frozen: byte layouts -- they are the Film serialization."

Stating the three is the deliverable here. The draft's job is to make the choice visible before something is built on the assumption that a digest was enough, and to record that the tidiest option is the one that costs a freeze.

Closure is not enough; it has to be closure one way

The default above says the bytes go inside event_ledger and stops there, which leaves the serialization free to satisfy D9.1 in several different ways:

Every one of them replays the same computation and produces a different film. That is not a small defect in a language whose central claim is that a run is a film that replays exactly: two conforming implementations would disagree on the artifact they hand each other, and neither would be wrong. Closure without canonicalization is the same failure as canonicalization without closure, arrived at from the other side.

EventLedgerBytes {
  objects,     ; sorted map: content_id -> canonical bytes
  entries      ; ordered accepted events, receipts, effects, outcomes
}

None of this touches the frozen record. §10 froze the ReplayBundle shape — five fields — and explicitly released the byte layouts as a Film serialization concern; this is a layout for one of the five, so it is exactly the change §10 left available. Law 5 is the one worth reading twice: without it, "closed" and "minimal" come apart, and a bundle could satisfy D9.1 while carrying an arbitrary extra payload that every replaying host would faithfully hash.

There are exactly two coherent ways out, and they are not equally compatible with the rest of §D9:

The first is the model this section was drifting toward, and §D9.1 has already ruled against it under a different name. Its opening sentence is "a digest detects divergence; it does not reconstruct a world" — and a manifest of content ids is a digest with better manners. Adopting it would leave D9.1's argument intact right up to the paragraph that serializes it, where a convenience quietly reverses it.

The cost is real, and it is why the replaced sentence was attractive: a run that consults a large solver artifact has a large film, and D9.3 offers no way to make it smaller as a film. What it offers instead is a name for the smaller thing and a plain statement of what the smaller thing cannot do. Compression, deduplication across films and shared content stores all remain available; none of them is a film until it is closed, and being closed is the entire property §D9.1 exists to require.

The promise D9.3 is protecting is one sentence, and it is worth isolating from the machinery, because everything above is only a way of keeping it true:

Possessing a valid film is sufficient to reconstruct its replay inputs, without trusting the continued availability of an outside service.

That is also the test for whether some other artifact is a film. Four things get called one, and only two of them pass:

Physical storage need not be monolithic, and D9.3 is often misread as saying it must be. Shared content-addressed chunks, deduplicated object stores, Merkleized storage, streaming and pack files are all available, and a deployment using every one of them can still be conforming. What is fixed is the canonical logical bytes: they are uniquely defined, and rehydration has to reproduce them exactly. The optimizations are permitted precisely because law 3 makes their result checkable.

Closure stops at the effect wall

Read without a boundary, D9.3 is not merely expensive but absurd. If a period consults an external model behind a gate, and a film must contain everything needed to reconstruct its replay inputs, then a naive reading demands the provider's weights, its inference cluster, its operating system and the packets on the wire. No such film has ever been produced and none ever will be. The rule needs to say where the closure ends, and the honest place is the point where WRL stops making decisions:

request  →  authorized effect  →  observed response  →  effect receipt
|                                                                    |
+------------------------- inside the film --------------------------+

        the wall is the effect itself, not what lies behind it

Replay reconstructs the world from the recorded outcome of an effect. It does not rerun the external universe, and it never claimed to. This is not a weakening: the outcome is what the world's subsequent decisions were actually made from, so a film containing it can reproduce every one of those decisions. An effect is a wall in the ordinary WRL sense — a boundary that commits and seals what crosses it — and closure stops at walls for the same reason everything else in this language does.

There is one case where the wall moves, and it moves because the promise changes. Where WRL claims a derivation is deterministic and independently re-executable, the recorded outcome is no longer sufficient — the point of the claim is that someone else can recompute it — so the solver program and the artifacts it needs do enter the closure. Two different promises are being made in the two cases, and a single word for both would let a film advertise the stronger one while carrying evidence for only the weaker:

The identity stack these rules add up to

The stack is seven layers, and only five of them are new. The other two are frozen, which is what makes this a chain rather than a proposal: §8's acceptance receipt and §8b's film were settled before any of these rules existed, and §D8 and §D9 build between and beneath them without the standing to renegotiate either end. The reason the five new names are not five ways of saying one thing is that each answers a question none of the others can:

AllocationGrant       authorizes a namespace
RelationAllocation    selects one name within that namespace
RelationBirthKey      binds that name to one semantic birth
ScheduledTransition   proposes when that birth becomes effective
ProposalEvent         records who proposed it, and with what evidence
acceptance receipt    records why the world accepted or refused it    ; §8  frozen
Film                  closes the complete replay-visible history      ; §8b frozen

Read downward it is an authority chain, and read upward it is a provenance chain. The test for whether a layer is redundant is whether removing it forces another to answer two questions — and every collapse tried in these sections did exactly that. Putting the period in the intent made one key answer what and when, and D8.6 and D9.2 immediately disagreed. Putting evidence in the structural identity made one key answer what and with what justification, and an inspection report became a lifecycle conflict. Letting a manifest be a film made one artifact answer what happened and where to find out, and D9.1's own opening sentence ruled against it.

What has to be proved when this becomes writable

A draft rule that is never reduced to a falsifiable property is a rule that will be quietly reinterpreted instead. The register below is the decisive battery: each row states a property, names the rule it would falsify, and declares two things that are easy to confuse — which layer the property lives at, and whether a check for it runs today. A row may not claim to run without naming a check that exists.

The two axes are independent, and keeping them apart is not bookkeeping. Every row of this register once read awaiting surface, which quietly asserted that nothing here could be tested until syntax landed — and that is false for the whole model layer, where identity is determined by structure that is already sealed. Collapsing the axes would have pushed the next milestone toward inventing syntax when the semantic model was the part still unproved.

That is not hypothetical. Separating the axes is what produced the kernel, and the model layer is now empty of debt: eighty rows run. The suite enforces that as a ratchet rather than a milestone — settling a model-layer property lowers the permitted count, and a new model row therefore has to arrive already executable. That ratchet is exactly what turned D8.7 from prose into twelve tests in the same commit: the rule could not be stated here without them. It also works in the other direction, which is the less obvious half: four rows first filed as awaiting a future artifact version turned out to be testable against two V1 worlds, because the break they were waiting for already happens every time a world is re-sealed. A row parked at the wrong stage is the same defect as a row parked at the wrong status, and it is harder to notice, because nothing about it looks unfinished.

The sharpest version of that error is a row that is half misfiled, and two rows here were. "The same authored name in two worlds yields two ids" was filed surface · awaiting, and "two overlapping grants do not collide" was filed runtime · awaiting — both correctly, as far as it went, because there is no syntax for naming a relation and no machinery for issuing a grant. But an identity is a function of a preimage, and both preimages are writable today: a NamedInitialAllocation carries its world_id and a GrantedAllocation carries its grant_id. The arithmetic was never blocked; only the way a person reaches it was. So each row is now two: a model row that runs, and a narrower awaiting row that names the surface or the runtime it is genuinely still waiting on. A single row covering both had the effect of hiding a settled property behind an unsettled one, and reported less than was known.

The severity is the point. The model layer is defined as the layer with no external blocker, so a model row saying awaiting is saying "nobody wrote it" in language that sounds like "nobody could" — and that substitution is the entire failure this register exists to catch.

What a period has to record about structure

The second half of closure is not about bytes but about what is worth recording, and §8 has already answered it for claims. The frozen blockquote says the phase distinction is what determines "which claims were seen, which candidate was accepted, whether a retransmission retries an effect" — so a film that recorded only accepted claims would already be non-conforming. Structure gets held to the same standard:

PeriodFilm { period,
             observed_proposals, accepted_events, rejected_events,
             conflict_outcomes, effective_topology_events,
             configuration_digest, world_frame_digest }

rejected_events is the row that looks redundant and is not. A rejected topology change does not affect future state, so a purely state-oriented film would drop it — and dropping it means a film cannot answer "did anything try to attach a writer to that terminal?" An attempt that was refused is an observable fact about the world, and for authority and admission it is frequently the fact that matters most. It is also the only evidence that classification ran at all: a period in which two competing revisions were proposed and one diagnostic was raised looks, in an accepted-only film, exactly like a period in which one revision was proposed.

Replication is a property of the invariant, not of the verb

An earlier draft of the row above said attaching a relation is merge-safe; transferring ownership is not. The second half is right and the first half is only right for unconstrained attachment. Two partitions can each attach a perfectly well-formed relation and still produce a union that violates a domain invariant — both consuming the last unit of road capacity, both attaching a writer to a single-writer terminal, both reserving the same charger, one attaching to an identity the other retired, or together exceeding a degree bound. Every one of those merges cleanly as a set of facts and is wrong as a configuration.

The escrow class is the interesting one, because it is the case a naive reading treats as needing global coordination and a careless one treats as merge-safe. It is neither. It is coordination arranged in advance: the allowance is divided while the network is healthy, so that the common path is local and only exhaustion is expensive. That construction is the reason capacity=3 in the sketch below is a claim a partitioned world can actually keep, and it is also the reason capacity cannot be an ordinary attribute — a bounded resource has to be declared as one, in the profile, before anything can be escrowed against it.

What it would look like

profile wrl.mobility.v1

[depot:west](bays=4){dispatch}
[segment:a12](capacity=3){occupancy}

; the operations a world authorises are part of what it seals.
; a change not named here cannot happen, however privileged
; the proposer — this is what keeps the id a meaning.
topology {
  allow create of drone by [west].dispatch
  allow attach mobility.occupies by [west].dispatch
       escrow [a12].capacity
  allow transfer occupancy by quorum
  allow retire of drone by [west].dispatch

  ; an ADMISSION rule, not an enumeration: the world does
  ; not know which vehicles exist, and does not need to.
  ; what it seals is the test they must pass.
  admit vehicle
    identity = public_key
    when certificate.root in #federation_ca
     and schema == #vehicle_v1
     and operator.quota_available
}

; a lease schedules its own expiry at attach time, so the
; release is in the ledger before the period that applies it
[d7] --mobility.occupies(cost=1, lease=6)--> [a12]

Sealed admission, not sealed enumeration

An earlier draft of this section ended by conceding that a world admitting genuinely unforeseen participants — another operator's vehicle joining mid-run — might be the point at which sealed identity and open topology genuinely conflict. That concession was too quick, and it mistook one way of closing a world for the only way.

A sealed artifact does not have to enumerate the identities that may exist. It has to fix the rule by which a new one is admitted. The distinction is routine outside this document: a SPIFFE trust domain [SP] is a trust root, and workloads are admitted by attested policy rules against that root rather than by having been listed in advance — which is exactly why two organisations can federate by exchanging bundles instead of exchanging inventories.

So what the seal covers is the admission rule and everything it depends on:

Two hosts replaying the same film admit the same participants, because they run the same sealed checker over the same recorded evidence. The world identity never moves; what moves is the configuration, which §D9 already established is a function of the artifact and the ledger prefix. Novelty is admitted without being anticipated.

This matters more than it looks, because the interesting worlds are all federated ones: drone fleets crossing operators, public roads carrying anyone's vehicle, a utility interconnecting with a neighbouring utility, androids moving between owners. A language that could only describe a closed roster would have been unable to describe any of them. The remaining hard part is not identity — it is that admission is now a wall, and a wall that admits participants has to be as carefully specified as one that admits messages.

What D9 owes before it can ship

1. Configuration digests in the film. Without a per-period structural digest there is no way to detect that two replays diverged, and the whole rule is unenforced.
2. A capability model. "Authorised by" presupposes capabilities, which are drafted (draft §23) and not built.
3. Attributed relations (§D8). Operation 5 changes attributes that do not yet exist.
4. A conflict diagnostic set. Every incompatible pair needs a code, in the same family as WRL_CONTROLLER_CONFLICT, which is today's static analogue of exactly this problem.
5. A declared bounded-resource kind. The escrow class above cannot be applied to an attribute that is merely a number. capacity has to be declared in the profile as a bounded resource, with a total, before an allowance can be split against it — which makes this a §D8 attribute-type-system obligation as much as a §D9 one.
6. An admission wall. The admit rule above turns participant entry into a boundary crossing, and §D6's wall obligations apply to it in full: what evidence is required, what is recorded, what happens when the checker rejects, and what a partition does while it cannot reach the quota state.

References

1. [K14] M. Kivelä, A. Arenas, M. Barthelemy, J. P. Gleeson, Y. Moreno, M. A. Porter. Multilayer networks. Journal of Complex Networks 2(3), 203–271, 2014. — node-layer tuples, aspects, intra- vs inter-layer edges, and the node-aligned special case.
2. [B] R. Milner. The Space and Motion of Communicating Agents. Cambridge University Press, 2009. — a bigraph is a place graph (nesting) and a link graph (connectivity) over one node set; links are hyperedges; bigraphical reactive systems reconfigure structure by rules that may create or destroy nodes.
3. [G] ISO/IEC 39075:2024, Information technology — Database languages — GQL. — the property graph as a directed, labelled, attributed multigraph in which nodes and edges carry properties.
4. [H] G. Gallo, G. Longo, S. Pallottino, S. Nguyen. Directed hypergraphs and applications. Discrete Applied Mathematics 42 (2–3), 177–201, 1993. — a hyperarc as an ordered pair of disjoint vertex sets, a tail and a head; the standard formulation behind endpoint roles.
5. [E] V. Balegas, D. Serra, S. Duarte, C. Ferreira, M. Shapiro, R. Rodrigues, N. Preguiça. Extending Eventually Consistent Cloud Databases for Enforcing Numeric Invariants. SRDS 2015. — the Bounded Counter: escrow splits a numeric allowance across replicas so that decrements commute locally and coordination is needed only when a replica's share is exhausted.
6. [SP] SPIFFE, Trust Domain and Bundle and Federation specifications. — a trust domain is a trust root; workloads are admitted by attested policy rules rather than by prior enumeration, and domains interoperate by exchanging bundles.
7. [M] Modelica Language Specification, ch. 9, Connectors and Connections. — potential variables equated, flow variables summed to zero, acausal connection semantics.
8. [V] IEEE 1164 std_logic_1164: std_ulogic (unresolved) vs std_logic (resolved, with a resolution function).
9. [P] Ptolemy II / System Design, Modeling, and Simulation using Ptolemy II, ch. on directors and hierarchical heterogeneity. — a director implements a model of computation; an opaque composite's local director need not match its executive director.
10. [R] ROS 2 documentation, About Quality of Service settings. — reliability, durability, history, depth, deadline, lifespan, liveliness as independent policies.
11. [S] Eclipse SUMO documentation, Randomness. — deterministic by default; --seed / --random.
12. [O] Google OR-Tools routing issue reports on reproducibility. — solution quality varies run to run; construction order affects results.

End of WRL Core 0.1.2, Parts I and II. Part I is frozen. Part II is an argument, and is meant to be argued with — see Direction for the case in prose.