Assurance case model
Understand the case, element, evidence, access and publication records stored by the platform.
Edit on GitHubAn assurance case is a structured argument. AssuranceCase stores its identity and settings; AssuranceElement stores the claims, strategies, evidence and references that make up the argument. The schema is in prisma/schema.prisma, with application rules in lib/services/.
Core records
| Model | What it holds |
|---|---|
AssuranceCase | Name, description, mode, creator, layout, publish status, deletion state and relations to elements and access grants |
AssuranceElement | Type, optional name, description, parent and case references, type-specific fields, assertion status and deletion state |
CaseInformation | Case metadata held separately from the element tree |
EvidenceLink | A many-to-many link from evidence to the claims it supports |
Comment | Internal discussion on case elements |
A case has STANDARD or ADVANCED mode. Its current publishing states are DRAFT and PUBLISHED. deletedAt marks a case moved to trash. The creator is recorded for attribution and receives access through the permission rules; other users can gain access directly or through a team.
Elements use parentId to form the argument hierarchy. A root goal has no parent and can have the TOP_LEVEL role. Other elements can have the SUPPORTING role. name is nullable, so consumers must not assume it is present. description is the main text. context is an array on an element, and assumption and justification are optional fields. Evidence has a urls array; the single url field remains for compatibility and tracks its first URL. Both cases and elements can be soft deleted.
Element types and relationships
The ElementType enum contains GOAL, STRATEGY, PROPERTY_CLAIM, EVIDENCE, CONTEXT, ASSUMPTION, JUSTIFICATION, MODULE, AWAY_GOAL and CONTRACT. This is a database vocabulary, not a promise that every type has a separate editor card. The editor currently registers six node renderers. Context is generally stored in the context field rather than added as a context node. See the case editor for the rendered types.
EvidenceLink lets one evidence element support several claims. A defeater uses isDefeater and defeatsElementId to challenge another element. A module can reference another case with moduleReferenceId; an away goal can also name a particular cited element through citedElementId. If an imported or deleted target cannot be resolved, dangling flags preserve that fact rather than pretending the citation is valid.
assertionStatus records the status of a claim or strategy. The enum includes ASSERTED, NEEDS_SUPPORT, ASSUMED, AXIOMATIC, DEFEATED and AS_CITED. The first five can be selected by an author in the edit dialog; AS_CITED is reserved and is not computed automatically in this build. A null value is treated as the default ASSERTED during interpretation or export. See the quick reference for the author-facing meanings.
Access
CasePermission grants an individual VIEW, COMMENT, EDIT or ADMIN access. CaseTeamPermission grants one of those levels to a team, and members inherit it. TeamMember separately records the member's OWNER, ADMIN or MEMBER team role. A team role and a case permission answer different questions: who manages the team, and what that team may do with this case. lib/permissions.ts combines applicable case grants with the creator's access.
Published records
Publishing creates a PublishedAssuranceCase JSON snapshot with a public slug. Republishing retires the current row and creates a new current row with the same slug. The snapshot is separate from the editable source case. It excludes internal collaboration comments. The schema also contains older Release and ReleaseSnapshot models; they are not the record that the current publishing service creates for Discover.
Working with the schema
The Prisma client is created in lib/prisma.ts and generated under src/generated/prisma. Prefer the service layer for application operations, since a direct database write can skip case permissions, type-specific validation, publication rules and event handling. Database changes use hand-written SQL migrations followed by prisma migrate deploy in the repository's deployment process.