Know what is current, checked, and approved

Outcome

A report can pass its checks and still be out of date. Before sharing it, check the source date, the tests completed on this version, and the approval required for the next action.

Record what exists, what you checked, what remains uncertain, and who approves the next step. Use the precise status definitions below when a result has several versions or destinations.

When to use it

Use this model for any work that can be reviewed, shared, uploaded, deployed, or published: analyses, documents, dashboards, presentations, application packages, websites, automations, and recurring reports.

It matters most when several surfaces exist at once: a source file, generated output, local preview, hosted review, staging candidate, and live destination. It also matters when the input data changes faster than the artifact. Even a small team benefits from this discipline once “ready” can mean different things to different people.

Use lighter labels for low-stakes personal notes. Do not create ceremony that exceeds the cost of being wrong.

Operating pattern

Track three axes separately.

Currentness answers: When were the canonical sources last read, what period do they cover, and what could have changed since then?

Lifecycle answers: What checks did this exact artifact revision pass? A useful progression is:

• draft: incomplete or not yet validated.
• validated: named checks passed for this revision and surface.
• release_candidate: a clean candidate exists, but one or more approval, packaging, currentness, or target-surface gates remain.
• release_ready: every named release contract is proven.
• published: the intended live target was updated and verified.

Authorization answers: What is the agent or operator allowed to do next? Read, draft, edit locally, change a shared artifact, deploy, publish, and alter access are separate permissions.

Every state transition should cite evidence, name the actor, and preserve the prior revision or recovery path.

Apply the same discipline to orchestrated work. A request can be detected, owner_verified, review_ready, advanced, blocked, or complete; those labels are not interchangeable. A fresh run receipt should name the source observation, existing owner, permitted action, action actually taken, outstanding approval, and completion evidence. Finding a task does not mean starting it, and starting it does not mean finishing it.

Copyable implementation

# Artifact state receipt

Artifact: [name and revision]
Owner: [role]
Intended destination: [surface]

Currentness:
- Canonical sources:
- Read at:
- Period covered:
- Known freshness gap:

Lifecycle:
- Current state: draft | validated | release_candidate | release_ready | published
- Checks passed:
- Checks not run or failed:
- Exact revision/checksum:

Authorization:
- Allowed now:
- Requires approval:
- Approver:

Run evidence, when applicable:
- Source observed at:
- Existing owner verified:
- Action authorized:
- Action actually taken:
- Completion independently verified:

Next transition:
- Proposed action:
- Evidence required:
- Verification after action:

Adopt one invariant: state is proven by evidence, not inferred from a filename, folder, previous release, successful command, or confident summary.

Example

For example, a planning team generates a quarterly briefing from a maintained workbook. The workbook was read Monday; on Tuesday, the owner adds a revised forecast. The briefing’s formatting and calculations passed their checks, so the artifact is still validated for the revision tested, but it is no longer current for the intended decision.

ChatGPT Work reports: “Validated against Monday’s source; currentness gap remains after Tuesday’s update.” It refreshes a local draft, reruns the named checks, and prepares a release candidate. It does not replace the shared briefing until the accountable owner approves that exact revision. After replacement, it opens the destination and verifies the version before using published.

Approval boundary

Validation is not authorization. A release-ready bundle may still require a human decision to deploy. Approval of a concept is not approval of every future revision, and access to a system is not permission to change it.

Require explicit approval for shared edits, uploads, deployments, publication, access changes, external messages, and destructive operations. The approval request should name the exact artifact, revision, destination, material changes, residual risks, and recovery method.

If a source changes after approval but before publication, stop and reassess currentness. Do not silently treat the prior approval as covering a materially different result.

Validation

Test the state model against realistic edge cases:

• A validated artifact with newly stale sources.
• A current source feeding an unvalidated transformation.
• A release candidate missing destination permissions.
• A successful deployment whose live route shows the prior version.
• A published artifact with a broken dependency.
• An approved revision that changes before action.
• A detected request that has not started or obtained approval.
• A resumed task whose output has not yet passed its completion checks.

Confirm the receipt identifies exact evidence and never uses “ready” without its qualifier. Verify the live destination after publication; command success alone is insufficient.

Failure modes

Typical failures include calling a directory “final,” treating a clean build as deployment proof, carrying currentness forward from an earlier run, and confusing access with authorization. Another is collapsing multiple surfaces: editor state, generated output, local preview, hosted review, and published output are described as if they were identical.

Avoid vague traffic-light labels without definitions. “Green” does not say which checks ran or which source period was used. Finally, do not let receipts become stale paperwork. Generate them from the same revision and validation run whenever possible, and make missing evidence block the stronger claim.