Re: Four open questions on the Agentic Web report (2026-09-24): preimage defense, address assurance, trust leases, statement granularity

Abisheak, Larry, Alan, Lars, Tymofii,

Abisheak -- you said you are putting justification_receipt and the VOC caveat
into Pillar 2 today, so this is one narrow point sent before it lands rather
than after.

I am not objecting to VOC. Your line in 0105 is right and I would not change
it: the accountability layer judges, the wire records, the protocol does not
read the opinion. What I want to add is one field, because of what follows
from that sentence.

1.

In 0105 the flow is: the sidecar verifies the signature, appends the reason
and the current registry state, and transitions to RESUMED.

Signature verification is an authenticity check. It tells us who signed. It is
not a restore-condition check -- it says nothing about whether the condition
that caused the halt still holds. So as written, verifying a signature is a
sufficient condition for RESUMED.

Two runs now reach the same end state and produce records that look identical:

  (a) the condition that caused the halt was verified as restored; and
  (b) someone with authority accepted the risk and proceeded anyway.

Both are legitimate outcomes, and neither is a defect. But an auditor reading
the record afterwards cannot tell which one happened. That is the specific job
you asked the record to do -- "immutably recorded for audit" -- and an
immutable record that cannot separate (a) from (b) is immutable without being
informative.

2.

The natural answer is that the reason is already in the record, so the
auditor can read it. I do not think that closes it, and the reason is the one
Lee has been making about closed sets all week, applied to a different object.

The reason is free text. A hash chain guarantees it was not altered; it does
not make it aggregable. An auditor who wants to know how many halts in a
quarter were reopened on evidence and how many on exemption has to read every
reason in the log and form a judgment about each. That is not an audit, it is
a reading assignment -- and at the volume this is meant for, nobody will do
it. Worse, the one query that matters most -- "show me every chain that
resumed after a revocation" -- is the one that free text cannot answer at all.

What makes a dimension auditable is not that a human wrote something down. It
is that the value is drawn from a closed set, so it can be counted, alerted
on, and recomputed by a third party who does not trust the filer.

3.

So, one field:

  resume_basis = evidence | exemption

  evidence   the registered restore condition was verified in full
             (evidence list, verifier role, validity window)
  exemption  an accountability layer accepted the risk; the reason is
             recorded, not evaluated

Both values permit RESUMED. I am not adding a state, not removing one, and not
touching the state space: the chain stays REGISTERED -> GATE_PASSED -> ACTIVE
-> ANOMALY -> PAUSE -> ROLLBACK -> REVERIFY -> RESUMED. The only change is
that a RESUME receipt says which door it came through.

Note what this field is not. It is not the protocol forming a view about the
justification. It is the protocol recording that it did not form one. Because
the protocol does not evaluate the opinion, it has to record that it did not
evaluate it -- otherwise the absence of evaluation is invisible, and invisible
is where an auditor's question goes to die.

4. Two boundaries I would write into the schema

Without these, VOC is not a path through the halt, it is a path around it.

(i) exemption does not cover authority_revoked.

Revocation is the issuing authority's decision, not the executing side's. A
manager on the executing side can accept a policy violation; he cannot
un-revoke someone else's authority. If a signed justification could open
RESUMED after a revocation, then revocation is advisory for anyone who has a
manager -- and the manager becomes the shortest path around the only mechanism
this design has for taking authority away.

(ii) exemption does not cover authority_not_determined.

That value means the registry could not be read, or the proof was against a
stale root. It is an absence of information, not a judgment about
information. A signature cannot convert "we do not know" into "we know." This
is the fail-closed property you asserted on 29 October, and a signed exemption
must not be able to buy it back.

In a receipt these read:

  exemption_covers         = policy_violation
  exemption_does_not_cover = authority_revoked, authority_not_determined

5.

One anticipation. If the answer is that STRICT is the default and VOC is an
explicit choice, so the exposure is bounded by the choice -- that is true, and
it is not the case at issue. The cases that reach an audit are exactly the
ones where someone chose VOC. The default value tells us nothing about them;
that is what makes them cases.

If the view is that the field belongs in the lab's decision record rather than
in NTI's schema, I have no stake in where it lives. The claim is only that it
has to exist somewhere on the wire, because it is the one bit that separates
two outcomes a records reader otherwise cannot separate.

Larry -- the runnable sidecar and the field list are in a separate note to
you; the receipt fields above are drawn from the same list, so the two should
line up.

This field is now written into the v0.1.4 revision of the transition-contract
spec (resume_basis plus the two exemption boundaries), enclosed with Larry's
note and available on request -- so the proposal has a frozen text behind it,
not only this email.

6.

One more, because it is the same day and the same state machine. In 0102 you
accept AlgoVoi's point 3 and say you will add a terminal REVOKED state to the
LGD state machine, with lease-renewal semantics. I would ask you not to.

In that sequence revocation is not a state. Expiry and revocation enter
through ANOMALY, and the refusal side is already carried by the boundary
values: a post-revocation new call is DENIED. Irreversibility does not need a
node of its own. Where a governing regime makes a revocation irreversible --
eIDAS Art. 28(4) is the instance in scope -- what becomes unavailable is the
REVERIFY -> RESUMED edge, not a new state: the chain remains in PAUSE, or in
ROLLBACK where the last checkpoint fails its integrity check, and no lawful
successor reaches RESUMED. Two things are preserved that a terminal state
loses: the state space stays finite and enumerable, so a conformance suite can
still cover it; and the irreversibility stays auditable where it belongs, in
the transition that is missing rather than in the label that is stuck.

Lease renewal belongs to the lease layer. Defining it there changes nothing in
the chain.

The transition-contract note, with the three contracts and the registry
split, follows on the halt thread.

Best regards,

Xinghua Zhao
Independent researcher (SynomosAI initiative)
ORCID: 0009-0001-0512-1237

[Disclosure: drafting of this message was assisted by AI; all positions
reviewed and approved by me.]

Received on Friday, 30 October 2026 05:33:52 UTC