Not Another Log
A log says what happened. Forge gives the independent proof of why the action was justified under the evidence and rules supplied.
Public API overview
The API that turns messy evidence into proof.
Forge connects to one high-consequence workflow and returns the thing a reviewer actually needs: why the action cleared, held, escalated, or was rejected. It shows the evidence that mattered, the rule that controlled the action, the uncertainty that remained, where human authority stayed, and how the result can be checked without trusting the original system's own logs. The engine is deterministic with no language model in the signed path, and every result is Ed25519-signed and verifiable offline.
Built For Challenge
The output is meant for the regulator, auditor, insurer, board, customer, program office, or executive team that asks why this action was allowed.
Proof Starts First
The first workflow can run through a scoped test path on non-sensitive data, then expand only after the buyer sees the proof hold up.
What Forge does through the API
The customer keeps the workflow, data custody, policy authority, and final business decision. Forge becomes the independent checkpoint around selected high-consequence actions. When the action matters enough that someone may challenge it later, Forge turns the evidence around that action into reviewer-ready proof.
Messy evidence becomes a clear case.
Forge accepts the evidence a team already has: questionnaires, reviews, control checks, exceptions, claims, policy constraints, approvals, notes, and missing items. It does not need the customer's whole system to show whether the action can be defended.
The allowed action is bounded.
The customer defines the action menu. Forge does not invent business outcomes. It determines which allowed action the supplied evidence supports, such as proceed, hold, escalate, reject, or a customer-defined equivalent.
The why is preserved at decision time.
The result carries the evidence path, controlling rule, confidence, uncertainty, and human-review boundary. The proof is created when the action is evaluated, not after a problem forces someone to reconstruct what happened.
The proof can stand outside the system.
A reviewer can check the result without relying only on the model, agent, workflow, or email trail that produced the original action. That is the difference between a self-attested log and a defensible proof trail.
The checked path is deterministic.
No language model sits in the signed path. Forge uses canonical inputs, bounded actions, reproducible checks, and standard Ed25519 verification so the proof can be replayed instead of explained away.
AI agents
Model governance
Underwriting
Vendor review
Infrastructure risk
Federal autonomy
How the integration fits
The public API overview is intentionally high-level. The shape is simple enough for a buyer to understand, but the private schema, tenant routes, adapters, scoring details, and runbooks stay behind workflow fit and security review.
01
Name the decision
Pick the action that would be painful to defend later if the proof trail is scattered across tools.
02
Define the boundary
Set the allowed actions, required approvals, hard constraints, and when a human must remain in control.
03
Send bounded evidence
Use synthetic, sanitized, or non-sensitive examples first. Production data waits for the right agreement and path.
04
Get decision proof
Forge returns the supported action, why it was supported, what stayed uncertain, and what must be reviewed.
05
Measure outcomes
Later outcome tags let Forge show whether that workflow is calibrated, over-confident, or still too early to call.
What this public page does not give away
Public API pages should create confidence, not publish the inside of the engine. Forge gives enough for a technical lead to see the integration model while keeping sensitive implementation detail out of the open.
- No live keys or tenant routes. Access is scoped after a named workflow and technical owner are identified.
- No full request or response schema. Field-level mappings, validation rules, and customer adapters are private handoff material.
- No scoring weights or engine internals. The public page explains the buyer outcome, not the internal mechanics.
- No customer data examples. First proof uses synthetic or sanitized evidence unless a buyer approves a different path.
- No certification overclaim. SOC 2, FedRAMP, ATO, and CMMC are not claimed. Production use follows the required diligence path.
Private handoff: after workflow fit, Forge provides the full quickstart, schema, test key,
verification notes, and security answers for that specific buyer and workflow.
Calibration without training
Forge can measure calibration on a customer's workflow without training on customer data. The customer tags what actually happened after an evaluated action. Forge compares the earlier confidence to the later outcome and shows whether the workflow is calibrated, over-confident, under-confident, or too early to call.
What improves
The customer's understanding of whether the workflow can be trusted, where confidence is strong, and where review boundaries need to stay tight.
What does not happen
Outcome feedback supports metrics-only calibration. It does not train Forge on customer data, create cross-customer learning, or put production data into a model.
Why executives care
Leadership does not just need a decision. They need to know whether the system understands when it is right, when it is uncertain, and when a person must step in.
Why reviewers care
The proof trail shows the evidence and rule behind one action. Calibration shows whether that workflow is earning trust over time.
Security and data boundary
The open page is not a key handoff. Live access is scoped to a named buyer, named workflow, and agreed integration path. The customer keeps custody and authority.
- Access
- Scoped credentials only after workflow fit. No public evaluation access.
- First data
- Synthetic or sanitized evidence is preferred for the first technical screen.
- Customer control
- The customer keeps the source systems, evidence vault, policy authority, and final decision.
- Verification
- The result is built so an outside reviewer can check the proof without trusting the original system's own logs.
- Training
- Outcome feedback supports metrics-only calibration. It does not train Forge on customer data.
- Production
- Restricted data and enterprise rollout wait for agreement, security review, and deployment path.
What a buyer gets after fit
The private handoff is concrete and narrow: the agreed workflow, a test access path, the exact data boundary, the verification path, and the acceptance criteria for the first proof. No giant migration. No vague platform adoption. One decision earns the next step.
For engineering
- Workflow-specific quickstart.
- Full schema and field mapping.
- Retry, idempotency, and error handling notes.
- Verification instructions for the returned proof.
For security and review
- Trust and security answers.
- Data handling boundary.
- Hosted, customer-operated, or isolated deployment discussion.
- Plain limitations before any production use.
Bring one decision. If Forge cannot show a stronger proof trail on that one workflow, the buyer should not
expand. If it can, the expansion path is obvious.