Every software project begins with a document.
It might be a Statement of Work negotiated with a client. A project brief assembled by an internal product team. A set of emails and notes compiled from a discovery call. In some cases, it is little more than a slide deck and a vague mandate.
Whatever its form, this document is the intake artifact — and it is the most consequential thing a delivery team will ever produce.
Every decision made downstream depends on what this document establishes. The capability map is built from the problem it defines. The user journeys reflect the users it names. The information architecture models the domain it describes. The scope of the engagement is bounded by what it includes and excludes.
When the intake artifact is incomplete, everything downstream is built on a gap.
What Intake Artifacts Are
The intake artifact is not one specific document. It is the body of founding material that establishes what a project is, why it exists, and what success looks like.
Common forms include:
- Statements of Work — formal contracts that define deliverables, timelines, and acceptance criteria between a client and an agency
- Project briefs — internal documents that articulate a problem and set direction for a product team
- Discovery documents — synthesis outputs from interviews, workshops, and research sessions
- Scoping documents — structured definitions of what a system will and will not include
- RFP responses — submissions that describe a proposed solution to a client's stated problem
In practice, most projects have a combination of these. The intake artifact is the collection of founding inputs that, together, are supposed to establish the project's foundation.
What a Well-Formed Intake Artifact Establishes
Not every intake artifact is equally useful. The measure of a good intake artifact is whether it answers the questions that downstream work depends on.
A well-formed intake artifact establishes:
The problem. A clear statement of what situation or limitation the system is intended to address. Not a feature list. Not a technology preference. The underlying problem.
The decision owner. The identity of the person with authority to resolve ambiguity, accept tradeoffs, and make final calls. Projects without a named decision owner accumulate unresolved questions.
The scope boundary. An explicit definition of what is in scope and what is out. Without a boundary, scope is whatever anyone thinks it is at any given moment.
The users. Who will interact with the system, what they are trying to accomplish, and what constraints shape their experience.
The domain. The major entities in the system — the things, events, and relationships the software must model.
The risks. Known constraints, concerns, and failure modes that have already been identified.
The data. What sensitive information the system will handle, and what obligations that creates.
When all of these are established, a project team knows what they are building and for whom. When any of them are absent, the team is making assumptions — and assumptions are not knowledge.
Why Most Intake Artifacts Fail Silently
The problem with intake artifacts is not usually that they are missing. It is that they appear complete while containing structural gaps.
A Statement of Work may have a scope section, but that section may define scope by listing features rather than by drawing a boundary. A project brief may name users without describing them. A discovery document may surface a problem statement that is three sentences long and answers none of the questions that design decisions depend on.
These documents pass review. They satisfy the checklist. They are filed, referenced in kick-off decks, and carried through the project — and the gaps remain. They surface later as questions raised in sprint reviews, as scope disputes between the client and the delivery team, as design decisions made on unexamined assumptions. By then, the intake artifact is a historical document. No one goes back to fix it. The project moves forward on a foundation it was never certain about.
The Intake Gap Analysis
An intake gap analysis is a structured review of the intake artifact against the conditions a project must satisfy before downstream work can safely begin.
It does not ask whether documents have been produced. It asks whether the conditions they were supposed to establish have actually been established.
A gap analysis evaluates:
- Is the problem stated with enough specificity to make architectural decisions?
- Is the scope boundary drawn explicitly, or implied by a feature list?
- Are users named and described, or assumed to be obvious?
- Has the domain been modeled, or are entities and relationships left implicit?
- Have risks been named, or are they present as vague concerns in meeting notes?
- Is the data classification documented, or unknown?
Each condition that cannot be confirmed from the intake artifact is a gap. Gaps are not failures — they are facts about a project's current state of knowledge. What makes them dangerous is when they are undiscovered, when teams proceed as if the gap does not exist. A gap analysis makes the gaps visible. Once visible, they can be addressed, accepted, or escalated. What they cannot do is disappear on their own.
The First Link in the Chain
The intake artifact is the first link in the artifact chain. Everything downstream — capability maps, user journeys, information architecture, component inventories — is derived from it.
This means the quality of the intake artifact determines the stability of everything that follows.
A capability map built from a well-established problem statement is stable. It reflects actual understanding of the system's purpose. A capability map built from a problem statement that was never examined is an elaborate document built on unverified assumptions.
The artifact chain connects these links by traceability. Each downstream artifact should be able to point back to the artifact it was derived from. When a component in the component inventory cannot be traced to a user journey, and that user journey cannot be traced to a capability, and that capability cannot be traced to the problem statement — the chain is broken.
Broken chains are not obvious. They show up as late-stage disagreements about scope, as design decisions that contradict product decisions, as development work that does not match the specification.
A strong intake artifact prevents chain breakage from the beginning.