Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Workflows

SOP learning

Checked

Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
SOP learning: turn observations into a better next step diagramAn 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.Observation — SOP learning: turn observations into a better next stepObservationCapture pattern — SOP learning: turn observations into a better next stepCapture patternReview proposal — SOP learning: turn observations into a better next stepReview proposalApproved SOP — SOP learning: turn observations into a better next stepApproved SOPApply & observe — Turnover readiness: evidence before a ready decisionApply & observe
A learning loop keeps the evidence, review, and next observation connected.Solid · information flow
Read the diagram as text

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.

  • Observation → SOP learning: turn observations into a better next step
  • Capture pattern → SOP learning: turn observations into a better next step
  • Review proposal → SOP learning: turn observations into a better next step
  • Approved SOP → SOP learning: turn observations into a better next step
  • Apply & observe → Turnover readiness: evidence before a ready decision
What it does

Show a safe path from an observation to a reusable, reviewed explanation of how work should happen next time.

Responsibility

Delivering and Planning surface incidents, exceptions, and reports that need explanation.

Next step

Keep the original observation distinct from the proposed procedure.

Start with the observation, not the preferred solution

Checked

An observation can be an incident, report finding, repeated exception, or an outcome that was unexpectedly hard to verify.

Read the details

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
Checked — the loop reflects the documented Learning responsibility and shared knowledge practice.
Proposed next state
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.
Checks to include when changing this section
  • 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

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.

Read the details

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
Checked — this is an explanatory documentation standard, not a claim that all existing SOPs meet it.
Proposed next state
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.
Checks to include when changing this section
  • 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

Checked

A proposed change should identify the expected outcome and the smallest test that could show whether it helps.

Read the details

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
Checked — the change path is intentionally documentation-only until a reviewed contribution begins.
Proposed next state
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.
Checks to include when changing this section
  • Check all contextual action choices include expected outcome and tests.
  • Check the panel’s Download Markdown output matches the complete displayed prompt.

Apply with care

A concrete safe example

Example, responsibilities & checklist

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

  1. Keep the original observation distinct from the proposed procedure.
  2. Remove private names, tokens, and record payloads from general learning notes.
  3. Name the review owner and the evidence that could validate the new SOP.
  4. Retire or revise procedures when current evidence contradicts them.
Expected outcome

A repeatable issue becomes a reviewable change to shared knowledge rather than an undocumented workaround.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / pages/organisation.html
  • Handoff / pages/workflows.html
Page MarkdownPage context JSON