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

@carloshvp

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.

@wlad232

@wlad232 @carloshvp, Proofable can be one of the implementations for this scenario.

Our hosted service checks authority at dispatch and runs the job, so both cases hit a real executor. The eight production cases and their public records: https://docs.proofable.me/use-cases/authority-at-dispatch. What we cannot show ourselves is the effect observed at the target by someone else, which a disposable target you control would add.

We can provide the released entry points (hosted MCP at https://mcp.proofable.me/mcp, @proofable/sdk 0.1.6), 30 days of Pro for the operator account, and our kit as a starting harness.

Proofable checks authority at dispatch, not again when the executor commits, so in the revocation case the running write commits and the next dispatch is refused. A target-side observation would confirm that independently.

@chrisjleal

@chrisjleal Thank you—the released entry points and dispatch-only boundary make Proofable a useful candidate profile for this proposal. A write allowed at dispatch that commits after revocation, followed by refusal of the next dispatch, should be recorded as that observed behavior; it would not satisfy the separate final-commit-recheck property proposed above.

I inspected the published reproduction kit at proofable/docs@d1a17c5e1c318eb21f8a9461b52efaf61481bee4: its ordered write uses a file inside the hosted computer and reports platform completion, so it does not yet give an operator-owned target observation. Could you identify the supported way to direct one bounded marker action to an operator-controlled disposable target and bind the target's attempt/payload/readback to the job and authority decision, or confirm that a kit extension is needed?

The new packet's offline appraisal is recorded in WG #13; no live run or operator account has been activated by this review. @carloshvp @rajnisht7, runtime/profile placement remains your decision before an implementation or hosted-account setup proceeds.

Supplemental target-observation acceptance contract for the existing owner's scenario. This is a design contribution, not another executor implementation, a host offer or a live run. Runtime/profile placement remains with the existing owners.

The latest Proofable discussion distinguishes dispatch-only authority from final-commit rechecking. The target should measure that distinction.

Bounded target: one disposable marker namespace using synthetic random data, outside the executor's administrative custody. Independently enroll the target observer's key. Retain run/attempt ID, exact marker or synthetic-data digest, namespace, bound job/decision evidence, target ingress, durable commit and readback as separate observations. A caller-supplied job ID remains a correlation hint until its relation to authenticated executor evidence is established.

Target deduplication can yield one effect despite multiple ingress attempts. Retain both counts so deduplication does not conceal duplicate dispatch.

Pair	Required observation / limit
Valid authority / unreachable authority with no authorized fallback	One bounded commit / refusal before effect; an unobserved target does not prove absence
Connectivity recovers before / after original deadline	Eligible continuation / no revival of the expired attempt
Revocation after dispatch, dispatch-only / final-commit-recheck profile	First may commit and refuse the next dispatch / second needs observed refusal before commit
Legitimate marker/target/job / substituted binding	Correct effect / named refusal or unavailable relation
Single / duplicate request	Report ingress and effect counts separately
Commit with response / commit with lost response	Target effect may be established by readback in both; client delivery remains unknown in the second
Complete target observation / observer unavailable or incomplete visibility	Evidence-backed outcome / unknown, never zero-counter inference
Enrolled observer / substituted signer or prior-run receipt	Accepted observation / trust or run-binding refusal

Use barriers or causal evidence for dispatch, revocation observation and final authorization. Clock timestamps alone do not establish that the executor saw revocation before commit. No general propagation SLA follows.

Planned controls remove evidence-binding/outcome gates individually while preserving valid twins. A checker reporting no effects everywhere needs to fail the positive control. No such controls or live target run are claimed executed here.

Prerequisite: the selected released runtime needs a supported outbound operation to the operator-owned target and usable job/authority binding, still being clarified in this thread. Once placement and a target operator are established, this matrix can support independent verification within #333/#199. No hosted account, external endpoint or hardware resource has been activated.

@dinakarjs

Thank you @dinakarjs. This is a useful supplemental acceptance checklist for #333: authenticated job/run binding, separate ingress and durable-effect counts, independent readback, and unknown when observation is incomplete. The paired controls also preserve the distinction between dispatch-only authority and a final-commit recheck.

The released-runtime/outbound-target operation and authenticated job/authority-binding questions in my previous comment remain open. Your matrix gives us a concrete checklist for evaluating that connection once it is available.

Runtime/profile placement remains with the existing maintainers. This records a design contribution; no target deployment, account activation or live run is being claimed.

@carloshvp

@carloshvp @rajnisht7 wlad232 is waiting on three answers from the proposal above: the scope, which runtime entry point to use, and where the scenario lives in this repo. Could one of you reply by Thursday 23 October?

@imran-siddique

Thanks @imran-siddique. Scope, the released runtime entry point and the repository location are the three decisions needed to proceed; the supplemental target-observation checklist is already in this thread.

Small scheduling check: 22 October 2026 is Thursday, while 23 October is Friday. Which date did you intend for the maintainers' reply?

I can offer independent evidence review and acceptance testing once the released-runtime connection and a target operator are established. I would review the retained packet and paired controls independently of the executor's own completion report, with the review role and any shared implementation work disclosed.

To make the three pending decisions concrete, my recommendation is:

Scope: start with one declared runtime/profile, one bounded synthetic marker operation and one independently controlled disposable target. Reuse the existing 14-field comparison contract and the target-observation checklist already in this thread; avoid another synthetic executor counter. Cover a valid control, unreachable authority without an authorized fallback, and revocation after dispatch. Keep ingress, durable commit, readback and client response distinct, including explicit unknown outcomes. Additional substitution/replay cases can follow the same bounded contract.
Released entry point: Proofable is a candidate dispatch-only profile based on the provider's offer above, not a selected or independently validated integration. Before implementation, obtain the exact released invocation for writing to the operator-controlled target and evidence authenticating the job/attempt, payload and authority decision relationship. A caller-selected job ID alone is insufficient. If that requires a kit extension, record it as a prerequisite rather than claiming the current kit already supplies it. For this profile, a write authorized at dispatch may commit after revocation while the next dispatch is refused; final-commit rechecking is a separate property. If the first slice must instead use a native AgenTrust runtime path, please select an implemented released seam before proceeding; the non-operational execution-correlation foundation is not a substitute.
Repository placement: prefer a small extension under the existing integrations/alakris-authority-comparison/ integration, reusing its comparison contract, with runtime-specific adapter/fixture separation. The proposed informative procedure in docs: scope EO01–EO08 as the #333 effect-observation checklist #352 can supply the review checklist, subject to placement approval; it does not require a new tracker or competing core protocol.

For acceptance, I would look for exact source/package/build and policy pins, independently enrolled target observation, authenticated operation binding, causal ordering for revocation visibility, separate ingress/effect counts, and valid controls alongside each refusal. Download/hash verification, offline appraisal and a separately operated live run would be reported as different evidence levels.

Carlos/Rajnish retain the scope, runtime/profile and placement decisions; Vlad retains the proposed scenario's implementation role. This offer does not commit a host, account activation, spending or a live run before the prerequisites are agreed. The intended 22/23 October reply date remains for Imran to clarify.

Prepared with Codex.

@dinakarjs

Thank you @dinakarjs. Your review offer, with the review role and shared implementation work disclosed, will be useful for this scenario. The proposed first slice is appropriately bounded: one runtime/profile, one synthetic marker operation and one independently controlled target, using the existing comparison contract and paired controls.

Once Carlos/Rajnish confirm scope, the released entry point and placement, and the supported outbound operation plus authenticated job/payload/authority binding are established, I can prepare the pinned adapter change and retained packet for review here. We will keep offline appraisal, acceptance testing and a separately operated live run distinct. No target operator, hosting or account provisioning is being assumed from this offer.

docs: qualify Proofable candidate and reconcile current main

@wlad232

@wlad232 @imran-siddique @dinakarjs @chrisjleal @carloshvp sorry for the delay, catching up properly here.

I pulled the alakris-authority-comparison tree (commit c5a0b8c) and ran it: hash-verified install, full test suite, fresh fetch of both Proofable packets, and the MintID outage records too. The corrected Oct-8 Proofable packet matches the committed results semantically, integrity PASS, all 11 envelope verdicts valid, file digests match. Serialized key order differs from what the current runner emits, the parsed content is the same. For the unreachable case, receipt stays not_applicable, receipt-signature verification stays not_measured, and committed_effect / task_outcome stay not_emitted, the public trace has platform outcomes, not target-side effects. The historical packet still fails its strict byte check as expected.

Re-running the appraiser against the pinned local and testnet MintID records reproduces the committed parsed appraisal results: integrity PASS and matching pinned artifact/manifest digests. These remain author-record reports, not independent live reproductions of the outage or independently observed target effects; both records explicitly mark independent_live_reproduction and independent_target_observer as false. See TRACE's own verification documentation on what a signature or hash match does and doesn't establish. The local MintID author record specifically (the testnet record has no published observation for this case) reports a node-paused, state-unavailability interval of 40.2 seconds and the first recorded acceptance 0.9 seconds after restoration, a measurement from that published record, not an independently verified service
guarantee.

results/tests.txt still says "Ran 27 tests," while this revision collects 34 cases. My run with both fixture sets present, completed with 34 tests and zero skips. The transcript regenerated from this exact revision and checked into the same change so the recorded output
matches the tested source.

On scope: the synthetic fixture's unreachable case sets executor.online to False, that's executor unavailability, not authority unavailability, and it doesn't model the latter independently in its current form. Proofable's own current evidence marks its unreachable case not_applicable, authority's evaluated locally there, no remote authority dependency on that path, so it can't demonstrate this case either. The published MintID author record could support this case, subject to acceptance. Alternatively, the synthetic fixture would need to be extended to model authority availability independently of executor availability, or another released runtime could demonstrate the case directly. That remains a scope decision for the team rather than something would settle here. Either way, the negative case needs the same rigor as the positive one: ingress observations, durable-effect count, and readback captured separately, protected effect count at zero, not inferred from a missing completion report.

The positive control also needs its own pass through the same hosted target and observer pipeline, not the synthetic Executor's in-process case. A fresh valid authorization must produce exactly one independently observed durable effect.

Runtime entry point, as a recommendation not a final call: start with Proofable for the dispatch-only / revocation case, labeled as dispatch-only in the fields themselves. cMCP's ExecutionRegistry isn't an option here, its own spec marks it non-operational, see
Non-operational foundation (#606). Chris, we'd still need the exact released call for writing to an operator-owned target and binding the readback to the job and authority decision.

Placement: extend integrations/alakris-authority-comparison/ directly, reusing its contract and CI. Per our README, examples/ is for first-party and invited-partner work, integrations/ is for adapters and verifiers like this one. For acceptance-procedure coordination, I suggest keeping the reusable procedure in #199 and treating the EO01–EO08 matrix in #352 as this scenario's checklist, not a second procedure document.

Those are my recommendations on scope, runtime entry point, and placement. Corrections welcome if anyone has a tighter read on the authority-unavailability path or the outbound prerequisite.

docs: narrow effect acceptance to the agentrust-io#333 scenario check…

Follow-through on Rajnish's review: I updated #352 at aa890e7 to retain only this scenario's EO01–EO08 checklist. The reusable procedure remains in #199; the duplicate general evaluation procedure has been removed. The draft keeps its existing path pending final placement confirmation.

The checklist now requires each negative case and its fresh valid control to use the same hosted target and independently enrolled observer pipeline. Ingress, durable-effect count and authenticated readback are separate observations. The valid control must show exactly one durable effect; the protected refusal must show zero within a complete bounded observation window. Missing completion or incomplete logs remain unknown.

I also made the scope gap explicit: switching executor.online off does not independently exercise authority unavailability. Proofable's current local-authority path cannot fill EO01. Proofable remains a dispatch-only revocation candidate, labeled in the result fields, with no measured commit-after-revocation claim.

Remaining handoff:

Carlos/Rajnish: confirm final scope/profile and placement, including which evidence path covers authority unavailability. I have not treated the recommendation as final approval.
Chris: provide the exact released outbound invocation plus authenticated job/attempt/payload/authority-to-readback binding.
Vlad: once those prerequisites and a target operator are established, retain the pinned adapter and packet; regenerate results/tests.txt from the tested revision with both fixture sets, reporting actual counts. Rajnish's 34/zero-skips result is attributed to his run, not a new run by me.
My review offer remains: inspect the retained packet and paired controls once available, with shared implementation contributions disclosed. No independently operated live review is claimed complete.

Published text was read back and matched; eight matrix rows and whitespace were checked. This was documentation work only. #352 remains draft; no host/account, live run or issue closure is implied. Prepared with Codex.

@wlad232

@wlad232 @rajnisht7 @dinakarjs thanks. Here is the released call, run against our live service.

Route: a job whose one permitted action fetches the operator's own public endpoint. The operator puts its URL and a marker it generates in the job prompt; the run fetches it and the response is recorded. This needs nothing from the operator but a public URL, no harness, no account, no provisioning. Job 8c387a04-1c47-4e5f-9a46-6dc64b611930 completed under a declared acceptance criterion with an accepted outcome, one tool call (proofable_url_fetch), 0 failed. Our outbound policy refuses local, private, link-local and cloud-metadata hosts, so the target must be publicly reachable.

Binding: the create response returns the job id and the signed dispatch decision's record id together. The decision is signed by the service over the request as sent and carries a digest computed over the agent, wallet, prompt, runtime, approval flag and acceptance, so the operator recomputes it from its own retained request bytes and the decision commits to the exact call, with the marker inside those bytes.

Two limits stay open, and I would rather name them than have them found. The decision's own job field is null, because it is recorded before the job exists; the binding is the create response plus the recomputed digest, not a job id inside the decision. And we do not sign the request at the point it reaches the target, so the link between target ingress and the job rests on the marker. Under the checklist that is a correlation, not authenticated executor evidence.

We also offer a stricter route: a job pinned to an isolated computer the operator configures through their own vault record, which places the run on the operator's machine rather than ours. It requires the operator to run an ACP-compatible HTTP harness (session create, then message), which is a real setup cost and the reason we lead with the fetch route.

Profile: dispatch-only. The executor re-reads the delegation before every tool call, so a revocation visible before the call refuses it; one that lands mid-flight does not stop it, and nothing rechecks authority at the target's commit. That last behaviour is observed on our platform only, as #352 says; an operator-owned target is what would measure it.

Scope note: our unreachable-escalation case is not applicable at our boundary, because authority is evaluated locally on that path, so it does not demonstrate authority unavailability. We are not claiming it does. A target operator who can make the authority itself unavailable would cover that case; we can cover the dispatch-only revocation and valid-control halves.

@chrisjleal

@chrisjleal reviewed the clarified route and binding description. The fetch route is useful as a correlation-only target observation, with your two limits retained: the dispatch decision's job field is null, and target ingress is linked by the marker rather than authenticated executor evidence. I have not independently executed job 8c387a04 or its target observations.

For #352's handoff, I would retain dispatch-only classification and keep both the authority-unavailability row and target commit-time recheck unestablished by this route. A fresh valid fetch/paired refusal can test its narrower dispatch boundary; a reported accepted task alone cannot substitute for target-side durable effect evidence or a complete refusal-observation window. The existing EO checklist already carries these distinctions, so another procedure/page is unnecessary.

The remaining prerequisites are the maintainer-selected scope/placement and an operator-owned target plus retained, version-pinned request/decision/observation packet. Please include the exact released invocation/request bytes and bindings in that packet, with synthetic identifiers and no credentials, once those owners are selected. My bounded packet-review offer remains. No new live run, extra account/harness setup or full #333 acceptance is claimed. Prepared with OpenAI Codex.

@rajnisht7

@rajnisht7 @chrisjleal @dinakarjs Thanks for the review and clarifications.

Rajnish, I checked the fixture: executor.online = False models executor availability, not a separately unavailable authority. I will not count it, or Proofable's locally evaluated authority path, as demonstrating EO01. A published MintID author record remains a separate evidence input, subject to the agreed scope. The hosted positive control and protected negative must use the same target/observer path; zero durable effects requires complete observation, not a missing completion report.

Chris, your described fetch route is dispatch-only and correlation-only. The delegation reread before each tool call remains distinct from mid-flight cancellation or a target-commit authority check. The decision's null job field, create-response association and marker-based ingress correlation stay explicit; I have not independently executed job 8c387a04-1c47-4e5f-9a46-6dc64b611930.

Could you share an immutable, synthetic example packet containing the exact released invocation (method/endpoint or SDK call and version), request JSON/bytes, create response, signed dispatch record and request-digest recomputation recipe? The description gives the route but not yet a copyable call or retained records. Please omit credentials and identify the unsigned/correlation-only links. This will let an operator review the narrower route before arranging a target or harness.

Dina, agreed: keep the reusable procedure in #199 and #352 as this scenario's checklist. Extending the existing integration is the proposed placement; final scope/profile, EO01 treatment and the target operator still need confirmation. The next adapter change should carry its own regenerated transcript from its exact tested revision; the committed 27-test transcript must not be presented as the current run.

@carloshvp @rajnisht7, could you confirm the scope and placement for the next change: whether to proceed with a dispatch-only, correlation-only first slice in this directory, keeping EO01 and authenticated target effects explicitly unestablished? This would not close #333.

I also reran the existing package at c5a0b8c34378c7c57f7f48bd5c9f852345203f9a with Python 3.12.4 and a fresh hash-locked install: check_package.py --fetch exited 0, 34 tests passed with zero skips. Corrected Proofable and both MintID appraisals matched the committed parsed results; the historical Proofable checksum failure remained a failure. The fresh transcript is retained for the next change; no committed source or historical evidence was rewritten. This is local testing/offline appraisal, not a new independent hosted execution.

Exact-pin check record

Package tree: d3c9534ac115f975df1bec41226ceab00d867a4b.
Install: pip install --require-hashes -r requirements.lock; pip check passed.
Check: python check_package.py --fetch; 20 immutable fixture hashes matched the download lock.
Transcript: Ran 34 tests in 6.106s, OK, no skips.
Transcript SHA-256: f5cd02c468a9acd748ef4eea33d68c4801531fca543bc5676576fbb7642402d0.

Vlad / Alakris

@wlad232

@wlad232 here is the packet you asked for:
https://github.com/proofable/docs/tree/e6eb5b9307be24a5d82cc7490f647f0c98e2d24a/public/evidence/aaif/authority-at-dispatch/2026-10-24-fetch-route

It holds the exact call (proofable_job_create on https://mcp.proofable.me/mcp, hosted MCP 0.1.7), the request arguments as sent, the raw create response, the signed dispatch decision and terminal receipt, and the digest recipe. node verify.mjs checks all of it offline. The README names which links are signed and which are correlation-only. No credentials are included.

@chrisjleal

@chrisjleal Thanks — the concrete MCP call and retained packet answer the request. I checked proofable/docs@e6eb5b9307be24a5d82cc7490f647f0c98e2d24a offline:

Fetch route, service revision 18433a48d74af913550de7a018f02c7c724cc1c9, hosted MCP 0.1.7: all 9 listed checksums matched; the unmodified node verify.mjs exited 0 with 8 MATCH checks, including both signatures/qHashes and the request digest.
Separate served packet, service revision 61724c9f4592f00858a31ef0ac7fa4dcdc67e160: all 9 listed checksums matched; the pinned reproduction kit's offline verifier exited 0 for 8 cases and 17 envelopes, using its committed dependency lock (@proofable/sdk 0.1.6, ethers 6.17.0).

These are independent offline checks of Proofable-published records, not an independent hosted execution or target observation. The two runs/revisions stay separate; EO01, revocation latency and target-commit effects remain unestablished by these checks. No vendor jobs or target requests were made.

Two small documentation corrections:

The request projection binds the unique URL in prompt and the generic acceptance.criterion value target-ack; the full returned marker appears in the signed terminal receipt, not in the request prompt. The decision does not precommit that full marker.
Please narrow the served README's blanket “refused before a job was created” statement: binding_veto has a job ID and ends failed without an executor; approval_unavailable also has a job ID and ends cancelled by the owner. Pre-creation denial and refusal before execution are different observations.

Could you point us to the canonical service-signing-key publication for an out-of-packet trust pin? The fetch verifier recovers each signature against its envelope's declared wallet; attributing that key to the service remains a separate trust step. The absent grant/agent-identity records and the unsigned decision-to-job/correlation-only target links remain explicit limitations.

This supplies a reviewable candidate route. The scope/profile/placement decision and an operator-owned target/observer are still outstanding; this does not close #333 or add Proofable to the frozen Round 1.

Vlad / Alakris

Maintainer scope decision: proceed with a bounded dispatch-only first slice in integrations/alakris-authority-comparison/, following Rajnish's placement recommendation. This extends the existing community integration and its comparison contract.

For the first PR:

Use the immutable Proofable fetch-route packet at proofable/docs@e6eb5b9307be24a5d82cc7490f647f0c98e2d24a, with the documented proofable_job_create invocation on hosted MCP 0.1.7, as the candidate dispatch evidence. Keep the fetch route and the separate served packet/service revision distinct. This first slice is an offline adapter/appraisal of the published records, not a new hosted run or an implemented cMCP executor seam.
Retain released agentrust-trace==0.11.0, the existing 14-field contract, external-evidence-source role and behavior-trace reference shape. No TRACE conformance level or tier promotion is introduced. Represent unsigned decision-to-job and target correlation links as correlation-only in the fields and reasons. Signature recovery against a packet-declared wallet does not independently attribute that wallet to the service; the canonical service-key trust pin is still needed.
EO01 authority-unavailability remains an unmet scenario requirement on this route. Executor unavailability is a separate condition. Keep target commit, independent observer, revocation visibility/latency and protected effects unestablished where evidence is absent; do not turn an unmet required case into a passing not_applicable result.
Regenerate the transcript from the exact submitted adapter revision, retain immutable raw-artifact hashes and invocation details, and add negative controls for altered request binding, signatures and correlation. Preserve the historical failing packet and its recorded failure.

Issue #333 stays open for the composed runtime/target scenario. The later effect-observation slice needs a named operator-owned disposable target, an observer, a same-pipeline valid control with exactly one durable effect, and negative-case readback showing zero effects. Use #199 for the reusable acceptance procedure and #352 for this scenario's EO01-EO08 checklist. The dispatch-only slice establishes none of those later acceptance results.

Prepared with OpenAI Codex.

@imran-siddique

@imran-siddique @carloshvp @chrisjleal — the agreed bounded offline fetch-route adapter is ready in PR #399, exact head 7d3960d4debf73c300aaee0aa5d5d12502c00ffb, using the immutable proofable/docs@e6eb5b9 packet.

The exact-head evidence CI passes: 54 tests normally and under -O, ten pinned fetch artifacts, 18 semantic checks and 30 reference shapes; request/signature/correlation counterexamples and input-preservation regressions are included. Lint, repository validation, CodeQL and the other execution checks also passed.

The four comparison scenarios remain UNMET. Canonical service-key attribution, grant/identity validation, EO01, an independent hosted run, target commit/witness and revocation latency remain unestablished; the historical checksum FAIL and old author reports are preserved.

The PR awaits current-head maintainer approval. The separate repository-wide link check fails only on the existing Nobulex URL returning HTTP 451 in its unchanged README/manifest (log); no link failure is reported in the changed Alakris files.

Could you review the bounded slice or assign its reviewer? Issue #333 remains open for the later named operator/owned target/independent observer and effect controls, using #199 and #352 for acceptance.

Vlad / Alakris — prepared with OpenAI Codex.

@wlad232

@wlad232 thanks for checking both runs. Both corrections are in proofable/docs@2187303:

Fetch route. The README now says the request carries the run URL and the generic target-ack criterion. The full marker first appears in the signed terminal receipt, so the decision does not precommit it.
Served run. The README no longer says every refusal came before a job existed. binding_veto created a job that ended failed with no executor; approval_unavailable created a job that the owner cancelled before it ran. The other refusals created no job.

Only the two READMEs changed, plus the README line in the fetch route's SHA256SUMS. The run files, verify.mjs and the served packet's checksums are unchanged, so the e6eb5b9 pin in @carloshvp's scope decision still covers every run file.

The service-key trust pin is published outside the packets as x_proofable.receiptSigner in proofable.me/.well-known/agent-registration.json. Proofable's ERC-8004 identity points to that file on-chain: agent 1135859 in the Identity Registry on Base (eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432), owned by our treasury Safe. Both packets are signed by that key, 0xa41494e1e5f9e5eaf786961e6ef84cd1a3071eec.

Agreed that the missing grant and agent-identity records and the unsigned decision-to-job link remain limitations. The operator-owned target and observer stay with the later slice, as Carlos set out.

@chrisjleal

@chrisjleal Thanks for the corrections and the separate service-key publication pointer. PR #399 retains the immutable e6eb5b9 input; the corrected README statements and the original run files stay distinct.

I could not independently retrieve the registration JSON: our direct request returned HTTP 403, and the Chrome fallback did not load it either. Could you publish a commit-pinned public snapshot of that document and a stable link/reference for the registry URI binding? Key validity/rotation metadata, if available, would also let us distinguish a current publication from attribution at the recorded run time.

Until that source can be checked, PR #399 keeps service-key attribution not_measured; this does not invalidate the verified signatures against the packet-declared wallet. Missing grant/agent-identity records, unsigned decision-to-job joins, and the later operator/target/observer acceptance remain separate limitations.

Vlad / Alakris — prepared with OpenAI Codex.

@wlad232

@wlad232 the source is pinned, and the signing key is bound to the agent on-chain now, so neither answer depends on a live fetch from us.

The document. docs/public/evidence/registry/agent-registration.json at commit f81b8416a4f6fc1f1439ef43216078261fb206d2, SHA-256 f297f8fbff06de768fe1a2ee3ecb0a00518ecbb34c4517d607d598c04f3b45c7, also served at https://docs.proofable.me/public/evidence/registry/agent-registration.json. The document the .well-known URL serves today is byte-identical to that commit. Our side answers 200 to it under curl, Chrome and python user agents, and the pinned copy means your checkout no longer depends on that request at all.

The registry binding, read at head block 53390968 on two public Base RPCs (eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432): tokenURI(1135859) returns the .well-known URL, and ownerOf(1135859) and getAgentWallet(1135859) both return 0x929BCAe13Cac6ac1C53EbEd8266F02F8c056F00c.

The signing account is bound to that agent on-chain. The owner wrote it with setMetadata in tx 0xe3c783072848a66c247f0f6a6b6bb4c84afded3f9453758c8e3df116f6054a24, Base block 53386669:

const reg = new ethers.Contract('0x8004A169FB4a3325136EB29fA0ceB6D2e539a432',
  ['function getMetadata(uint256,string) view returns (bytes)'],
  new ethers.JsonRpcProvider('https://mainnet.base.org'));
ethers.toUtf8String(await reg.getMetadata(1135859n, 'x_proofable.receiptSigner'));
// {"schema":"proofable.service-key/v1","agentRegistry":"eip155:8453:0x8004A169…","agentId":1135859,
//  "receiptSigner":"0xa41494e1e5f9e5eaf786961e6ef84cd1a3071eec","scheme":"eip191-caip380",
//  "validFrom":"2026-11-01","registrationSha256":"f297f8fb…"}

Read that way: ownerOf gives the Safe, getMetadata gives the account, and every record's signature recovers to that account. registrationSha256 is the digest of the document above, so the mutable URL is hash-bound to the bytes the chain attests.

Rotation and validity. The binding carries validFrom and no expiry. A rotation writes the same key again, so the registry's MetadataSet events are the rotation log and there is no separate validity document to fetch.

What this settles for the slice, and what it does not. The binding is dated 2026-11-01, after both retained packets were signed on 2026-10-24. For those two runs it attributes the signatures to that account as of now; at their own run time the attribution remains documentary, resting on the registration file that was served then. A run taken after the binding does not carry that gap. The missing grant and agent-identity records, the unsigned decision-to-job join, and the operator-owned target with an independent observer remain exactly where you and Carlos placed them.

@chrisjleal

@chrisjleal — thanks for publishing the immutable copy: I fetched proofable/docs@f81b8416a4f6fc1f1439ef43216078261fb206d2 and independently matched the registration bytes to SHA-256 f297f8fbff06de768fe1a2ee3ecb0a00518ecbb34c4517d607d598c04f3b45c7.

Direct read-only calls to the Base and PublicNode RPC endpoints returned HTTP403 here, so I have not independently confirmed the transaction/metadata binding. I will retain your temporal distinction: the reported November1 binding is separate from attribution at the October24 signing time and must not be backdated. The missing grant/agent-identity records, unsigned decision-to-job join and independent operator/target-observer limitations remain outside the bounded offline slice now merged in #399.

Vlad / Alakris — prepared with OpenAI Codex.

On the part of this thread that is mine to make concrete: the kit that produces records under an operator's own account, rather than appraising ours, is public/evidence/aaif/authority-at-dispatch/reproduce. It runs the same eight permission cases plus the ordered post-revocation probe against the hosted endpoint https://mcp.proofable.me/mcp with an npk_ access key from the operator's own Proofable profile, and it does not touch the Base RPCs that your egress returns 403 for, so it needs no fetch from us.

Run it and the records are yours: the kit names the operator's account as custodian, not Proofable. node aad.mjs verify <run-dir> checks them offline from the files alone — every checksum, the trace digest, all disclosed envelopes, and the coverage the run declares — and node aad.mjs verify <run-dir> --expect-signer 0x… pins the signing key an operator read out of band. That produces the second-party observation every round of this thread has so far been missing: each round has been offline appraisal of our packets, which is the right thing to do with our records and cannot by itself yield an independent one.

The part that is not mine: the operator-owned disposable target with an independent observer. The four comparison scenarios wait on it, and Carlos owns naming the placement. If that placement can be named — even as a declared synthesis with a local target and a retained target-side readback — the rest of the slice is mechanical, and nothing in it depends on a Proofable account or endpoint beyond the one the kit already uses.

@chrisjleal

@chrisjleal — thank you; the reproduction-kit location and own-account custody handoff are clear. An operator-owned run would provide that operator's records, with independent target-side observation remaining a separate requirement.

Our delivered #399 slice remains the bounded offline appraisal. A live paired run still needs Carlos's placement decision with a named coordinator/operator, disposable target and independent observer under #199/#333; @carloshvp, could you confirm the owners and scope for that next stage before execution is scheduled?

Vlad / Alakris — prepared with OpenAI Codex.

Navigation Menu

Repository navigation

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

Existing baseline and proposed next step

Proposed acceptance criteria

Validation and boundaries

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Existing baseline and proposed next step

Proposed acceptance criteria

Validation and boundaries

Activity

chrisjleal commented on Oct 18, 2026

wlad232 commented on Oct 18, 2026

dinakarjs commented on Oct 19, 2026

wlad232 commented on Oct 19, 2026

imran-siddique commented on Oct 19, 2026

wlad232 commented on Oct 20, 2026

dinakarjs commented on Oct 20, 2026

wlad232 commented on Oct 20, 2026

rajnisht7 commented on Oct 21, 2026

dinakarjs commented on Oct 21, 2026

chrisjleal commented on Oct 22, 2026

dinakarjs commented on Oct 22, 2026

wlad232 commented on Oct 23, 2026

chrisjleal commented on Oct 26, 2026

wlad232 commented on Oct 26, 2026

carloshvp commented on Oct 27, 2026

wlad232 commented on Oct 27, 2026

chrisjleal commented on Oct 27, 2026

wlad232 commented on Oct 28, 2026

chrisjleal commented on Nov 1, 2026

wlad232 commented on Nov 2, 2026

chrisjleal commented on Nov 2, 2026

wlad232 commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions