The four roles in Assurance-as-Code and the per-operation authorization matrix.
Authorization and roles
Assurance-as-Code enforces authorization on every state-changing operation. The authorization model separates authoring, review, approval, and release across four distinct roles, so that no single person can drive an artefact from draft to released baseline without independent checks.
Every role-sensitive write operation is logged as an immutable audit event, recording the actor, the role they held at the time of action, the operation, and a correlation identifier.
The four roles
| Role | Scope | Description |
|---|
admin | Global | Full configuration access. Creates users, assigns global and project roles, configures repository connectors, and can delete or archive projects |
project_lead | Project | Manages team access. Creates and approves baselines. Approves tailoring decisions |
quality_engineer | Project | Releases artefacts and baselines. Triggers release-gate evaluation. Updates released-artefact revisions |
user | Project | Standard operational access. Creates and edits draft artefacts, runs imports, validation, traceability, and impact analysis |
Roles are not hierarchical. Project Lead and Quality Engineer have distinct, controlled responsibilities. Admin has global privileges and does not require project membership to perform project-scoped operations.
Effective project role is the union of the user’s global role and their explicit membership on that project. Membership on other projects is not carried across.
Return codes
The API uses standard HTTP codes to distinguish authorization from state failures:
| Code | Meaning |
|---|
401 | Not authenticated — no valid token |
403 | Authenticated but role is insufficient for this operation |
409 | Operation preconditions not met (e.g. state transition invalid) |
423 | Project is temporarily locked (baseline creation in progress) |
Artefact operations
| Operation | Required role |
|---|
| Create artefact | User, Project Lead, Quality Engineer, or Admin |
| Update draft/reviewed artefact | User, Project Lead, Quality Engineer, or Admin |
| Update released artefact | Quality Engineer or Admin (triggers impact analysis + suspect propagation) |
| Submit for review | User (own artefact), Quality Engineer, or Admin |
| Mark reviewed | Quality Engineer, Project Lead, or Admin |
| Approve | Project Lead or Admin |
| Release | Quality Engineer or Admin |
| Obsolete (soft delete) | Admin |
Relationship operations
| Operation | Required role |
|---|
| Create relationship | User, Project Lead, Quality Engineer, or Admin |
| Update relationship | User, Project Lead, Quality Engineer, or Admin |
| Delete relationship | Admin |
Baseline and release-gate operations
| Operation | Required role |
|---|
| Request baseline creation | Project Lead or Admin |
| Cancel baseline creation | Project Lead or Admin |
| Trigger release-gate evaluation | Any project role |
| Approve baseline | Project Lead or Admin |
| Release baseline | Quality Engineer or Admin |
| Obsolete baseline | Admin |
| Publish approval to GitHub | Project Lead, Quality Engineer, or Admin |
Validation, tailoring, and configuration
| Operation | Required role |
|---|
| Trigger validation run | Any project role |
| Suppress validation issue | Admin |
| Reopen suppressed issue | Admin |
| Create/update tailoring decision | Project Lead or Admin |
| Revoke tailoring decision | Admin |
| Configure project profile | Admin |
| Tailor ASPICE process scope / capability | Admin (requires rationale + evidence) |
Cross-cutting rules
- Only a Quality Engineer or Admin may create a new revision of a released artefact. Doing so automatically triggers impact analysis and suspect propagation.
- Baseline creation acquires a project-scoped update lock. While held, artefact and relationship writes for the project return
423 Locked. Reads and queries continue to work.
- Import processing preserves the initiating actor. Automatic import mode does not bypass released-artefact authorization — an import that would revise a released artefact still requires the initiating actor to hold the correct role.
- Job read access is restricted. An individual job may only be read or cancelled by its original requester or an Admin. Project members can see project-level job summaries with sensitive detail redacted.