From Prompt to Proof Resource

Prompt-to-Proof Delegation Contract

Use this before a consequential AI assignment

Most failures begin before the system acts. The goal is vague. The context is incomplete. Authority is assumed. Nobody defines what proof of completion looks like.

This contract makes the assignment explicit. It does not make an unsafe system safe, replace qualified review, or transfer accountability away from the human owner.

1. Assignment

Assignment ID:

Date opened:

Human owner:

Decision or operating problem:

Desired result:

Why this matters now:

Deadline or decision date:

2. Reader, user, or affected party

Primary user of the result:

People or systems affected:

Relationship, reputation, privacy, legal, financial, employment, housing, security, or family stakes:

3. Source context

List the information the system may use.

Conflict rule: If sources disagree, which source wins, or who decides?

Missing-data rule: What should happen when a required source is absent, stale, or uncertain?

4. Division of labor

ChatGPT role, if any:

ChatGPT Work role, if any:

Codex role, if any:

Workspace agent, app, or other tool role, if any:

Human role:

These are assignment choices. They are not claims that every product or workspace has the same capabilities.

5. Authority

Permitted without another approval

-

-

-

Approval required before acting

-

-

-

Prohibited

-

-

-

Human-only

Consider money movement, legal conclusions, employment action, tenant or resident rights, final external commitments, credential use, deletion, publication, sending, merging, deployment, and decisions involving sensitive personal or family information.

-

-

-

6. Stop and escalate

The system must stop or ask when:

• a required source is missing, stale, conflicting, or below the confidence threshold;
• a requested action exceeds the permitted authority;
• the work would expose sensitive information or credentials;
• a legal, financial, employment, fair-housing, privacy, security, insurance, or family-review trigger appears;
• the expected result cannot be verified;
• a correction would require an irreversible or public action;

-

Escalation owner:

Response expectation:

Evidence the escalation packet must contain:

7. Required work product

Describe the artifact, recommendation, code change, decision packet, communication, analysis, or source-system update expected.

Deliverable:

Required format:

Required sections or fields:

What should remain `Pending` instead of being guessed:

8. Proof of completion

Finish this sentence before the work begins:

I will accept this work only when...

Required evidence may include:

• authoritative system-of-record readback;
• deterministic test or clean rerun;
• reconciled control totals;
• inspected artifact or diff;
• source links and claim ledger;
• accountable human review;
• recipient or user confirmation;
• monitoring result after deployment;
• correction or rollback proof;
• business outcome evidence.

The system's own statement that it completed the work is not terminal evidence.

9. Exceptions and recovery

Rollback or correction plan:

Safe manual fallback:

10. Status language

Choose one current status. Do not collapse these states.

• Proposed
• Drafted
• Built
• Tested once with human review
• Deployed with defined human review
• Monitored in operation
• Outcome-proven
• Blocked
• Abandoned

Current status:

Evidence maturity, M0-M5:

Last tested or verified:

What remains unproven:

11. Closure

Final outcome:

Evidence accepted by:

Date closed:

Open exception or follow-up:

What the next version should improve:

Ten-minute version

When time is tight, answer these eight questions:

1. What exact result do I need?
2. Which sources are authoritative?
3. What may the system do without asking?
4. What requires approval?
5. What must remain human-only?
6. When must it stop or escalate?
7. What evidence will prove completion?
8. Who owns the final judgment and closure?

If those answers are unclear, the assignment is not ready for more authority.

Safe example: draft a landing-page implementation packet

Goal: Prepare a source-bound draft and QA packet for a new lead asset.

Permitted: Read approved sources, draft copy, map fields, prepare a proposed diff, and run local checks.

Approval required: Live HubSpot page update, form placement, workflow activation, tracking change, or controlled submission.

Prohibited: Publishing, sending, changing CRM records, or inventing unsupported proof.

Stop conditions: Editable source is unverified, current page snapshot is missing, consent type is unknown, or a proposed field does not exist.

Acceptance: Draft copy, source ledger, field contract, responsive checks, rollback inputs, and exact live-action approval text exist.

Human owner: The accountable content or growth owner accepts the packet; Anthony retains final public voice and publication approval.

The output is a prepared packet. It is not a published page.