What is an AI agent proof trail?

An AI agent proof trail records a selected action, evidence, policy, disposition, uncertainty, alternatives, human-review boundary, replay key, and signature. The complete-record Ed25519 signature detects alteration of any delivered decision field. Attribution to Forge requires an out-of-band pinned signing identity.

How do you prove what an AI agent did, and why it was justified?

Forge can evaluate a supported action before execution and return a proof trail. Execution control exists only when the customer deploys and validates an exclusive protected boundary the agent cannot bypass. With the engine and configuration pinned, an auditor can replay the recorded basis and compare the semantic disposition and replay key; a new issuance has its own record ID, timestamp, and signature.

What is the difference between an AI agent audit trail and a Forge proof trail?

An audit trail records what an agent did and can show whether the log changed later. A Forge proof trail evaluates supplied evidence and structured policy results, returns one action from the customer's submitted menu, and records why. A reviewer can replay the recorded basis and compare the semantic disposition and replay key, not just inspect an append-only log.

How is Forge different from non-human identity governance for AI agents?

Identity governance answers who an agent is, what it may access, and how to revoke it. Forge records a different layer: the supplied evidence, encoded policy result, uncertainty, and human boundary for a selected action. Complete-record verification checks integrity under an independently pinned signer; it does not prove the evidence or business judgment was correct.

Why use an independent checkpoint instead of the agent's own logs?

Self-attested logs are produced by the same system being judged. When the customer places Forge outside the agent and makes it part of the protected action path, Forge is a separate deterministic checkpoint. A reviewer can verify the complete record against an out-of-band pinned Forge identity.

Is there a generative model in the decision path, and does that prevent hallucinations?

No generative model sits in the checked decision path. That removes generated prose from the determination, but it does not establish the truth of customer-supplied evidence. The complete-record Ed25519 signature detects altered delivered fields; attribution to Forge requires an out-of-band pinned signing identity. Deterministic replay separately checks reproducibility under a pinned engine and configuration.

What is a proof trail for a high-consequence decision?

A deterministic proof trail produced at decision time records the evidence considered, constraints applied, uncertainty, alternatives, and human boundary. Its complete-record Ed25519 signature detects altered fields, and a reviewer pins the Forge signing identity out of band before attributing the record.

How does Forge review synthetic-data grounding?

Forge evaluates whether customer-submitted evidence supports one declared synthetic-data use. It records that supplied basis, uncertainty, and named next tests. Forge does not independently inspect, benchmark, validate, certify, or attest the underlying dataset, generator, artifacts, or upstream sources.

Can proof trails be verified offline or in isolated environments?

Yes. The complete-record signature can be checked offline against an out-of-band pinned Forge signing identity without a network call to Forge. Deterministic replay is a separate reproducibility check. Neither proves customer-supplied evidence is true.

Does Forge run or replace my AI agent, and is it on-prem?

No. Forge does not run your agent or replace its brain. A hosted path can use synthetic, sanitized, or metadata-only evidence. Customer-operated or on-prem deployment is contract-scoped and requires environment qualification. Forge does not train product models on customer data. Only an authorized customer outcome plus explicit retention opt-in can write tenant-local calibration state; decision and audit-record retention is a separate contract-scoped control.

Teams whose decisions and AI agents get challenged later: financial-services model governance, specialty insurance and underwriting, cyber, critical infrastructure, and any organization deploying AI agents into workflows where a reviewer may challenge the action. On the federal side, the Forge solution was assessed as Awardable on the U.S. Department of Defense CDAO Tradewinds Solutions Marketplace and independently evaluated by the NRO on a bounded cislunar space-domain-awareness use case.

Bring one decision. Start with the authenticated synthetic request at forgeorbital.com/api-docs, or scope a customer-operated boundary for sensitive data. One bounded workflow produces the first proof trail for buyer-side review.

How is a Forge proof trail different from a notarized log?

A notary or audit trail signs a decision that was already made. Forge applies the customer's policy to the action and records the result and replay basis. Deterministic replay lets a reviewer compare the disposition and replay key against that basis; it does not promise a byte-identical response.

Is observability or an eval suite enough to govern an AI agent?

Observability and eval tooling record and score what an agent did after the action, which is useful for debugging but is a report on a decision already taken. Forge can create a per-action proof trail today and return a pre-action disposition. Whether a downstream action proceeds is controlled only at the customer's protected boundary.

Is a Forge synthetic-data record an AI bill of materials (AI-BOM)?

It can supply one input to a customer-defined AI bill of materials. A Forge grounding-diligence record preserves customer-submitted provenance and grounding claims, uncertainty, and named next tests. Its signature protects the returned record; Forge does not independently inspect or attest the dataset or its upstream sources.

Forge Orbital: Independent Decision Records for AI Agents

Why now

Regulators started naming this problem in their own words.

Not AI policy in the abstract. Specific supervisory language about agents that act, and about firms being unable to reconstruct how the system got there.

FINRA2026 Annual Regulatory Oversight Report
December 2025

multi-step reasoning or complex chains of agent actions may be difficult to reconstruct

Listed as a named auditability and transparency risk for AI agents, alongside guidance to track agent actions and decisions and to determine where human oversight is required.

ESMASupervisory Briefing on Algorithmic Trading
26 February 2026

the algorithmic trading systems and algorithms should be explainable

An affirmative explainability duty, with pre-trade controls treated as binary pass or fail blocks set by named internal functions. The closest thing in force to a written requirement.

SECFY2026 Examination Priorities
November 2025

supported by contemporaneous documentation

The test applied to allocation and side-by-side conflicts. Contemporaneous is the operative word: produced when the decision was made, not assembled afterward.

$100M

Civil penalty in a June 2026 SEC settlement with an asset manager over trade allocation. Charged as a controls failure, not fraud. The gap was evidence that the control ran, at the time, before the trade.

Forge exists to answer that. Reconstruct the decision, not just the output.

Eighteen months later, in an exam or a deposition, the question is never what the system produced. It is which evidence it relied on, which system asserted that evidence, which rule applied and whether it passed, and who held authority at the moment it mattered. Forge produces that record at decision time and signs it. You keep the underlying material; Forge keeps the proof of what governed the decision and exactly how.

No regulator endorses, approves or certifies any vendor, and nothing above is an endorsement of Forge Orbital. These are obligations landing on firms. We quote them because the firms we build for are the ones who have to satisfy them, and because we would rather show you the demand than assert it. Sources: FINRA 2026 Annual Regulatory Oversight Report; ESMA Supervisory Briefing ESMA74-1505669079-10311; SEC Division of Examinations FY2026 priorities.

The engine

Three properties. One API call.

Independent by construction

Forge sits outside the decision path. It will not mark a decision confident without evidence carrying a named source system and a named constraint or approval. That floor is in the code, it cannot be configured to zero, and nobody here can switch it off for a customer.

Deterministic

No language model anywhere in the signed path. The same inputs produce the same record, every time, which is what makes replay a real check rather than a fresh guess. Unverified control evidence is weighted at zero.

Verifiable offline

An Ed25519 signature anyone can check with the public key, on a laptop, with no network and no account with us. If we disappeared tomorrow, every record you hold still verifies.

Ed25519Signature algorithm

ZeroLLMs in the signed path

OfflineVerification, no vendor call

Design partnerCurrent stage

Actual response, abridged POST /v1/decision-records/evaluate

{
  "record_id": "FDR-70E6D5554748391E03F3028E28495C97",
  "selected_action": "block",
  "confidence": 0.5,
  "abstained": false,
  "assessment_mode": "completed_assessment",
  "decision_type": "reviewable_decision",
  "workflow_type": "enterprise_agent_pre_action",
  "replay_key": "9766c4113426f9171ac1c8757b25c11dad3c9432ad246999f01f8d764663b4ff",
  "input_binding": {
    "hash_algorithm": "sha256",
    "canonicalization": "forge-tagged-json-f64be-v1",
    "api_operation_sha256": "6f0367d5afe76e1f12868ef7b0b1fbbe5a05baac1b3d49c8273d68824eb60312"
  },
  "signature": {
    "algorithm": "ed25519",
    "schema_version": "forge-record-signature/v2",
    "key_id": "ed25519:b3d7a886f4c46d5c83b3e8d717b51a9870ffd54cb805e7595ddcc778f42f8316",
    "public_key": "fcHOwf6pUvO7jm6sjHMpFs3dOdlx/2AvuBaQDExoKM0="
  }
}

A partner-owned agent proposed a 450 USD refund. The customer’s own policy engine asserted a hard limit of 250. Forge returned block, before execution, naming the constraint and the system that asserted it. There is no dashboard. The record is the interface: it returns to your systems, lands in your evidence store, and a regulator or counterparty verifies it offline with the public key, with no account here and without asking our permission.

One call, start to finish

It is an API key and a base URL. This is what happens in between.

A merger-arb research agent re-rates a live deal off expert transcripts, filings and a licensed data feed, and produces a recommendation for the PM order pad. Another desk was wall-crossed on the acquirer financing two weeks ago. These are the numbers the engine actually returned.

▸

1You sendPOST /v1/…/evaluate

X-API-Key: fi_••••

decision_options
  execute · hold · escalate · block

evidence[0]  0.72
  expert_transcript_library
  "Former divisional VP describes
   integration cadence consistent
   with a Q3 close."

evidence[1]  0.95
  sec_edgar
  "Merger proxy sets the vote,
   no financing condition."

evidence[2]  0.41
  alt_data_catalog
  "Licence diligence 16 months
   stale against a 12-month
   policy window."

hard_constraint
  issuer_not_restricted
  source control_room
  passed false

You declare the options, the evidence and the rules. Forge never invents any of them.

▸

2Forge weighs itdeterministic

Execute0.304

Escalate0.097

Hold0.072

Block0.048

Every option scored from the evidence you supplied. The research is sound, so the evidence leans execute at 0.304. Block scores lowest of the four, at 0.048.

Then the rule runs

issuer_not_restricted
passed: false

Name restricted since 2026-07-02 under a wall-crossing on acquirer financing. The agent's retrieval window opened after that.

A failed hard constraint is not something to weigh. The rule decides, inference is skipped, and the record says so.

3You get backsigned record

blockselected_action

abstained        false
confidence       0.50
posterior        uniform

posterior_semantics
  "uniform_placeholder_
   not_inference"

confidence_semantics
  "neutral_placeholder_for_
   deterministic_rule; not a
   probability that the gate
   disposition is correct"

signature  ed25519
key_id     b3d7a886…

Plus all three evidence rows, the constraint, every option considered, and where a human held authority. Signed, and verifiable offline.

The part most tools would hide

The engine did not reason its way to this answer, so it says so. It labels its own posterior uniform_placeholder_not_inference and its own confidence not a probability that the gate disposition is correct. A system that invents a confident-looking number for a decision it reached by rule is the exact thing your regulator is trying to catch. Forge writes down which one happened.

And what it does not do. Forge does not detect material nonpublic information and cannot certify that an agent's context was clean. It records that a named barrier system asserted a result, at a stated time, against a stated list version. It does not observe the agent either: the evidence rows are what your integration declares. What Forge forces is that the enumeration exists, at decision time, and cannot be repudiated afterward.

And it replays either way. This one was blocked, but an execute would carry the same replay_key, the same signed basis and the same evidence rows. Months later an auditor, an LP or a regulator takes the normalized inputs, re-runs them through the same engine version, and gets the same result, or the record does not hold up. The signature proves the bytes are the ones Forge issued. The replay is what proves the content, which is why we keep the two claims separate. Neither check needs our servers, our cooperation, or our continued existence.

Boundaries

Six things Forge is not.

Not a notary

A notary attests after the fact and has one output. Forge runs before the action, tests it against the rules you encoded, and returns allow, hold, escalate or block. Four outcomes, because something was actually evaluated.

Not logging or observability

Your logs are written by the stack under review, and they tell you what happened. Forge is outside that stack and records why the evidence justified the action, which is the question an examiner asks and a log cannot answer.

Not model explainability

Feature attributions explain a model to a data scientist. Forge records the decision boundary: which named control system asserted what, which rule passed or failed, and where a human held authority. That is what survives a deposition.

Not a controller

Forge takes no authority and executes nothing. You encode the policy, a human keeps authority, and whether your system honours the disposition is a property of your integration, which any assurance argument has to account for openly.

Not another probabilistic system

Checking one model with a second model leaves you holding two probabilistic systems and still no ground truth. Forge is deterministic code. The same inputs return the same record every time, which is what makes re-running a decision a check rather than a resample.

Not an LLM wrapper

There is no language model anywhere in the signed path and the API holds no model keys. Nothing in the record depends on a vendor’s model version, so a decision made today still replays after the model behind your agent has been swapped.

Where it applies

The engine is industry agnostic. Our focus is not.

Forge reads from whatever control systems you already run, so the engine fits any high-consequence workflow. We are concentrating first where the regulated decision is sharpest. Select one to explore it.

The primary focus

An agent acts faster than any human can review it.

Once an agent proposes, routes or executes a consequential action, human-in-the-loop review stops being timely, scalable or feasible. The reviewable artifact has to be produced at decision time or it does not exist at all. Forge evaluates the proposed action against the policy you encoded and returns a signed record before it executes, so you keep capacity instead of adding a checkpoint.

Pre-action gateAfter-action recordTool and plan tracesAny agent runtime

Vertical one

Model risk and operational resilience already demand substantiation.

Banks, insurers and asset managers already run named control systems: case management, KYC and AML, credit decisioning, limit systems. Those are exactly the named sources the engine reads from. When an automated or agent-assisted call lands inside a critical function, the question from a supervisor is not what happened, it is why it was justified and who held authority.

Head of Model RiskOperational resilienceInternal auditChief Risk Officer

Vertical two

You cannot price an error you cannot define.

Underwriting an AI-enabled process needs the model output, the ground truth it is measured against, and an agreed definition of a meaningful error. Ground truth is the hard one, and it gets harder with generative and agentic systems where no labelled answer exists, only ground rules the system is not supposed to break. Forge produces a signed, deterministic record of the rules a decision was evaluated against, at decision time, by a component the model does not control.

UnderwritingClaims evidenceReserving decisionsGround rules, not labels

The pattern

The determination is confident. The evidence under it is not.

An agent produces a determination: a quote, a claim decision, a reserve, a denial. Forge takes the same evidence that agent was given and runs it against the rules you declared, deterministically, outside the model. Where the submitted evidence does not carry the conclusion, Forge names what is missing and signs that finding, and the record replays later for whoever asks, whether that is a counterparty, a market conduct examiner or a court. Forge does not judge whether an assumption was probabilistic, because that cannot be read off an output. It attests to what the evidence does and does not support. What the gap is worth is your number, not ours.

Same evidence, deterministic rulesNames the unsupported assumptionReplays for an examiner or a courtYou price the gap

Government

Accountability requirements arrive before the technology settles.

Forge Orbital is a US company and the Forge solution has been assessed as Awardable on the DoD CDAO Tradewinds Solutions Marketplace. The engine was built against high-consequence government requirements, including an evaluation by a national agency on a bounded cislunar space-domain-awareness use case. It runs in your environment or ours, selected by one configuration line.

SAM registeredCAGE 1ASL5Customer-hosted optionUS owned

Not a limitation, a sequence

Energy, healthcare, legal, critical infrastructure, defense.

Nothing in the engine is specific to finance or insurance. It reads evidence from named source systems, applies constraints you declare, and signs the result. Any sector where an automated decision has to be defended later is in scope, and several are already in conversation. We are sequencing rather than excluding, because a design-partner-stage company earns the right to breadth by proving depth first.

Energy and gridCritical infrastructureLegal and complianceHealthcare

How we start

Narrow first. One surface, every decision inside it.

No engagement starts with a platform rollout. It starts with one surface you already have to defend: a model under governance, an agent workflow, or a class of decisions that gets challenged. From then on every action inside that surface gets the same deterministic treatment and the same signed record, not a sample and not a demo.

Step one

PilotFour to six weeks

Prove it on one surface

One surface, integrated against your own control systems, with an acceptance test agreed before we start. Real evaluations, signed records, and you verify them yourself offline.

Step two

IntegrationOne time, scoped

Build it into what matters

The surfaces that matter, wired properly into the systems you already run. Scoped once against a fixed statement of work rather than billed by the hour, because the integration is the thing that has to survive an examiner. Integration is also where calibration starts: Forge learns from outcomes you attest to, never by training on your data, and no model is fitted to anything you hold. Held-out outcomes score the confidence number against what actually happened, and the map is applied after the action is chosen, so it can sharpen what a number means without ever changing a decision or the way it replays.

Step three

LicenseAnnual

Scoped to workflows under record

Priced against the workflows under record and the deployment shape, hosted or in your environment. Design partners keep preferred terms as coverage expands.

Enterprise only. There is no free tier and no sign-up flow, because every deployment reads from control systems that have to be scoped with a person in the room. Pricing is set against the workflows under record and the deployment shape, and we will give you a number on the first call rather than after four of them. The scoping question is always the same one: which of your existing control systems should we read from.

The API and trust

One product. One key. One base URL.

RESTPlus OpenAPI, Python and TS SDKs

HashesNot content, so data can stay put

SaaS or on-premOne configuration line

ScheduledIndependent security assessment

Any runtime that can call a tool or fire a hook can reach Forge. Without retention opt-in, no calibration row is written. Forge records the basis a customer supplies and signs it; it does not independently inspect, benchmark, validate, certify, or attest the customer's model, vendor, or data. Production deployment is a qualified managed integration, scoped per workflow, and enforcement mode applies only inside an exclusive protected boundary the customer defines. We publish what the signature proves and what it does not, we do not describe records as immutable, and we would rather tell you a limitation than have your engineers find it in an afternoon.

Who is behind it

No account managers. You work with the people who built it.

Joseph Varga

Founder and Chief Executive Officer

Three years as an executive in defense technology before founding Forge. Built the decision engine and leads the federal and commercial pursuits. BA, Wabash College.

Kyle Helseth

Strategic Advisor

Four years building federal go-to-market at a YC-backed, Series C technology company, most recently as a regional vice president serving US national-security and defense customers. Advises Forge on commercial strategy, enterprise positioning, and regulated-market go-to-market.

Rob Parkhurst

VP of Sales

Nine years as an intelligence specialist at Naval Special Warfare Command, across geospatial and financial intelligence. Runs business development and partner sourcing, working the financial services and enterprise networks the design-partner motion depends on. MBA ’27, University of Notre Dame.

Verify it here

Do not take our word for the proof trail.

Download one bounded synthetic Forge proof, its separately stored test-key pin and an edited copy. The original verifies. The edited copy does not. After download, the check needs no Forge account, API credential or network connection.

Download original Download edited copy

01 · Attribution

Require the separate pin

The embedded public key must derive to the full key ID supplied separately from the proof.

02 · Integrity

Verify the original

The valid synthetic proof passes against that pin and the complete public payload remains bound to its signature.

03 · Rejection

Change one field

The edited copy changes the signed basis. The same verifier fails closed instead of producing a reassuring answer.

macOS or Linux · Python 3.11 Expected: original true · edited false

mkdir forge-proof-check && cd forge-proof-check
curl --proto '=https' --fail --silent --show-error https://forgeorbital.com/verify/files/forge_verify_public_proof.py -O
curl --proto '=https' --fail --silent --show-error https://forgeorbital.com/verify/files/requirements-verifier.lock -O
curl --proto '=https' --fail --silent --show-error https://forgeorbital.com/verify/files/response.json -O
curl --proto '=https' --fail --silent --show-error https://forgeorbital.com/verify/files/tampered_response.json -O
curl --proto '=https' --fail --silent --show-error https://forgeorbital.com/verify/files/trust_root.json -O

python3.11 -m venv .venv
.venv/bin/python -m pip install --require-hashes --only-binary=:all: -r requirements-verifier.lock
KEY_ID=$(.venv/bin/python -c 'import json; print(json.load(open("trust_root.json"))["key_id"])')
.venv/bin/python forge_verify_public_proof.py response.json --expect-key-id "$KEY_ID"
! .venv/bin/python forge_verify_public_proof.py tampered_response.json --expect-key-id "$KEY_ID"

What this proves

The delivered public proof has not changed since the pinned test identity signed it, and a changed field is rejected.

What it does not prove

It does not certify source truth, policy correctness, outcome quality, compliance or execution authority. Those boundaries remain explicit.

Ready to see a record you can verify yourself?

We are working with a small number of design partners to put Forge against real workflows. First conversation is a scoping call, not a pitch.

Everyone logs. A log written by the system being questioned is not independent evidence.

Regulators started naming this problem in their own words.

Forge exists to answer that. Reconstruct the decision, not just the output.

Three properties. One API call.

Independent by construction

Deterministic

Verifiable offline

It is an API key and a base URL. This is what happens in between.

Change one byte and it stops verifying.

Six things Forge is not.

Not a notary

Not logging or observability

Not model explainability

Not a controller

Not another probabilistic system

Not an LLM wrapper

The engine is industry agnostic. Our focus is not.

An agent acts faster than any human can review it.

Model risk and operational resilience already demand substantiation.

You cannot price an error you cannot define.

The determination is confident. The evidence under it is not.

Accountability requirements arrive before the technology settles.

Energy, healthcare, legal, critical infrastructure, defense.

Narrow first. One surface, every decision inside it.

Prove it on one surface

Build it into what matters

Scoped to workflows under record

Built against government requirements from the start.

Standing

Why it fits

One product. One key. One base URL.

No account managers. You work with the people who built it.

Joseph Varga

Kyle Helseth

Rob Parkhurst

Do not take our word for the proof trail.

Require the separate pin

Verify the original

Change one field

What this proves

What it does not prove

Ready to see a record you can verify yourself?