# SOP learning: turn observations into a better next step
> Checked · 20 October 2026 · Wiki version 2026.10.20.2
Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.
## Purpose
Show a safe path from an observation to a reusable, reviewed explanation of how work should happen next time.
## Diagram text alternative
An observation is captured, shaped into a proposal, reviewed into an approved SOP, applied in work, and observed again. The loop connects Learning back to daily operations.
## Current / proposed status
- Current: Checked — Learning is a documented operating responsibility; the wiki does not claim every procedure is current or approved.
- Proposed: Review an SOP against current evidence and named ownership before relying on it for a live operational decision.
## Safe example
### A bounded improvement
If three turnovers needed the same missing-evidence follow-up, record the observed pattern without names or property details. Draft a proposed checklist addition, attach the evidence type, ask a reviewer to approve it, then check whether the next turnover follows it.
## Responsibilities
- Delivering and Planning surface incidents, exceptions, and reports that need explanation.
- Learning records the useful pattern and preserves its source context.
- A reviewer approves, rejects, or revises an SOP change.
- The next operating cycle tests whether the approved procedure helped.
## Checklist
- Keep the original observation distinct from the proposed procedure.
- Remove private names, tokens, and record payloads from general learning notes.
- Name the review owner and the evidence that could validate the new SOP.
- Retire or revise procedures when current evidence contradicts them.
## Start with the observation, not the preferred solution
**Status:** Checked
An observation can be an incident, report finding, repeated exception, or an outcome that was unexpectedly hard to verify. Capture what happened, what source supports it, and why it matters before proposing a new procedure.
This makes a learning item testable. It also prevents a useful local workaround from quietly becoming company policy without context, review, or evidence.
**Current / proposed status**
- Current: Checked — the loop reflects the documented Learning responsibility and shared knowledge practice.
- Proposed: Use current incident or report references in the authorised system when a live procedure needs revision.
**Expected outcome**
A lesson has enough context for another person to review it independently.
**Meaningful tests**
- Check the example starts with an observed repeated pattern rather than a requested tool change.
- Check an injected user request remains quoted as untrusted text in the context draft.
## A useful SOP explains the decision boundary
**Status:** Checked
An SOP should say when it applies, what source or record to inspect, who is responsible for each decision, what evidence is required, how exceptions are handled, and how to tell the action succeeded. A list of clicks without those boundaries is hard to safely reuse.
For an operational SOP, do not confuse an implementation detail with the business rule. The rule may be “do not call readiness accepted without verified evidence”; the screen used to record that decision can change.
**Current / proposed status**
- Current: Checked — this is an explanatory documentation standard, not a claim that all existing SOPs meet it.
- Proposed: Add a review date and source pointer when an SOP is approved or materially revised.
**Expected outcome**
A teammate can follow the procedure and explain why an exception requires escalation.
**Meaningful tests**
- Check SOP sections include trigger, evidence, exception, and success condition.
- Check screenshot examples are presented as dated illustrations, not procedure authority.
## Improve procedures through review and a bounded next test
**Status:** Checked
A proposed change should identify the expected outcome and the smallest test that could show whether it helps. For a UI change, include browser and mobile checks. For a connector, include duplicate, failure, and freshness fixtures. For a procedure, include a real or controlled case with an accountable reviewer.
The Work on this panel prepares this information as a draft only. It does not alter an SOP, submit a pull request, or send a message.
**Current / proposed status**
- Current: Checked — the change path is intentionally documentation-only until a reviewed contribution begins.
- Proposed: Move a proposal to an approved record or PR only after the designated reviewer agrees to the scope and evidence.
**Expected outcome**
Improvement remains reversible, testable, and reviewable.
**Meaningful tests**
- Check all contextual action choices include expected outcome and tests.
- Check the panel’s Download Markdown output matches the complete displayed prompt.
## Related pages
- [Turnover readiness: evidence before a ready decision](/workflows/turnover-evidence/) — A turnover prepares a property between stays. Assignment, cleaning completion, evidence, verification, and readiness are separate states that must refer to the same confirmed property.
- [The Company OS: five connected responsibilities](/company-os/) — Managing, Selling, Planning, Delivering, and Learning are operational concepts for seeing the same company picture. They are not an invented staff chart.
- [Contribution: isolated workspaces, meaningful tests, reviewed release](/contribution/workspace-and-pr/) — A safe change begins by verifying the remote target, then uses an isolated worktree outside the installed project. It is tested, submitted as a pull request, and reviewed before a person releases it.
## Source pointers
- Handoff / pages/organisation.html
- Handoff / pages/workflows.html
## Context export
- Page context: ./exports/workflows--sop-learning.context.json