The Intake Test: What Must Be Known Before Work Can Start?

Start with the decision the work must support

An intake record should state what the requester needs and which decision or deliverable the work is meant to support. A vague request such as “please handle this” leaves the team to guess at scope, urgency, and completion. A useful request names the expected outcome in ordinary language and identifies who can clarify or approve it.

This is context, not ceremony. NIST's AI Risk Management Framework begins its Map function by establishing intended purpose, users, expectations, assumptions, and limitations. The same discipline is useful before any consequential workflow begins, whether or not AI is involved.

Six things should be visible before work starts

• Request: What outcome or decision is being requested?
• Owner: Who owns the next action, and who can resolve a scope question?
• Authoritative source: Which record, message, or file controls the facts the team will use?
• Required inputs: Which items are necessary for the first authorized step—not every item that may eventually help?
• Constraints: Which deadline, permission, confidentiality rule, or approval boundary affects the work now?
• Next decision: What observable result will show that the work may advance, pause, or return for clarification?

Do not turn every unknown into a blocker

Some missing facts make the next step unsafe or meaningless. Others can remain visible while work proceeds. The distinction is whether the missing fact changes authorization, scope, source reliability, ownership, or the immediate decision.

Record a nonblocking unknown with an owner and next action. Hold the work when authority conflicts, a required source cannot be identified, sensitive information would be handled without permission, or the team cannot tell which outcome it has been asked to produce. This keeps incomplete intake from becoming either paralysis or silent guesswork.

Use the source-and-owner test

For each material input, ask two questions: Where did this come from, and who is responsible for resolving a conflict? A copied value without a source invites correction later. A flagged discrepancy without an owner simply moves the delay downstream.

NIST's Cybersecurity Framework 2.0 emphasizes defined roles, responsibilities, authorities, and an understanding of organizational context and assets. GAO's AI Accountability Framework likewise organizes accountability around governance, data, performance, and monitoring. For a small team, those ideas become practical when the intake record names the source, owner, expected result, and review point.

Run a seven-question intake test

• What exactly has been requested?
• Who is authorized to request it and answer scope questions?
• Which source controls each material fact needed now?
• What must be present before the first step can begin?
• Which unknowns can remain open, and who owns each next action?
• What would require the team to stop or seek approval?
• What readback or review will prove the handoff is ready for the next person?

A good intake state is honest and usable

The intake record should not claim that work is complete, approved, or ready for release. It should tell the next person what is known, what remains open, which source controls, who owns the next action, and why the current step is permitted.

That standard gives a team a clean starting point without pretending uncertainty has disappeared. It also creates a useful place to measure rework later: repeated missing inputs, recurring source conflicts, unclear ownership, and avoidable approval loops become visible patterns instead of anecdotes.