Data Suitability Recipe Permissions

An AI Use Case has no teams of its own. Every permission derives 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. On top of that, the platform role and, for Members, ownership of the record decide who can change it and who can sign it off. For the canonical matrices, see User Roles and Team Permissions.

Two Permission Systems

User Roles (Member, Manager, Admin) control what a user can do across the platform. Team Permissions (Reporter, Viewer, Drafter, Author, Editor) control what a user can do on the specific datastores they reach through team membership. They are independent systems with different scopes. For AI Use Cases, the team permission is checked on every bound datastore at once.

User Roles (Platform-Level)

Action	Member	Manager	Admin
Open the recipe and view the records you can access
Create a use case
Edit, delete, baseline, generate evidence, submit for review, or save recipe progress on a use case you created
Do the same on a use case someone else created
Certify or revoke a use case

Each row still requires the matching team permission on every bound datastore, listed below. Ownership is set when the record is created and never changes.

Team Permissions (Datastore-Level)

The team permission must hold on every datastore the use case binds. Creating a record that binds no datastore yet, the usual shape of a fresh draft, still needs the Author team permission on at least one datastore somewhere.

Action	Reporter	Viewer	Drafter	Author	Editor
View a use case, its baseline, its recipe run, and its attestations
Compare and export attestations
Create a use case and bind assets (Model, Inputs, Standard)
Edit or delete a use case; save recipe progress
Capture a baseline (Baseline)
Submit for review, or send back to Draft (Evidence)
Generate an attestation (Evidence)
Certify or revoke (Evidence), with the Manager role

Two people, by design

Preparing evidence and signing it off are different jobs. An Author on every bound datastore builds the record and submits it for review. Certifying it takes the Manager role together with Editor on every bound datastore, or the Admin role. Being the author of a record never grants the ability to certify it, and the Manager role alone does not bypass the team permission.

How Both Layers Work Together

To build a use case and generate its evidence, a user must satisfy all of these:

User Role: at least Member, and for a Member, ownership of the record
Team Permission: Author on every bound datastore

To certify or revoke, a user needs the Manager role plus Editor on every bound datastore, or the Admin role. Ownership plays no part in certification, so an author cannot approve their own record.

Admin Bypass

Users with the Admin role bypass team permission checks and can reach, edit, and certify every AI Use Case.

UI Behavior Without Permission

Scenario	What the User Sees
User lacks Viewer on one of the bound datastores	The record does not appear in the record list and its page is not found. A partial view of a model's governed inputs is never shown.
User can view but not edit the record	Edit in Recipe, Continue Recipe, and Adjust Model or Inputs are not shown. On the Evidence step, no transition buttons appear and the step explains that authoring needs Author on every bound datastore and certifying needs a Manager with Editor, or an Admin.
User can edit but not certify	Submit for Review and Send back to Draft are offered; Certify and Revoke are not. On a record In Review, the step asks you to share the page with an approver.
Member working on someone else's record	The record is visible but treated as read-only, as above, even with Author on every bound datastore.
Creating a record without Author on any datastore	Creation is refused with a permission error, even when no datastore is bound yet.

Important Notes

Losing access to a bound datastore hides the record. Losing Viewer on any one bound datastore hides the whole use case until access is restored.
Attestations follow the record. Reading, comparing, and exporting them needs the same Viewer access as the record; there is no separate permission for evidence.
The recipe's autosave needs edit rights. A user who can view but not edit a record can browse it in the recipe, but progress is not saved and the side panel footer reports the failed save.