Testing AI agent trust through public dialogue: three conditions revised in ARC

When connecting an AI agent to real work, what should we check after its declarations pass? Public discussions around Agent Role Contracts (ARC) have changed three conditions in our design: the origin of authority, the subject to which evidence belongs, and permission to retry when an outcome is uncertain.

The original sections follow the public record as of October 27, 2026. An October 31 update below adds subsequently published bounded trial results and a confirmed external listing. It separates external reports, design decisions, bounded prototypes and independent acceptance. The incremental value of adding ARC to existing controls remains a hypothesis to test.

Record public feedback as changes to acceptance conditions

PR #83 maps seven public feedback inputs to design decisions. Its merged commit is 2bae232b5d62221b468dc6d58228da8faf85e82f. Only four Markdown documents changed: ARCHITECTURE.md, ASSURANCE.md, FEEDBACK_INTEGRATION_DESIGN.md and INTEGRATION.md. The merge did not ship new runtime functionality.

The design at that fixed commit connects public engineering discussions to decisions about grant provenance, effective permissions, setup effort, projections from existing role manifests, settlement and retry, and requests changing after approval. We organize those decisions and subsequent test proposals into three conditions below. Later issue proposals must not be counted as implementations shipped by PR #83.

For the declaration checker's behavior, see what a PASS establishes. The workflow evaluation kit announcement covers the evaluation entry point and its publication history.

Condition 1: Check declarations, authority provenance and actual restrictions separately

External feedback

A public exchange with Srinath moved the next question to where a grant authorizing execution comes from. Another evaluator's comparison, referenced in the design, reports excess capability in a host inventory while ARC declarations pass. That is an external report, distinct from independent verification of actual runtime enforcement.

Revised condition

The design requires separate evidence for the canonical approval or policy revision, whether its issuer may grant that authority, and the effective permissions of the current execution environment. Where a canonical role manifest already exists, declarations should be reproducibly projected from it rather than creating another manually maintained authority roster. Unsupported restrictions must remain visible and hold the affected native admission.

Verification status

The maintainer's bounded stdio MCP comparison reports identical results across six synthetic rows for a custom task gate and an equally informed host policy. This is a bounded prototype result, not acceptance of an installed agent harness. The overlap cannot be presented as an ARC-specific enforcement advantage.

Issue #85 specifies a test of actual write restrictions. A disposable workspace and a protected sentinel file use fictional data. Native denial, actual dispatch and observed file changes are recorded separately. Authorized positive controls bracket the restricted case. A denial paired with a mutation remains a contradiction; missing, stale or incomplete observation yields UNKNOWN.

The published DEV sentinel protocol also contains no new execution results. A second process under the same account alone does not establish tamper-resistant observation. Equal before-and-after hashes cannot exclude a transient write followed by restoration. We have not established a third-party product vulnerability or whole-machine confinement.

Condition 2: Keep delayed evidence bound to its original subject

External feedback

A proposed comparison following the public Zeolite discussion considers a context change within the same client. Collection starts for document A, the client navigates to B, and A's response arrives late. An unchanged client ID or identical visible text is insufficient to establish that this evidence completes B.

Revised condition

The proposal binds evidence to its original document generation and request instance. A's evidence stays in A's history; B needs evidence for B. This extends the freshness question from a request replaced after approval to the attribution of observations returned after execution.

Verification status

The comparison has not run. Its expected result is to retain B's completion as UNKNOWN when A's delayed evidence arrives. Matching evidence for B may later establish B independently without rewriting A's history. Missing generation information or incomplete observation coverage retains uncertainty.

The proposed comparison gives existing correlation controls and an ARC-assisted report identical records and trusted inputs. Correct attribution already supplied by existing controls is a valid overlap result. This proposal adds neither a runtime identity authority nor a stable API.

Condition 3: Separate effect reconciliation from permission to execute again

External report

A public comment under issue #69 discusses an external self-report: a publishing API returned 404, but thread readback found the comment. Author attribution reportedly remained unknown because of a display-name mismatch. We have not independently reproduced the reporter's implementation.

Revised condition

The design separates dispatch start, remote receipt, response, effect completion and evidence settlement. Treating an error response as proof of no effect can cause duplication. Appending evidence to settle an outcome must not itself permit another execution or restore a consumed grant.

A retry requires a new admission against current authority, target and input, with a fresh one-use grant while preserving the logical operation identity. It also requires either independently sufficient no-effect evidence or a verified receiver reconciliation or deduplication contract that makes repetition safe within its scope. If neither is established, the retry is held.

Verification status

The fictional publishing-store comparison has not run. It proposes recording “one observed effect” and “author identity UNKNOWN” separately, without reposting to resolve the identity check. Missing, stale or mismatched readback cannot be promoted to zero effects or completion.

The design targets at most one local start per grant. It does not prove exactly-once remote delivery. Human permission cannot establish that an earlier effect did not occur.

Acceptance still open: the native environment and human value

This October 31 update adds results published after the original record. After publishing the protocol, the October 28 cloud trial observed a change to a fictional sentinel through the direct-edit route, and a read-only error with no observed change through exec. Effective configuration and actor identity were incomplete, so strict acceptance remains UNKNOWN for both routes. The decision is REVISE; the direct-file effect is not reported as a successful denial.

A separate bounded Codex CLI 0.147.0 trial observed denial and unchanged recorded sentinel fields for both direct-edit and exec routes in v2. The supplied records classify as BOUNDED_DENIAL. Version 1 remains UNKNOWN because attribute events could not be independently distinguished from effects of the observer's own reads. The same-UID observer is not tamper-proof, and the full direct-edit argument payload was not independently exported.

Existing native controls performed this trial. ARC only classified the same evidence afterward; it demonstrated no extra native enforcement or unique actionable finding. The recorded decision keeps the existing controls and evidence checklist, and stops further ARC admission or adapter expansion on the strength of this experiment. Making observation failures and unresolved results explicit is the concrete outcome.

For external discovery, the awesome-agent-trust maintainer's review led to inclusion on October 30. The submission disclosed that it was self-submitted. The list maintainer checked licensing, the public repository, declaration-checking scope and the explicit boundary that ARC does not grant runtime authority. This is a review against listing criteria, not security certification or evidence of production adoption. The ARC product page collects verified listings and product profiles alongside the source and evaluation guidance.

N0 is the next implementation decision: identify a willing harness owner and a verifiable canonical approval and policy source, then pin the harness, adapter, configuration, actors and effective permission provenance. N0 native acceptance remains unmet. An MCP transport test cannot substitute for acceptance of the installed harness.

N6 also remains open. Beyond an equally informed incumbent comparison, human-value measurement across two distinct genuine tasks is unmet: setup, maintenance and review time, useful catches, false refusals and a keep-or-remove judgment. An injected negative control must not count as a naturally useful catch, nor a scripted rerun as voluntary reuse.

External reports, completed design, bounded implementation and independent verification require different evidence. We do not treat these three conditions as independently accepted in a native environment. Participation or an offer to review is not adoption or endorsement. Merging documents establishes neither a formal proof nor a safety guarantee.

Testing ARC's incremental value requires retaining results where existing controls are sufficient. If maintenance grows without improving a decision, stopping the integration remains an option. Public dialogue is useful when it makes the conditions and evidence for that judgment more concrete.

See the ARC product page for the current declaration checker and evaluation entry points. Before adding it to a workflow, identify what evidence is missing and compare whether the added check improves a decision under the same existing controls.