Proposal: runnable reference scenario for unreachable escalation authority and revocation after dispatch

First resolve the requested decisions: whether this belongs in the community integration or a separate example, and which released runtime/API and TRACE profile to target. Then inspect the merged runner and fixture from #288 and the 14-field contract at integrations/alakris-authority-comparison/comparison-contract.json. Done means a runnable, evidence-backed scenario meets the listed acceptance criteria without claiming unsupported runtime capabilities.

Human-directed proposal for Vladislav Kostitsyn, following Imran's October 15 guidance. @carloshvp (primary), @rajnisht7 (backup): could you confirm the scope, runtime entry point and placement below?

An agent cannot reach its escalation authority; alternatively, authorization valid at dispatch is revoked before the protected effect commits. The proposed reference should make the permitted behavior and the observed effect independently inspectable.

Existing baseline and proposed next step

The shared AAIF evidence-appraisal runner and synthetic executor fixture are already merged through #288, with the provenance clarification in #315. This follows #287 and AAIF WG #13.

The next contribution would connect one agreed AgenTrust runtime path to a disposable protected-effect target and retained target-side observations, building on the fixture rather than claiming that another synthetic counter is new. This issue proposes that work; it does not report a completed integration or independent reproduction.

Proposed acceptance criteria

• Declare the authorizer, escalation authority, executor, target, policy, original deadline, trusted components and precise effect boundary. Use synthetic identities and a disposable local target.
• Unreachable authority: record an explicit refusal or a previously authorized, bounded fallback under the declared policy. No current authorization or applicable fallback means no protected commit. Restored connectivity must not reopen the original expired request; a newly authorized request is distinct.
• Revocation after dispatch: arrange revocation after admission/dispatch but before the executor's final commit check, retain that ordering and observe the target result. State when revocation became visible to the executor; do not claim retroactive cancellation of an already committed effect or a general propagation SLA.
• Controls: a fresh valid authorization commits exactly once; action/target substitution, forged dispatch, duplicate delivery and expired-request recovery exercise explicit refusal or deduplication outcomes. Uncertain external outcome must remain unknown, not inferred from a receipt.
• Keep authority, decision, dispatch, committed effect, task outcome and receipt separate, using the existing 14-field contract and evidence states. Publish exact released dependencies, source/build pins, invocation, environment, raw artifacts and hashes.
• Map the selected released APIs to TRACE references and external execution evidence. A digest, signature or reporting flag alone does not establish an external effect or independent execution. Scenario-local correlation IDs must not be presented as implemented native protocol support.

Validation and boundaries

On October 17, I reran nine existing synthetic boundary tests: unavailable authority, post-dispatch revocation, expired recovery, valid control/duplicate, action tampering, late veto, forged dispatch, veto and prior revocation. All passed against a checkout whose tree exactly matches merge 12353a2b84cb08498221c92965092f70784aa4d7. These validate the existing synthetic baseline only.

egsim research, author-operated implementation records, offline evidence appraisal and independent operator runs remain separate. Radiolaria's proposed restart/source-applicability row remains supplementary; it does not fill a protected-action control. No production, hardware isolation, universal mediation or certification claim is proposed.

The cMCP execution-correlation foundation explicitly remains non-operational. The example must use an implemented released seam or label an adapter-level boundary; gaps belong in the owning core repository. Related scope discussions: #199, #290.

Decision requested: should this extend the existing community integration or live as a separate reference example, and which released runtime/API and TRACE evidence profile should the first implementation target? An Alakris product integration can follow after this scenario is agreed and lands.