Templates

Assumption Gap · Gap 01

Assumption Log

A co-authored register of the implied logic beneath every stated agreement. Completed before configuration begins. Fields marked * are required for each entry — an assumption without these fields is incomplete.

Log Header — One entry per assumption Complete before build begins · Co-signed by both parties

Assumption ID

Sequential identifier for cross-referencing. Format: ASM-001, ASM-002, etc.

Text / Auto-number

Assumption Statement

A declarative statement of the implied logic — written so it can be true or false. Example: "Org structure will remain stable through go-live date." Not: "Org structure."

Text (complete sentence required)

Dependency

Which deliverable, configuration item, or scope element depends on this assumption being true? Name the specific item.

Reference to scope item

Owner

Who is responsible for monitoring this assumption and raising a flag if it changes? Must be a named individual, not a team or role.

Named individual

Verification Method

How will the owner verify that this assumption remains true? Example: "Monthly confirmation from HR project sponsor." Not: "Monitor."

Specific mechanism

Consequence if False

If this assumption proves wrong, what specifically changes? Which deliverables are affected? What rework is required? What is the estimated cost or time impact?

Specific impact statement

Status

Active / Changed / Invalidated. Updated by the owner when the assumption is no longer true. A changed assumption triggers immediate escalation.

Status field

Date Captured

Date the assumption was named and entered into the log. Must precede the start of build work for any dependent item.

Date

Co-signed By

Both parties confirm this assumption reflects their shared understanding. A log entry signed by only one party is not co-authored — it is a unilateral claim.

Two signatures / initials

Critical timing note

An assumption captured after the configuration it supports has begun is a retroactive record, not a gap-closing intervention. The Assumption Log closes the gap only when entries precede the build work that depends on them. Timing is the protocol. The template is the record.

Supporting protocol: Assumption Anchoring Protocol →

Rationale Gap · Gap 02

Rationale Field Standard

A field specification for capturing decision reasoning at the point of decision. Appended to every significant configuration entry — workarounds chosen, standard functionality bypassed, trade-offs accepted. Fields marked * are required.

Rationale Block — Appended to each significant configuration decision Completed at the moment of decision · Not retrospectively

Decision ID

Sequential identifier linking this rationale block to the configuration record it describes. Format: DEC-001, DEC-002, etc.

Reference ID

Decision Summary

What was decided, in one or two sentences. This is the WHAT. The remaining fields are the WHY. Do not conflate them — a decision summary that explains reasoning instead of stating the decision fails both functions.

1–2 sentences

Decision Type

Workaround / Standard bypass / Design exception / Trade-off accepted / Configuration choice. Select the category that most accurately describes the nature of this decision.

Category selection

Alternatives Considered

What other approaches were evaluated? List each alternative and why it was ruled out. If only one approach was considered, state that explicitly — "No alternatives evaluated; only viable approach given [constraint]."

List (minimum one entry required)

Decision Criteria

What made the chosen approach correct? Performance, cost, timeline, client constraint, technical limitation, regulatory requirement? The criteria are the reasoning — they allow a future reader to evaluate whether the criteria still apply.

Named criteria with brief explanation

Load-bearing

Is this decision a constraint that downstream work depends on? Yes / No. If Yes, list the downstream items that depend on this decision remaining as-is. This field distinguishes what can be changed from what cannot without cascading impact.

Yes / No + dependency list if Yes

Decision Owner

Who made this decision? Named individual. This is not accountability assignment — it is context for locating the source if the reasoning needs to be verified or expanded.

Named individual

Date

When was this decision made? A rationale block dated after the configuration it describes was built is retroactive. Retroactive rationale is incomplete — it may not reflect the actual criteria used at the time.

Date (at time of decision)

Review Trigger

Under what conditions should this decision be revisited? Example: "If client org structure changes after go-live." Optional but recommended for high-impact decisions.

Condition statement (optional)

Closure verification

The Rationale Field Standard is correctly applied when a team member who was not present at the decision can read this block and: (1) explain what was decided and why, (2) evaluate a proposed change against the original criteria, and (3) identify what would break if the decision were reversed — without asking anyone. If any of these three are impossible from the block alone, the block is incomplete.

Supporting protocol: Decision Rationale Protocol →

Transition Gap · Gap 03

Handoff Verification Checklist

A structured verification record confirming that the receiving party has demonstrated understanding of inherited decisions — not merely possession of artifacts. Completed at every major phase boundary before the handoff is confirmed.

Handoff Record — One per phase boundary Confirmed by both sending and receiving parties

Handoff ID

Sequential identifier. Format: HO-001, HO-002. Linked to the phase boundary it covers (e.g., Discovery → Design).

Reference ID

Phase Boundary

Which phases are involved? Discovery → Design / Design → Build / Build → UAT / UAT → Go-live / Go-live → Operations. Specify both sending and receiving phases.

Named boundary

Sending Party

Team, vendor, or individual handing off. Named specifically — not "implementation team."

Named party

Receiving Party

Team, vendor, or individual receiving. Named specifically.

Named party

High-Risk Areas Identified

List of areas where embedded reasoning is most likely to affect future decisions: workarounds, load-bearing constraints, non-obvious dependencies, configuration decisions with downstream impact. Identified by the sending party before the handoff meeting.

List (minimum three entries required)

Comprehension Verified — High-Risk Areas

For each high-risk area: did the receiving party demonstrate understanding without prompting? Record the area, the receiving party's explanation (summarised), and whether comprehension was confirmed or a gap remains. Do not mark as confirmed unless the explanation was provided independently.

Area / Explanation summary / Confirmed or Gap

Load-Bearing vs. Adjustable Confirmed

Can the receiving party correctly identify which inherited elements are constraints and which are adjustable starting points? Yes / No. If No, list the items where this distinction was not established before confirming the handoff.

Yes / No + unresolved items if No

Comprehension Gaps Documented

Any area where the receiving party could not demonstrate understanding is listed here. The handoff is not confirmed until all gaps are resolved. This field should be empty on a confirmed handoff.

List (empty = all gaps resolved)

Handoff Confirmed

Both parties confirm that understanding has been transferred. The sending party confirms they have transferred reasoning, not just artifacts. The receiving party confirms they can operate on the inherited context without escalating to the sending party for routine questions.

Two confirmations required

Date Confirmed

The date on which both parties confirmed the handoff. Not the date artifacts were delivered — the date comprehension was verified.

Date

Open Items at Handoff

Known items that remain unresolved at the handoff point — not comprehension gaps, but outstanding decisions or dependencies. Listed with owner and expected resolution date.

List (optional)

Verification standard

The handoff is not confirmed by the delivery of a completed checklist. It is confirmed when the receiving party can answer "why does this work this way" for every high-risk area — without calling the sending party. A checklist where the comprehension verification fields were completed by the sending party on behalf of the receiving party has not closed the Transition Gap.

Supporting protocol: Handoff Verification Protocol →

Assumption Log

Rationale Field Standard

Handoff Verification Checklist

The Three Diagnostic Gaps

Assumption Gap

Rationale Gap

Transition Gap