Compliance

The Compliance step checks the project's requirements against the regulatory frameworks Alara Code ships with, and writes the result up as a Compliance Assessment: which controls the requirements trigger, how severe each one is, what evidence each needs, and the overall risk. It is a report, not a review gate — it runs once the test plan exists and is complete as soon as it is written.

What you get

A Markdown document titled Compliance Assessment. The bridge writes all of it from the agent's structured reply — the agent returns data, not prose — so its layout is fixed:

The frameworks

Every run checks against all eight framework definitions, each a list of controls with keywords, required evidence and a severity:

All eight are sent on every call rather than guessed from the project, because missing a critical control is a worse failure than scanning a few extra.

Before you run it

• The STS must exist. It does not need to be approved. Until it exists, /compliance is locked with "Run /sts first". The assessment itself reads only the requirements; waiting for the STS keeps it in pipeline order, after the core documents.
• The project state must hold a non-empty requirement list.

How it works

Compliance makes one skill call, sdlc-compliance-checker, with up to three attempts — the same skill the SRS step uses for its inline flags.

Drawing diagram…

The skill works mechanically, so the result is repeatable:

1. For each requirement, it joins the title, description and acceptance criteria into one text.
2. For each control in each framework, it checks whether any of the control's keywords appears in that text, ignoring case.
3. Each match is a finding, recorded with the framework code, control id and title, the triggering requirement, the matched keyword, the control's severity and required evidence exactly as the framework states them, and status "pending-review".
4. It reports each framework, control and requirement combination once.
5. It never adds keywords, frameworks or controls that are not in the definitions. Zero findings is a valid result for a project with no regulated scope.

It also returns which frameworks now apply to each flagged requirement, the gap counts, and a summary with the overall risk level: critical if any finding is critical, otherwise high if any is high, otherwise medium if there are any findings, otherwise low.

The reply is validated against the compliance schema, which rejects unknown keys and checks every required field. When it passes, the bridge merges the findings into the project's compliance flags — updating a flag that already exists for the same framework and control, adding new ones — and adds the frameworks to each flagged requirement.

The run panel shows: Checking project state, Assessing frameworks, Persisting to project state, Writing the Markdown document. The completion message gives the mode, the number of flags and how many are critical.

Ids this step owns

None. Findings are identified by the framework's own codes — a framework code such as SBP-2024 and a control id from that framework's definition — and point at the requirement ids (REQ-…) that triggered them.

Reviewing it

There is no approval step, but the report is meant to be read:

• Start with the critical and high findings, and check the SDS addresses each control's required evidence.
• A finding triggered by a keyword that is clearly incidental is worth noting, but the fix is in the requirement wording, not the report.
• Frameworks the project is not subject to will still produce findings if their keywords match. Ignore those, or reword the requirement.

The Proposal names the frameworks found in the project's compliance flags, so running Compliance before the Proposal gives the proposal writer the fuller list.

When it fails

Under the hood

• The driver is bridge/src/services/compliancePipeline.service.ts; the message is built by bridge/src/lib/complianceMessage.ts from the files in bridge/sdlc-engine/frameworks/.
• Written to the project state: complianceFlags (merged by framework and control), each requirement's complianceFrameworks, and artifacts.compliance. The phase moves to compliance unless the project is already further along.
• The document is .sdlc/artifacts/compliance-vN.md. Because Compliance is never approved, every run takes the next version number.
• The project's flags are also available from GET /api/projects/:id/compliance-flags.