Name one decision.
Refund, hold, bind, approve, reject, escalate, submit, block, or another buyer-defined action.
Customer onboarding
They said yes. Now get a proof trail running.
Forge onboarding is built for a fast technical screen, not a giant platform migration. The buyer names one high-consequence decision surface, receives a scoped access path, runs a synthetic or sanitized workflow, and reviews the proof trail with engineering, security, legal, or the business owner.
The onboarding path is intentionally narrow.
Forge starts with the decision a buyer does not want to reconstruct from screenshots, logs, emails, or memory. Once that surface is named, the technical work is concrete: map inputs, map allowed actions, run the API path, store the proof trail, and review what the outside reviewer would see.
Map evidence and rules.
Identify the source facts, policy boundary, allowed actions, and where human authority must remain.
Run synthetic first.
Use a synthetic or sanitized workflow so the proof model is visible before restricted data is in scope.
Review the proof.
Engineering and the workflow owner inspect evidence, rule, uncertainty, human boundary, replay, and integrity check.
Scope the next step.
Expansion follows observed proof trails, not a broad promise. One workflow earns the next one.
Verification stands on its own. Offline and air-gapped, an outside reviewer can confirm a proof trail is authentic and re-derive the determination from the recorded inputs, without trusting Forge, using the standalone verifier that ships with the key. The integrity check confirms the record; deterministic replay reproduces the result.
What the buyer receives after workflow fit.
| Integration brief | A one-page map of where Forge sits, what the buyer sends, what Forge returns, and what stays under customer control. |
|---|---|
| API quickstart | Workflow-specific access instructions, sample synthetic payload, response walkthrough, verification notes, and error-handling expectations. |
| Sandbox workflow guide | A guided run using a synthetic AI-agent or model-governance workflow so the buyer can see proof before sensitive data is involved. |
| Data-handling memo | What Forge needs, what Forge does not need, where data can stay, what is stored, and how retention is handled under the engagement. |
| Calibration explainer | How outcome feedback keeps score against prior confidence without silently training on customer data or changing the buyer's rule logic. |
The first pilot is 10 business days when the surface is named.
Pick the surface.
Name the decision, reviewer, data boundary, technical owner, and business owner.
Map inputs and actions.
Capture evidence sources, policy conditions, allowed actions, uncertainty flags, and human-review triggers.
Connect or simulate.
Run the scoped API path or synthetic workflow. Keep the first data path clean and bounded.
Generate proof trails.
Review action, evidence, rule, uncertainty, human authority, verification, and storage on the buyer side.
Decide the next SOW.
Document gaps, security needs, integration depth, success criteria, and whether the workflow should expand.
Data boundary
Forge does not need the whole enterprise to prove one action.
- Start with bounded evidence. The first workflow can use synthetic, sanitized, redacted, or approved non-sensitive evidence.
- Customer keeps authority. The buyer keeps the source systems, policy authority, evidence vault, and final business decision.
- Private handoff stays private. Tenant routes, live keys, full schemas, field mapping, and adapters are provided only after workflow fit.
- Sensitive paths have options. Hosted, customer-operated, isolated, and on-premises paths are discussed during security review.
Calibration improves measurement, not secret model behavior.
Forge starts working on day one. After the customer later tags what actually happened, Forge compares the earlier confidence against the later outcome and shows whether the workflow is calibrated, over-confident, under-confident, or still too early to call. That loop helps the buyer understand where the workflow is earning trust. It does not train its product on customer data, and it does not learn across customers.
The customer tags outcomes.
The tag comes from the buyer's own review, event, claim result, approval state, or follow-up evidence.
Forge keeps score.
Prior confidence is compared against what happened, so the workflow's trust profile becomes visible.
No silent training.
Metrics-only calibration does not train Forge on customer data or mutate the buyer's decision logic.
Bring one workflow and one technical owner.
Forge will not ask a buyer to start with a giant implementation. Start with the action that needs proof, then let the proof trail decide whether the next step is worth taking.