Close Open Loops

Find the work that is falling between conversations and systems, then prepare the smallest actions needed to close it.

Focus on exceptions that deserve attention rather than rebuilding every message, task, or project record.

1. Define which loops matter

Establish:

• time window;
• people;
• workstreams;
• systems;
• desired result.

Clarify what the user considers:

• open;
• resolved;
• closed.

Closure may require:

• reply;
• accepted decision;
• named owner;
• due date;
• delivered artifact;
• completed task;
• updated system of record.

Identify the source of truth where one exists.

Determine whether the user wants:

• personal follow-ups;
• team commitments;
• project exceptions;
• combination.

Start with one useful workstream or representative time window before scanning broadly.

2. Gather candidate commitments from real work

Use approved context from:

• meetings;
• transcripts;
• email;
• Slack or messaging;
• task tools;
• project tools;
• documents;
• calendars;
• files;
• tabs;
• memory.

Follow evidence into the underlying records where possible.

Keep a path back to each source so a resolution can be applied in the correct system later.

Look for:

• explicit promises;
• requests;
• approvals;
• decisions;
• introductions;
• follow-up dates;
• unanswered questions;
• meeting actions missing from task systems;
• tasks without credible owner or date;
• decisions not reflected in the systems that depend on them;
• items marked complete without evidence of the promised outcome;
• duplicate or contradictory representations.

Do not treat:

• every unanswered message as an obligation;
• every conversational suggestion as a commitment.

Match identities, projects, and workstreams carefully before combining evidence.

3. Reconcile before declaring something open

Check whether each candidate was:

• completed;
• superseded;
• delegated;
• declined;
• resolved elsewhere.

Prefer direct, current evidence over:

• stale task state;
• inference;
• old notes.

Classify candidates using clear labels such as:

• confirmed open;
• likely open, evidence incomplete;
• conflicting status;
• blocked;
• waiting;
• resolved.

Keep ambiguity visible when:

• identity;
• ownership;
• date;
• wording;
• definition of done

could change the action.

Never invent an owner, deadline, or commitment merely to complete the list.

4. Return an exception list

Prioritize by:

• consequence;
• urgency;
• dependency;
• user's operating rules.

For each important loop, include:

• what is open;
• why it matters;
• owner when supported;
• due date when supported;
• evidence;
• systems checked;
• gap or contradiction;
• smallest proposed next action;
• whether a human decision is required.

Group duplicate references to the same underlying issue.

Keep resolved items out of the main list unless an audit trail is needed.

Summarize coverage and name important sources or workstreams that could not be checked.

5. Route adjacent workflows appropriately

Use meeting debrief when one recent meeting still needs to be turned into decisions and actions.

Use status-update preparation when accepted findings should become an async update.

Use the exception list as context for meeting preparation when the gaps require shared discussion or decision.

6. Prepare approved resolutions

Possible resolutions include:

• reply;
• nudge;
• clarified owner;
• clarified date;
• new task;
• corrected task;
• project-status update;
• recorded decision;
• escalation;
• explicit closure.

Draft each proposed action beside the evidence supporting it.

7. Keep approvals separate

Treat these separately:

• exception-list approval;
• sending messages;
• task creation;
• ownership change;
• project updates;
• record changes.

Approval of the exception list is not permission to modify systems.

Before execution, confirm:

• people;
• account;
• destination;
• record;
• scope

unless already covered by active scoped permission.

Verify consequential writes afterward.

Report anything that remains open or blocked.

8. Learn the team's closure rules

Use feedback to learn:

• which commitments matter;
• authoritative systems;
• definition of closure;
• acceptable waiting states;
• common false positives.

Preserve durable rules only after the user corrects real outputs.

Do not turn one audit into a permanent operating rule without evidence.

9. Reuse the method carefully

Share an approved exception list when useful.

Save the accepted method as a reusable team skill when multiple people should audit open loops the same way.

Recurring monitoring may be useful once the audit is trusted.

A recurring version may:

• run before a coordination meeting;
• inspect agreed meeting, communication, task, and project sources;
• surface only new or materially changed loops;
• prepare proposed nudges or updates;
• wait for approval.

Stop when:

• identity matching is unclear;
• source-of-truth matching is unclear;
• permissions are missing;
• private context may cross a boundary;
• resolution depends on a decision the user has not made.