An AI agent proposes a refund. Here is the proof-trail shape.

The scenario.

A subscription retailer runs an autonomous customer-operations agent that resolves billing complaints end to end. On a ticket about a service outage, the agent proposes a goodwill gesture: refund 4,200 USD to keep a long-tenured account happy. The catch is that the risk service has flagged the account, and the amount is far above the level a policy would ever let an agent release on its own.

This is the moment that hurts to defend later. If the refund is fraud, someone has to explain why it went out. If the refund is legitimate and it is blocked, a good customer is punished. The honest reviewer of that call, a chargeback and dispute reviewer, an internal auditor, and a regulator, all sit outside the team that built the agent. Forge is built for exactly that moment: the customer integration supplies bounded evidence and evaluated policy controls, Forge deterministically applies its policy-gate precedence and evidence fusion, and the customer keeps execution authority over the returned disposition.

The messy evidence in.

Before a Forge request is submitted, the customer's agent, adapter, or extraction service turns source material into bounded evidence fields. Two facts pull toward approval, two risk signals pull the other way, one is the hard policy limit, and one is context. That tension is the point.

Nothing here is missing. The problem is that the evidence disagrees, and the account has been flagged. An agent that just averaged this and acted would leave nobody able to prove, later, why the money moved.

The integration pattern this walkthrough illustrates.

The values below explain how a bounded action menu, supplied evidence, executable approval controls, uncertainty, and customer-owned action boundary fit together. Labels in this panel are explanatory, not a copy of the current JSON schema. The real request and response JSON is in the API docs.

The human-review boundary.

This example uses a customer rule that sends an over-ceiling request to a supervisor. In the current API, human_review_boundary is signed descriptive governance metadata. It does not execute the rule. An executable integration sends named hard_constraints with explicit constraint_results, and names required and completed approvals separately. Forge records those customer assertions and applies its fail-closed policy-gate precedence; it does not independently inspect the source policy system that produced them.

A qualified customer integration can resolve the device-mismatch signal and submit a new decision request, or let a supervisor decide under the customer's own authority. Forge does not become the refund-system authority.

How a real exported v2 record is verified offline.

For a real authenticated API response, the reviewer saves the complete record, obtains the full Forge key ID through an independent authenticated onboarding/configuration channel, and verifies offline. The public signing-identity route is readback only; it cannot bootstrap its own trust.

export FORGE_SIGNING_KEY_ID='ed25519:<64 lowercase hex provisioned independently>'
python3 scripts/forge_verify_record.py record.json \
  --expect-key-id "$FORGE_SIGNING_KEY_ID"

Required checks:
  derive key ID from the 32-byte Ed25519 public key
  compare it with the independently provisioned full pin
  validate the v3 complete-record signature and contract
  reject malformed, unsigned, mismatched, or altered records

The standalone verifier does not rerun Forge, rescore evidence, or derive the
selected action. It also does not establish that customer-supplied evidence
was true.

python3 scripts/forge_verify_record.py edited-record.json \
  --expect-key-id "$FORGE_SIGNING_KEY_ID"

Expected result: non-zero exit and VERIFIED = false.
The v3 complete-record signature binds every delivered decision-record field,
including its signature metadata. Only the self-referential signature bytes and
message digest are omitted and checked independently. Release evidence must
capture this negative test against a real response.

A green result establishes record integrity and attribution to the independently pinned signer. It does not by itself prove that the policy was wise, the evidence was true, the engine calculation was independently reproduced, or the business action was correct.

What the current v2 record exposes for review.

• selected_action and submitted menu The returned action can be checked against the exact decision options in the signed normalized request.
• assessment_mode, abstained, abstention_reason, and confidence The record says whether Forge completed the assessment or fell back safely, and why.
• normalized_request and evidence commitments A data-minimized signed view preserves source labels, evidence confidence, claim-support level, and normalized evidence hashes. It does not prove the supplied facts were true.
• policy-gate results The record exposes the evaluated gate state and customer-supplied control assertions. Forge does not silently treat unevaluated safeguards as passed.
• governance metadata Customer-declared provenance, versions, intended use, and human-review description can be carried in the signed record. Descriptive metadata is not an executable approval.
• record_id and SDK request binding The current SDK includes a signed client-request binding so the protected helper can reject a valid but stale or wrong-request response. A raw API integration must implement the published binding contract explicitly.
• complete-record Ed25519 signature and full key ID The integrity check. Forge attribution additionally requires a full key ID provisioned independently from the record and API response.