ARC Execution Gate

Project status: Non-normative simulated application examples. This repository is not a deployable gateway or an independent credential boundary. No new Commerce example is approved by this documentation cleanup.

ARC records and projects authority. ARC Execution Gate is a collection of minimal, non-normative examples for pre-dispatch authorization of simulated AI agent actions. Each application checks delegated authority and an exact approval immediately before dispatch to a simulated adapter.

The currently published examples intentionally focus on single-Agent, application-local execution boundaries. ARC's broader multi-principal model — independent principals acting through Agents, counterparty interaction, negotiation evidence, conflict, challenge/adjudication, and standing recomputation — is defined at the ARC Protocol layer. These examples are only pre-dispatch consumers of ARC-derived authority semantics; they neither implement nor represent that broader model.

This repository is an application-level experiment against ARC Protocol. It demonstrates application-local handling for approval, withdrawal (the fixtures' revocation path), and replay prevention. It does not add an ARC Event type, change ARC Canon, define ARC Projection semantics, or implement a complete Action Gate Protocol.

Repository direction

This repository keeps multiple ARC application examples in one place. Each example keeps its application policy and simulated adapter separate while sharing only the narrow execution-boundary code that is already common in practice. Additional examples should demonstrate a new execution boundary not already covered by the current three examples.

Application policies, decision values, and adapters in this repository remain non-normative. They do not extend ARC Canon or define ARC Projection semantics. New examples should not introduce a generic policy DSL, plugin framework, or registry unless concrete examples later demonstrate that such an abstraction is necessary.

Application examples

Three runnable examples use the same execution boundary: ARC-derived authority, application policy, a local GateDecision, simulated dispatch, and a mock receipt.

• simulated_air_conditioner uses a simulated appliance API. It does not control a physical appliance or connect to a manufacturer API, Home Assistant, or an LLM.
• simulated_software_deployment uses a process-local deployment adapter. Its consumer path derives a structural authority projection through a locally checked-out ARC Reference Core before applying the existing Gate policy. It does not run commands or connect to a production deployment platform, network, database, CI system, or cloud provider.
• simulated_treasury_payment uses a process-local vendor-payment adapter. It does not contact a bank, payment network, accounting system, blockchain, wallet, or real vendor.

Only the software-deployment consumer is connected to ARC Reference Core. The treasury-payment and simulated-air-conditioner paths retain their existing independent application-local authority flows.

From the repository root, run:

PYTHONDONTWRITEBYTECODE=1 python3 examples/simulated_air_conditioner/demo.py
PYTHONDONTWRITEBYTECODE=1 python3 examples/simulated_treasury_payment/demo.py

# The full test suite and software-deployment path require a sibling local
# checkout of ARC Reference Core; replace this relative path if needed.
PYTHONPATH=../arc-reference-core-alpha/src \
  PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v
PYTHONPATH=../arc-reference-core-alpha/src \
  PYTHONDONTWRITEBYTECODE=1 python3 examples/simulated_software_deployment/demo.py

At the current baseline, the test command passes 69 tests. ARC Reference Core is not currently an automatically installed package dependency; the local checkout and PYTHONPATH above are required for the software-deployment integration and the full test suite.

The air-conditioner fixture evaluates one structured request against a hard application envelope, an exact human approval, and one scoped mandate:

• delegated scope: living-room AC set_temperature, 24–27 C, 1–120 minutes, and occupied: true
• hard envelope: 20–30 C, 1–240 minutes, and occupied: true

These are demo-routing rules, not appliance safety standards. Occupancy, timestamps, and device state are fixture inputs; ARC and this execution gate do not prove their real-world truth.

ALLOW means only that the exact bound request may be sent to the simulated adapter. It does not prove physical execution or a real-world outcome.

ALLOW, DENY, REQUIRE_APPROVAL, and REVOKED are local execution-gate decisions, not ARC Event types or extensions to ARC Canon. Only ALLOW has dispatch_allowed: true.

Proposal binding

The request hash uses UTF-8 JSON with sorted keys, no insignificant whitespace, and all fields returned by ActionRequest.review_body(). The scheme identifier is sha256-stable-json-v0. This is documented stable JSON for this fixture; it is not ARC canonical encoding.

An exact approval is an AUTHORIZE consent.approval whose illustrative payload contains:

{
    "approval_binding": {
        "profile": "arc-execution-gate/home-appliance/v0",
        "scheme": "sha256-stable-json-v0",
        "proposal_hash": "sha256:..."
    }
}

Proposal binding in this repository is an illustrative application-profile payload, not finalized ARC wire-format semantics. The proposal hash is not placed in refs.

Approval consumption is an in-memory fixture set. It prevents a bound approval from dispatching twice in one process; it is not a portable ARC replay prevention primitive.

The software-deployment example uses the sibling application profile arc-execution-gate/software-deployment/v0. Its exact approval binds the request identity, actor, service, environment, artifact digest, and observation time through the same fixture hash scheme. A current scoped mandate permits staging dispatch, while production additionally requires that exact approval. Its in-memory dispatch set also blocks replay of an already dispatched request. The Reference Core connection is structural-only: it does not establish production-grade signature verification, key provenance, or root trust. The software-deployment README also includes a five-minute, simulation-only boundary experiment showing that valid authentication, OAuth scope, and tool availability do not turn causally contested ARC authority into current authorization.

The treasury-payment example uses profile arc-execution-gate/treasury-payment/v0. A current scoped mandate permits a fixed vendor's invoice payment up to 250,000 minor units. A payment above that delegated limit and no greater than the 2,500,000-minor-unit hard envelope also requires an exact approval. The approval binds the payer account, vendor, beneficiary account, invoice, amount, currency, actor, request identity, and observation time.

The treasury fixture blocks both proposal replay and a distinct request for an invoice already dispatched in the same process. This semantic invoice check is application-specific, process-local behavior, not durable idempotency or an ARC primitive. Its mock receipt does not prove that funds were accepted, transferred, settled, or received.

These examples do not define a complete Action Gate Protocol. Their GateDecision values remain local application decisions, not ARC Events, and their mock receipts are not cryptographic signatures or evidence of real-world execution.

Limits

The examples do not own a production credential, approval channel, network boundary, or target resource policy. They do not close direct API or alternate network paths, provide target-side idempotency, atomically couple approval consumption with an external side effect, reconcile partial failure, or provide production availability and observability. Those properties require a separate deployment architecture outside the untrusted agent runtime.

These fixtures recognize withdrawal only from the exact same declared signer. ARC key-rotation lineage is intentionally not implemented here. Signer identifiers in the fixture are compared as declared values; this implementation does not verify signatures, key custody, identity, or an ARC wire format.

Each fixture supports one matching mandate. Multiple matching mandates, causally concurrent withdrawal, unsupported resources or operations, and malformed request fields fail closed instead of widening coverage.

This is not an ARC conformance suite, interoperability profile, product safety certification, or production authorization system.