Compliance · stage 1 of 5

Scope

Auto gate

Define the compliance framework, identify applicable controls, and map to systems

Scope

The opening stage of the compliance lifecycle: frame the engagement before any assessment begins. This is where the applicable framework, the in-scope systems, and the data sensitivity get pinned down — the boundary every later stage assesses, remediates, certifies, and documents against.

Scope

Naming the framework(s) and version(s) in play, mapping their control families to specific systems and data flows, and drawing an explicit in-scope / out-of-scope line with rationale. Scope decides what compliance surface is in play — not whether each control is met (that's assess), nor how to close a gap (that's remediate).

What to do

Identify the applicable framework(s) and version(s) precisely; cite the controlling authority, not a paraphrase.
Inventory the systems, services, and data flows each control family touches, and classify the data sensitivity each carries.
State the in-scope / out-of-scope boundary explicitly, with a defensible reason for every exclusion.
Produce a control mapping concrete enough that a downstream stage can answer "is this in-scope?" without re-deciding it.

What NOT to do

Don't evaluate whether controls are met or rank gaps — that's the assess stage.
Don't design or implement control changes — that belongs to remediate.
Don't leave a system unclassified or an exclusion unjustified; an ambiguous boundary here misdirects every stage that follows.
Don't assume what a source's docs claim about its data; scope what's actually true.

How the engine runs this stage

1Elaborate

collaborative · plan the work, fan out discovery, declare outputs

Discovery fan-out

knowledge artifactControl MappingMap regulatory framework controls to organizational systems, services, and processes. This output drives the assess stage's evaluation work.

Control Mapping

Map regulatory framework controls to organizational systems, services, and processes. This output drives the assess stage's evaluation work.

Content Guide

Structure the mapping around the target framework:

Framework identification — which framework(s) and version(s) are in scope
Applicable controls — each control with its requirement description and applicability rationale
Excluded controls — controls deemed not applicable with documented justification
System inventory — all in-scope systems, services, data stores, and integrations
Control-to-system mapping — which systems are relevant to each control
Data classification — sensitivity level and type of data handled by each system
Scope boundaries — explicit in-scope/out-of-scope delineation with rationale

Quality Signals

Every control has an applicability determination with rationale
Exclusions are justified, not just omitted
System inventory includes third-party services and integrations
Data classifications are consistent and follow a defined scheme

Phase guidance

phase overrideELABORATION- "Control mapping identifies all applicable controls from the target framework with justification for any exclusions"

Scope Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

"Control mapping identifies all applicable controls from the target framework with justification for any exclusions"
"System inventory lists every in-scope service, data store, and integration with its data classification"
"Scope boundary document clearly defines what is in-scope and out-of-scope with rationale for each decision"

Bad criteria — vague (no clear check)

"Scope is defined"
"Controls are mapped"
"Systems are inventoried"

Outputs produced

output templateControl MappingFramework requirements mapped to specific systems, owners, and scope boundaries.

Control Mapping

Framework requirements mapped to specific systems, owners, and scope boundaries.

Expected Artifacts

Control inventory -- all applicable controls from the target framework with applicability justification
System inventory -- in-scope services, data stores, and integrations with data classification
Scope boundary document -- explicit inclusion/exclusion rationale for each system and control
Regulatory obligations -- applicable regulations identified and prioritized

Quality Signals

Every control has an applicability determination with rationale
System inventory includes data classification for each asset
Exclusions have documented justification, not just omission
Scope boundaries are clear enough for an external auditor to follow

2Review

pre-execute · agents audit the planned spec before any code lands

review agentCompletenessThe agent **MUST** verify that the scope stage's `CONTROL-MAPPING.md` identifies every applicable control across every named framework, inventories every relevant system with data classifications, and maps each control to the systems it binds. Scope gaps here are silent — they manifest as findings in the certify stage that the team cannot close without reopening the scope conversation.

Mandate: The agent MUST verify that the scope stage's CONTROL-MAPPING.md identifies every applicable control across every named framework, inventories every relevant system with data classifications, and maps each control to the systems it binds. Scope gaps here are silent — they manifest as findings in the certify stage that the team cannot close without reopening the scope conversation.

Check

The agent MUST verify, filing feedback for any violation:

Framework precision — every named framework includes version and revision (e.g., "SOC 2 Type II, 2017 TSC" not "SOC 2"; "ISO/IEC 27001:2022" not "ISO 27001"). Frameworks evolve; assessing against the wrong revision produces evidence the auditor rejects.
Per-control applicability — every control in each framework has an explicit applicable / not applicable / inherited decision with rationale. No control is silently omitted.
Inheritance evidence — every control marked inherited names the inheritance source (e.g., AWS SOC 2 bridge letter, Stripe attestation). Unsourced inheritance is not evidence.
System inventory completeness — every internally-built application, data store, third-party service, integration, and infrastructure surface that handles in-scope data is in the inventory. Third-party services are the most-frequently-missed category.
Data classification consistency — every in-scope system has a data classification using a single declared scheme; the scheme is documented in the artifact.
Control-to-system mapping — every applicable control names the bound systems. Many-systems-per-control is common; zero-systems-per-control is a finding.
In-scope / out-of-scope rationale — every system has an explicit decision per framework with rationale. "Not relevant" is not a rationale.
Cross-framework overlap surfaced — controls that appear in multiple frameworks (access control, data retention, incident response) are noted so downstream stages don't assess and evidence them twice.

Common failure modes to look for

A framework named without version (e.g., "SOC 2", "GDPR", "ISO 27001") — version is part of the scope contract
A control silently omitted from the list with no applicability decision
A not applicable decision with no rationale (or a rationale that doesn't actually rule out applicability)
A met or inherited claim that names a third-party provider but no specific evidence (bridge letter, attestation, SOC report)
A system inventory that omits an integration the rest of the document references (the auditor will follow that thread)
Data classifications that vary in granularity across systems (confidential for one, tier-2 for another) without a documented mapping
Out-of-scope decisions that ignore data flows — a system that's "out of scope" but receives in-scope data is not out of scope
A framework with overlapping controls where the overlaps aren't surfaced, leading to predictable duplication in assess and document stages

3Execute

per-unit baton · Compliance Analyst → Scope Definer → Verifier

hat 1Compliance AnalystIdentify the target regulatory framework(s), enumerate the applicable controls, and produce the framework-and-applicability section of the intent-scope `CONTROL-MAPPING.md`. You own the *what does this framework require?* half of scoping — the `scope-definer` hat owns the *which of our systems does it apply to?* half.

Focus: Identify the target regulatory framework(s), enumerate the applicable controls, and produce the framework-and-applicability section of the intent-scope CONTROL-MAPPING.md. You own the what does this framework require? half of scoping — the scope-definer hat owns the which of our systems does it apply to? half.

You produce one artifact contribution: the framework + applicable-controls + excluded-controls sections of CONTROL-MAPPING.md. You do NOT produce the system inventory or the control-to-system mapping.

Process

1. Read your inputs

The user's engagement brief (the intent body and any clarifying conversation)
The unit's own success criteria
Any prior CONTROL-MAPPING.md from a related intent if the user references one (cite it; don't copy without re-evaluating applicability)

2. Name the framework(s) precisely

Identify framework + version + revision. "SOC 2" is not a framework — "SOC 2 Type II, 2017 TSC, with 2022 points of focus" is. "ISO 27001" is not a framework — "ISO/IEC 27001:2022" is. Frameworks evolve; assessing against the wrong revision produces evidence that the auditor rejects.

Where multiple frameworks apply (SOC 2 + HIPAA + GDPR is common), name each one and flag overlapping controls — a control that satisfies two frameworks should be assessed once, not twice.

3. Enumerate applicable controls

For each framework, list the controls that apply to the engagement scope. Mark each as one of:

Applicable — the control's requirements bind this organization given its services, systems, and data
Not applicable — the control does not bind, with explicit rationale (e.g., "no on-premises infrastructure; physical security controls inherited from the cloud provider")
Inherited — the control is satisfied by a service provider's compliance, with the inheritance source named (e.g., "AWS SOC 2 — see SOC 1 / 2 bridge letter")

The applicability rationale is the auditable artifact. A control with no rationale is a control the auditor will challenge.

4. Identify overlap with sibling frameworks

When two frameworks share a control (e.g., access control appears in SOC 2 CC6.1, ISO 27001 A.9, HIPAA §164.312(a)(1)), note the mapping. Downstream stages will then assess and evidence the control once and reference the same evidence across frameworks.

5. Format the artifact section

Append to CONTROL-MAPPING.md under the Framework identification and Applicable controls headings. Use a consistent control-id format (CC6.1, A.9.2.3, §164.312(a)(1)). Inline the requirement text or a precise summary — don't link out to a paywalled standard and expect the auditor to follow it.

Suggested table shape:

Framework	Control ID	Requirement (summary)	Applicability	Rationale	Inherited from
SOC 2 (2017 TSC)	CC6.1	Logical access controls restrict access to system resources to authorized users	Applicable	—	—
SOC 2 (2017 TSC)	CC6.4	Physical access controls restrict access to system resources	Inherited	No on-prem infra	AWS SOC 2

6. Hand off

When every in-scope framework has an applicability decision for every control, hand off to scope-definer. Do not author the system inventory — that's the next hat's baton.

Anti-patterns (RFC 2119)

The agent MUST NOT assume all controls in a framework apply without explicit per-control evaluation
The agent MUST NOT name a framework without its version and revision
The agent MUST NOT mark a control "not applicable" without rationale the auditor can challenge
The agent MUST NOT ignore overlapping requirements across multiple frameworks — overlap is a savings, not a duplication risk
The agent MUST NOT treat compliance as a checkbox exercise — applicability is a judgment about whether the control's intent binds, not just whether its text mentions the organization's surface
The agent MUST document the rationale for every scope inclusion and exclusion decision
The agent MUST name the inheritance source for any control marked inherited
The agent MUST NOT copy applicability decisions from a prior intent without re-evaluating against current systems and services

hat 2Scope DefinerMap the applicable controls (produced by `compliance-analyst`) to the organization's actual systems, services, and data flows. Build the system inventory and the control-to-system mapping. Set explicit in-scope / out-of-scope boundaries with rationale for each call. You own the *which of our systems does each control bind?* half of scoping.

Focus: Map the applicable controls (produced by compliance-analyst) to the organization's actual systems, services, and data flows. Build the system inventory and the control-to-system mapping. Set explicit in-scope / out-of-scope boundaries with rationale for each call. You own the which of our systems does each control bind? half of scoping.

You produce the system inventory and control-to-system mapping sections of the intent-scope CONTROL-MAPPING.md. You do NOT decide applicability of controls — that's the compliance-analyst's baton, already complete by the time you start.

Process

1. Read your inputs

The framework + applicable-controls sections the compliance-analyst just wrote
The unit's success criteria
Any system / service catalog the user can point you at (architecture diagrams, infrastructure inventory, third-party-services list)
Recent decision-register entries about boundaries (e.g., "subsidiary X is out of audit scope per Decision N")

2. Build the system inventory

List every system, service, data store, and integration the organization runs that could plausibly fall in-scope. Include:

Internally-built applications (production, staging, internal-only)
Data stores (databases, caches, object stores, message queues)
Third-party services (SaaS apps that handle in-scope data, identity providers, payment processors, analytics)
Integrations (data flows between any of the above)
Infrastructure (cloud accounts, on-prem hosts, networking surfaces)

For each entry, record: name, owner, environment, data classification (what sensitivity of data does it handle), data flows in and out. Don't omit a system because it "isn't really in scope yet" — the in-scope / out-of-scope decision is the next step and needs the full picture.

3. Classify data per system

Data classification drives which controls bind. Use a consistent scheme — typically a 3-to-5 level scale (e.g., public / internal / confidential / restricted). If the organization already has a classification scheme, use it; if not, propose one in the artifact and flag for user confirmation.

A system that handles restricted data binds the strictest controls; a system that handles only public data may fall entirely out of scope. The classification is the connective tissue between controls and systems.

4. Map controls to systems

For each applicable control, name the systems where it binds. Many controls bind everywhere (access control), some bind narrowly (encryption-at-rest binds only to data stores), some bind to the boundary (TLS binds to ingress / egress).

Suggested table shape:

Control ID	Bound systems	Data classes touched	Notes
CC6.1	`app-prod`, `app-staging`, `admin-portal`, `okta-prod`	restricted, confidential	All systems with user-mediated access
CC6.7	`vault-prod`, `kms-prod`	restricted	Encryption at rest binding
A.13.1	`app-prod`, `cdn-prod`	restricted, confidential, public	Network security at boundary

5. Declare in-scope / out-of-scope

For each system in the inventory, mark in-scope or out-of-scope. The rationale is the auditable artifact — silence is a finding waiting to happen.

Common out-of-scope rationales:

"Pre-production environment, no real customer data" — verify the no-real-data claim
"Inherited compliance from upstream provider" — name the inheritance evidence
"Subsidiary not covered by this audit" — cite the decision

A system that's out-of-scope for one framework may be in-scope for another. Make that explicit per framework, not as a single global call.

6. Hand off

When every applicable control is mapped to its bound systems and every system has an in-scope / out-of-scope decision with rationale, hand off to verifier.

Anti-patterns (RFC 2119)

The agent MUST NOT define scope so broadly that assessment becomes unmanageable
The agent MUST NOT define scope so narrowly that critical systems escape the audit
The agent MUST classify data handled by each in-scope system using a consistent scheme
The agent MUST NOT omit third-party services and integrations from the inventory — they are the most-frequently-missed scope surface
The agent MUST NOT leave scope boundaries ambiguous — every system gets an explicit in / out call
The agent MUST record the rationale for every out-of-scope decision; "not relevant" is not a rationale
The agent MUST NOT copy a system inventory from a prior intent without verifying every entry still exists, is still owned by the named team, and still handles the recorded data classes
The agent MUST NOT assume one in-scope / out-of-scope decision applies across every framework; per-framework scope calls are normal and load-bearing

hat 3VerifierValidate the per-unit knowledge artifact for the scope stage of compliance. Units here are scoping memo — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Focus: Validate the per-unit knowledge artifact for the scope stage of compliance. Units here are scoping memo — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Anti-patterns (RFC 2119):

The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
The agent MUST name a specific failed criterion in any rejection.
The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

4Approve

post-execute · the same agents re-run against the built work

The agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.

approval agentCompletenessThe agent **MUST** verify that the scope stage's `CONTROL-MAPPING.md` identifies every applicable control across every named framework, inventories every relevant system with data classifications, and maps each control to the systems it binds. Scope gaps here are silent — they manifest as findings in the certify stage that the team cannot close without reopening the scope conversation.

Check

The agent MUST verify, filing feedback for any violation:

Framework precision — every named framework includes version and revision (e.g., "SOC 2 Type II, 2017 TSC" not "SOC 2"; "ISO/IEC 27001:2022" not "ISO 27001"). Frameworks evolve; assessing against the wrong revision produces evidence the auditor rejects.
Per-control applicability — every control in each framework has an explicit applicable / not applicable / inherited decision with rationale. No control is silently omitted.
Inheritance evidence — every control marked inherited names the inheritance source (e.g., AWS SOC 2 bridge letter, Stripe attestation). Unsourced inheritance is not evidence.
System inventory completeness — every internally-built application, data store, third-party service, integration, and infrastructure surface that handles in-scope data is in the inventory. Third-party services are the most-frequently-missed category.
Data classification consistency — every in-scope system has a data classification using a single declared scheme; the scheme is documented in the artifact.
Control-to-system mapping — every applicable control names the bound systems. Many-systems-per-control is common; zero-systems-per-control is a finding.
In-scope / out-of-scope rationale — every system has an explicit decision per framework with rationale. "Not relevant" is not a rationale.
Cross-framework overlap surfaced — controls that appear in multiple frameworks (access control, data retention, incident response) are noted so downstream stages don't assess and evidence them twice.

Common failure modes to look for

A framework named without version (e.g., "SOC 2", "GDPR", "ISO 27001") — version is part of the scope contract
A control silently omitted from the list with no applicability decision
A not applicable decision with no rationale (or a rationale that doesn't actually rule out applicability)
A met or inherited claim that names a third-party provider but no specific evidence (bridge letter, attestation, SOC report)
A system inventory that omits an integration the rest of the document references (the auditor will follow that thread)
Data classifications that vary in granularity across systems (confidential for one, tier-2 for another) without a documented mapping
Out-of-scope decisions that ignore data flows — a system that's "out of scope" but receives in-scope data is not out of scope
A framework with overlapping controls where the overlaps aren't surfaced, leading to predictable duplication in assess and document stages

5Gate

controls advancement to the next stage

Auto

The harness advances automatically — no human in the loop at this gate.

Fix loop

a separate track · Classifier → Compliance Analyst → Feedback Assessor

Not a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.

fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's

Classifier (feedback triage)

You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.

What you do

Read the FB body via haiku_feedback_read { intent, stage, feedback_id }.
Read the stage's unit list via haiku_unit_list { intent, stage }.
Decide:
- target_unit — which unit this FB counter-signals.
  - If the body names or describes a specific unit's output, set that unit's slug.
  - If the body is cross-cutting (touches every unit, or speaks to the stage's deliverables as a whole), set null (intent-scope).
  - When in doubt: null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
- target_invalidates — which approval roles get cleared on closure. Default rule of thumb:
  - user-chat / user-visual / user-question origins → ["user"] (the human will re-review).
  - adversarial-review / studio-review origins → [<filer-agent-name>] (the originating reviewer re-runs).
  - drift origin → ["user"] (drift always escalates to human).
  - agent origin → [] (informational; no rerun).
Call haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes the target_unit / target_invalidates routing only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance.
Decide severity and call haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returns severity_already_set and you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.
- blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
- high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
- medium — a genuine issue worth fixing; not delivery-blocking.
- low — a nit, polish, or nice-to-have.
Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.
Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself: haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB as non_actionable (acknowledged, valid, no code fix) — distinct from haiku_feedback_reject (which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step.
Otherwise, call haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" } to hand off to the next fix-hat. The message is the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_write is refused). Your reasoning lives in the handoff message.

What you do NOT do

You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
You do NOT call haiku_feedback_reject — that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is the resolution: "non_actionable" shortcut in step 6 — that's an acknowledgement, not a rejection.)
You do NOT spawn subagents. The classification is a single read + single write + advance.

Why this hat exists

Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.

fix-hat 2Compliance AnalystIdentify the target regulatory framework(s), enumerate the applicable controls, and produce the framework-and-applicability section of the intent-scope `CONTROL-MAPPING.md`. You own the *what does this framework require?* half of scoping — the `scope-definer` hat owns the *which of our systems does it apply to?* half.

Process

1. Read your inputs

The user's engagement brief (the intent body and any clarifying conversation)
The unit's own success criteria
Any prior CONTROL-MAPPING.md from a related intent if the user references one (cite it; don't copy without re-evaluating applicability)

2. Name the framework(s) precisely

Where multiple frameworks apply (SOC 2 + HIPAA + GDPR is common), name each one and flag overlapping controls — a control that satisfies two frameworks should be assessed once, not twice.

3. Enumerate applicable controls

For each framework, list the controls that apply to the engagement scope. Mark each as one of:

Applicable — the control's requirements bind this organization given its services, systems, and data
Not applicable — the control does not bind, with explicit rationale (e.g., "no on-premises infrastructure; physical security controls inherited from the cloud provider")
Inherited — the control is satisfied by a service provider's compliance, with the inheritance source named (e.g., "AWS SOC 2 — see SOC 1 / 2 bridge letter")

The applicability rationale is the auditable artifact. A control with no rationale is a control the auditor will challenge.

4. Identify overlap with sibling frameworks

5. Format the artifact section

Suggested table shape:

Framework	Control ID	Requirement (summary)	Applicability	Rationale	Inherited from
SOC 2 (2017 TSC)	CC6.1	Logical access controls restrict access to system resources to authorized users	Applicable	—	—
SOC 2 (2017 TSC)	CC6.4	Physical access controls restrict access to system resources	Inherited	No on-prem infra	AWS SOC 2

6. Hand off

When every in-scope framework has an applicability decision for every control, hand off to scope-definer. Do not author the system inventory — that's the next hat's baton.

Anti-patterns (RFC 2119)

The agent MUST NOT assume all controls in a framework apply without explicit per-control evaluation
The agent MUST NOT name a framework without its version and revision
The agent MUST NOT mark a control "not applicable" without rationale the auditor can challenge
The agent MUST NOT ignore overlapping requirements across multiple frameworks — overlap is a savings, not a duplication risk
The agent MUST NOT treat compliance as a checkbox exercise — applicability is a judgment about whether the control's intent binds, not just whether its text mentions the organization's surface
The agent MUST document the rationale for every scope inclusion and exclusion decision
The agent MUST name the inheritance source for any control marked inherited
The agent MUST NOT copy applicability decisions from a prior intent without re-evaluating against current systems and services

fix-hat 3Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.

Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.

Anti-patterns (RFC 2119):

The agent MUST NOT edit any file — you are a verifier, not a fixer
The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
The agent MUST NOT call advance_hat (close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden — reject_hat with what's outstanding.
The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean reject_hat