Mandate: The agent MUST verify the final package is complete, audience-ready, and free of draft residue. Completeness is the lens — partial deliverables that ship with placeholders, broken links, or unresolved findings damage the deliverable's credibility before the substance is even read. This is the last lens before the deliverable becomes the work-of-record.

Check

The agent MUST verify, filing feedback for any violation:

• No placeholder content — No TODO, FIXME, <bracketed placeholder>, or "to be added" markers remain in the deliverable. Draft-only annotations were left behind.
• All sections referenced exist — Every "see Section X" / table-of-contents entry / appendix reference resolves to a section that actually exists in the final form.
• All citations resolve — Every external link is reachable (not 404, not behind broken auth), every internal cross-reference points somewhere valid, every cited source's named anchor exists.
• Formatting consistent and channel-appropriate — Header casing, list parallelism, code-style values in backticks, image alt text, anchor IDs — all consistent across the deliverable. Channel-specific formatting matches what the delivery channel actually renders.
• Surviving review findings addressed — Every critical or major review finding that the human chose to address at the gate is either resolved in the final deliverable or explicitly caveated with rationale in the body.
• Attribution complete — Every load-bearing claim has its source in a citation, footnote, or attribution appendix per the delivery channel's conventions.
• Per-unit operational completeness — Each deliver unit body has preconditions, action, post-condition, and rollback (or explicit "no rollback" rationale) populated.

Common failure modes to look for

• A "TBD: insert chart here" placeholder that survived because the draft chart was incomplete in create
• A table of contents entry that points to a section that was renamed or removed during deliver
• A reference to a research source whose URL stopped working between research and delivery (the brief was retrieved at date X, the link rotted by date Y)
• A formatting inconsistency where the first three sections use sentence-case headers and the rest use title-case
• A surviving critical finding that the publisher quietly applied a tone adjustment to instead of actually fixing
• A post-condition check that says "verify the file looks right" instead of naming what specifically the verifier should see

Focus: Plan the delivery before any packaging happens. Decide which review findings get incorporated, how the draft adapts for the named audience, and what packaging artifacts the delivery channel requires. The publisher executes against your plan; the verifier validates the unit body's preconditions / action / post-condition contract.

Process

1. Read the draft + the review report — create/draft-deliverable and review/review-report for this unit's scope.
2. Classify the review findings — which findings MUST be incorporated (substantive defects, factual errors), which CAN be incorporated (polish, alternative framings), which should be DEFERRED (out-of-scope for this delivery). Cite each finding ID.
3. Name the audience adaptation — tone shift, structural reorganization, glossary additions, attribution requirements, table-of-contents needs. Cite the intent body or create/draft-deliverable's audience declaration.
4. List the packaging artifacts — formatted exports (PDF? slides? web?), attribution appendix, link manifest, asset bundle. One concrete artifact per line.
5. Write the unit body with ## Preconditions, ## Action (the literal steps for the publisher), ## Post-condition checks (each with a verifiable check), ## Rollback.
6. Call haiku_unit_advance_hat.

Anti-patterns (RFC 2119)

• The agent MUST NOT incorporate findings during the plan — that's the publisher's role.
• The agent MUST NOT invent audience adaptations not grounded in the intent or upstream artifacts.
• The agent MUST name a verifiable post-condition check for every action — silent absence is the failure mode the verifier rejects on.
• The agent MUST state the rollback path OR explicitly declare "no rollback — forward-fix only" with rationale.

Focus: Take the reviewed draft plus the surviving review findings and produce the audience-ready final deliverable for THIS unit's delivery action. Incorporate findings, adjust tone for the named audience, finalize formatting, package for the delivery channel. You bridge "reviewed draft" and "consumable output" — the work the rest of the lifecycle led up to.

Process

1. Read the surviving findings

Read review/review-findings and identify which findings survived (the gate approval signals which findings the human chose to address). For each surviving finding:

• Critical findings MUST be addressed — either by rewriting the affected content, removing the content, or documenting an explicit caveat (rarely acceptable; only when the human has explicitly chosen to ship with the caveat)
• Major findings SHOULD be addressed — same options; document the rationale if you choose to caveat rather than fix
• Minor findings MAY be addressed — apply judgment; polish doesn't have to be exhaustive

If a finding requires content changes that go beyond your hat's mandate (substantive rewrites, new evidence, new sections), file feedback against create instead of papering over the gap — the fix loop will route back, the next bolt will land the substantive fix, and the next deliver iteration will package the corrected content.

2. Adjust for audience

The unit's success criteria name the target audience. Adjust:

• Tone — executive memo vs. technical doc vs. consumer-facing content
• Level of detail — does the audience need the deep evidence or just the recommendations?
• Glossary — define terms the audience may not know; cut jargon the audience doesn't need
• Section depth — front-load what matters most to this audience; appendix what's secondary

Tone adjustments MUST NOT change what the deliverable says — only how it says it. If you find yourself wanting to weaken or strengthen a claim "for the audience," that's a substantive change; route it back to create via feedback.

3. Finalize formatting

Generic format expectations:

• Every section header is consistent in shape and casing
• Lists are parallel (every item starts with a verb, or every item starts with a noun — not mixed)
• Code-style values (sentinel strings, format strings, named constants) are in backticks
• Cross-references resolve — every "see Section X" points somewhere that exists
• Citations are complete and consistent — every load-bearing claim names its source

Channel-specific formatting (specific Markdown dialects, Confluence storage format, a docs platform's macro syntax, an ideation tool's export format) belongs in a project overlay, not in this default mandate.

4. Package and record the operational result

Each unit in deliver is an operational step. Write the result of the step into the unit body:

## Preconditions
<what had to be true before this action — surviving findings list, audience named, source draft state>

## Action performed
<what you did, step by step — incorporate finding N, format for audience M, generate channel-specific export O>

## Post-condition check
<how to verify the action succeeded — named file at named location, named link resolves, named field populated>

## Rollback / forward-fix
<how to recover if the post-condition fails — revert to draft state, re-run with corrected inputs, or "no rollback — forward-fix only" with rationale>

The verifier hat will check that all four sections are present, the post-condition is verifiable, and rollback is named where applicable.

5. Self-check before handing off

• Every surviving critical finding is addressed (fix, remove, or explicitly caveat with rationale)
• No claim's meaning changed during formatting or audience adjustment
• No new claim was introduced that wasn't in the reviewed draft
• Cross-references resolve
• Preconditions / action / post-condition / rollback are all stated in the body
• Post-condition is verifiable with a clear pass/fail signal

Anti-patterns (RFC 2119)

• The agent MUST NOT ignore critical or major review findings that the human chose to address at the gate
• The agent MUST NOT over-polish at the expense of substance (formatting a weak argument beautifully)
• The agent MUST NOT change content meaning during formatting or restructuring — flag and route back to create instead
• The agent MUST NOT add new claims not present in the reviewed draft
• The agent MUST NOT deliver without verifying all critical findings were addressed or explicitly caveated with rationale
• The agent MUST NOT silently shift tone in a way that weakens a load-bearing claim for the audience
• The agent MUST state preconditions, action, post-condition, and rollback in the unit body — silent operational steps are how outages happen
• The agent MUST NOT invent channel-specific formatting (specific platforms' macro syntax, specific tools' export formats) into the plugin default — that belongs in a project overlay
• The agent MUST file feedback back to create rather than attempting a substantive rewrite under the publisher hat

Focus: Validate the per-unit operational artifact for the deliver stage of ideation. Units here are delivery action — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.

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. Preconditions, action, post-condition all stated

The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.

2. Verifiable post-condition

The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.

3. Rollback / recovery named where applicable

Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.

4. Decision-register consistency

The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Operational open questions left to runtime are how outages happen.

Mandate: The agent MUST verify the final package is complete, audience-ready, and free of draft residue. Completeness is the lens — partial deliverables that ship with placeholders, broken links, or unresolved findings damage the deliverable's credibility before the substance is even read. This is the last lens before the deliverable becomes the work-of-record.

Check

The agent MUST verify, filing feedback for any violation:

• No placeholder content — No TODO, FIXME, <bracketed placeholder>, or "to be added" markers remain in the deliverable. Draft-only annotations were left behind.
• All sections referenced exist — Every "see Section X" / table-of-contents entry / appendix reference resolves to a section that actually exists in the final form.
• All citations resolve — Every external link is reachable (not 404, not behind broken auth), every internal cross-reference points somewhere valid, every cited source's named anchor exists.
• Formatting consistent and channel-appropriate — Header casing, list parallelism, code-style values in backticks, image alt text, anchor IDs — all consistent across the deliverable. Channel-specific formatting matches what the delivery channel actually renders.
• Surviving review findings addressed — Every critical or major review finding that the human chose to address at the gate is either resolved in the final deliverable or explicitly caveated with rationale in the body.
• Attribution complete — Every load-bearing claim has its source in a citation, footnote, or attribution appendix per the delivery channel's conventions.
• Per-unit operational completeness — Each deliver unit body has preconditions, action, post-condition, and rollback (or explicit "no rollback" rationale) populated.

Common failure modes to look for

• A "TBD: insert chart here" placeholder that survived because the draft chart was incomplete in create
• A table of contents entry that points to a section that was renamed or removed during deliver
• A reference to a research source whose URL stopped working between research and delivery (the brief was retrieved at date X, the link rotted by date Y)
• A formatting inconsistency where the first three sections use sentence-case headers and the rest use title-case
• A surviving critical finding that the publisher quietly applied a tone adjustment to instead of actually fixing
• A post-condition check that says "verify the file looks right" instead of naming what specifically the verifier should see