Data Suitability Recipe Examples
Real scenarios showing a model's inputs turned into a certified evidence record. Pick a tab to see how the risk tier, the bound scope, and the certification hand-off differ with the situation.
Certifying the inputs of a high-risk model
Context. A bank's model risk team must show that the tables feeding its retail credit scoring model met the documented data standard before the model's annual validation. The tables live in two datastores, both profiled and scanned regularly. A data steward with the Author team permission on both datastores opens Recipes, chooses Data Suitability, and clicks Start a new record.
What happens. On Model, they name the record "Retail Credit Scoring v4" and pick High Risk, since EU AI Act Article 10 and SR 11-7 obligations apply. On Inputs they bind the two datastores and the seven tables the training pipeline reads. On Standard they bind the completeness, uniqueness, and freshness checks the team agreed on, and enable the daily expiry check. On Baseline they capture today's scores and row counts. On Evidence they click Submit for Review and send the page to the head of data, a Manager with Editor on both datastores, who reviews the bindings, sets the certification to expire in twelve months, and clicks Certify. The steward then clicks Generate Attestation and downloads the JSON and the HTML report for the validation file.
Why it works. The record captures intent, scope, and standing in one object, and the attestation freezes them at the moment of approval. The two-person hand-off means the author never certifies their own work, and the expiry date plus the scheduled check make the certification lapse on its own instead of quietly staying green.
Evidence for an agent that reads governed tables
Context. A support team runs an agent that answers questions by retrieving from three product and policy tables. No model is trained, but auditors still ask which data the agent reads and whether it meets the standard. The team lead owns the record and holds Author on the single datastore involved.
What happens. They name the record after the agent and choose Limited Risk, since transparency obligations apply. They bind the datastore and the three tables and leave the check set empty, so the attestation reports every active check on those tables at generation time. They skip the expiry schedule, because the approval has no fixed validity. After the baseline, a Manager certifies the record without an expiry date, and the lead generates the attestation. The HTML report goes into the agent's launch review.
Why it works. Nothing in the record assumes a trained model. An agent that retrieves from governed tables at run time raises the same governance question, and the recipe answers it the same way. Leaving the check set empty is a valid choice: the standard becomes "whatever is active on these inputs", recorded explicitly in the attestation.
Refreshing evidence without rebuilding the record
Context. Three months after certification, the credit scoring model's inputs have been reloaded several times and two tables were re-profiled. The validation team wants fresh evidence of drift against the approved baseline, without redefining anything.
What happens. The steward opens the record from the Data Suitability record list and, on the AI Use Case page, opens Attestations to see the live comparison of the current attestation with today's data health: two containers changed, none added or removed, check set unchanged. To record it, they click Review Recipe on the Latest Recipe Run card, which reopens the recipe at Complete, step back to Evidence, and click Generate a New Attestation. The new record supersedes the old one, which stays in the history, and both export cleanly.
Why it works. The baseline and the certification are still valid, so no re-approval is needed. Regenerating never overwrites: the earlier attestation remains the answer to "what was in force in January", and the new one becomes the answer for today.
Adding a table after certification
Context. The credit scoring pipeline starts reading a new bureau table. The steward binds it to the certified record from Edit in Recipe.
What happens. The definition change means the run's current attestation no longer matches the record, and the Evidence step asks for a new one. Generating it fails, because the bound containers changed after the baseline was captured. The steward goes back to Baseline and clicks Start New Baseline, which snapshots all eight tables and returns the record to Draft. They submit for review again, the Manager certifies the new cycle, and a new attestation is generated. The earlier attestations are untouched.
Why it works. A baseline belongs to one certification cycle and one scope. Letting a new table ride on an old baseline would make "drift" meaningless for it, so the recipe forces a new referent and a new approval. The cost is one extra review, and the benefit is that every attestation can be trusted to describe the scope it names.
See Also
-
Best Practices
Guidelines for naming, binding scope, baselines, certification, and keeping evidence trustworthy.
-
Permissions
The roles, team permissions, and ownership rule behind each step of the recipe.
-
How It Works
The two phases, the Use Case picker, how progress is saved on the AI Use Case, and what the recipe writes.
-
Define the Use Case
Model, Inputs, and Standard: naming the model, binding its assets, and pinning the check set and expiry schedule.
-
Capture the Evidence
Baseline, Evidence, and Complete: fixing the drift referent, certifying, generating the attestation, and exporting it.
-
AI Use Cases
The governance record the recipe writes: certification lifecycle, who can do what, attestations, and audit obligations.
-
Entry Points and Resuming
Get Started, Open in Recipe, Continue Recipe, Edit in Recipe, and how a run resumes from the AI Use Case.