Model-change approval
Show why a change cleared governance, what evidence supported it, what stayed uncertain, and where review occurred.
Financial services
Banks, funds, fintechs, and market infrastructure teams are already using models and AI agents inside decisions that examiners, boards, customers, and counterparties may challenge later. Forge turns the scattered evidence behind those decisions into a defensible proof trail.
| Messy evidence | Model output, validation notes, control checks, counterparty evidence, approvals, policy text, exceptions, and missing facts. |
|---|---|
| Allowed actions | Proceed, hold, escalate, reject, approve with conditions, or any equivalent action menu the firm defines. |
| Proof trail | The controlling evidence, rule applied, confidence, uncertainty, alternatives, and human-review boundary. |
| Calibration | Outcome tags let the firm see whether the workflow is calibrated over time without product training on customer data or cross-customer learning. |
Show why a change cleared governance, what evidence supported it, what stayed uncertain, and where review occurred.
Check selected agent actions before execution and return proceed, hold, escalate, or reject with proof.
Turn one recurring exception workflow into proof a CCO, risk owner, or examiner can inspect.
Forge supports the documentation and evidence obligations behind modern model governance. It does not certify compliance, and no Forge proof trail is a legal conclusion. That line stays with your counsel and your regulators.
| SEC Marketing Rule | Substantiate on demand. The proof trail reproduces the basis for a performance or capability claim as it stood on the day it was made, with the replay key and the signed evidence chain, however long after the fact the request arrives. |
|---|---|
| Model-risk governance, SR 11-7 tradition | This is your firm's own supervisory regime, not something Forge provides. The proof trail binds a specific model output in production to the model version, inputs, and policy in force at the moment of the decision, including decisions an agentic workflow made with no human in the loop. |
| NIST AI Risk Management Framework | The proof trail gives Govern, Map, Measure, and Manage a concrete artifact. Measurement is traceable and reproducible, and confidence is calibrated against real outcomes through feedback you control. |
| EU AI Act, Article 10 | Data and data governance. Each input is carried with its source and a content hash, and stale or unverified data is flagged rather than absorbed, supporting the record's technical account of how a determination was reached. |
The following is a synthetic, representative example for a de-identified archetype: a mid-size asset manager running an agentic onboarding workflow. An automated workflow proposes a model portfolio for a new client, and the suitability determination is pointed at the Forge API against the firm's encoded suitability policy before the allocation is presented. Names, values, and hashes are illustrative and do not describe any real client, model, or record.
decision_id: sfa-2026-04-17-0002913
surface: client_suitability_screen
policy_ref: suitability_policy_v7 (hash sha256:1b9c4e... )
disposition: REVIEW_REQUIRED
confidence: 0.71
data_reliability: 0.63 (one input flagged stale, see evidence e3)
evidence_chain:
e1 risk_tolerance = "moderate-conservative"
source: onboarding_questionnaire_Q9 | hash sha256:7a02f1...
e2 liquidity_need = "high, 0 to 12 months"
source: onboarding_questionnaire_Q14 | hash sha256:c48d20...
e3 income_verification = "unverified"
source: kyc_service_response_2026-04-17 | hash sha256:9f2a3c...
note: value older than policy freshness window (stale)
e4 proposed_allocation = "70% equity growth sleeve"
source: portfolio_model_M22_output | hash sha256:5e11ab...
extraction: normalized pre-decision, outside signed path
alternatives_considered:
a1 APPROVE rejected: liquidity_need conflicts with e4 horizon
a2 DECLINE not selected: risk profile not disqualifying on its own
a3 REVIEW_REQUIRED selected
uncertainty_held:
- income unverified (e3); confidence capped pending refresh
- questionnaire risk tolerance conflicts with proposed equity weight
human_review_boundary:
route_to: suitability_reviewer_queue
reason: high-liquidity-need vs high-equity-weight conflict + stale KYC
recommended_next_action:
refresh income_verification, then re-run; or route to a licensed
reviewer for a documented override with rationale
signature: Ed25519 (integrity check; verifies offline)
replay_key: rk_4d8f2a91c... (same input reproduces this record)
Read it the way a reviewer would. The disposition is not "the model said yes." It is that the policy, applied to these exact inputs, requires human review, and precisely why: the equity-heavy model output was flagged against a stated high liquidity need, and the KYC input was carried with a note that it fell outside the firm's freshness window, so confidence was capped rather than quietly asserted. The decision routed to a licensed human with the reason attached. Later, model validation re-runs the replay key and gets the identical record, and an examiner verifies the signature offline without taking the firm's word for any of it. Forge returns the disposition and the proof trail. The human keeps the decision.
Forge can integrate on one financial workflow with synthetic, sanitized, or approved sample evidence, then show whether the proof trail is strong enough to expand.