Establishing Append-Only Decision and Deviation Logs

Good governance is not only about making a decision; it is about preserving the conditions under which that decision was made. In the previous lesson, you learned to distinguish evidence from assumptions and to calculate the share of load-bearing claims that remain unverified. This lesson turns that review into a durable record.

You will initialize two related, append-only artifacts:

• the Decision Log, which records every gate decision and the evidence, thresholds, opposing cases, and accountable people behind it;
• the Deviation Log, which records every material departure from the standard process, including departures that seem sensible in the moment.

Together, they make Phase 17 calibration possible. Months later, the team must be able to reconstruct not merely what it chose, but what it believed, what evidence it had, what the strongest objection was, and whether it followed its own process.

---

Why two logs instead of one?

A Decision Log answers:

What did we decide at a gate, based on what threshold and actual result?

A Deviation Log answers:

Where did the way we worked differ from the standard, and what happened because of that?

They are related, but mixing them creates confusion. A gate decision may be fully compliant with the process and still be a STOP. For example, failing the Phase 3 unprompted-recognition threshold is not a deviation; it is the process working as designed.

Conversely, a team might reach a PROCEED decision while departing from the standard, such as allowing an unplanned cap extension. That extension must be visible as a deviation even if everyone felt it was justified.

Artifact	Unit of record	Main question	Typical timing
Decision Log	One row per gate	Did the run meet the precommitted conditions for this decision?	At every gate
Deviation Log	One row per departure	Did work differ from the standard, and why?	As soon as the departure occurs or is discovered

The supplied Decision Log Template shows a useful general structure: decision ID, date, description, status, rationale, impact, decision-maker, affected stakeholders, consultation, and follow-up actions. The Product Factory needs a stricter version because its decisions are numeric, adversarial, and intended for later calibration.

---

Append-only means preserving history, not freezing learning

“Append-only” does not mean that the team can never change its mind. It means the team never quietly rewrites what it believed at the time.

Suppose a Phase 3 gate is recorded as STOP because only seven of twelve interviewees recognized the problem unprompted, against a threshold of eight. Two weeks later, a new market change gives the idea a genuinely different basis for investigation. The correct action is not to edit the old entry from STOP to PROCEED. Instead:

1. Keep the original gate record unchanged.
2. Open a new run at Phase 0.
3. Link the new run to the earlier stopped run.
4. State precisely what changed and why the new investigation is warranted.

This preserves the signal needed for calibration. If the original decision is later judged a false negative, Phase 17 can examine the actual threshold and evidence rather than a tidied-up account of events.

The same principle applies to corrections. If a typo or broken link appears in a log entry, a narrowly marked correction is reasonable. If the correction changes a threshold, evidence figure, rationale, decision, or named decider, append a correction record that references the original entry. Do not overwrite the original.

The operating rule is simple:

The current decision may change. The historical record of prior decisions does not.

---

The Decision Log: the minimum viable gate record

A generic decision register is often too vague for this process. “Approved” in a status field tells a future reviewer almost nothing. Approved against which criteria? With what results? Who made the STOP case? Was the evidence sufficiently sourced?

Each gate record should therefore contain six groups of information.

Group	Required fields	Why it matters
Identity	Decision ID, run ID, date and time, phase and gate, lane	Makes records findable and comparable across runs
Precommitment	Exact threshold, cap, and evidence cutoff	Shows the standard existed before evidence was interpreted
Actual evidence	Actual figures, evidence references, assumption-share result	Allows the gate to be audited and later calibrated
Opposing cases	STOP case first; PROCEED case second	Protects against advocacy disguised as review
Authority	Owner, Challenger, decider, consulted people	Makes decision rights visible
Outcome	Decision, rationale, required next action, successor link if relevant	States what happened without ambiguity

A practical Decision Log schema

You can implement this as a protected spreadsheet, a database table, or Markdown records in version control. Initially, a spreadsheet is often sufficient if it has controlled edit rights and a reliable revision history.

Field	What to record
decision_id	Unique chronological ID, such as DL-024
run_id	The product-factory run, such as RUN-2026-004
recorded_at	Date and time the gate was decided
phase_gate	For example, Phase 3: Does the problem exist?
lane	S, M, or L
decision_status	PROCEED, SIMPLIFY, PIVOT, PARK, STOP, GO, or DELAY, as applicable to the gate
threshold_version	The precommitted threshold set and its effective date
thresholds	The exact numeric conditions that had to be met
actual_figures	The observed counts, costs, test results, or other measures
evidence_references	Claim IDs, interview IDs, data-query names, or URLs supporting the actual figures
assumption_share	Numerator, denominator, percentage, and unresolved load-bearing assumptions
stop_case	The Challenger’s strongest honest argument for stopping
proceed_case	The Owner’s strongest honest case for continuing
owner	Named accountable person doing the work
challenger	Named person who authored or reviewed the STOP case
decider	Person with standing to make the final decision
consulted	People consulted but not necessarily responsible for the decision
rationale	Why the decider chose the stated outcome
next_action	Specific required action, owner, and due date where needed
links	Idea Record, Evidence Pack, Build Spec, deviation entries, or successor run
supersedes_or_superseded_by	Blank unless a later record formally replaces the decision

The most important fields are the ones teams are tempted to omit under time pressure: the threshold, actual figures, STOP case, and decider. Without them, a row is a meeting note, not a decision record.

Keep the threshold and actual result separate

A gate cannot be calibrated if the record says only “validation was positive.” Store the target and outcome separately.

For example, a Phase 3 record might state:

Item	Recorded value
Threshold	At least 12 ICP-matched conversations; at least 8 unprompted recognitions; at least 3 participants with a paid or two-hour weekly workaround; at least 1 abandoned alternative; at least 3 stated-value figures
Actual figures	12 ICP-matched conversations; 7 unprompted recognitions; 4 workaround cases; 1 abandoned alternative; 3 stated-value figures
Provenance result	2 load-bearing assumptions out of 9 load-bearing claims, or 22.2%
Decision	STOP

This is a STOP even though most figures passed and the provenance rule passed. Gates are not weighted scorecards unless the process explicitly says they are. The missed unprompted-recognition threshold is enough.

Write the STOP case before the PROCEED case

The Product Factory gives the Challenger a structural role: write the strongest honest case for STOP before the case for PROCEED is written. This sequencing matters because once a team begins explaining why it wants to continue, contrary evidence often becomes “manageable,” “interesting,” or “something to test later.”

A useful STOP case is concrete and testable:

The run fails the unprompted-recognition threshold: only 7 of 12 ICP-matched participants described the problem before prompting, against a precommitted minimum of 8. The other passed checks cannot compensate because this threshold tests whether the problem is naturally salient rather than merely agreeable when described. Continuing would violate the gate rule. [data: p3-unprompted-tally-v1]

A weak STOP case is vague or performative:

There are some risks, but the opportunity seems promising.

Likewise, the PROCEED case must engage with the actual evidence rather than simply restate enthusiasm:

The workaround and stated-value thresholds passed, suggesting a costly problem among a subset of the target population. However, the missed unprompted-recognition threshold requires STOP under the current Lane M gate. A smaller, more narrowly defined problem may justify a new Lane S run if a specific change in scope is documented.

Notice that a good PROCEED case can still conclude that the gate requires STOP. The purpose of the two cases is honest reasoning, not balanced advocacy.

---

An example gate record

Here is a compact but complete Phase 3 Decision Log entry. It is intentionally written so that a Factory Keeper can revisit it after launch or after a later re-entry.

Field	Example entry
Decision ID	DL-024
Run ID	RUN-2026-004
Gate	Phase 3: Does the problem exist?
Lane	M
Thresholds	12 ICP-matched conversations; 8 unprompted recognitions; 3 revealed-cost cases; 1 abandoned alternative; 3 stated-value figures; load-bearing assumption share at most 30%
Actual figures	12 conversations; 7 unprompted recognitions; 4 revealed-cost cases; 2 abandoned alternatives; 3 stated-value figures; 2 assumptions among 9 load-bearing claims, 22.2%
Evidence references	p3-participant-audit-v1, p3-unprompted-tally-v1, p3-workaround-tally-v1, int-019, p3-value-tally-v1
STOP case	The unprompted-recognition result is below the precommitted minimum. Participants often agreed after the problem was named, but that is not evidence of naturally experienced pain. The run must stop at the time-box.
PROCEED case	Workaround cost and stated value meet their thresholds, indicating a potentially valuable subgroup. However, those results do not override the failed recognition threshold. Consider a new, narrower Lane S run only if the ICP or problem statement materially changes.
Owner	Priya Shah
Challenger	Mateo Green
Decider	Product Portfolio Lead
Decision	STOP
Rationale	One required numeric condition failed. No extension or additional research is authorized within this run.
Next action	Finalize the Idea Record and preserve links to the Evidence Pack. Review only if a new trigger justifies a new Phase 0 intake.
Recorded at	2026-10-17, 16:00

The entry does not say “the idea was bad.” It says something narrower and more useful: this run did not satisfy its precommitted conditions for further investment.

---

Where the logs should live

The logs must be easy to use at the moment a decision is made and easy to find months later. A sophisticated system that people bypass is worse than a simple shared record that is consistently maintained.

For a software-backed Product Factory, version-controlled storage is a strong default. It provides an edit history, access control, review workflow, durable links, and a natural association with the implementation work. For a cross-functional team that cannot work directly in a code repository, use a controlled workspace with an owner, stable links, and revision history.

A practical starting layout might look like this:

product-factory/
  runs/
    RUN-2026-004/
      idea-record.md
      evidence-pack.md
      build-spec.md
      decision-log.csv
      deviation-log.csv
      source-register.md
  indexes/
    active-runs.md
    closed-runs.md

The exact tooling is secondary. The rules are not:

• Every run has a stable identifier.
• Every gate record has a unique identifier.
• Records have a visible author and time.
• Final gate records are not silently edited.
• Evidence links resolve to retrievable underlying material.
• A later entry can correct, supersede, or re-open work only by referencing the earlier entry.

---

The Deviation Log: evidence about the process itself

A deviation is a material difference between what the standard required and what actually happened. It is not automatically misconduct, failure, or bureaucracy. It is data.

For example, the following are deviations:

• The Phase 3–6 time-box was extended by two days.
• The Owner also acted as Challenger.
• Market research was conducted without a written decision-trigger statement.
• A Lane M build estimate exceeded the cap, but the team continued without cutting scope.
• A gate was decided without a complete STOP case.
• A committed run was accidentally included in kill-rate reporting.

The following are not deviations:

• A Phase 4 market analysis was skipped because no later decision depended on it. Skipping is compliant with the standard.
• A Phase 3 gate resulted in STOP because its numeric threshold was missed.
• The team chose Lane L because the Phase 0 risk screen required it.
• A later run began after a stopped run because the triggering conditions genuinely changed and the new run was logged.

The Deviation Log should preserve the before-and-after facts. It must never become a way to retroactively bless exceptions.

A practical Deviation Log schema

Field	What to record
deviation_id	Unique ID, such as DEV-011
run_id	The affected run
identified_at	Date and time observed
phase	Where it occurred
standard_expected	Exact process rule, cap, or role requirement
actual_departure	What happened instead
reason_given_at_the_time	Constraint, error, emergency, missing capacity, deliberate exception, or unknown
impact_on_decision	Whether it affected evidence quality, budget, timing, authority, or calibration
related_decision_id	Link to the affected gate decision, if any
recorded_by	Person entering the deviation
acknowledged_by	Owner, Challenger, Factory Keeper, or decider as appropriate
immediate_action	Correct now, accept temporarily, stop the run, or escalate
calibration_note	Blank during the run; completed in Phase 17 if a pattern emerges

Example: logging a cap extension honestly

Field	Example entry
Deviation ID	DEV-011
Run ID	RUN-2026-006
Phase	Phase 10: Build
Standard expected	Lane M build time-box is a maximum of three weeks. At the cap, test what exists rather than extending the cap.
Actual departure	Build continued for four additional working days to complete a dashboard feature.
Reason given at the time	Team believed the dashboard was necessary for user testing.
Impact on decision	The build cap no longer constrained scope; Phase 11 results may not be comparable with other Lane M runs.
Related decision	DL-031
Immediate action	Record the extension; remove the dashboard from the core-hypothesis claim unless the Build Spec maps it to a hypothesis; Factory Keeper reviews the pattern at Phase 17.

The correct response is not to rewrite the run as though it remained within its cap. The deviation may reveal that the lane cap was unsuitable, that Phase 8 scope discipline failed, or that the team had treated a nonessential feature as necessary. Phase 17 needs the unvarnished record to distinguish among those possibilities.

---

A short operating ritual

Initialize both logs at Phase 0, alongside the Idea Record. Do not wait until the first difficult decision; by then, history has already begun to disappear.

Use this minimal ritual throughout the run:

1. Open the run. Create the run ID, lane, Owner, Challenger, intended decider, Decision Log, and Deviation Log.
2. Precommit the gate. Before gathering evidence, record the applicable threshold values, lane caps, and evidence cutoff.
3. Maintain evidence links. As evidence is gathered, link claim IDs and source records to the relevant prospective gate.
4. Write the STOP case first. The Challenger drafts it before the Owner’s PROCEED case.
5. Record actual figures. Copy the observed counts, costs, and assumption-share calculation exactly; do not translate them into vague summaries.
6. Name the decider and outcome. Record the person, time, decision, rationale, and required next action.
7. Log departures immediately. If the team deviates from a standard rule, add a Deviation Log entry rather than relying on memory.
8. Protect final entries. Use version history, locked rows, or review controls so that changes create a visible new record.

A decision log that is completed at the end of a project is usually a reconstruction of what people now wish they had believed. A useful log is created at the point of uncertainty, before the outcome is known.

---

Key takeaways

The Decision Log and Deviation Log are the Product Factory’s institutional memory.

• Create one append-only Decision Log row per gate, with the exact threshold, actual figures, evidence references, assumption-share result, STOP case, PROCEED case, decider, decision, and next action.
• Preserve gate history. Correct or reverse a material decision by appending a linked record or opening a new run, never by silently rewriting the past.
• Require the STOP case first so that the Challenger’s argument is not weakened by an already-established narrative of continuation.
• Use a separate Deviation Log to record departures from roles, caps, sequencing, evidence rules, or other process standards.
• Treat deviations as evidence about the process. A recurring deviation may indicate that the standard needs revision at Phase 17.
• Store the logs somewhere searchable, durable, access-controlled, and easy to use during real work.

Next, you will begin the evidence module by defining an initial ideal-customer profile and a recruitment plan for 6–11 relevant participants, while being explicit about which Lane M claims that initial sample cannot yet support.