GovCodex

GovCodex × Agentic Commerce Protocol

From code to cart—without hiding the hard boundaries.

A real, version-pinned ACP checkout implementation connected to construction planning, explicit approval and order-driven project state.

Run the sandbox storyInspect the test vectors

Synthetic catalog · test payment only · no production data

protocol  acp@2026-04-17bindings  REST = MCPapproval  sha256(exact checkout)payment   sandbox_testproject    order → budget + tasksstatus     reproducible

One extension, existing systems

The Code-to-Cart architecture

ACP is a transport at the commerce boundary. It does not replace GovCodex's product model, ranking, project engine, budget ledger or task graph.

  1. 01Code evidence

    Parcel, code and project facts establish what fits.

  2. 02Product selection

    The canonical commerce layer remains commission-blind.

  3. 03Durable Buy list

    Items group by seller and declare project dependencies.

  4. 04ACP discovery

    A pinned version and safe seller endpoint are negotiated.

  5. 05Seller checkout

    REST or MCP returns authoritative availability and totals.

  6. 06Human approval

    One click is bound to the exact seller, lines and total.

  7. 07Order lifecycle

    Signed events become budget, task and case-state updates.

  8. 08Service dependency

    A 240V visit remains experimental, explicit and separate.

The blue nodes are the ACP transaction boundary; every other node reuses a pre-existing GovCodex domain seam.

Default-off public runner

A live execution with nothing real at risk

The route accepts no project, product, address, credential or payment input. Each click constructs a new in-memory seller and discards it with the response.

Isolated live execution

Run the synthetic checkout

A fresh in-memory seller processes one fixed sauna checkout. There is no user, database, network egress, payment provider, or real merchant.

Default-off and test-only. The server returns 404 unless every sandbox gate is enabled.

90-second walkthrough

Tell the complete story, including the limits

  1. Fit before buy

    Select a synthetic sauna after code and parcel constraints establish a viable project.

  2. Discover

    The buyer negotiates ACP 2026-04-17 with Aurora Sauna Works (Sandbox).

  3. Price at checkout

    The seller returns freight, tax and the authoritative total; estimates do not silently become truth.

  4. Approve exactly this

    GovCodex hashes seller, session, lines and totals before a human can approve completion.

  5. Project the order

    The synthetic order maps into deterministic budget, fulfillment and task events.

  6. Show the gap

    The 240V dependency leads to an experimental electrician slot hold—not a claim that stable ACP supports services.

Public implementation evidence

Reproduce the claim, not the production system

ArchitectureExtension seams and the buyer/seller/project boundary.Implementation findingsGeneralizable interoperability and security lessons.Conformance and paritySupported scope, test vectors and REST/MCP equivalence.Demo guideThe 90-second script and zero-production-data reproduction.Fixture manifestChecksummed synthetic REST and MCP fixture inventory.

Specification pin: ACP 2026-04-17 at 7fdd78df677a.

Disclosures

What this does—and does not—prove

  • The demo project, seller, catalog, price, token and order are synthetic.
  • GovCodex does not hold card data, mint a Shared Payment Token or act as merchant of record.
  • This is a tested implementation of a pinned ACP subset, not ACP certification or endorsement.
  • REST/MCP parity means equivalent operations over the same deterministic engine.
  • Service appointments are a namespaced experiment, not stable ACP functionality.
  • Affiliate eligibility is kept outside ranking; compensation cannot improve an offer's rank.