Define the Use Case

Define the Use Case is the first phase of the Data Suitability recipe: "What the model is, what it reads, and the standard its inputs are held to." Its three steps create the AI Use Case and fill in its definition. Each Next saves the step to the record before moving on, so nothing here is lost if you leave. For the mechanics shared by the whole recipe, see How It Works.

Model

Name the model this evidence covers and set its governance risk tier.

Model Name is the name the governance record is filed under. The step advises using the name your model risk team already knows the model by, including its version, such as "Retail Credit Scoring v4". Names are limited to 255 characters and must be unique across AI Use Cases.

Risk Tier offers three cards. They follow the vocabulary of the EU AI Act, and the tier is recorded on the use case and in every attestation.

Description (optional) records what the model decides and who relies on it.

Next requires a name and a tier. On a new record, Next creates the AI Use Case; from then on the side panel footer reads Writing to AI Use Case #N.

Inputs

Bind the datastores and containers the model trains or scores on.

Input Datastores is a multi-select of the datastores you can access. The step notes that only users who can access every bound datastore will see this use case, which is how the record's permissions work. See Permissions.

Input Tables & Files appears once a datastore is selected and lists that datastore's containers, grouped by datastore, with Select all and Clear. A datastore whose containers have not been discovered yet shows "No containers found. The selected datastores have no containers yet. Run a profile operation first." Removing a datastore also removes its containers from the binding.

The footer counts the selection and explains its role: these are the assets the evidence reports quality, drift, and lineage for, and later comparisons surface inputs that were added to or removed from this governed scope.

Next requires at least one datastore and at least one container.

Standard

Confirm the check set that defines "suitable", and how often certification is re-evaluated.

Governed Check Set lists the quality checks on the bound containers, each with its rule type, identifier, description, and status, with Select all and Clear. Binding a subset pins the evidence standard to those checks. Leaving it empty includes every active check on the governed inputs at generation time. When the containers have no checks yet, an info message says so and points out that the attestation will report every check that exists on them when it is generated, and that you can bind a specific set later.

Certification Expiry Check is a toggle, Check certification expiry on a schedule, that reveals a schedule editor. The default schedule is daily at 06:00, so an expiry is visible the morning it happens. The step is explicit about what this schedule does and does not do: it does not scan data, re-profile inputs, recapture a baseline, or generate another attestation. It only updates a Certified record to Expired after its certification validity date passes. Source-data operations are configured separately.

Both the check set and the schedule are optional, so Next is always available here. It saves the step and moves to the second phase, Capture the Evidence.

See Also