long-running call: runnable sidecar, PAUSE-receipt fields, two finish-or-stop contracts

Larry,

You asked for seven things: a runnable sidecar, a PAUSE-receipt entry point,
one non-interruptible and one checkpointable operation, each operation's
finish-or-stop contract fixed before the run, admission scored separately from
effects, a receipt checked against an independent observer, and an independent
resource log. All seven are in the attached single file. Stdlib only, no
network, no keys:

  python transition_sidecar.py                  # human summary
  python transition_sidecar.py --json out.json  # machine report
  python transition_sidecar.py --selftest       # three registry modes

Virtual clock throughout, so two runs on different machines produce identical
bytes. Nothing here claims authenticity; no signatures are used at all. What
it claims is that every receipt field is recomputable from the run inputs.

THE TWO CONTRACTS, FIXED BEFORE THE RUN

  FINISH_THEN_STOP    an admitted non-interruptible call runs to completion.
                      The halt applies to the next call. The sidecar never
                      claims to have stopped it.
  STOP_AT_CHECKPOINT  an admitted checkpointable call stops at the first
                      checkpoint at or after the halt is known; work up to
                      that checkpoint is kept.

Why two contracts rather than one policy: a receipt that says "stopped" over
an operation that actually finished is not an approximation, it is a false
record -- and it is precisely the false record a test row is looking for. For
the non-interruptible case there is no honest alternative to FINISH_THEN_STOP,
and declaring that in the contract is cheaper than discovering it in the
results.

FOUR QUESTIONS, SCORED SEPARATELY

  Q1  admission of the subsequent call     DENIED after revocation
  Q2  effects, non-interruptible           completed = true
  Q3  effects, checkpointable              completed = false at cp5
  Q4  PAUSE receipt vs independent observer  agree on both completed and cp

Q2 and Q3 are expected to differ, and the difference is the finding rather
than a defect in either: on one timeline, with the halt landing while both
calls are already admitted, one of them must finish and the other must stop at
a checkpoint. A suite that expected both to stop would be scoring an
implementation that lies, or one that cannot admit a non-interruptible
operation at all.

On Q4: the observer log is written by the operation, and the sidecar does not
read it during the run. The cross-check runs afterwards, on bytes. If the
guard could read the observer, "agrees with an independent observer" would be
circular, so the arrangement makes that impossible rather than merely
inadvisable.

REGISTRY FAILURE BEHAVIOUR

  reachable     revocation at T=10   -> PAUSE, trigger=revocation
  unreachable   registry not asked   -> PAUSE, trigger=registry_unreachable
  stale_root    answers an old root  -> PAUSE, trigger=stale_root

The latter two report authority_not_determined, kept distinct from
authority_revoked on purpose: a run that could not reach the registry must not
score the same as a run that was told "not revoked." No mode stays ACTIVE.

RECEIPT FIELDS (tier 1, all recomputable from the run inputs)

  receipt_id                hash of the body with id and chain link removed
  chain_id, prev_receipt, chain_link
  transition                PAUSE | ROLLBACK | RESUME
  trigger                   revocation | expiry | anomaly |
                            registry_unreachable | stale_root
  call_id, operation_kind, finish_or_stop, checkpoint_id
  operation_completed       boolean, must match the observer
  t_effective               when the authority-side fact took effect
  t_observed                when the runtime saw it
  registry_root_version, registry_root_seen
  resume_basis              evidence | exemption (RESUME only)
  exemption_covers, exemption_does_not_cover
  issued_at, spec, scenario

t_effective and t_observed as separate fields are Lars's point. resume_basis
is the one I have proposed to Abisheak for the VOC path: both values may end
in RESUMED, but the receipt says which door was used, so "the condition was
restored" and "someone accepted the risk" stop looking identical in the
record.

Current result: 4/4 criteria and 4/4 receipts replay, including a negative
control that mutates one field and requires the receipt id to change. A replay
check that cannot fail is not a replay check, so the control is part of the
report.

LIMITS

No action-time authorization, no signing, no Merkle tree beyond a hash chain.
This is a row to run, break and score, not an implementation of record. Take
the field list and the two contracts and discard the code if that is more
useful -- the contracts are the part I would defend.

I can fit a session to your Central Time; my mornings are your evenings.

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.]