Model-change approval
Show why a change cleared governance, what evidence supported it, what stayed uncertain, and where review occurred.
Financial services
When a model change, credit exception or proposed trade needs review, a model score is not enough. Forge keeps the supplied evidence, policy checks, uncertainty and human approval requirements with the result. Banks, funds and fintech teams can use that trail to explain the decision to their reviewers.
In plainer terms: start by paper-testing one proposed refund, payment, credit, or trading decision. A real pre-action check requires scoped access and a customer-deployed protected boundary the agent cannot bypass.
| 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 | Only authorized firm outcomes with explicit retention opt-in create tenant-local calibration state. Without retention opt-in, no calibration row is written. |
Show why a change cleared governance, what evidence supported it, what stayed uncertain, and where review occurred.
Evaluate selected actions before execution only through a customer-deployed protected boundary the agent cannot bypass. The public walkthrough does not authorize, block, or execute a financial action.
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 | Preserve the recorded basis for a performance or capability claim, then verify the issued complete record under an independently pinned signer and replay the governed result separately. |
|---|---|
| Model-risk governance, SR 26-2 (successor to SR 11-7) | This is your firm's own supervisory regime, not something Forge provides. A qualified managed integration is intended to bind a specific model output to the recorded model version, inputs, and policy; the public walkthrough is not production evidence. |
| NIST AI Risk Management Framework | The proof trail can support Govern, Map, Measure, and Manage documentation. Calibration uses only authorized outcomes the firm explicitly opts in to retain; framework applicability remains the firm's assessment. |
| EU AI Act, Article 10 | Data and data governance. Forge binds every normalized evidence item into the complete proof trail and can carry a caller-supplied source content hash. The complete-record signature is the integrity check. Source freshness or verification affects a decision only when the integration supplies and evaluates that status as evidence or an explicit constraint; Forge does not infer it from a raw file. |
An asset manager's automated workflow proposes a portfolio for a new client. The example below shows how the proposal and the firm's suitability rules could be checked before presenting the allocation. It is synthetic. This page calls no API and describes no 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
complete_record_signature: not generated by this walkthrough
trust_anchor: full expected key ID must be provisioned separately
replay_key: rk_4d8f2a91c... (illustrative; replay compares action + replay key)
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. In a real managed deployment, model validation would verify the issued complete record against an independently provisioned full key ID, then separately replay the governed action and replay key under the pinned engine and configuration. This synthetic page generates no signature or verification result. The human keeps the decision.
Forge is live and tested, at design-partner stage. It can scope one financial workflow with synthetic, sanitized, or approved sample evidence. Production use remains conditional on security, audit, build, deployment, and operational qualification.