Follow-Through Checkback¶
Feedback ritual — instantiates Knowing-Doing Bridge Design
Circles back after the fact to check whether the action actually happened — measuring the doing, not the knowing — and flags drift when a once-reliable action starts slipping.
A Follow-Through Checkback is a scheduled return to the scene of an agreed action to verify that it was actually done — not that it was understood, promised, or scheduled, but done, on the evidence. Its defining move is that it measures execution after the fact and feeds that reading back into the system, which makes it the mirror image of the anticipatory bridges: rehearsal and cueing act before the moment, the checkback acts after it. It exists because the most common failure of a knowing-doing system is silent: everyone agreed, everyone meant to, and nobody noticed the action quietly didn't happen. The checkback closes the loop by turning "we assume it got done" into "we looked, and here is the action evidence," and it watches over time so a bridge that worked at launch doesn't rot unnoticed.
Example¶
A software team ends every incident review with a list of action items: add the missing alert, fix the retry logic, document the runbook. Everyone knows the items matter and everyone intends to do them — and, historically, half quietly evaporated once the next fire started. The team installs a Follow-Through Checkback: two weeks after each review, a standing agenda slot walks the previous list and asks, for each item, "show the evidence it's done" — the merged pull request, the live alert, the updated page — not "is it on track?" Items with no evidence are surfaced, reassigned, or explicitly killed. Over months the checkback also reads the pattern: it notices that alert-related items keep slipping and that completion rates dip every quarter-end, which is drift the team can now correct at the source. The mechanism changed nothing about what the team knew; it made the doing observable, and kept it observable as conditions shifted.[n1]
How it works¶
- Return on a schedule. Set a fixed later moment to revisit each committed action — a standing slot, not an ad-hoc "did you get to that?"
- Demand action evidence. Accept only observable proof the behavior occurred (the artifact, the log, the changed metric), never a restated intention or a "yes, on it."
- Feed the reading back. Route each result to a response: done and closed, not-done and reassigned, or no-longer-needed and killed — so the check drives action rather than just recording failure.
- Watch the trend, not just the instance. Track completion over time and by type, so a rising slip-rate or a recurring category is caught as drift before it becomes normal.
Tuning parameters¶
- Check cadence — how soon and how often the callback fires. Sooner catches drift earlier and costs more attention; too rare and the loop goes slack.
- Evidence bar — what counts as proof, from a self-report to a verified artifact. A higher bar is harder to game and heavier to administer.
- Response coupling — how tightly a missed item triggers reassignment or escalation. Tight coupling drives follow-through; too tight breeds defensive reporting.
- Trend window — how much history the drift-watch spans. Longer windows separate noise from real decay but react more slowly.
- Blame temperature — whether misses are treated as design signal or personal fault. Cooler framing gets honest evidence; hot framing gets gamed numbers.
When it helps, and when it misleads¶
Its strength is that it catches the silent failure — the agreed action nobody notices didn't happen — and it is the only bridge that keeps a system honest over time, so a fix that worked at launch is caught when it starts to erode. It converts intention into a checkable fact and makes drift visible while it is still small.
Its failure mode is measuring the wrong thing: a checkback that accepts stated intent or attendance as evidence certifies follow-through that isn't there, and one run hot enough to punish misses trains people to report completion rather than achieve it — the metric detaches from the behavior. It is also purely diagnostic downstream; it reveals that action failed but installs no bridge, so a team that only checks back, without ever fixing the barrier the misses reveal, simply documents the same failure on a schedule. The guarding discipline is to insist on real action evidence, keep the temperature low enough for honest reporting, and treat each miss as a pointer back to the doing channel that needs a bridge, not merely a box to re-open.
How it implements the components¶
Follow-Through Checkback fills the after-the-fact side of the bridge — the loop that keeps it honest:
action_feedback_loop— it is the loop: it observes whether the action occurred and routes that reading back into reassignment, closure, or escalation.maintenance_drift_monitor— by tracking completion across time and category, it detects when a once-reliable action begins to slip, before the erosion becomes the new normal.
It assigns no responsible person — the accountability_or_support_partner that owns each action is Named Action Owner Protocol's component — and it provides no easy restart after a lapse, since the recovery_pathway for getting a stalled action moving again belongs to Tiny First-Step Design.
Related¶
- Instantiates: Knowing-Doing Bridge Design — it is the bridge's feedback loop, measuring the doing and watching for drift.
- Consumes: Named Action Owner Protocol supplies the owner each checkback holds to account.
- Sibling mechanisms: Named Action Owner Protocol · Tiny First-Step Design · Action Barrier Walkthrough · Activation-Energy Reduction Pass · Default Path Redesign · Point-of-Action Prompt · Feedforward Action Rehearsal · Social Permission Script · Implementation Intention Script
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: The mechanism repeatedly circles back to observe whether the promised action actually occurred and flags drift as once-reliable execution begins slipping.
Nearest alternative: Assessment, Review & Assurance — Each check can yield a finding, but repeated observation of actual follow-through over time is primary.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Closing the loop by checking execution after assignment is a long-standing management and supervision practice.
Related originating lineages:
- Accounting & Auditing — Corrective-action verification and evidence-based closure materially shape the check.
- Education & Pedagogy — Transfer-of-learning assessment independently checks whether knowledge became later action.
Review resolution: Both reviewers agree that organizational_management is primary. I retain education_pedagogy, accounting_auditing only as formative origin lineage(s), without treating every later application as an origin. convergent is appropriate because the same operational structure arose through materially independent professional lineages. Reach is universal as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The after-action review — the structured post-event check, developed in U.S. Army training, that compares what was supposed to happen with what actually happened and feeds the difference back into the next cycle. Its discipline of examining observed outcomes rather than intentions is exactly what a follow-through checkback applies to committed actions. ↩