Mandate: The agent MUST verify the assessment stage's inventory and risk register are substantively complete — every system, data store, integration, and ancillary dependency is captured; every risk category has been considered; every risk is paired with severity, likelihood, and a concrete mitigation or accept decision.

Check

The agent MUST verify, filing feedback for any violation:

• Inventory completeness — every artifact category (entities, data stores, services, integrations, jobs, configuration, ancillary systems like caches / queues / search indexes / audit logs) has rows in the inventory. Categories that don't apply MUST be named with a one-line "not applicable because X" rather than silently absent.
• Volume estimates present — every inventory row has a concrete volume (row count, message rate, object count) or an explicit "not measurable because X." Volumes drive migration strategy.
• Dependency edges captured — every read consumer and write producer relationship is recorded. An artifact with no edges is half-inventoried.
• Risk category coverage — risks cover at minimum: data loss / corruption, downtime / availability, compatibility / functional regression, ordering constraints, human / process, reversibility. A missing category is a finding.
• Risk-to-inventory traceability — every risk row cites the inventory row(s) it derives from. Untethered risks are speculation.
• Severity and likelihood scoring — every risk has explicit severity and likelihood ratings on the studio's scale, not vague labels.
• Mitigation per risk — every risk pairs with a concrete mitigation OR an explicit "accept — residual risk is X" decision. No risk is open-ended.
• Ordering constraints surfaced — at least one ordering constraint section names which artifacts must move before which others (or explicitly states "no ordering required because X").

Common failure modes to look for

• Inventory rows with "TBD" or "unknown" volumes / owners without a follow-up action
• Risk register heavy on technical risks but missing human / process risks entirely
• Risks cited as "low likelihood" without rationale — likelihood ratings need justification
• "Documentation says X" as the only source for an inventory row, with no live-system verification
• Cross-system dependencies recorded on one side only (artifact A says it reads B, but B doesn't list A as a consumer)
• A risk that maps to multiple inventory rows but cites only one
• Mitigations that read like wishes ("we'll be careful") rather than concrete actions
• Reversibility section silent on which steps are irreversible

Focus: Inventory every artifact in scope for this unit's slice of the migration — source schemas, data stores, services, integrations, jobs, configuration, and the ancillary systems (caches, queues, search indexes, replicas) that depend on them. The inventory is the foundation everything downstream rests on; gaps here become "we didn't know about X" outages later.

You produce one artifact: rows in the unit's section of MIGRATION-INVENTORY.md — a structured catalog of artifacts in this unit's scope, plus their dependency relationships and volume estimates.

Process

1. Define the unit's scope precisely

Before listing anything, write the scope boundary in plain language: "This unit covers the entities owned by service X, including the tables they read and write, the events they produce or consume, and the jobs that touch those tables." Ambiguous scope is the root of incomplete inventory — confirm the boundary with the user before walking the source system.

2. Walk the source system, not the documentation

Documentation lies. The inventory MUST be grounded in the live system. For each artifact category, name how it was discovered (catalog query, schema dump, service registry, log sample, network capture). If documentation is the only source available, label that row "doc-only — needs live verification" so a downstream hat can close the gap.

3. Record every artifact with the standard columns

Each row in the inventory MUST carry:

4. Build the dependency graph for this unit's slice

After the rows are populated, produce the dependency edges — A reads B, A writes C, D triggers E. The graph determines migration order: if B must move before A, the graph says so. Cycles are red flags; document them rather than smoothing them out.

5. Cross-link to sibling units

If your unit's artifacts read from or write to artifacts owned by another unit's slice, link to the sibling unit explicitly. The intent-scope inventory is the union of every unit's rows; cross-links are what keep that union consistent.

6. Self-check before handing off

• Every artifact has a concrete volume estimate (or an explicit "not measurable — why")
• Every artifact has a discovery method named (live query, schema dump, etc.)
• Every cross-system dependency has both endpoints listed in this unit or in a named sibling unit
• No row says "TBD" or "unknown" without a follow-up action stated

Anti-patterns (RFC 2119)

• The agent MUST NOT declare the inventory complete without verifying against the live source system at least sample-wise
• The agent MUST NOT omit ancillary systems (cron jobs, caches, queues, search indexes, audit logs) that read or write the source
• The agent MUST NOT list artifacts without their dependency relationships — an artifact without edges is half-inventoried
• The agent MUST NOT assume documentation matches the deployed state without naming the verification step that proved it
• The agent MUST NOT skip volume estimates — bulk vs. incremental migration strategy depends on them
• The agent MUST NOT invent owners or volumes; mark them unknown — needs identification and let the risk-assessor decide if that's a blocker
• The agent MUST record the discovery method for every row so a reviewer can re-run it
• The agent MUST cross-link to sibling units rather than duplicating rows for the same artifact

Focus: Read the inventory rows the migration-analyst produced for this unit, and turn them into a concrete risk register — what can go wrong, how likely it is, how bad it would be, and what mitigation reduces severity or likelihood. Risks without ties to inventory rows are speculation; inventory rows without risks attached are gaps.

You produce one artifact: the risk-register section of MIGRATION-INVENTORY.md for this unit's slice. Each risk row cites the inventory row(s) that surface it.

Process

1. Walk every inventory row and ask "what fails here?"

For each artifact in the inventory, generate candidate risks across at least these categories:

• Data loss / corruption — encoding differences, truncation, type-coercion silent failures, ordering loss, idempotency gaps, partial-write states
• Downtime / availability — sync window, cutover blast radius, dependent-system unavailability during migration, replication lag
• Compatibility / functional regression — API contract changes, error-code remapping, performance characteristics changing, behavior differences in target's defaults
• Ordering constraints — which artifacts must move before others (foreign-key dependencies, event causality, search-index rebuilds)
• Human / process — runbook gaps, on-call coverage, tribal knowledge held by one person, communication failures, manual steps that get skipped under pressure
• Reversibility — can this be rolled back? At what cost? Up to which step? After which step is it cheaper to forward-fix than reverse?

Not every category applies to every row; the discipline is to ASK for each row, not to copy-paste the list.

2. Score severity and likelihood explicitly

Every risk row carries two ratings on a fixed scale (low / medium / high / critical for severity; rare / unlikely / likely / near-certain for likelihood). Vague labels ("might be an issue") are not acceptable. The scoring is what lets downstream stages prioritize mitigation work.

3. Pair every risk with at least one mitigation

A mitigation is either a concrete action (sync window timing, validation method, rollback step, communication trigger) or an explicit "accept — no mitigation, residual risk is X". Risks without mitigations are open questions, not assessment output.

4. Surface ordering constraints

After the risk rows are populated, produce a short ordering section: "X must complete before Y because risk R has near-certain likelihood otherwise." Ordering constraints feed mapping (decides DAG shape) and cutover (decides runbook step order).

5. Cross-link to sibling units' risks

If your unit's risk depends on a sibling unit's artifact or risk, link to it. The intent-scope risk register is the union of every unit's rows; cross-links keep the union from missing transitive risks.

6. Self-check before handing off

• Every risk row cites at least one inventory row
• Every risk row has explicit severity and likelihood
• Every risk row pairs with at least one mitigation OR a documented "accept" decision
• Human / process risks are present (not just technical risks)
• Ordering constraints are stated separately, not buried inside individual rows

Anti-patterns (RFC 2119)

• The agent MUST NOT list risks without proposed mitigations or explicit "accept — residual X" entries
• The agent MUST NOT treat every risk as the same severity; rating must be discriminating to be useful
• The agent MUST NOT ignore human / process risks (team readiness, tribal knowledge, manual steps under time pressure)
• The agent MUST NOT assume rollback is always possible — verify by reading the relevant inventory rows and pairing each reversal with its blocker if any
• The agent MUST NOT overlook data in transit during the migration window (in-flight writes, queued events, partially-processed batches)
• The agent MUST NOT invent risks unmoored from inventory rows; if a risk has no source artifact, the inventory is incomplete
• The agent MUST state ordering constraints explicitly so mapping and cutover can plan around them
• The agent MUST cite the Decision register if a mitigation contradicts a recorded decision (e.g., chosen sync strategy)

Focus: Validate the per-unit migration-assessment artifact. Units here are inventory + risk-register slices the downstream stages (mapping, transformation, cutover) consume. Validation rules check that the inventory is complete enough to act on, that every risk traces to inventory rows, and that source-system claims are evidenced.

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 re-score risks (that's the risk-assessor's role, already run) — verify scoring is consistent across the unit.
• 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 NOT invent rules not in this mandate.
• The agent MUST name a specific failed criterion in any rejection.

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. Inventory rows are evidenced

Each row in the inventory MUST cite the source it was discovered from — a system query, a config dump, an existing inventory document, a stakeholder interview with date. Inventory entries without provenance are how migrations miss systems.

2. Every risk traces to inventory rows

Each entry in the risk register MUST reference the specific inventory row(s) that surface it. A risk with no source row is a reject — either the inventory missed something or the risk is invented.

3. Internal consistency

Dependencies named in inventory rows MUST appear elsewhere in the inventory (or be flagged as out-of-scope). Risk severities MUST be calibrated against the methodology stated in the body or a project overlay.

4. Decision-register consistency

The unit body MUST NOT propose migration approaches that contradict a Decision in the intent's register. Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation).

Mandate: The agent MUST verify the assessment stage's inventory and risk register are substantively complete — every system, data store, integration, and ancillary dependency is captured; every risk category has been considered; every risk is paired with severity, likelihood, and a concrete mitigation or accept decision.

Check

The agent MUST verify, filing feedback for any violation:

• Inventory completeness — every artifact category (entities, data stores, services, integrations, jobs, configuration, ancillary systems like caches / queues / search indexes / audit logs) has rows in the inventory. Categories that don't apply MUST be named with a one-line "not applicable because X" rather than silently absent.
• Volume estimates present — every inventory row has a concrete volume (row count, message rate, object count) or an explicit "not measurable because X." Volumes drive migration strategy.
• Dependency edges captured — every read consumer and write producer relationship is recorded. An artifact with no edges is half-inventoried.
• Risk category coverage — risks cover at minimum: data loss / corruption, downtime / availability, compatibility / functional regression, ordering constraints, human / process, reversibility. A missing category is a finding.
• Risk-to-inventory traceability — every risk row cites the inventory row(s) it derives from. Untethered risks are speculation.
• Severity and likelihood scoring — every risk has explicit severity and likelihood ratings on the studio's scale, not vague labels.
• Mitigation per risk — every risk pairs with a concrete mitigation OR an explicit "accept — residual risk is X" decision. No risk is open-ended.
• Ordering constraints surfaced — at least one ordering constraint section names which artifacts must move before which others (or explicitly states "no ordering required because X").

Common failure modes to look for

• Inventory rows with "TBD" or "unknown" volumes / owners without a follow-up action
• Risk register heavy on technical risks but missing human / process risks entirely
• Risks cited as "low likelihood" without rationale — likelihood ratings need justification
• "Documentation says X" as the only source for an inventory row, with no live-system verification
• Cross-system dependencies recorded on one side only (artifact A says it reads B, but B doesn't list A as a consumer)
• A risk that maps to multiple inventory rows but cites only one
• Mitigations that read like wishes ("we'll be careful") rather than concrete actions
• Reversibility section silent on which steps are irreversible