Three protocols. One per diagnostic gap. Each is designed to close a specific gap before it compounds — not to document what happened after it did.
A structured process for surfacing implied logic before it becomes load-bearing. Applied at the agreement point — before configuration begins.
For each deliverable or configuration item in scope, identify what must be true for it to be achievable. Do not assume these dependencies are shared knowledge. Write them down.
For each dependency, ask: what are we assuming is true that we have not verified? Prompt both parties independently, then compare. Differences in the response identify assumptions that are not shared.
An assumption is not named until it is written as a statement that can be true or false. "We assume org structure is stable through go-live" is named. "Org structure" is not. The act of naming forces specificity.
Each named assumption has an owner responsible for monitoring it and a stated method for verifying whether it remains true. Assumptions without owners are unmonitored risks.
For each assumption, document what changes if it proves false — which deliverables are affected, what rework is required, what the cost is. This converts assumption capture from documentation into risk management.
Both parties review and confirm the assumption log before configuration begins. If a dependency cannot be named as an assumption, the dependency is not ready for build. Do not begin work on an unnamed premise.
The protocol is complete when every significant configuration dependency has a named assumption with an owner and a stated consequence — and that log was completed before configuration began. If the log was written retroactively, the gap may still be open.
A structured standard for capturing the reasoning behind configuration decisions at the moment they are made — before the reasoning leaves the room.
A decision is significant if it involves a workaround, bypasses standard functionality, accepts a trade-off, or creates a constraint that downstream work will depend on. Identify it at the moment it happens — not retrospectively.
What other approaches were evaluated? A decision without documented alternatives cannot be re-evaluated later — because there is no way to know what was ruled out and why. Even "we only considered one option" is a valid and important entry.
What made the chosen approach correct at this point? Performance, cost, timeline, client constraint, technical limitation? The criteria are the reasoning. Without them, the decision appears arbitrary to anyone who was not in the room.
Which future decisions, configurations, or deliverables depend on this choice? A decision that constrains downstream work is load-bearing. Mark it as such. This allows any future team member to distinguish between what can be changed and what cannot without cascading impact.
Who made this decision, and when? This is not accountability assignment — it is context. If the reasoning later needs to be verified or expanded, knowing who was present at the decision and when it was made locates the source.
The Rationale Gap is closed when a team member who joined after go-live can explain a workaround, evaluate a proposed change against it, and identify what would break if it were removed — without a conversation with the person who built it. If that explanation requires a person, the gap is still open.
A structured verification process that confirms the receiving party has transferred understanding — not just received artifacts. Applied at every major phase boundary.
Before the handoff meeting, the sending party identifies the areas where embedded reasoning is most likely to affect future decisions: key workarounds, load-bearing constraints, non-obvious dependencies, and configuration decisions with downstream impact.
For each high-risk area, the sending party explains not just what was built but why — what decision was made, what alternatives were ruled out, what constraint made the chosen approach necessary, and what would break if it were changed.
The receiving party is asked to explain the high-risk areas in their own words — without the sending party prompting. This is the verification test. If the receiving party cannot explain a decision without asking, comprehension was not transferred and the handoff is not complete.
The receiving party must be able to identify, for each high-risk area, which elements are constraints — changing them would break something — and which are starting points that can be revisited. A handoff that does not establish this distinction transfers outputs without decision context.
If the receiving party cannot explain a high-risk area, that gap is documented before the handoff is confirmed. The sending party provides additional context until demonstrated comprehension is established. The handoff is not confirmed until verification passes.
The Transition Gap is closed when the receiving party can answer "why does this work this way" for every high-risk area — without calling the sending party. If the answer to a routine operational question requires locating the previous team, the transition transferred artifacts but not understanding.
Each protocol above closes one gap. The gaps are sequential — the Assumption Gap creates conditions for the Rationale Gap, which compounds into the Transition Gap. All three must be closed.
Both parties proceed on logic that was never surfaced or verified.
Configuration decisions made. Reasoning not captured. Every future change becomes archaeology.
Something present in one phase does not survive transfer to the next.