invariant-r10 invariant-r10/inputs-gpt-execution-adjudication-v5.md
Date: 2026-09-02 (America/Chicago) Input: fable51-r10pre-execution-v5.zip + sidecar SHA-256 Disposition: F36/F37 EXACT DEFECTS CLOSED UNDER THE DECLARED PROFILE. R0.8 SAFETY MEC…

GPT-5.6 Adjudication — R10-pre Execution v5

Date: 2026-09-02 (America/Chicago) Input: fable51-r10pre-execution-v5.zip + sidecar SHA-256 Disposition: F36/F37 EXACT DEFECTS CLOSED UNDER THE DECLARED PROFILE. R0.8 SAFETY MECHANISM IS NEAR-FREEZE, BUT FINAL R0.8 FREEZE SHOULD WAIT FOR ONE SMALL RECOVERY-REPORT / OBSERVABILITY DECISION+CONTROL. `package-v2.7` STRUCTURE ACCEPTED; CREATE v2.8 FROM THIS ADJUDICATION. NO BROAD FABLE THEORY ROUND.

0. Independent verification

Outer archive

The supplied SHA-256 sidecar matches exactly:

e83f03a79accc4317274884b66d0ed991a013425c69ab2aa282b34766108e28b

Top-level integrity

SHA256SUMS verifies successfully.

package-v2.7 drift gate

Independent run:

drift_gate v2.7:
    12 current-facing files
    56 crosswalk records
    5 promotion/evidence-transition records
DRIFT GATE PASS

The v2.7 gate rejects v2.6 with 54 findings.

L1 temporal v2.7

Across:

PYTHONHASHSEED=0
PYTHONHASHSEED=1
PYTHONHASHSEED=42
PYTHONHASHSEED=123

every run returns:

21 expectations, 0 failed

and byte-identical stdout:

c28adfe3c97c1533a968a8f8c2b0b39a943e32ea9945d815f5665092122158d0

E-51 / effect identity model v2.7

Independent run:

19 expectations, 0 failed

The two retained mutations still reintroduce the intended defects.

TRVM contract probes

Independent run:

35 expectations, 0 failed

The raw E-42/E-43 APIs remain red; the adapters close their stated finite witnesses without promoting the laws.

Factory evidence-state validator

The real v2.7 projection is admitted:

evidence-state@1
56 records
5 transition records
ADMISSIBLE

The selftest baseline passes and all fourteen registered mutations are refused.

Generated projection

Actual:

package-v2.7/evidence_state.json
sha256:
cc55f5183ada7fb322f8e958300b0e87c212e368c780e138fb09ca24bd533686

This matches the projection.sha256 recorded in the crosswalk.

R0.8.7 handback

The complete COMPUTEDRIVEN_R087_FOR_GPT.tar.gz is present.

Its internal SHA256SUMS.txt verifies successfully.

Retained source identity:

commit:
21a1452eb6de183292e398872a4e83176566790b

tree:
5dda9d0c40339bc1a360b687a90649e0edae9457

History:

fe883e9
    F36 falsification committed before repair;
    F37 window recorded

21a1452
    F36 + F37 repair

The retained series reports:

21 PASS / 0 FAIL of 21

with nine independently logged legs:

guards
nc15
nc25
nc26
nc27
nc28
nc29
nc30
run_r08

and the independent battery verifier reports verify=0 on all retained runs.

I can inspect the complete source, git history, manifests, controls and retained receipts. This review environment does not contain Rust/Cargo or the original PX13 Docker runner, so I am not claiming an independent re-execution of the R0.8.7 Rust/PX13 battery.

1. F36 — ACCEPT closure

Defect

R0.8.6 correctly required the anchor to authorize the exact committed successor, but it authenticated only the endpoint.

A foreign root could remain at the honest anchor's own committed:

revision R
head H0

while carrying:

pending R+1 / Hforeign

produced legitimately under another anchor.

Because the committed root matched the honest anchor:

Root::open
    did not challenge root.pending

Recovery selected roll-forward.

The replay then called the ordinary pending path, whose first act was to write the candidate's pending successor into the honest anchor.

So:

candidate state
    ->
trusted successor authorization

The trust direction was reversed.

This is both:

S3:
    lineage/successor provenance lost during an intermediate transition phase

and an S2-shaped failure:
    recovery evidence minted authority from claimant-provided state

Repair

R0.8.7 introduces two load-bearing protections.

A. The pending state machine is checked at Root::open

For a root with an in-flight transition:

anchor none + root Hx
    REFUSE

anchor H1 + root Hx != H1
    REFUSE

anchor H1 + root H1
    potentially recoverable

The candidate cannot reach recovery while carrying a pending transition this deployment did not already authorize.

B. PendingOrigin

Original
    may CREATE the anchor reservation
    because it originates from this controller's already-verified state

Replay
    must FIND and MATCH an existing reservation
    and can never mint one

The replay/original distinction is derived from the internal recovery path, not from claimant-controlled durable bytes.

Ruling

F36 exact foreign-pending-import defect: CLOSED under the existing R0.8 profile.

Preserve the failing NC29 witness append-only.

Cross-registry interpretation

Do not create a new S-row.

I recommend:

primary:
    S3 continuity / anti-resurrection / successor provenance

cross-reference:
    S2 authority non-amplification

A useful corollary name, if Graphonomous needs one, would be:

S3-PHASE-COMPLETE-PROVENANCE

Every durable intermediate state that can affect recovery must preserve the
same admitted lineage authorization; recovery may complete an admitted
transition but may not manufacture its missing authority from the candidate
being recovered.

This is a corollary / refinement, not a new primitive.

2. F37 — ACCEPT closure

Defect

The F35/F36 ordering intentionally writes:

anchor reservation
BEFORE
root pending transition

so authorization precedes the act.

A real process crash between those two writes reaches:

anchor:
    committed R/H0
    pending   R+1/H1

root:
    committed R/H0
    pending   NONE

store:
    R/H0

R0.8.6 reopened cleanly but left the unused anchor reservation intact.

That reservation could later authorize a candidate that the actual root had never recorded as an in-flight transition.

Repair

R0.8.7 explicitly defines the semantic roles:

anchor.pending
    = RESERVATION / authorization

root.pending
    = durable transition record

Only after Ctl::open has:

opened the root
validated the committed pair
re-derived the semantic history

does reconcile_anchor() cancel:

anchor pending != none
root pending == none
committed anchor == committed root

The controller does not invent a transition or advance the committed lineage.

NC30 reaches this state with an actual crash at:

after-anchor-pending

rather than hand-writing the files.

It then verifies:

reservation existed
root pending did not exist
store did not move

restart succeeds
reservation is cancelled
committed head stays H0

later legitimate transition succeeds

a foreign candidate cannot spend the cancelled slot

Ruling

F37 exact unused-reservation defect: CLOSED under the declared process crash / single-host profile.

This is an S3 lifecycle/currentness refinement, not a new semantic primitive.

3. NC29 requirements a–d — ACCEPT

The v4 requested five things.

I accept the evidence for:

a. controller does not invent H1 as committed

b. foreign H != authorized H1 is refused

c. only the exact authorized successor can occupy the ahead-recovery case

d. a cancelled reservation cannot later be spent

The combination of NC28/NC29/NC30 plus the now-total anchor/root pending checks is sufficient for these exact questions.

4. Requirement e — I recommend one more tiny control before FINAL R0.8 freeze

The remaining question was:

Does the recovery/report surface distinguish "nothing was ever authorized" from "H1 was durably authorized but the root never recorded pending", or is there an explicit design decision that this distinction is intentionally not externally observable?

The current source does not surface this distinction.

In the F37 window:

Ctl::open
    first classifies root/store recovery as clean

later:
    reconcile_anchor()
        mutates the trusted anchor
        cancels the unused reservation

but RecoveryReport.resolution remains:

"clean"

This does not create an S3 safety failure.

After cancellation, the two states are intentionally future-equivalent:

never reserved
reservation existed but was never used and has now been cancelled

So S4 does not require the historical distinction merely because the past bytes differed.

However, R0.8 already treats recovery-report as trusted operator evidence:

  • F20 protects the trusted recovery evidence;

  • F21 keeps recovery-report available under poison while preventing it from

serving contaminated live state;

  • the durable model says ambiguous committed transitions are surfaced rather

than silently guessed.

Given that existing contract, reporting:

resolution = clean

while recovery actually changed the trusted anchor is too ambiguous for a final freeze.

Preferred solution

Add one small control, call it NC31 without minting a new F-number yet.

Reach the real F37 crash window and assert the restart reports something like:

resolution:
    "unused-anchor-reservation-cancelled"

or fields:

anchor_reservation_recovered = true
cancelled_successor_revision = R+1
cancelled_successor_head = H1

The report need not make the reservation a semantic World transition.

It is diagnostic recovery evidence about trusted infrastructure.

Alternative

If the architecture deliberately defines:

recovery-report.resolution
    = semantic root/store transition recovery only

and explicitly excludes internal currentness-reservation cleanup, document that contract and add a control proving "clean" means exactly that.

I prefer surfacing the cancellation.

Ruling

Do not mint F38 merely from this review.

First make the contract explicit and let NC31 determine whether current behavior violates it.

5. R0.8 freeze decision

The mechanism part is now close enough that I would distinguish:

R0.8-SAFETY-MECHANISM:
    READY FOR FREEZE under the declared profile
    after F36/F37 adjudication

R0.8 COMPLETE ROUND:
    PENDING one recovery-report / observability decision and control

The profile must remain exact:

IN SCOPE:
    process crash / restart
    SIGKILL/abort-like process failure
    single host
    protected deployment-owned anchor namespace
    trusted root + anchor parent directory
    content-addressed canonical successor identity

OUT OF SCOPE:
    power loss / block-layer persistence theorem
    Byzantine storage implementation
    distributed consensus
    network partitions
    anchor-service failover

If NC31 is green and introduces no new semantic defect, I would be comfortable freezing R0.8 under that profile.

Do not keep R0.8 eternally open because a different power-loss profile remains unclaimed.

6. package-v2.7 — structure ACCEPTED, but it is no longer the final current evidence state

The v2.7 architecture is good:

generated evidence_state.json
stable class tokens
subject identities
cross-lane adjudication refs
typed sensitivity witnesses
projection hash
explicit profile boundaries
F35 adjudication recorded
F36/F37 shipped but unadjudicated

This adjudication changes the state:

F36 -> CLOSED
F37 -> CLOSED
NC29 a-d -> ACCEPTED
R0.8 -> pending only the requirement-e / report decision

Therefore create:

package-v2.8

as an evidence-state patch.

No theory pass is needed.

7. Projection hash placement — ACCEPT as an interim binding; station receipt should become the root

Current v2.7 does:

canonical crosswalk
    ->
deterministic evidence_state projection
    ->
sha256(evidence_state)
    ->
crosswalk.projection.sha256

That is acceptable as an interim cross-reference.

It proves the shipped projection is the projection the current crosswalk names.

For the long-term factory, however, the station receipt should be the stronger root of evidence.

Recommended station receipt:

{
  "station": "factory-station@...",
  "generator_sha256": "...",
  "input_registry_sha256": "...",
  "promotion_records_sha256": "...",
  "projection_sha256": "...",
  "validator_sha256": "...",
  "validator_result": "ADMISSIBLE",
  "subject_identity": "...",
  "timestamp": "..."
}

Then the crosswalk should point to:

station_receipt_id / hash

rather than being the ultimate authority for the hash of its own derived projection.

This avoids circular-looking authority and keeps:

registry
projection
validation
receipt

as distinct layers.

8. Small schema correction: "promotion" is currently overloaded

v2.7 contains five records under promotions.

One of them, E-13b, is:

TESTED-CONDITIONAL
    ->
TESTED-CONDITIONAL

because the class token did not change; the evidence/profile closure was strengthened by the F35 adjudication.

That is a legitimate evidence-state event, but it is not literally an evidence-class promotion.

For the station contract, I recommend:

evidence_transitions:
    transition_kind:
        class_promotion
        closure
        scope_strengthening
        adjudication_update
        evidence_refresh

Then:

from_token == to_token

is legal for a closure/adjudication update but not called a class promotion.

The current package remains valid; this is a schema naming refinement.

Tiny v5 documentation typo

FAC-EVIDENCE-TRANSITION-SCHEMA-CLOSED.claim.json says the v2.7 projection contains:

56 records, 6 promotions

The actual generated projection and gate both report:

56 records, 5 transition records

Patch that in v2.8.

9. FAC-EVIDENCE-TRANSITION-SCHEMA-CLOSED — ACCEPT the PROVED shape, with the stated domain

I accept the narrower factory claim as:

PROVED / EXHAUSTIVE-IN-DECLARED-DOMAIN

provided the wording stays narrow:

over evidence-state@1, the structural validator is total for its declared schema obligations and rejects every registered mutation.

That does not prove receipt semantics.

It does not prove subject reach.

It does not make FAC-CONTROL-SENSITIVITY proved.

So the split is now clean:

FAC-EVIDENCE-TRANSITION-SCHEMA-CLOSED
    PROVED in declared structural domain

FAC-CONTROL-SENSITIVITY
    DECLARED
    semantic content/reach still requires domain-specific evidence/adjudication

I would let the factory lane mint the exact registry entries.

10. L1 three-assumption contract — enable is the right current granularity

The v2.7 finite temporal model now separates:

ENV-SUCCESSOR-AVAILABILITY
    a willing/eligible candidate is offered

SYS-SUCCESSOR-ENABLEMENT
    the system turns a valid offer into an admissible successor opportunity

SYS-ATTACH-FAIRNESS
    a continuously enabled admissible attachment is eventually processed

and shows omission of enablement breaks service succession.

That is a useful result.

Should enablement be split into authority / policy / finality proof now?

No, not yet.

At the current semantic level:

SYS-SUCCESSOR-ENABLEMENT

is the right obligation.

Authority, policy, generation/finality proof, resource compatibility and world/locus admission are candidate mechanisms / preconditions that discharge enablement.

Do not turn every conjunction inside a mechanism into another liveness law.

Split enablement only if we can construct an independence witness such as:

authority available, policy unavailable -> liveness fails in a distinct way
policy available, finality proof unavailable -> ...

and the distinctions matter semantically rather than operationally.

For Graphonomous, represent:

L1
    REQUIRES -> SYS-SUCCESSOR-ENABLEMENT

SYS-SUCCESSOR-ENABLEMENT
    DISCHARGED_BY -> authority evidence
    DISCHARGED_BY -> policy admission
    DISCHARGED_BY -> finality/generation proof
    DISCHARGED_BY -> resource compatibility

until reduction/falsification shows those deserve separate obligations.

11. E-51 — claim-time SATISFIED-REPEAT line needs one further refinement

The v2.7 model's basic distinction is correct:

UNKNOWN:
    ordinary replay refused
    REPLAY_RISK_AUTHORIZED may admit a replay

SATISFIED:
    same intent is done
    another physical effect is a NEW intent

FAILED-ABSENT:
    retry under the same intent may be admissible

I accept that.

But I do not think claim-time classification alone is sufficient.

Consider:

t0:
    intent K is UNKNOWN

t1:
    operator grants REPLAY_RISK_AUTHORIZED

t2:
    replay attempt A2 is CLAIMED

t3:
    before A2 crosses the irreversible effect boundary,
    reconciliation establishes that A1 actually COMMITTED

t4:
    A2 performs the external effect anyway

At t2, the replay was legitimately admitted under uncertainty.

At t3, uncertainty is gone.

If A2 has not yet crossed the irreversible effect boundary, continuing at t4 creates a duplicate that was no longer necessary and is avoidable using information the system already has.

Therefore add:

EFFECT-TIME CURRENTNESS / REVALIDATION

A replay-risk authorization permits an attempt while completion is UNKNOWN,
but immediately before the irreversible effect boundary the attempt must
revalidate the intent's current satisfaction state.

if still UNKNOWN:
    proceed under REPLAY_RISK_AUTHORIZED

if SATISFIED before effect:
    do not effect
    terminate/supersede/cancel the replay attempt

if the replay already crossed the effect boundary while UNKNOWN and the
original is only later discovered COMMITTED:
    any resulting duplicate is an ACKNOWLEDGED-RISK duplicate

This is the same architectural pattern we have seen elsewhere:

authority/admission at proposal time
!=
authority/currentness at use time

Do not mint a new E-number from prose alone.

Extend the finite model first.

Answer to the v5 question

So:

an authorized replay claimed while UNKNOWN whose duplicate lands after the original is reconciled COMMITTED is an acknowledged duplicate only if the replay had already crossed the irreversible effect boundary before that resolution became available, or if the boundary could not safely observe the new information.

If satisfaction becomes known while the replay is still safely cancellable, the effect boundary should refuse it.

That is the sharper line.

12. Super E-50b remains correct

Keep the identity split:

INTENT
ATTEMPT
RISK AUTHORIZATION
ATTEMPT TERMINAL
INTENT SATISFACTION

SUPERSEDED is attempt-level.

A useful additional attempt terminal for the effect-time refinement may be:

CANCELLED_SATISFIED

or simply a structured SUPERSEDED reason:

SUPERSEDED(reason = intent_already_satisfied)

Do not make it an intent outcome.

13. TRVM handoff — current refinement still stands

No new TRVM governance result is present in this v5 return.

I still recommend the TRVM lane adjudicate:

E-43

A-IDEMPOTENT

same source digest:
    no semantic write

changed source digest:
    one protected World transition

The compare-and-mutate decision must be inside the World boundary.

E-42

Treat:

world/birth identity
+
history/ancestry position

as potentially complementary coordinates.

The lane must decide what fork() means before deciding warrant portability.

Keep both laws red until that governance decision and native witness.

14. Current frontier after v5 adjudication

Safety / semantic integrity

S1  Admission singularity

S2  Authority non-amplification
    F36 cross-reference:
        recovery may not mint successor authorization from claimant state

S3  Continuity / anti-resurrection
    currentness/exclusivity
    canonical-history continuity
    exact successor authorization
    phase-complete successor provenance

    F31 CLOSED
    F32 CLOSED
    F35 CLOSED
    F36 CLOSED
    F37 CLOSED

S4  Semantic observability
    R0.8 recovery-report reservation-cancellation visibility:
        DECISION/CONTROL PENDING
    E-42/E-43 remain red

S5  External-effect honesty
    TESTED under first real adapter profile
    E-50a/E-50b remain Super work
    effect-time replay revalidation newly identified as a model question

Liveness

L1? Recoverable resolution / succession

requires:
    ENV-SUCCESSOR-AVAILABILITY
    SYS-SUCCESSOR-ENABLEMENT
    SYS-ATTACH-FAIRNESS

Factory epistemics

FAC-CONTROL-SENSITIVITY
    DECLARED

FAC-EVIDENCE-TRANSITION-SCHEMA-CLOSED
    suitable for PROVED / exhaustive-in-evidence-state@1-domain

15. What should happen next

A. Build package-v2.8

Evidence-state patch only:

F36 CLOSED
F37 CLOSED
NC29 a-d accepted
R0.8 freeze_decision:
    PENDING requirement-e / recovery-report decision

add S2 cross-reference for F36
patch factory 56-record / 6-promotion typo -> 5 transition records

B. NC31 / recovery-report decision

Preferred:

real after-anchor-pending crash
restart
reservation cancelled
recovery-report explicitly says it cancelled an unused reservation

If the architecture deliberately treats this cleanup as non-reportable, document the exact contract and make the control test that contract.

C. After NC31

If clean, freeze R0.8 under the explicit process-crash/single-host profile.

D. Super

Extend E-51 with:

effect-time revalidation after claim but before irreversible effect

Then implement E-50a/E-50b in the owning Super/ampd lane.

E. TRVM

Govern E-42/E-43.

F. Factory

Mint / adjudicate:

FAC-CONTROL-SENSITIVITY = DECLARED

FAC-EVIDENCE-TRANSITION-SCHEMA-CLOSED
    = PROVED in declared structural domain

and introduce an actual station receipt that binds:

inputs
generator
projection
validator
result

G. L1

Keep enablement as one semantic system obligation for now.

Decompose it only after an independence/falsification result demands it.

H. EMB-E1

Still operator-gated.

No spend authorization is implied.

16. Final ruling

v5 is a successful execution return precisely because NC29 did not merely go green.

It exposed that endpoint provenance was insufficient:

OURS AT COMMIT
!=
OURS THROUGHOUT THE TRANSITION

and then exposed that an authorization itself has a lifecycle:

AUTHORIZED
but never used
must not remain spendable forever

R0.8.7 repairs both exact defects coherently.

The resulting semantic picture is cleaner:

anchor reservation
    authorizes a specific successor

root pending
    proves the transition actually entered the durable recovery protocol

replay
    may complete an existing authorization
    never create one

unused reservation
    is cancelled after verified recovery

committed successor
    must be the exact authorized head

That looks like a total phase model of S3 successor provenance, not another new primitive.

The one thing I would still resolve before the final R0.8 freeze is whether a trusted-anchor cancellation during recovery is visible in the trusted recovery-report.

After that, if no new process-crash defect appears:

freeze R0.8 within its declared profile and move on.

No broad Fable invariant-search round is warranted.

Next loop:

v2.8
-> NC31
-> R0.8 freeze decision
-> Super E-50 effect-time model
-> TRVM governance
-> factory station receipt / promotion round
-> GPT adjudication

Open in the interactive atlas