Governance that runs after a model is already serving customers isn't governance — it's a post-mortem with a compliance label on it. By the time an audit finds a control gap in a live model, the only question left is how to explain it to the regulator, not how to have prevented it. The Zytra SDK exists to move that checkpoint back into the pipeline, where a failure gets caught before a customer ever sees it.
Why governance-as-a-separate-workstream keeps failing
Most AI governance today runs in parallel to engineering, not inside it. A model gets built, validated, and deployed. Separately — on a different timeline, often with a different team — governance staff document controls, compliance maps policies, and risk updates a register. This structure breaks in two predictable ways.
First, evidence gets reconstructed after the fact. Someone pulls logs, retraces validation runs, and writes a narrative that takes weeks to assemble and is never quite complete. Second, the gap between what was actually tested and what got documented grows with every release — nobody malicious is causing this, it's just what happens when two processes run on separate clocks. By the time an OCC examiner or RBI inspector asks for the evidence trail, the team is assembling something that was never designed to be assembled on demand.
SR 11-7 is explicit that this isn't optional: model risk management requires ongoing monitoring and a documented validation process, not a one-time exercise and not a document produced in response to an examination request. "Ongoing" means every deployment, every material change, every material drift event — not once a year when the audit calendar says so.
Policy-as-code, in practice
The SDK lets a bank express governance policy as code that runs inside its own CI/CD pipeline. A policy might say: this model must clear a minimum benchmark threshold before promotion, must pass the FinProof Tier 1 calibration set, and must have an assigned risk owner on file in the governance registry before it ships.
from zytra import Governance
gov = Governance(tenant="acme-bank")
result = gov.check(
model="loan-assistant:v4",
policy="sr-11-7-high-risk",
)
assert result.passed, result.findings
When that check runs, it does two things at once: it enforces the policy gate — failing the build if the requirements aren't met — and it writes a hash-chained evidence record to the signed ledger. The evidence is a side effect of the pipeline doing its normal job, not a separate task someone has to remember to do.
Evidence as a by-product, not a project
This distinction is the whole point. Evidence collection run as its own project competes with engineering time for attention, and it loses that competition more often than anyone wants to admit — a sprint deadline will always feel more urgent than a compliance write-up due next quarter. Evidence collection that's a by-product of a process already running — the CI/CD pipeline itself — happens on every build, with no marginal effort and no one who has to remember to do it.
Each SDK check produces a timestamped, hash-chained record: which policy ran, what model version, what result, who triggered it. Those records accumulate into an evidence ledger exportable in PDF or OSCAL format for regulatory review, or surfaced directly in Zytra's governance dashboard for day-to-day use.
What the SDK deliberately doesn't do
It doesn't replace human judgment on high-risk decisions. It enforces the policy gates your risk committee has already defined — it doesn't write them for you. A model that clears every policy check is still subject to the same model risk oversight your SR 11-7 framework already requires; the SDK makes that oversight faster and better-evidenced, not optional.
It also doesn't replace integration testing or domain-specific validation. Policy compliance and functional correctness are different questions answered by different checks. The SDK runs alongside your existing test suite — it doesn't try to be it.
Getting started
SDK access is available on Professional and Enterprise tiers. Pre-built policy templates cover SR 11-7, EU AI Act high-risk requirements, RBI's AI governance expectations, and NIST AI RMF. Custom policies are written in YAML and version-controlled alongside the model code they govern, the same way any other engineering artifact would be.
Where to start if you're evaluating this
- Pick one Tier 1 model already in production and run it through an existing policy template before writing any custom policy — this tells you how much of your current validation work the template already covers.
- Check whether your current evidence trail for that model could be reconstructed in under an hour; if not, that's the gap the SDK is built to close.
- Write your highest-risk policy (your SR 11-7 or RBI-equivalent high-risk gate) as code first, not your easiest one — the hard policy is where the time savings actually show up.
- Wire the SDK check into the same CI/CD stage that already blocks a bad deploy, so governance failure and build failure are the same failure, not two separate alerts nobody reconciles.
- Export one evidence record in OSCAL format and hand it to whoever owns your next regulatory submission, to confirm the format actually fits what they need before you scale it across your model inventory.