Evidence
What was observably true, with a source and a date.
The model reached 61 percent precision in the eight-week pilot window.
Framework Mechanic
Organizations do not learn because people attend retrospectives. They learn when evidence changes how the organization operates.
Most organizations review what happened and still repeat it. The review produces a narrative, not a change. Nothing in the operating model is different afterwards, so the same failure returns with new names attached.
A lesson is not retained until it changes the operating model, or until an accountable authority documents why no change is required.
That single sentence is the test. If nothing changed and no accountable authority wrote down why nothing needed to change, the organization did not learn. It remembered.
The Failure
Why the same lesson keeps coming back.
The loop below is not a meeting format. It is the sequence that breaks, one stage at a time, when an organization reviews something and changes nothing.
- 01
Evidence disappears
What was actually known at the time is never captured. Weeks later the team argues from memory, and the memory has already been edited by the outcome.
- 02
Assumptions become remembered as facts
Something the team believed but never verified gets retold until it sounds settled. Nobody can point to when it was checked, because it never was.
- 03
Judgment is not preserved
The call someone made, the alternatives they weighed, and how confident they were all vanish. Only the decision survives, stripped of the reasoning that would let anyone challenge it.
- 04
Authority is unclear
It is never recorded who actually had the right to decide or act. Accountability spreads across a group until it belongs to no one.
- 05
Action starts without a defined expected outcome
Work begins with no stated target. Without a prediction made in advance, no result can later be called a success or a failure.
- 06
Results are not measured against the original expectation
The outcome is compared to whatever now seems reasonable rather than to what was predicted, so hindsight quietly rewrites the standard.
- 07
Operating model artifacts do not change
No rule, owner, standard, or process is different afterwards. The lesson lives in a document nobody consults while the operating model keeps producing the old behaviour.
- 08
The organization repeats the lesson
A different team meets the same failure, runs the same review, and produces the same narrative. This is the loop closing on itself instead of on the operating model.
The Mechanic
Seven stages, in a fixed sequence.
Each stage answers one question and produces one required output. Skip a stage and the loop cannot close, because the next stage has nothing to work from.
Select a stage to see the question it answers and what it must produce. The sequence is fixed: a stage cannot be completed while an earlier one is empty.
Stage 1 of 7
Evidence
- The question it answers
- What happened, and what was known at the time?
- What it must produce
- Sources, dates, facts, limitations, and missing information.
- Where it lands in the framework
- Information Ecology
- Where the output is recorded
- Loop record, Evidence stage fields
Read all seven stages as a list
Stage 1
Evidence
What happened, and what was known at the time?
Required output. Sources, dates, facts, limitations, and missing information.
Stage 2
Judgment
How was the evidence interpreted?
Required output. Assumptions, interpretation, alternatives, confidence, and the named person exercising judgment.
Stage 3
Authority
Who had the right to decide or act?
Required output. Named authority holder and the relevant decision right.
Stage 4
Action
What changed, who acted, and what result was expected?
Required output. Action, accountable executor, date, target, and the expected outcome recorded before execution.
Stage 5
Outcome
What actually happened?
Required output. Measured result, unintended effects, and evidence quality.
Stage 6
Revision
What should change in the operating model?
Required output. An approved revision, or a documented decision not to revise.
Stage 7
Retention
Where will the lesson live and influence future work?
Required output. Versioned canonical artifact, owner, effective date, and review date.
The Distinctions
Four things that must never collapse into one story.
Weak operating models collapse all four into one sentence that starts with we learned that. Once they are collapsed, the reasoning cannot be audited, the assumption cannot be tested, and no one can tell whether the conclusion was earned or assumed.
Assumption
What was believed but never verified.
The team believed the activity data in the CRM was current. Nobody had checked.
Interpretation
What the evidence was taken to mean.
Precision collapsed only on records with stale activity dates, so this reads as a data problem rather than a model problem.
Judgment
The call a named person made, with alternatives and confidence recorded.
The data lead decided to fix the data standard before retraining, and set aside the option of replacing the model.
Across The Framework
Where each stage lands.
The loop is a cross-layer mechanism. It shows how the existing layers work together over time. It is not an additional layer, and it does not replace any of them.
| Stage | Framework layers | Recorded in |
|---|---|---|
| 1. Evidence | Information Ecology | Loop record, Evidence stage fields |
| 2. Judgment | Decision Architecture | Loop record, Judgment stage fields |
| 3. Authority | Identity & Incentives | Loop record, Authority stage fields |
| 4. Action | Platform Structure, Communication Architecture | Loop record, Action stage fields |
| 5. Outcome | Governance Architecture, Information Ecology | Loop record, Outcome stage fields |
| 6. Revision | Decision Architecture, Governance Architecture | Operating Model Revision Record |
| 7. Retention | Information Ecology, The layer that owns the revised artifact | Loop record, Retention stage fields, and the learning ledger |
In Practice
How to run the loop on a real event.
Steps 1 through 7 fill one loop record. Step 8 and step 9 produce a revision record, or a documented decision that no change is required. Step 10 puts the closed loop on the ledger so recurrence becomes visible.
- 1
Select a meaningful event, decision, failure, success, or exception.
Learning Loop Record
- 2
Preserve what was known at the time.
Learning Loop Record
- 3
Separate evidence from assumptions and interpretations.
Learning Loop Record
- 4
Name who exercised judgment.
Learning Loop Record
- 5
Confirm who had authority.
Learning Loop Record
- 6
Record the action, baseline, target, expected outcome, and review date before execution.
Learning Loop Record
- 7
Measure the actual outcome.
Learning Loop Record
- 8
Decide what must change.
Operating Model Revision Record
- 9
Update the canonical operating model artifact.
Operating Model Revision Record
- 10
Retain the record and monitor recurrence.
Learning Ledger
Worked Example
One loop, carried all the way to a retained change.
A pilot that missed its target, run through all seven stages. Every fact below is rendered from the governed record, not written for this page.
Illustrative and non-customer. Illustrative, non-customer worked example. Not a governed Knowledge Object. It instantiates ko.operating_models.organizational-learning-loop-record v0.1.1.
- Company profile / scale
- scaling (~450 people)
- Current stage
- Retention
- Record ID
- OLL-2026-014
- Status
- Closed
- Terminal state
- RETAINED_REVISION
- Title
- Customer-churn-prediction pilot missed accuracy target
- Trigger type
- Pilot
- 1
Evidence
What happened, and what was known at the time?
Sources: 8-week pilot logs, model evaluation report, a one-off customer-data quality audit, CRM export samples. Facts: the churn model reached 61% precision against a 80% target; 22% of the training rows had a stale or missing "last activity" date; two product lines had no usable engagement signal. Limitations: single training window, no holdout from the enterprise segment. Missing information: no baseline for how a human analyst performed on the same accounts.
- 2
Judgment
How was the evidence interpreted?
Named judgment holder: Dana R., Data Lead. Assumption (flagged as an assumption, not a fact): the sales team believed the CRM activity data was current. Interpretation: the miss was primarily a data-quality problem, not a model-architecture problem, because precision collapsed specifically on the accounts with stale activity dates. Alternatives considered: "the model is wrong" (set aside: precision was strong where data was clean) and "the target was unrealistic" (set aside: clean-data cohort hit 79%). Confidence: medium-high.
- 3
Authority
Who had the right to decide or act?
Named authority holder: Priya S., VP of Product. Relevant decision right: authority over the product analytics operating model and the customer-data standard, per the ownership model.
- 4
Action
What changed, who acted, and what result was expected?
Action: pause the churn model in production; commission a customer-data ownership and freshness standard before any re-training. Accountable executor: Dana R. Date: week 9. Target: raise usable-activity-data coverage from 78% to 95% within one quarter. Expected outcome, recorded before execution: with clean data, precision should reach the 80% target on re-training; if it does not, the model architecture becomes the suspect.
- 5
Outcome
What actually happened?
Measured result: after the data standard, activity-data coverage reached 93% (short of 95%); on re-training, precision reached 82%, clearing the target. Unintended effect: the data-quality work surfaced a duplicate-account problem that was inflating churn counts across all reporting, not just the pilot. Evidence quality: high (measured on a fresh holdout including the enterprise segment).
- 6
Revision
What should change in the operating model?
Approved and retained revision: adopt a Customer Data Ownership and Freshness Standard (named owner per customer-data domain, required freshness windows, and validation at CRM intake), effective start of the next quarter, retained in the Northwind operating-model guide (this became Operating Model Revision Record OMR-2026-031). This retained revision sets the loop's terminal state to RETAINED_REVISION. A scoped, item-level no-change was recorded for a separately evaluated area, "retire churn prediction or switch model vendors?", with authority Priya S., rationale (the failure was data, not model), and a review date at the start of next quarter. That scoped no-change does not create a second terminal state.
- 7
Retention
Where will the lesson live and influence future work?
Versioned canonical artifact: Northwind operating-model guide v4, section "Customer data standards." Owner: Priya S. Effective date: start of next quarter. Review date: one quarter out. Supersedes: the prior informal "keep the CRM updated" guidance. The standard is now a required input to the next three planned AI use cases.
Terminal state
RETAINED_REVISION
A loop has exactly one terminal state. This loop retained 1 revision, so its terminal state is RETAINED_REVISION. The scoped no-change decision below covers a separately evaluated area. It does not create a second terminal outcome, and it does not make this loop CLOSED_NO_REVISION.
CLOSED_NO_REVISION would apply only if no revision had been retained.
Retained revision
- OMR-2026-031, the Customer Data Ownership and Freshness Standard (revision category: information), retained in Northwind operating-model guide v4.
Scoped no-change decision
"Retire churn prediction or switch model vendors?" resolved as no-change
- Accountable authority
- Priya S. (VP of Product)
- Rationale
- the pilot's failure was data quality, not the model; the clean-data cohort already cleared the target
- Review date
- start of next quarter (with the next deflection/accuracy reading)
Measurement
Three measures, and a warning.
Three measures, and only three. Counting how many records were filled in tells you about compliance, not about learning.
OL-01
Retained Learning Rate
completed loops with a retained revision / completed loops
Shows how often a closed loop actually changed the operating model rather than ending in a narrative.
Valid closures with no revision must stay visible in the denominator. A legitimate documented decision not to change is a real outcome, and hiding it turns this measure into a target to be gamed.
OL-02
Learning Cycle Time
date closed - date opened
Shows how long the organization takes to convert an event into a retained change. Long cycles usually mean authority or evidence is missing, not that people are slow.
Optional segments
- Evidence to judgment
- Judgment to action
- Action to outcome review
- Outcome review to retention
OL-03
Repeat Issue Rate
repeat reviewed events linked to a prior operating model weakness / total reviewed events
Shows whether retained changes are holding. A rising rate means the loop is closing on paper while the underlying weakness stays in place.
Template completion is not a success measure.
Starter Pack
Take the records with you.
The three records are structured canonical definitions in JSON, generated from the governed source library rather than written for this page. The template is a blank CSV you can use today.
JSON
Organizational Learning Loop Record
The structured canonical record defining what one trip through the loop must capture at each stage.
Open one record per event you review.
- Version
- 0.1.1
- Schema
- 1.1.0
JSON
Operating Model Revision Record
The structured canonical record defining how a change to the operating model is described, owned, and dated, including a documented decision that no change is required.
Produce one when the loop reaches its revision stage.
- Version
- 0.1.1
- Schema
- 1.1.0
JSON
Organizational Learning Ledger
The structured canonical record defining the ledger that carries every closed loop, its terminal state, and its recurrence signal.
Read this to understand the columns before you start tracking.
- Version
- 0.1.1
- Schema
- 1.1.0
CSVStart here
Organizational Learning Ledger Template
A blank spreadsheet with the ledger's canonical columns as its header row. This is the immediately usable operational tracker.
Open it in a spreadsheet and add one row per loop. Start here.
- Version
- 0.1.1
- Schema
- 1.0.0
Provenance
These files are generated from the governed source library and copied here without modification. Every one carries a sha256 checksum that is verified whenever the snapshot is validated.
- Canon
- 0.5.0 @ d4d36e2
- Source
- lpm-knowledge-objects @ d1494c1
- Export schema
- web 1.1.0, example 1.0.0
- Generated
- 2026-07-24
Where this fits
The loop only works on an operating model somebody can see. If ownership, decision rights, and information flow are still unclear, start by finding out where the model is weakest, then run the loop against what you find.