An AI agent wanted to release a refund. Here is the proof trail Forge returned.

The scenario.

A subscription retailer (synthetic archetype) 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 encodes the refund policy, Forge applies it and returns a disposition with its full proof trail, and a human keeps the decision.

The messy evidence in.

Before anything is signed, the agent and natural-language extraction pull the values the decision needs, each carried with its source and a content hash, entirely outside the signed path. 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 proof trail Forge returned.

This is the product: a defensible proof trail, not a signed blob. The action was pointed at the Forge API against the encoded refund policy. Forge did not release the money. It returned the disposition, the numbers behind it, and every field an outside reviewer needs. All values are synthetic.

The human-review boundary.

Autonomy stops at a line the customer sets, and the record makes that line explicit. In this workflow the boundary is a dollar threshold and a confidence floor. Either one routes the action to a person before it can take effect.

This is what keeps an agent in check without taking a person out of the loop. The agent proposed, Forge scored and signed, and the release itself waits for human authority. The next action Forge recommends is to resolve the device-mismatch signal and confirm the refund velocity, then re-run, or to have a supervisor confirm or deny with a written rationale. That recommendation is not binding.

Verify it yourself, offline.

The reviewer who has to be satisfied should not have to trust the system that produced the action. An outside reviewer receives the exported package and the public key, and checks it on their own machine, offline, with no connection to Forge. Toggle the tamper case to see what changes when a single field is altered after signing.

$ forge verify ./goodwill-refund-package/            (illustrative)

  record dr_7c41f0a9e2b8455d
    signature (Ed25519, kid forge-signing-key-2026-02) ... VALID
    canonical_input_hash recomputed from inputs ......... MATCH  sha256:c4a90b7e...11f0
    ruleset_hash present in bundle ...................... MATCH  sha256:4e19b2...c7a0
    evidence content hashes (6/6) ....................... MATCH
    deterministic replay ................................ REPRODUCED
        selected_action = approve_with_human_confirmation
        confidence      = 0.62
        posterior       = 0.71 legitimate / 0.29 fraud_pattern
        replay_key      = rk_8b3e77a1d4c20596  (MATCH)

  RESULT: package is authentic and reproduces the engine
          determination from the recorded inputs.
          Business judgment stays with the customer.

$ forge verify ./goodwill-refund-package-EDITED/     (illustrative)

  record dr_7c41f0a9e2b8455d
    signature (Ed25519, kid forge-signing-key-2026-02) ... INVALID
    canonical_input_hash recomputed from inputs ......... MISMATCH
    evidence content hashes (5/6) ....................... 1 ALTERED (ev-4)
    deterministic replay ................................ replay_key MISMATCH

  RESULT: package rejected. A field was altered after signing.
          This is exactly what tamper-evidence is meant to catch.

Forge proves the action was justified under the encoded policy and the recorded evidence, and lets an outside reviewer re-derive it. It does not decide whether the policy or the evidence was right. That line stays with the customer and its reviewers.

What a proof trail contains.

• selected_action The disposition under the customer's encoded policy, plus the alternatives that were considered and why each was or was not selected.
• confidence and posterior The decision confidence and the deterministic posterior over the claim, both re-derivable by hand from the recorded inputs.
• evidence_chain Each item carried with its source, a source-class reliability weight, and a content hash. Extraction runs before the signed path, so a reviewer can see where every fact came from.
• uncertainty held The weak spots kept in view: unresolved signals, an over-ceiling amount, and the sensitivity that would change the result.
• human-review boundary The dollar threshold and confidence floor that route the action to a named person, so the buyer can show where autonomy stopped and accountability stayed.
• record_id and replay_key The handles that re-derive this exact record. The same canonical input reproduces the same disposition and replay_key, every time.
• Ed25519 signature and key_id The integrity check that verifies offline. It proves the record is authentic and unaltered. It is never the headline.