Work as imagined vs work as done: why records of real practice beat SOPs alone

What do work as imagined and work as done mean?#

Work as imagined is how managers, auditors and procedure writers believe a task is performed; work as done is how the people doing the task actually perform it. The distinction comes from safety science and resilience engineering, where researchers noticed that procedures describe an ideal world while front-line staff deal with the real one.

The gap is not a sign of a badly run company. Procedures are written in advance, for typical cases, often by people who are not on the job site, warehouse floor or support queue. Real work involves missing parts, unclear customer requests, system outages and time pressure, and skilled staff adjust.

Operations leaders feel this gap daily. The dispatch SOP says one thing, and the dispatcher's notes on a busy morning show another. Both are true descriptions of the business.

Side by side: SOP steps vs recorded work#

Side-by-side comparisons make the gap concrete. The examples below are illustrative and drawn from several kinds of operating companies, from trades and software to manufacturing.

Why the gap is not just non-compliance#

The gap between procedure and practice is not just non-compliance, because some deviations are better than the procedure. A technician who checks a known failure point first, against the SOP's order, may be applying experience the SOP never captured.

Useful analysis sorts deviations into three groups. Improvements should be written into the next SOP version. Workarounds point to a broken tool, a missing part or a bad handoff that should be fixed at the source. Risks, where a control was skipped and the outcome suffered, call for retraining or a hard stop in the system.

Over time, small accepted deviations can add up to procedural drift, where practice moves far from the document without anyone deciding it should. Comparing records with the SOP is how drift gets caught.

Why AI developers want both the SOP and the records#

AI developers want both the SOP and the records because each answers a different question. The SOP states the rule an agent should know. The records show how competent people applied, bent or overrode that rule, and what happened next.

A procedure on its own often resembles a public template, so it adds little a developer could not write. Records of real practice are specific to the business and much harder to reproduce. Together they let an evaluator check whether an agent follows policy where it should and handles exceptions the way skilled staff did.

Recorded outcomes complete the picture. A deviation followed by a callback, a credit memo or an NCR teaches something different from a deviation followed by a satisfied customer.

Which records capture work as done?#

Records that capture work as done are the ones written during or right after the work, by the people doing it. Formal reports written weeks later tend to drift back toward the procedure.

• 1Technician notes and job comments in ServiceTitan, Housecall Pro or Jobber.
• 2Internal notes and macros used on tickets in Zendesk or Intercom.
• 3NCRs, CAPAs and deviation reports in a QMS or an ERP quality module.
• 4Change orders, RFIs and field reports in Procore or similar tools.
• 5Exception logs and carrier claims in a WMS or TMS.
• 6Code review comments and incident retrospectives in GitHub and Confluence.
• 7Slack or Teams threads where staff ask each other how to handle an odd case.

Illustrative: a manufacturer compares its NCR procedure with its records#

Illustrative: a fictional contract manufacturer of machined parts keeps its nonconforming material SOP in its QMS and logs NCRs in the ERP. The SOP says quality decides every disposition. The NCR records show that many use-as-is decisions were actually made by a manufacturing engineer and confirmed by quality afterward by email.

The COO reviewed a sample of NCRs against the SOP and sorted the gaps. The engineering review turned out to be an improvement, because engineers had the drawings and customer tolerances in hand. Late quality confirmations were a risk.

The company issued a new SOP version adding the engineering review step and a system hold until quality signs off, and kept the old version with its effective dates. In its data inventory, the NCR history is now described alongside both SOP versions, so anyone reading the records knows which rule applied when. Customer-owned drawings stay out of scope.

How to measure the gap in your own operation#

Measuring the gap is a small, repeatable exercise, not a consulting project. Start with one process and widen only if the first pass is useful.

Move to a second process only after the first SOP update is in place. The comparison works best as a habit tied to each revision cycle rather than a one-time study.

• 1Pick one process with a written SOP and a system that records the work.
• 2Pull a sample of recent records, including some exceptions.
• 3Walk each record against the SOP steps and note every difference.
• 4Sort the differences into improvements, workarounds and risks.
• 5Update the SOP as a new version, with the reason, and keep the old one.

How SourceX looks at procedures and practice#

SourceX looks for exactly this pairing. In the Supply step of the SourceX five-step transaction, the inventory lists procedure documents and the operational records done under them, described as metadata only, so nothing is shared at that stage.

The SourceX Enterprise Data Value Framework favors records with domain expertise and human-generated signal, and discounts material that is easy to reproduce, which is why procedures alone rarely make a package. When records proceed, the SourceX Evidence Packet records permitted use and provenance, including which SOP versions accompany which records.