Stage-gated delivery requires an enforcement mechanism. Without one, gates become opinions — teams debate whether a project is ready based on subjective confidence rather than observable evidence, and the gate becomes a meeting rather than a checkpoint. For gates to work, readiness must be measurable. This is where truth conditions come in.
What a Truth Condition Is
A truth condition is a specific fact about a project that must be established before the project can safely advance. It is not a task or a milestone — it is a verifiable piece of knowledge about the system being built.
Examples of truth conditions relevant to the intake stage of a project:
- The problem the system is intended to solve has been written down in a clear statement.
- A single person with authority to make decisions has been identified.
- The scope boundary has been documented — what the project includes, and what it explicitly excludes.
- The users interacting with the system have been named and described.
- The major entities within the system domain have been identified.
- The key delivery risks have been surfaced and recorded.
- The sensitivity of the data the system will handle is understood.
Each of these conditions represents a discrete fact. Each fact either exists in the project's documentation, or it does not. When all of these conditions are satisfied, the intake stage is complete. When any of them remain undefined, the project has unresolved ambiguity — regardless of how much work has been done or how much time has passed.
Three States, Not Two
Truth conditions are not binary. A simple yes/no evaluation fails to capture the most common reality: partial evidence. A project may have a problem statement that is technically present but contains significant structural gaps. A scope boundary may be documented but challenged by open issues that have not been resolved.
A more useful model recognizes three states.
Defined means the condition is satisfied. Evidence exists in a project artifact, and no structural issues undermine that evidence.
Partial means evidence exists but is incomplete or contested. There may be a problem statement, but it is contradicted by unresolved questions elsewhere in the documentation. The condition is not absent, but it cannot be relied upon.
Undefined means no evidence exists at all. The project has not yet produced the information required to satisfy this condition.
This three-state model reflects the actual situation on real projects more accurately than a simple checklist.
From Truth Conditions to Readiness
Individual truth conditions matter, but what matters more is what they collectively imply. A delivery system needs to answer questions like: Is this project ready to begin design? Is it ready to begin development? Is it ready for release? These questions cannot be answered by looking at a single condition in isolation — they require looking at which conditions have been satisfied as a group. This is what readiness derivation does.
Different readiness questions depend on different combinations of truth conditions. Whether a project is ready for design work depends primarily on having a defined problem, a documented scope, identified users, and a known domain model — the conditions that make design decisions stable. Whether a project is ready to begin development depends on a broader set, including everything design readiness requires, plus data classification, risk assessment, and a complete specification.
When all conditions in a readiness group are defined, that readiness node is safe. When some conditions are partial, the readiness node is conditional — the project may be able to proceed, but with known gaps that require monitoring. When key conditions are undefined, the readiness node is unsafe, and proceeding risks building on an unstable foundation.
Why This Model Is More Useful Than Checklists
Most delivery teams already use checklists at stage transitions. Checklists verify that specific artifacts have been produced — that a problem statement exists, that a scope document has been written, that user stories are in the backlog. The problem with checklists is that they verify existence, not substance.
A project may tick every box on the intake checklist while still containing unresolved ambiguity in every area. The document exists, but whether it represents stable knowledge is a different question. Truth conditions address this by evaluating the substance of artifacts, not their presence. A truth condition is not satisfied simply because a document has been filed. It is satisfied when the evidence in that document — read against the project's open issues, decisions, and known gaps — supports a confident claim about the project's state. That distinction changes what "ready" actually means.
Human Judgment and Override
Automated evaluation can assess evidence, but it cannot replace human judgment. There are situations where a truth condition appears unsatisfied by strict evidence but a PM or delivery lead knows the situation is resolved. A key stakeholder has verbally confirmed a decision. A risk has been accepted by the client. A scope question has been settled in a meeting that preceded the formal documentation.
In these cases, the delivery system should allow human override. A PM can mark a condition as confirmed — with a rationale — allowing the project to advance even when the automated evidence is incomplete. This flexibility is important: delivery systems exist to support teams, not to block them based on documentation lag. The override is recorded, the rationale becomes part of the project's decision log, and if the assumption later proves incorrect, the audit trail explains what was believed at the time.
Readiness as a Continuous Signal
Truth conditions change as a project evolves. An initial intake analysis may identify fifteen gaps, leaving most conditions partial or undefined. As the project team resolves questions, produces artifacts, and records decisions, conditions shift from undefined to partial to defined. Readiness improves continuously, not in step changes.
This means readiness is better understood as a signal than as a threshold. Rather than waiting for all conditions to flip to defined before acting, delivery teams can use readiness to understand which areas of a project require the most attention — which conditions are blocking progress, which gaps are genuinely structural, which issues need to be resolved before the next phase begins. This continuous signal gives delivery leads an honest view of where a project actually stands and what needs to happen before it can safely advance.
The Practical Value
What makes truth conditions useful in practice is not their individual definitions — it is the discipline of making them explicit. Most delivery teams have an intuitive sense of what they need to know before moving to the next stage. They know that design cannot begin until scope is stable. They know that development cannot proceed until design decisions are resolved. Truth conditions formalize that intuition.
By naming the specific facts that must be established, the delivery system creates a shared standard for readiness. The team no longer debates whether the project "feels" ready — they examine whether the conditions are satisfied. That shift from subjective confidence to observable evidence is the foundation of predictable delivery.