Keep recurring work in one place

Outcome

Keep a recurring job’s sources, instructions, and results in one project. Use an existing task to continue the same outcome, and a new task for a separate outcome. Record the owner, status, and next decision so you can find the work again.

A task registry gives you a defined list to review for missing owners, duplicate work, or results waiting for review. If you ask ChatGPT Work to review it, limit the review to that list. Save important context and remaining obligations in project files before archiving a conversation.

When to use it

Create a durable project when a domain has recurring sources, specialized instructions, repeated deliverables, or a lifespan longer than one session. Examples include quarterly planning, customer research, a hiring process, or a product launch.

Organize by the workstream, not the application. A monthly forecast project can keep its approved data sources, spreadsheet, presentation, review notes, and reusable checks together. Separate projects named only "spreadsheets," "slides," or "queries" split the decisions and corrections that belong to the same job.

Keep one primary task for each outcome. Independent outcomes may have separate tasks; link them from the same project so ownership is clear. Create a new task when the objective, acceptance contract, security boundary, or owner changes materially. Continue the current task when the next action uses the same sources and definition of done.

Archive completed and superseded tasks after recording a reusable result and any remaining obligations.

Operating pattern

Use a four-level model:

1. Portfolio: the small set of durable domains competing for attention.
2. Project: stable instructions, sources, vocabulary, and governance.
3. Workstream: a recurring outcome with a clear owner.
4. Task: the active unit that advances one outcome.

Name tasks for retrieval rather than chronology: <Project>; <Subject> — <purpose or state>. Maintain a registry with the canonical task, owner, state, source links, last verified checkpoint, next action, and review date.

Before creating another task, check whether the same source, outcome, and human owner already point to an active workstream. Reuse that owner when verified. If the match is uncertain, record the uncertainty and ask; a second task is not a safe substitute for missing ownership evidence.

Use the same states in the guide and registry: active, waiting, review, blocked, paused, complete, and archived. Use waiting for a named dependency, blocked for an issue requiring intervention, and paused for work deliberately stopped. A draft awaiting review stays in review. A scan may recommend a state change, but evidence should support it. “No recent message” does not necessarily mean “stalled.”

Checkpoint after three major milestones, before changing lanes, or whenever a different person should be able to continue safely.

Copyable implementation

# Task registry

| Project | Canonical task | Owner | State | Last checkpoint | Next action | Review date |
|---|---|---|---|---|---|---|
| [domain] | [Project; Subject — purpose] | [name/role] | active | [link/date] | [bounded verb] | [date] |

## Task rules

- Keep one primary task per outcome; link related tasks with independent outcomes.
- Keep the workstream's sources, files, Skills, and review history together.
- Propose a new task when objective, owner, security boundary, or acceptance contract changes; create it only if the user explicitly requests it.
- Check the existing owner before creating a potentially duplicate task.
- Record decisions and evidence before archiving.
- Flag duplicates; do not merge or close them automatically.
- A scan may advance at most one specifically authorized, reversible internal step.
- If no safe step exists, report the blocker or no change.

Add a short project index that points to each registry and defines which tasks are canonical.

Example

For example, an operations manager maintains a project called “Vendor Renewal.” The project contains stable policies, the approved contract repository, and a calendar of renewal dates. Its canonical task is named Vendor Renewal; Analytics platform — decision package.

The registry shows the task as waiting because a security review is missing. A routine scan confirms the review is still absent and finds no newly approved evidence. Instead of drafting a recommendation from outdated notes, ChatGPT Work updates nothing and reports: dependency unchanged; owner and review date remain valid.

Later, the review arrives. ChatGPT Work verifies the document, changes the task recommendation to review, and prepares a decision summary. It does not accept the renewal or contact the vendor.

Approval boundary

A registry authorizes inspection and internal organization only to the extent explicitly configured. It does not authorize closing tasks owned by other people, reassigning work, merging records, changing due dates, sending reminders, or committing the organization to a decision.

Allow automatic changes only when they are reversible, internally scoped, and rule-based. For example, adding a verified checkpoint link to a local registry. Require approval for outbound communication, priority changes, access changes, destruction, publication, financial commitments, or actions affecting another person’s workflow.

Installation, project creation, connector setup, and scheduled scans require separate configuration and authorization.

Validation

Audit the architecture monthly:

• Every project represents one durable domain.
• Every active outcome has one primary task; related tasks have distinct outcomes and a clear owner.
• Related applications and outputs stay with their workstream rather than becoming separate ownership silos.
• Each task has an owner, state, and bounded next action.
• Checkpoints identify evidence rather than relying on transcript memory.
• Waiting tasks name the dependency and expected owner.
• Complete tasks have a reviewable result and no hidden follow-up.
• Archived tasks can be found through the project index.

Sample a fresh task and test whether it can resume using only the project instructions, registry, and latest checkpoint.

Failure modes

Too many projects fragment context; too few mix unrelated sources and permissions. Date-only task names become impossible to retrieve. Long-lived “miscellaneous” tasks hide ownership and make completion meaningless.

Automatic scans can also create noise by repeatedly declaring unchanged work urgent, generating follow-ups no one requested, or using inactivity as proof of failure. A task registry is not a surveillance system or a substitute for prioritization.

Do not duplicate the same plan across a task transcript, spreadsheet, and document without naming one canonical surface. If two records disagree, stop and reconcile the source hierarchy before advancing the work.