Model risk documentation pack

Putting Sentinel in your model inventory.

Written for the model risk function that has to classify, validate and monitor a purchased control. It covers the classification question first — because under SR 26-2 the honest answer may be that Sentinel is not a model at all — then gives you the evidence for whichever way you decide.

1. Start with the classification question

Most vendors hand a model risk team a model card and let them work it out. The more useful thing we can do is tell you what the guidance actually says about software like ours, and give you the evidence to make the determination yourself.

Sentinel’s enforcement path is comparison operators, an AST expression evaluator, condition types and fixed verdict precedence. No statistical, economic or financial theory underpins it. On the face of the guidance, that falls inside the exclusion.

2. The evidence, and the complication

Fourteen pipeline components are classified. Twelve are deterministic. Two are genuinely statistical, and we say so rather than rounding down.

One statistical component can influence a verdict, and it is disableable. With anomaly_enabled=false, every component in the decision path is deterministic. That is the configuration in which the SR 26-2 exclusion argument is strongest, and it is a configuration you set, not a claim we make.

# Retrieve the classification from your own instance
curl $BASE/governance/determinism/classification

# And the attestation for your current configuration
curl $BASE/governance/determinism/attestation

The classification endpoint is configuration-independent, so you can export it before deciding anything. The attestation reflects the config actually running.

3. Whichever way you classify it

4. Inventory record

Fields for your model inventory. Sentinel keeps its own inventory for the agents it governs, so the shape will be familiar.

The development data row is the one most inventory templates have no good answer for with an AI vendor. Ours is that there is no training corpus, no fitted parameter and no retraining schedule, because nothing was learned. Confidence values in the security stages are hand-authored constants, which is a design choice with real limitations — see the measured detection rates.

5. Validation evidence

SR 26-2 keeps three validation components: conceptual soundness, outcomes analysis, and ongoing monitoring. Here is what to collect for each, and where it comes from.

6. Section VII — vendor obligations

These survived the SR 26-2 rewrite intact and apply to a vendor product regardless of how you classify it.

Sentinel also runs a Section VII register for your vendor products, inheriting each product’s materiality from the agent types it feeds. That is a separate capability from this pack — see the SR 26-2 brief.

7. What we cannot give you

• Independent third-party validation. None has been commissioned. Our evidence is reproducible by you, which is a different and weaker thing than an outside party having reproduced it.
• A penetration test report. Not commissioned. Internal adversarial testing exists in the suite and is not the same thing.
• SOC 2 or ISO 27001. Not held. Current posture and the trigger for starting.
• Backtesting against your portfolio. We have no customer data. A shadow-mode pilot is how that evidence gets generated, and it generates it in your environment.
• A benchmark against competing products. We have not run one and will not publish a comparison we cannot reproduce.
• An assertion that we are out of scope. §1. That determination is yours.

If your MRM template has a field this pack does not answer, send it. We would rather add it here than answer it once verbally.