Connect your workflow. Check the result.

What you send, what comes back, and what a reviewer can check

Forge records the result and its basis when an action is evaluated. Your team keeps that record instead of rebuilding the explanation later from logs and emails. These are the inputs and outputs.

What the record does not prove

• Forge does not validate your inputs. Forge does not independently inspect, benchmark, validate, certify, or attest the customer's inputs. Evidence arrives as the customer's own bounded summaries and references. If an upstream system supplied something false, the record faithfully preserves that it was supplied, not that it was true.
• There is no generative model in the signed path. The evaluated result is produced by a deterministic engine. No language model sits between the request and the signature, so there is nothing in the signed path that can paraphrase, invent, or drift.
• Tamper-evident, not unchangeable. The record is tamper-evident under replay and reproduces byte for byte. Any alteration breaks verification. That is a detection property: it means a change is caught, not that a stored copy cannot be edited or deleted. Custody of the stored record stays with the customer.
• Signature and replay answer different questions. The Ed25519 signature establishes that this record is authentic and unaltered. Deterministic replay separately establishes that the same basis reproduces the same content. Neither one is evidence that the underlying facts were correct.
• Forge does not execute your action. Forge returns a disposition and a proof trail. Whether anything actually runs is decided by the customer's own separately qualified boundary, which the customer owns and operates.
• No certifications and no endorsements. SOC 2, FedRAMP, ATO, and CMMC are not claimed. No regulator or standards body endorses Forge, and nothing on this page should be read as an accreditation of the customer's own system.
• Design-partner stage, stated plainly. The engine is live and tested at design-partner stage. This page publishes no live key, tenant, or production-ready claim, and the public demo pages are illustrative synthetic walkthroughs rather than live customer calls.

How to get access

Before issuing credentials, we agree the workflow, technical owner and data boundary. The steps below show what your team needs for the handoff.

1. Apply, or ask for a scoping call

   You send one message describing the decision you want proof for. Forge replies with either a scoping call or a straight answer that this is not a fit. There is no queue to sit in and no form that disappears.

   Bring: one named decision or automated action, the business reason it would be hard to defend later, and who owns it internally. One paragraph is enough.

2. The fit conversation

   A short working call on that one decision. The goal is to establish whether the decision can be expressed as a closed option list with real evidence behind it. Some cannot, and that is a legitimate outcome of this stage. Forge says so rather than scoping a project around it.

   Bring: the workflow owner and a technical owner, the actions currently possible at that decision point, the rules and approvals that apply, and where a human must stay in control.

3. Boundary and security review

   Before any credential exists, both sides agree what data may cross, where the record is stored, and which deployment shape applies. Forge is one API: the base URL picks the host, so a customer-operated deployment is a configuration decision rather than a different product.

   Bring: your security review route, your data-handling constraints, your deployment preference, and the procurement path this would follow.

4. Scoped credentials, then one synthetic call

   Forge issues the named technical owner a signed onboarding descriptor and a separate display-once managed key file. The onboarding authority key id and public key arrive through an independent trusted channel. The first call runs on synthetic or sanitized evidence and ends with a verified record saved in your own environment. Restricted data enters scope only after that has worked.

   Bring: the named technical owner, a place to store the returned record, and a reviewer from security, legal, or the workflow itself to read the first proof.

First call after a scoped handoff

The first-call path takes four customer-supplied values: two local file paths plus the independently delivered onboarding authority key ID and public key. The SDK verifies the complete descriptor, reads the managed key without exposing it, confirms its active durable identity, derives every runtime and signer pin, sends one synthetic request, verifies the returned proof locally, and saves it before an adapter is written. The SDK derives a stable non-PII idempotency key for this exact first call.

The standalone enterprise API exposes one compact-v1 response contract. There is no response profile header to configure and no legacy diagnostic envelope in the buyer runtime. Every retry under the same Idempotency-Key returns the same committed compact response.

The signed descriptor supplies the complete action menu, safe fallback, exact control profile, allowed operation, tenant, API origin, and record-signing trust anchor. The issued decision:write key can evaluate the described decision but cannot reach tenant administration, calibration, or unrelated routes.

The protected AI-agent operation is POST /v1/decision-records/pre-action. Forge returns a disposition and proof trail; only the customer's separately qualified boundary decides whether an action may execute.

export FORGE_VERIFIER_PY="$PWD/.forge-verifier/bin/python"
test -x "$FORGE_VERIFIER_PY"
export FORGE_ONBOARDING_DESCRIPTOR_PATH="/secure/forge-onboarding.json"
export FORGE_BOUNDARY_API_KEY_FILE="/secure/forge-managed-key.json"
export FORGE_ONBOARDING_AUTHORITY_KEY_ID="ed25519:<64-hex-key-id>"
export FORGE_ONBOARDING_AUTHORITY_PUBLIC_KEY_B64="<base64-32-byte-key>"
export FORGE_FIRST_CALL_RECORD_PATH="/customer-vault/forge-first-call.json"

PYTHONPATH=sdk/python "$FORGE_VERIFIER_PY" sdk/python/examples/quickstart.py

Run that command from the root of the verified Forge integration kit. The kit contains the SDK, verifier, examples, and an offline golden proof; no Forge source checkout is required. The example saves forge-first-call.json only after complete-record, request-binding, action-binding, and profile-v2 control verification succeeds.

Record and proof versioning

Record schema is forge-decision-record/v2; the complete-record proof scheme is v3. The two version independently. Authenticated responses include a complete v2 record Ed25519 signature. Offline attribution requires the verifier to use a full signing-key ID provisioned through a separate trusted channel; integrity and replay do not prove the supplied evidence or the business judgment.

Response fields the caller uses

The response includes the complete signed record. The compact fields below are non-authoritative convenience projections and must match that record when the full envelope is verified:

{
  "decision": {
    "action": "block",
    "abstained": false,
    "abstention_reason": null
  },
  "record_reference": {
    "record_id": "FDR-<32-hex-issued-id>",
    "replay_key": "<64-hex-semantic-basis-id>",
    "verification_required": true,
    "complete_record_signature": {
      "algorithm": "ed25519",
      "key_id": "ed25519:<derived-64-hex-key-id>",
      "signed_field": "complete_decision_record"
    }
  },
  "record": {
    "schema_version": "forge-decision-record/v2",
    "selected_action": "block",
    "complete_record_signature": {"...": "complete signature block"}
  }
}

This sample is designed to exercise the fail-closed policy path: the submitted hard constraint fails, so the engine selects the in-menu block action with abstained=false. Treat that disposition as a refusal to send the trade. A separate low-confidence or incomplete-evidence request can select the configured hold abstention action, but that is not the result of this sample.

Do not branch on decision.action before verification. After the complete envelope verifies, those fields may be used for display because the verifier has proved they exactly match the signed record. Use record_reference.record_id as the issued-record handle and record_reference.replay_key as the semantic replay handle. Before relying on the result, verify record.complete_record_signature against the full Forge key ID provisioned through your separate trusted onboarding/configuration channel. The verifier must derive the key ID from the public-key bytes; a declared or embedded key ID, or same-API identity readback, is not a trust anchor.

"$FORGE_VERIFIER_PY" scripts/forge_verify_record.py "$FORGE_FIRST_CALL_RECORD_PATH" \
  --expect-key-id "$FORGE_SIGNING_KEY_ID" \
  --expect-control-environment "$FORGE_CONTROL_ENVIRONMENT" \
  --expect-control-deployment-id "$FORGE_CONTROL_DEPLOYMENT_ID"

# Continue only when the verifier reports all three:
# verified=true, full_record_integrity=true, production_attributable=true

The scoped handoff supplies the versioned forge_verify_record.py verifier with its reviewed runtime requirements. Obtain the full expected key ID separately; do not copy it from the response or identity-readback endpoint.

For an online execution boundary, use the reviewed SDK supplied in the managed handoff or implement the published forge-client-request-binding/v1 tagged-JSON contract exactly. The client must reject an old but otherwise valid signed record when the operation, request ID, question, evidence, action menu, or tenant differs from the request just sent. Only then may it read record.selected_action, and only a separately configured allow-family action may proceed.

Persist the complete record in the customer system of record. The v3 complete-record proof binds every delivered decision-record field, including signer and format metadata. Only its self-referential signature bytes and signed-message digest are omitted and independently checked. Deterministic replay is a separate reproducibility check; neither mechanism proves that customer-supplied evidence is true.

Fail closed in the caller

• No execution authority on transport or contract failure. Timeout, non-2xx status, invalid JSON, schema mismatch, a decision/record action mismatch, or an action outside the request menu means use the declared safe fallback.
• No execution authority on trust failure. Missing signature, failed complete-record verification, a derived key-ID mismatch, or verification_required not equal to true means stop.
• No execution authority on a non-allow result. In this example, hold, escalate, any abstention, or any value other than an explicitly permitted allow routes to the human boundary.
• Retry deliberately. Reuse an idempotency key only with the identical request. A different payload needs a new key; never retry around a hold, escalation, abstention, or verification failure.

Compact error model

What Forge does through the API

The customer keeps the workflow, data custody, policy authority, and final business decision. The API records the supplied evidence and encoded policy result for selected actions. It becomes a pre-action control point only after the customer deploys and validates an exclusive protected boundary.

How the integration fits

The public contract endpoints define the common request, response, verification, and deployment surfaces. Tenant-specific field mapping, adapters, scoring configuration, and operating runbooks are scoped after workflow fit and security review.

What happens after yes

The handoff is practical. Forge issues a scoped API key to the buyer's technical owner, sends a synthetic workflow, and walks the team from first call to first proof trail before any sensitive production data is in scope.

Public reference and private handoff

The common contracts are public; the internal scoring implementation is not. Customer-specific mappings and operating details stay inside the scoped handoff.

• No live keys or tenant routes. Access is scoped after a named workflow and technical owner are identified.
• One canonical common contract. This overview does not duplicate every field inline. The describe and schemas endpoints above are the machine-readable source of truth reachable from this site; the standalone OpenAPI contracts are served by the decision API on the issued host.
• Common schemas are public. The describe, schemas, signing-identity, and integration-status endpoints above define the shared contract.
• Customer mappings remain private. Tenant-specific source fields, validation rules, and 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.

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 your integration team receives

Your handoff covers the agreed workflow, test access, data boundary, verification instructions and acceptance criteria. Engineering and security reviewers get the details they need for that integration.