Materialize the Brief
A queue entry begins as references: a pipeline name, task notes, requested brains, and perhaps attachments. Execution needs a closed artifact. Materialization resolves the current pipeline row, stamps its version, renders the template with the scoped notes, and records the resulting brief path as the session's work order.
The rendered brief is intentionally redundant with source data. That redundancy is a snapshot boundary, not copy-paste architecture. A reviewer should be able to read the exact instructions handed to the author even if the pipeline row is edited later or the live provider presents different defaults.
Materialization also makes missing information fail early. A template can require destination and proof sections; the engine can refuse to queue or take if they remain empty. Once the brief exists, another brain should not need access to the original scoping conversation to know its authority.
The work order carries provenance: delegation key, pipeline key and version, creation time, requested reviewer policy, and task notes. It should not carry operational secrets or private infrastructure trivia. Enough context to execute is different from every fact the engine knows.
Render, Then Read It Back
After materialization, parse the header and assert the stamped identity, pipeline version, and review mode. Then read the human body as a work order. A syntactically valid file can still omit the sentence that makes scope closed.
The handoff test is simple: give the brief package to a fresh session with no conversation history. If it must ask what the destination or completion evidence means, materialization preserved text but failed to preserve authority.