The origin relation: an added or modified hand-Rust item must show its capability was modeled before it, and that the model constrains it

[briansrls]

What this adds

gunbc.capability_origin — the origin relation, the second and third tests beside the leaf test #9426 landed.

CapabilityAlreadyModeled was payload-free. It could be satisfied by inspecting the final candidate, and a final candidate cannot distinguish

• a model that existed before its realization, from
• a model authored beside the realization that inspired it

which is the entire question the arm existed to ask. The vocabulary moves here and grows a payload.

CapabilityOrigin = NoNewCapability | ModeledCapability { origin }

ModeledCapabilityOrigin
  = CapabilityPresentOnBase          { authority }
  | CapabilityIntroducedInModelEpoch { authority, model_epoch, ground }

CapabilityGround
  = ExistingCapabilityMigration { predecessor, preserved_contract }
  | ExternalContractGround      { authority: ExternalAuthority }
  | OperatorRatifiedModel       { ruling }

There is deliberately no arm meaning "the Rust behaves this way, therefore this is the intended model." That state is unwritable rather than refused by a check. NoNewCapability stays correct for an edit that only repairs, narrows, moves or deletes.

Three tests, establishing three different things

test	what it proves	what it misses
leaf (#9426)	Rust owns no semantic decision	a retro-described implementation passes it perfectly
origin	the semantics predate the Rust	fixtures may still follow the behavior
conformance	the model constrains the Rust	—

The origin test: remove the hand-Rust delta, build E1 (base + the .dag delta, minus every added or modified hand item), and the cited authority must still resolve, compile and pass its controls. If producing the model projection requires the new leaf, the model is not independently prior and that substrate capability separates first.

The conformance test is directional: mutate only the Rust realization. The predicted evidence must go RED while E1 stays GREEN. A mutation nothing notices establishes that the fixtures follow the realization. FixtureProvenance refuses GeneratedByRealization even when the mutation went red — redness is necessary, and provenance is what makes it evidence.

Additions are covered, not only modifications

#9426 closed the large-existing-function escape. But a newly added item can carry a perfectly good SeedGrowthJustification row and still have been retro-modeled in the same change, so the relation participates in the addition arm too. a_roster_named_addition_still_refuses_when_no_bridge_states_its_origin runs the same addition the positive control admits, with the identical justification row, and the only difference is the origin evidence.

The epoch is identified, and it expires

ModelEpochRef names the exact derived E1 population (synthetic tree identity or content identity), and ModelEpochSubject carries both the base and the head it was derived against — one alone leaves the failure unrepresentable in one direction.

This came out of a live incident on #9426, and it is recorded in the carrier rather than as advice: a structural finding reported five scm modules changed, a witness file deleted and a type removed. Every one was main's own work rendered in reverse, from a two-dot diff between current main and a branch whose base predated it. Nothing in it was true and all of it was internally consistent. So a probe taken against a different base refuses — the class is unrepresentable instead of discouraged.

Rung, stated honestly

The vocabulary is structural: no not-executed arm has a path to an admitting verdict — ProbeNotExecuted, ConformanceProbeNotExecuted and a missing bridge all refuse, and a caller supplies probe results, never verdicts, so a conclusion cannot be written in directly.

The tests are executed by nothing in this repository yet. No host supplies ModelEpochProbeResult or ConformanceProbeResult, so every real call today lands on the not-executed arms and refuses. That is the correct fail-closed reading, not a passing one, and calling this a wall would be the inflation §4b(1) names as worse than sitting low. The next-rung trigger names the capability — a route that materializes E1 against the actual proposed base, builds and runs the authority's controls inside it, and mutates the realization to observe the conformance evidence flip — with three explicit non-retirements (constructing the subject without building it; building one entry when the controls span several; deriving the base from whatever ref the caller had).

What is deliberately not here

No terminal PinnedKernel / AuthorizedTemporarySeedBridge roster. That closes with the final claim_executor cut; hand-transcribing ~1,500 moving declarations today is rung inflation wearing a roster. The bridge shape is authored once and read twice — prospectively by this join, contemporaneously by the terminal join later — and no parallel list is introduced for either reader.

Two proposals were considered and rejected on the ruling: requiring the model in a prior merged PR (sufficient but not necessary, and it buys another moving-base epoch per realization), and requiring model refusals the realization does not implement (it creates an incentive to author decorative refusal arms).

Base

Stacks on #9426, whose head is 5c593b2e4e. Until that merges this PR's diff against main shows #9426's nine files as well; the origin relation itself is the commit 0b05d6a0c0 and touches four files. It cannot be based on main directly — it consumes the types #9426 introduces.

Evidence

rust_item_host_observation_witness_test — 21 arms green, including four new ones:

• a_capability_modeled_in_the_same_change_refuses_until_a_probe_runs
• conformance_fixtures_generated_by_the_realization_refuse_despite_a_red_mutation
• a_realization_mutation_no_evidence_noticed_refuses
• a_probe_taken_against_another_base_expires_rather_than_admitting

The third test broke a control that was already green

an_addition_the_roster_already_names_is_admitted is the positive control, and it passed the leaf test and the origin test: its bridge names a capability already on base, so the origin arm admits it with no probe needed. Adding the conformance test turned it red — no conformance probe existed for its authority, and a missing probe refuses.

That is the strongest available evidence the three tests are independent rather than three spellings of one: a case that satisfied the first two was refused by the third. A test that landed green everywhere would be the decoration §4b names as worse than absent. The control now supplies conforming evidence to pass — without it, the refusals above would be satisfied by a join that refuses everything. seed_growth_admission_witness_test — 7 arms green.

Hand-Rust delta: zero. Every file in this change is .dag.

[gunbai-bot]

Merge-order note, measured — not a defect in this PR, and no change requested.

This branch is a descendant of #9426's branch, not an independent one:

git merge-base --is-ancestor session/loyal-ram-883 session/loyal-ram-883-origin  -> true
commits unique to #9444 over #9426: 2
nine files appear in both PRs

So #9426 must merge before #9444. Merging #9444 first would carry #9426's commits in with it and land that PR's content under this PR's title, unreviewed as such.

Verified conflict-free in both directions as of dabe4c5804:

• #9426 vs current main — 0 conflicts
• #9444 vs current main — 0 conflicts
• #9444 vs #9426's head (simulating 9426-merged-first) — 0 conflicts

One caveat worth stating because the repo squash-merges: after #9426 is squashed, this branch still carries the pre-squash commits, so its merge-base with main will be stale and its diff will re-present #9426's content. Git resolves that cleanly when the content is byte-identical, which it is today — but if anything is adjusted during #9426's merge, this branch needs a fresh main merge before it lands rather than a rebase.

Flagging only so the manual merge order is explicit. Nothing to do here.

— sent from merry-bear-547