Sample signed decision record

This is what you would hand a reviewer.

Everything below is one synthetic, illustrative record. It is not a customer record, and the refund, the amounts, the reviewer names, and the key material are all invented for this page. The point is the shape: what a signed decision record contains, what question each field lets a reviewer answer, and exactly how far the record goes before it stops. If you are a compliance officer reading this, the section you should read twice is what this proves and what it does not.

The record Field by field What it proves Verify it offline

One synthetic record, in full.

A refund workflow is the easiest case to read, so that is the example. An AI agent inside a customer support system was about to release a refund. The customer's own policy says a refund above a set amount needs a named human approver, and no approval was on file. Here is the record that came out.

Synthetic decision record, illustrative only

{
  "record_id": "rec_9f2c41a7b3d84e6f",
  "issued_at": "2026-07-20T14:12:08.441Z",
  "tenant_id": "synthetic-demo-tenant",
  "subject": "Synthetic refund request 0042",

  "decision_question": "Should the agent release this refund?",
  "decision_options": ["proceed", "hold", "escalate"],
  "abstention_action": "hold",

  "selected_action": "hold",
  "abstained": true,
  "confidence": 0.31,

  "evidence": [
    {
      "evidence_id": "ev_1",
      "summary": "The required customer-operations reviewer approval has not been recorded.",
      "source_label": "workflow_approval_queue",
      "option_support": {"proceed": -0.95, "hold": 0.95, "escalate": 0.75}
    },
    {
      "evidence_id": "ev_2",
      "summary": "Refund amount 4,180.00 USD is above the 2,500.00 USD agent limit.",
      "source_label": "billing_system_export",
      "option_support": {"proceed": -0.80, "hold": 0.60, "escalate": 0.85}
    }
  ],

  "constraint_results": [
    {
      "constraint_id": "refund_limit_usd_2500",
      "status": "violated",
      "detail": "Requested 4,180.00 USD against a 2,500.00 USD unassisted limit."
    },
    {
      "constraint_id": "reviewer_approval_required",
      "status": "unsatisfied",
      "detail": "customer_operations_reviewer approval is required and absent."
    }
  ],

  "uncertainty": {
    "missing_evidence": ["customer_operations_reviewer approval"],
    "conflicts": [],
    "note": "No evidence supports proceed. The record is held pending the named approver."
  },
  "empirically_calibrated": false,

  "human_review": {
    "required": true,
    "required_approvals": ["customer_operations_reviewer"],
    "completed_approvals": [],
    "authority_retained_by": "customer_operations_reviewer",
    "system_authority": "recommend_only"
  },

  "request_basis_hash": "sha256:1b8f0a5d7c3e2249ab61f4d0e7c95b8a2f6d341c0b9e7a5384fd21c6e0b74a99",
  "record_reference": {
    "record_id": "rec_9f2c41a7b3d84e6f",
    "replay_key": "rk_4d0c19be7a2f5836"
  },

  "signing": {
    "algorithm": "Ed25519",
    "key_id": "forge-signer-2026-07-a1c4e8b2f7d05936",
    "public_key": "ed25519:MCowBQYDK2VwAyEAKq3Tn8Yb0d9Wc1sF7vJhR2mLpX4eZaQ6uT8yN0iBc5w=",
    "signature_format": "forge-complete-record-v3"
  },
  "complete_record_signature": "Yk9tQ2xZd0hFdlNqRnBLeE0yUnVBaFRjTjZnV3pEeUJvMUlmU3ZMYUVqUTdQckNoVXhZbjRkTWt2VDlzR3dGMEJlSXpSYUxxOHRYY05qUHVoWTJEbVY1b1M3Zg=="
}

Synthetic and illustrative. The identifiers, hash, public key, and signature bytes above are placeholders typed for this page. They will not verify. A real record is produced by your own tenant against your own signing identity.

Field by field, in plain language.

Each row is one field, what it actually is, and the reviewer question it lets you answer. If a field does not survive that second test, it does not belong in the record.

`decision_question`	The single, bounded question that was being answered, written in your words at the moment the action was about to happen. Reviewer question it answers: what was actually being decided here, as opposed to what someone reconstructed afterward?
`decision_options`	The complete menu of answers your organization allowed for this workflow. You define it. Forge does not add to it. Reviewer question it answers: what was the system permitted to do, and what was it never permitted to do?
`selected_action`	The disposition that was selected. It is menu-bound, meaning it can only ever be one of the options you listed above. There is no free-text outcome. Reviewer question it answers: what disposition came out, and was it inside the boundary the business set?
`evidence` and `option_support`	The facts that were supplied for this decision, each with a short summary, a label naming where it came from, and a number for each option saying whether that fact pushed toward or away from that option. Negative pushes away. Reviewer question it answers: what was in front of the system, and which specific fact moved the outcome?
`constraint_results`	Your policy rules, evaluated one by one, each with a pass, violated, or unsatisfied status and a readable reason. Reviewer question it answers: which written policy applied, and did it hold or break, without anyone having to read the source code?
`confidence` and `uncertainty`	How strongly the evidence supported the selected disposition, plus the named weak spots: evidence that was missing, facts that conflicted, and a plain sentence explaining the doubt. Low confidence is recorded, not hidden. Reviewer question it answers: did anyone know this was a thin call at the time, or is that only obvious now?
`empirically_calibrated`	A flag stating whether the confidence number has been measured against your own real outcomes yet. In this record it is false, which is the honest default at the start of an engagement. Reviewer question it answers: is this confidence figure grounded in your history, or is it still an untested score?
`abstention_action` and `abstained`	The option you designated as the safe answer when the evidence is not good enough, and whether the system took it. Here the safe answer is `hold`, and it was taken. Reviewer question it answers: when the system did not have enough to go on, did it stop where you told it to stop?
`human_review`	Whether a person was required, which named role was required, which approvals had actually been collected, who kept authority, and what the system itself was allowed to do. In this record the system was `recommend_only` and the approver had not signed off. Reviewer question it answers: who was accountable, and did the machine ever act in a place where a human was supposed to?
`request_basis_hash`	A canonical fingerprint of the exact request the decision was made from. Canonical means the request is serialized in one fixed, ordered way before hashing, so the same inputs always produce the same fingerprint. Reviewer question it answers: is this record about the request in front of me, or about a slightly different one?
`record_reference`	Stable handles for the record: an identifier for retrieval and a replay key for re-running the same decision under the pinned engine and configuration. Reviewer question it answers: how do I pull this exact record again, and how do I reproduce it?
`signing`	The verification material a reviewer needs and nothing more: the algorithm (Ed25519, a widely used public-key signature scheme), the key identifier, the public key, and the record format version. Reviewer question it answers: what do I need in hand to check this myself?
`complete_record_signature`	The signature over every delivered field of the record. Only its own signature bytes and the signed message digest are left out, because a signature cannot cover itself, and those are checked separately. Reviewer question it answers: has a single character of this record changed since it was issued?

Boundaries

What this proves, and what it flatly does not.

It proves the record has not changed. The signature covers the delivered fields. If anyone edits a number, a summary line, or an approval after the fact, verification fails. The record is tamper-evident under replay and reproduces byte for byte under the pinned engine and configuration. It is not unchangeable, and nobody should describe it that way. It is checkable.
It proves what was in front of the system at the time. The evidence, the constraints, the confidence, the missing items, and the human boundary are captured at the moment of the decision, not reconstructed later from memory or from a ticket thread.
It proves the disposition stayed inside your own boundary. The selected answer came from your option list, and the abstention path you designated is visible in the record when it was used.
It does not prove your evidence was true. If the billing export was wrong, the record faithfully preserves a wrong number. Forge does not independently inspect, benchmark, validate, certify, or attest customer inputs, and it does not reach into your source systems to check them.
It does not prove the business judgment was correct. A defensible record of a bad call is still a record of a bad call. The record supports a defense. It does not supply one.
There is no generative model in the signed path. Nothing in the record was written by a language model. That removes a whole category of question about whether the reasoning was invented after the fact.
It is not a legal conclusion. This page describes a technical artifact. What weight it carries in any particular proceeding, regulatory examination, or contract dispute is a question for your counsel, not for a vendor page.

How a reviewer checks it without trusting anyone.

The whole point of a signature is that the person checking it does not have to take the producer's word for anything. A reviewer can verify a Forge record offline, on a laptop with no network connection, using ordinary public-key tooling. Forge is not in the loop, and neither is the system that produced the decision.

One step matters more than the rest: get the key identifier from somewhere other than the record. A record that carries its own public key only proves it was signed by whoever signed it. The signing identity is provisioned to your team through a separate trusted channel during onboarding, and that is the value you compare against. Checking a record against a key that arrived inside the same record is circular, and a reviewer should say so.

1. Pin the key	Take the full signing key identifier your organization received separately at onboarding. Confirm the `signing.key_id` in the record matches it exactly. If it does not match, stop.
2. Rebuild the signed message	Take the record, remove `complete_record_signature` and the signed-message digest, and serialize what remains using the published canonical format named in `signature_format`. Every other delivered field stays in, including the signer metadata.
3. Check the signature	Verify the Ed25519 signature over that message with the pinned public key. This is a standard operation in every mainstream cryptography library, and it requires no Forge software.
4. Confirm the fingerprint	Recompute the canonical fingerprint of the original request and compare it against `request_basis_hash`. This ties the record to the exact request rather than to a similar one.
5. Replay if you need reproducibility	Use `record_reference.replay_key` to re-run the decision under the pinned engine and configuration and confirm it reproduces byte for byte. Replay is a separate reproducibility check. It is not a substitute for the signature check above.

Offline verification sketch, synthetic values

import base64, json
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

record = json.load(open("record.json"))

# 1. The key ID comes from onboarding, NOT from the record.
PINNED_KEY_ID = "forge-signer-2026-07-a1c4e8b2f7d05936"
PINNED_PUBLIC_KEY = base64.b64decode("...provisioned separately...")
assert record["signing"]["key_id"] == PINNED_KEY_ID
assert record["signing"]["algorithm"] == "Ed25519"

# 2. Rebuild the signed message: everything except the signature bytes
#    and the signed-message digest, in the published canonical form.
signature = base64.b64decode(record.pop("complete_record_signature"))
record.pop("signed_message_digest", None)
message = json.dumps(record, sort_keys=True, separators=(",", ":")).encode()

# 3. Standard Ed25519 verification. No Forge software involved.
Ed25519PublicKey.from_public_bytes(PINNED_PUBLIC_KEY).verify(signature, message)
print("signature verified against the independently pinned key")

Illustrative sketch against the synthetic record above. The exact canonical serialization is published with the record format and is what your implementation should follow. Live contracts: GET /v1/decision-records/describe · GET /v1/decision-records/schemas · GET /v1/decision-records/signing-identity

Forge is live, tested, enterprise-grade, and enterprise-ready at design-partner stage. Nothing on this page claims a certification, an accreditation, an authorization to operate, or an endorsement by any regulator or standards body.

Bring the decision you would least like to explain later.

One workflow, one option menu, synthetic or sanitized evidence first if that is easier. You get a record in this shape against your own question, and your compliance and legal reviewers can pull it apart line by line before anyone commits to anything.

Bring one decision See how it works