One decision that matters.
Approve, deny, bind, hold, refund, escalate, release, submit, or another action your organization already defines and already governs.
How to start with Forge
From first conversation to working integration.
Tell us what your AI does and what you want checked. We work with your business and technical owners to agree the scope, connect your systems and test the result. Below is the path from first contact to your team's deployment review. Forge is live and tested, and it is at design-partner stage.
Who this is for.
Forge is for businesses of any size using AI or software in decisions that matter. Your team may need to explain those decisions to a customer, an auditor, an insurer, a regulator or your board.
Could you explain a decision from six months ago without piecing together emails and screenshots? Forge keeps the supplied evidence, rules, uncertainty and human approvals with the result.
An outside reader in your future.
A regulator, auditor, insurer, litigator, counterparty, or internal second line who will eventually ask you to justify a specific decision.
Low-stakes volume.
Decisions nobody will ever ask about do not need a signed record. Forge will tell you so on the first call rather than sell you a project.
Forge is sold and delivered as a scoped engagement with a named technical owner on your side. There is no sign-up form on this site and no public product tier. That is deliberate. Every engagement is scoped against a specific decision in a specific environment.
What we discuss first.
We discuss the work you want checked, the tools you use and who manages them. You do not need a technical brief or confidential data. We work out whether Forge fits and what your team would need for setup before proposing an engagement.
The decision and the reader.
What gets decided, who or what decides it today, and who would question it later. Nothing confidential is needed at this stage.
Fit, or no fit, plainly.
We explain what Forge could add to your workflow, what integration would involve and where it would not help.
A written follow-up.
A short summary of the decision as Forge understood it, the fit assessment, and the proposed next stage or a clear no.
A clear no is a real outcome of this call and it happens. Forge would rather decline a poor fit in the first conversation than discover it during an integration.
What happens next.
Email us or book a conversation through the contact page. The stages below show a typical path. The first two do not require system access, confidential material or a financial commitment.
You email Forge.
Send one paragraph describing the decision you would not want to reconstruct from memory. We will discuss the fit, who needs to be involved and the next step.
Forge sends a written scope.
One decision, the evidence it relies on, the options a decider may choose from, the policy conditions, and where human authority stays. You receive this document before anything is signed or connected.
A mutual non-disclosure agreement, then technical review.
Only once real specifics are in play. Your security, privacy, and legal reviewers get the data-handling description, the security documentation, and access to ask questions directly.
One workflow runs on synthetic or sanitized evidence.
The first run deliberately uses made-up or de-identified evidence so your team can examine the whole mechanism before any restricted data is in scope. You receive signed decision records from that run.
You review and decide.
Your engineering, security, legal, and business reviewers read the records and verify one offline. You then decide whether to extend to real evidence, stop, or walk away. Nothing renews by default.
Commercial terms are discussed with you directly once the scope is known, because they depend on the decision, the environment, and the depth of integration. They are not published on this site and they are not quoted before the scope exists.
What we need for setup.
Start with these six questions. We can discuss them without accessing your systems or customer data. Your technical team can help fill in the details.
| The decision question | The single question being decided, written as your organization would write it. For example: should this claim be paid, held, or referred to a human adjuster? |
|---|---|
| The decision options | The complete list of dispositions a decider is permitted to select. You define this list. Forge does not add to it, and the engine cannot select anything that is not on it. |
| The evidence | Which facts, documents, scores, model outputs, or system signals are placed in front of the decider, and where each one comes from. |
| The policy conditions | The rules, thresholds, and constraints that must hold. These are your policies, expressed in your language. Forge records the result of applying them. |
| The human boundary | Which conditions must stop and go to a named human, and who that human is. This includes the cases where evidence is too thin to decide at all. |
| The two owners | One technical owner who can answer questions about systems, and one business or compliance owner who can say whether the record would satisfy the outside reader. |
Notice what is not on this list. Forge does not need production credentials, a data migration, a platform rollout, or a change to how your organization makes decisions. Your policies stay yours and your people keep their authority.
What you receive at each stage.
| After stage 1 | A written summary of the decision as Forge understood it, an honest fit assessment, and either a proposed scope or a clear no. |
|---|---|
| After stage 2 | A written scope covering one decision: the question, the options, the evidence, the policy conditions, the human boundary, and what stays entirely under your control. |
| After stage 3 | A data-handling description for your privacy and legal reviewers, security documentation for your security reviewers, and direct access to ask follow-up questions. |
| After stage 4 | Signed decision records produced from the synthetic or sanitized run, plus the material needed to verify one offline without trusting Forge. |
| After stage 5 | A written review of what worked, what did not, what your reviewers still need, and a recommended next step or a recommendation to stop. |
The evidence your team keeps.
Each decision record keeps the result and its basis together. People can read it; software can check its integrity. These are the details available to your reviewers.
| The decision question | The question that was being decided, in your organization's own words. |
|---|---|
| The decision options | The complete list of dispositions that were available, as your organization defined them. |
| The selected disposition | Which option was selected. The selection is bound to your menu: it can only ever be one of the options on your own list. |
| The supplied evidence and its per-option support | Each item of evidence that was supplied, and how much that item supported each available option. This is what makes the reasoning legible rather than asserted. |
| Constraint and policy results | Which of your policy conditions and constraints were evaluated, and what each one returned. |
| Confidence and uncertainty | How confident the evaluation was, and where the uncertainty sat. Recorded as a stated quantity, not as a reassurance. |
| The abstention or hold path | When the evidence was insufficient to select any option, the record shows that the system declined to decide and shows why. Abstaining is a recorded outcome, not a failure. |
| The human-review boundary | Where the boundary sat and which named human retained authority. The record is explicit that a person, not the software, held the decision. |
| A canonical request basis hash | A fixed fingerprint of exactly what was submitted, so a reviewer can confirm the record corresponds to that submission and no other. |
| An Ed25519 signature | A cryptographic signature over the record, using a widely implemented public standard. |
| Offline verification material | The public key, the key identifier, and the algorithm, so a reviewer can check the signature on their own machine without trusting Forge and without trusting the system that produced the record. |
The last point is the one that usually matters most to a legal reader. Verification does not require Forge to be online, cooperative, solvent, or still in business. A reviewer with the record and the public key can check it themselves.
Boundaries
What a signed decision record does not do.
- It supports a defense. It does not prove you were right. The record shows what was decided, on what basis, under which policy, and with whom holding authority. It does not prove that the evidence you supplied was true, and it does not prove that the business judgment was correct.
- Forge does not vouch for your inputs. Forge does not independently inspect, benchmark, validate, certify, or attest the evidence, models, scores, or data you supply. Forge records what was supplied and how it was used.
- There is no generative model in the signed path. Nothing in the path that produces a signed record writes prose, invents a rationale, or paraphrases your evidence. The disposition is selected from your list and the record states the basis.
- Tamper-evident, not unchangeable. A record reproduces byte for byte under replay, so alteration is detectable. Forge does not claim that a record can never be altered or deleted, and does not describe records as unchangeable.
- Your authority does not move. You keep your source systems, your policy authority, your evidence, and the final business decision. Forge signs the record of what happened; it does not take execution authority over your workflow.
- No claim of endorsement or accreditation. Forge claims no customers, no deployments, no certification, no accreditation, no authority to operate, and no endorsement from any regulator or standards body. Forge is live and tested at design-partner stage, and says so plainly.
- Sensitive environments require qualification. Forge is one API and the base URL picks the host, so a customer-operated, isolated, or on-premises deployment is designed to be a configuration decision rather than a different product. The target environment is contract-scoped and requires workload, hardware, dependency, security, operational, and accreditation qualification, and Forge claims no compliance, certification, accreditation, or authority to operate of its own.
Where your data sits, in plain terms.
Made-up or de-identified evidence.
Stage 4 runs on synthetic or sanitized evidence by default, so your reviewers can inspect the whole mechanism before restricted data is ever in scope.
Nothing is retained without your opt-in.
Forge can compare a past confidence against a real outcome only if you supply an authorized outcome and explicitly opt in to retention. Without retention opt-in, no calibration row is written.
No product model trains on you.
Calibration scoring does not train a product model on customer data and does not create learning that moves between customers. It keeps score against prior confidence; it does not change your rule logic.
Retention of decision, audit, and accountability records is a separate matter, governed by the deployment pattern and the written engagement rather than by a default setting.
Tell us about your AI work.
Tell us which tools you use, what they do and what you want checked. We can work through the scope with you and whoever manages your systems. No technical pitch is needed to start.