AI Use Cases

An AI Use Case is the governance record for the data feeding an AI agent or model. It is what the Data Suitability recipe creates and writes to. It binds together, in one governed object:

the source datastores and containers the initiative consumes,
the quality checks that define the initiative's data standard,
an evaluation schedule that keeps the certification honest, and
a certification state that other systems, and other people, can rely on.

Why this matters

AI initiatives consume data through pipelines, agents, and training jobs that rarely leave a governance trail. When someone asks "which tables feed this model, and did they meet our standard?", the answer is usually assembled by hand.

An AI Use Case makes that answer a first-class object. It records intent (what the model or agent is, its governance risk tier, and who owns the record), scope (which assets feed it), and standing (whether those assets are certified against the initiative's check set right now).

Nothing in the record assumes a trained model. An agent that retrieves from governed tables at run time raises the same governance question, and carries the same AI Use Case.

Certification lifecycle

Every AI Use Case carries a certification state:

State	Meaning
Draft	Being assembled; not yet submitted for review.
In Review	Submitted by its author; awaiting a certification decision.
Certified	Meets the initiative's data standard, until the expiry date.
Expired	The certification lapsed; consumers must treat the use case as uncertified.
Revoked	A Manager withdrew the certification.

Two rules keep the state trustworthy:

Transitions are enforced. A use case moves from Draft to In Review to Certified, and a record in review can be sent back to Draft. A certification can be revoked. Getting certified again always means passing review: an expired record returns to In Review, a revoked one to Draft. Only these transitions are allowed, and Expired can never be set directly: it is derived.
Expiry is automatic. A certification can carry an optional expiry date, set when it is certified. Once that date passes, the use case reads as Expired everywhere, even before the scheduled evaluation runs. The optional evaluation schedule on the use case re-checks expiry so the stored state catches up on its own; a certification with no expiry date never lapses.

Who can do what

An AI Use Case has no teams of its own. It derives every permission from the datastores it binds, and the requirement must hold on all of them. A use case is only as accessible as its weakest binding, because a partial view of a model's governed inputs is worse than no view at all.

To do this	You need
View a use case, its baseline, and its attestations	Viewer on every bound datastore
Create, edit, or delete a use case; bind assets; capture a baseline; generate an attestation; submit for review or reopen a draft	Author on every bound datastore
Mark a use case Certified, or Revoke a certification	The Manager user role plus Editor on every bound datastore, or the Admin role

Two consequences worth stating plainly:

Preparing evidence and signing it off are different jobs. An Author assembles the use case and submits it for review; a Manager of the underlying data decides whether it is certified. Being the author of a record never grants the ability to certify it.
The Manager role is not a shortcut past the data's own permissions. A Manager who holds only Viewer on a bound datastore cannot certify that use case, and one who holds only Author cannot either. "Manager of the datastore" means the Manager role together with Editor on it.

Members can additionally only edit, delete, baseline, generate evidence, submit for review, reopen, or save recipe progress on use cases they created. Ownership is set at creation and never changes. Admins are not subject to team permissions and can reach every use case.

For the canonical matrix of every team-permission-gated action, see Team Permissions.

The Data Suitability recipe writes AI Use Cases

A Recipe is a guided, repeatable process in the platform. The Data Suitability recipe produces an AI Use Case as its durable output. It walks you through naming the model and its risk tier, binding the input assets, pinning the check set and expiry schedule, fixing a baseline, getting the record certified, and generating the attestation. What it saves is the use case, including the recipe's own progress. You can close the browser mid-recipe and resume from where the recipe left off, because each recipe run is persisted on the use case rather than in the browser session. See How It Works.

Certification answers one question with evidence: did this model's inputs meet the documented standard? Regulatory drivers such as SR 11-7 and the EU AI Act's data-governance obligations are the reason that answer needs a durable, accountable record rather than a spreadsheet.

Data Suitability Attestations

Certification says an AI Use Case met your standard. An attestation is the evidence, captured as an immutable, point-in-time record you can hand to an auditor.

Attestations are generated by the Data Suitability recipe, on its Evidence step, and only once the use case is Certified: certification is the governance approval, and the attestation is the immutable evidence of that approved state. The AI Use Case's own Attestations tab is where you read, compare and export them. Each attestation contains:

Section	What it records
Use case	Name, description, risk tier, certification state, and certification dates.
Baseline	When the baseline was captured and how many containers it covered.
Containers	Per container: quality scores across all eight dimensions with the platform's explanation of the score, the profile identifier and row count behind it, and drift against the baseline.
Open anomalies	Counts of unresolved anomalies at the time of generation, in total and per container.
Checks	The check set that defined the standard.
Lineage	The lineage edges into the bound assets, at field and container level.
Access controls	A masking summary for the bound assets: how many fields are masked, which ones, and how often masked values were revealed over the last 90 days.
Record provenance	The generator, generation time, record ID, and any superseded record.
Deployment	The tenant and application version that produced the record.

Two rules make it evidence rather than a report

A baseline is required. "Drift" is only meaningful against a recorded starting point, so the recipe has you capture a baseline on its Baseline step before it will generate an attestation. Attestation is refused without one, and also when the bound containers changed after the baseline was captured, until a new baseline is taken. A baseline belongs to one certification cycle. Starting a new baseline returns the AI Use Case to Draft and clears the prior approval; the new cycle must be certified before another attestation can be generated. Existing attestations remain unchanged.

Attestations are immutable. Regenerating does not overwrite: it creates a new attestation that supersedes the previous one, and the superseded record stays readable forever. That is what lets you answer a question about a past date honestly. Ask for the attestation that was current on a given date and you get exactly the record that was in force then.

Audit trail and exports

The attestation history is managed in the AI Use Case. Each record names the actor who generated it, its generation time, and the record it supersedes. The use case separately records its certification state, certifier, expiry, and lifecycle transitions. Authors prepare evidence and submit it for review; only a Manager of the bound datastores, or an Admin, can certify or revoke it.

Export as JSON (the authoritative evidence record) or as a self-contained HTML page for an audit file. Both include the point-in-time evidence and record provenance, so the record remains understandable outside the application while in-app history remains the source for ongoing governance management.

Review movement in the application

Open an AI Use Case from the Data Suitability recipe's record list (there is no separate AI Use Cases page) and select Attestations. Qualytics automatically compares the newest evidence record with current data health; select Compare on an older record to use that point in time instead. Refresh the comparison whenever you need the latest state.

The tab opens with Attestation as of a date, which is the question an audit usually starts from: pick the date a decision was made and Qualytics retrieves the record that was in force then, ready to compare or export. Below the comparison, History lists every record newest first, marking which one is current and which it supersedes.

The comparison deliberately separates two periods:

Period	Question it answers
Baseline to attestation	What changed between the approved referent and the point-in-time evidence capture?
Attestation to current	What has changed since that evidence was approved and recorded?

For each governed container, the comparison shows quality-score movement, row-count movement, whether a different profile is current, and whether the quality score was recomputed. It also identifies containers added to or removed from the governed scope. This distinction prevents a later baseline from rewriting the meaning of an older attestation: the attestation itself is the fixed checkpoint for the live comparison.

What is recorded, and what is not

Attestations carry scores, counts, ratios, identifiers, timestamps, and customer-authored governance context. The evidence assembly path never reads or includes complete rows from anomaly source records or datastore previews. Administrators should still govern free-form names and descriptions because users control that text.

The evidence stays at container granularity. It records how each governed container scored, which profile and row count produced that score, and how far it has moved since the baseline, never the values inside a column. That boundary is what makes the record safe to hand to a reviewer outside your data perimeter, and it is enforced in the assembly path rather than left to the exporter.

Meeting your obligations

The artifact is built for the questions model risk reviewers actually ask under frameworks such as SR 11-7 and the EU AI Act's data-governance requirements for high-risk systems.

The question	Where the attestation answers it
Which data feeds this model or agent?	Bound datastores and containers, listed per attestation.
What standard was it held to?	The bound check set and the certification state.
Was the standard met on a given date?	The attestation that was current on that date.
How has the data changed since approval?	Drift against the captured baseline.
Who could access it?	The access control summary.
Who generated the evidence and what superseded it?	Record provenance and the attestation history.

One caveat worth stating plainly: this evidence covers structured inputs. It does not assess whether a model's or an agent's output is correct, grounded, or free of hallucination.