Data Suitability Recipe Best Practices

Name the model the way your risk team does

The record is filed under the model name, including its version. Reuse the identifier your model inventory already carries, so the attestation can be matched to the model without a lookup.

Pick the risk tier deliberately

The tier is recorded on the use case and in every attestation, and it frames which obligations the evidence supports. Choose it with your governance team rather than defaulting to the lowest one.

Bind exactly what the model reads

Bind the datastores and the containers the pipeline actually consumes, no more. Extra tables widen the permission requirement (every viewer needs access to all of them) and dilute the evidence. Later comparisons flag containers added to or removed from the scope, so keep it honest from the start.

Profile and scan before you bind

The attestation reports quality scores, profiles, row counts, and check outcomes. Make sure the bound containers have been profiled and scanned recently, or the evidence will describe stale or missing metadata.

Decide whether to pin the check set

Binding specific checks pins the standard to them and lets later comparisons flag checks that were added, archived, removed, or changed outcome. Leaving the set empty records every active check at generation time. Pick one approach and state it in the description.

Turn on the expiry check when certifications have a validity date

The schedule only flips a Certified record to Expired after its validity date. Without it, an expired certification still reads as Expired everywhere, but the stored state catches up only when someone looks. Enable the schedule when auditors rely on the stored state.

Configure data operations separately

The expiry schedule never scans, profiles, or re-baselines. Keep your Profile and Scan schedules on the datastores themselves, and generate new evidence after the next governance review.

Capture the baseline right before review

The baseline is the referent every attestation in the cycle measures drift against. Capture it once the inputs are stable and the checks have run, immediately before submitting for review, so the approved referent describes the data the approver looked at.

Keep authoring and certifying separate

An author submits; a Manager with Editor on every bound datastore, or an Admin, certifies. Do not work around this by giving authors the Manager role. The separation is what makes the certification an approval rather than a self-declaration.

Set a validity date on the certification

A certification with no expiry never lapses. Unless the approval is genuinely open-ended, set Certification valid through when certifying, so the record expires and a fresh review is forced.

Tell the approver

Qualytics does not send an approval notification. Share the AI Use Case page with the approver when you submit for review, and agree on where the approval request lands.

Generate the attestation immediately after certification

The attestation freezes the certified state. Generating it right after Certify keeps the evidence and the approval aligned, before inputs drift.

Regenerate rather than edit

Attestations are immutable. When you need fresh evidence, generate a new attestation; it supersedes the old one, which stays retrievable for questions about past dates. Never try to reproduce an old record by hand.

Export both formats to the audit file

Download the JSON as the authoritative record and the HTML report as the readable copy. Both carry the same evidence and provenance, so a reviewer without platform access can still read the record.

Re-baseline when the scope changes

Adding or removing a bound container after the baseline blocks new attestations until you capture a new baseline, which returns the record to Draft. Treat that as a new certification cycle and plan the re-approval.