Sample signed decision record

See what a reviewer can check.

This synthetic example shows the decision, evidence, rules and approval requirements in one place. It is not a customer record. The trade, dates, names and key material are invented; its signature will not verify. Start with what a real record can and cannot prove, or read the fields and technical verification steps below.

The record Field by field What it proves Verify it offline

Example: a proposed trade is held.

In this invented scenario, an AI research agent proposes a trade in a pending merger. Another desk has confidential information about the deal, so the issuer is restricted. The required compliance clearance is missing. The example records a hold and the reason for human review; no trade is sent.

Synthetic decision record, illustrative only

{
  "record_id": "rec_9f2c41a7b3d84e6f",
  "issued_at": "2026-07-20T14:12:08.441Z",
  "tenant_id": "synthetic-demo-tenant",
  "subject": "Synthetic merger-arb trade recommendation 0042",

  "decision_question": "Should the agent send this trade to the order pad?",
  "decision_options": ["proceed", "hold", "escalate"],
  "abstention_action": "hold",

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

  "evidence": [
    {
      "evidence_id": "ev_1",
      "summary": "Control-room clearance for this issuer has not been recorded.",
      "source_label": "control_room_clearance_queue",
      "option_support": {"proceed": -0.95, "hold": 0.95, "escalate": 0.75}
    },
    {
      "evidence_id": "ev_2",
      "summary": "Issuer has been on the restricted list since 2026-07-02 after a wall-crossing on the acquirer financing.",
      "source_label": "compliance_restricted_list",
      "option_support": {"proceed": -0.80, "hold": 0.60, "escalate": 0.85}
    }
  ],

  "constraint_results": [
    {
      "constraint_id": "issuer_not_restricted",
      "status": "violated",
      "detail": "Issuer is restricted. The recommendation may not reach the order pad without clearance."
    },
    {
      "constraint_id": "reviewer_approval_required",
      "status": "unsatisfied",
      "detail": "compliance_control_room clearance is required and absent."
    }
  ],

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

  "human_review": {
    "required": true,
    "required_approvals": ["compliance_control_room"],
    "completed_approvals": [],
    "authority_retained_by": "compliance_control_room",
    "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.

What each field means.

Each row explains a field and the question it helps a reviewer answer.

`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 a real record can and cannot prove.

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 restricted-list feed was wrong, the record faithfully preserves the wrong entry. 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 to verify a real record independently.

A reviewer can verify a real Forge record offline using public-key tooling. The record, published format and separately trusted key material are needed; a live response from Forge is not. The synthetic values on this page are not a working verification fixture.

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 and tested 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 high-consequence call, 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