# Artifact Brief and Delivery Card

An artifact does not need to be complete on day one, but it needs boundaries on day one. Copy this card into a private project directory and keep the independent, revised, reviewed, and delivered versions. Do not include passwords, client data, unauthorised third-party information, or unnecessary personal details.

## 1. Artifact boundary

### Artifact Brief — YYYY-MM-DD

Artifact name:\
Real situation:\
Audience/user:\
One problem to solve:

Inputs and sources:\
My current baseline:\
Key assumptions:

Smallest deliverable:\
Format, time, and other constraints:\
Acceptance criteria:\
What this will not include:

First-version deadline:\
Who will give feedback:\
Evidence to preserve:\
How to shrink, pause, or roll back:\
Next review date:

## 2. Four versions

| Version     | Completion condition                                                 | What to keep                                            |
| ----------- | -------------------------------------------------------------------- | ------------------------------------------------------- |
| Independent | Complete the smallest action without an answer key or AI writing it  | Original file, time, bottlenecks                        |
| Structure   | Audience can find the problem, conclusion, and next step             | Structural diff, fact/guess marks                       |
| Review      | A real reader, user, peer, or defined AI reviewer completes a review | Feedback, error categories, accept/reject reasons       |
| Delivery    | Another person can begin without your oral explanation               | Version, limits, sources, known issues, handover record |

## 3. Quality gates

| Gate         | Check                                                                | Evidence location | Owner/date |
| ------------ | -------------------------------------------------------------------- | ----------------- | ---------- |
| Clear        | Does the audience know the problem and next action?                  |                   |            |
| Accurate     | Do facts, citations, code, and numbers return to a source or test?   |                   |            |
| Usable       | Can the main action work under real constraints?                     |                   |            |
| Maintainable | Are version, dependencies, limits, and owner visible?                |                   |            |
| Responsible  | Are privacy, copyright, permissions, and error consequences handled? |                   |            |

Write “unverified” when there is no evidence for a pass. Speed, word count, and feature count are proxy measures, not quality gates.

## 4. AI and feedback record

AI/tool and date:\
Work it was allowed to do:\
Human judgments I kept:\
Three highest-impact issues it raised:\
What I accepted/rejected, and why:\
Main point restated by a real reader/user:\
Most important repair:

Save your version first, then use AI to diagnose, simulate an audience, or generate a parallel task. A person confirms critical facts, permissions, privacy, cost, and final authorship.

## 5. Delivery and rollback

Delivery audience and permission scope:\
Delivery date and version:\
Instructions:\
Known limits:\
Support owner/contact:\
Cost and retention period:\
Pause/degrade/rollback trigger:\
Who must be notified after a problem:\
Next review date:

Delivery is not the end. After 3–7 days, run a parallel test and record whether another person can start independently, what still needs explanation, and the one change for the next version.

Related chapters: [Artifacts: Turn Learning into Something Made](https://byoungd.github.io/up/en/threads/part-3/4-artifacts-and-delivery) | [90-Day Cycle Map](https://byoungd.github.io/up/en/templates/90-day-cycle)

---

Source: [Life Level-up Guide](https://byoungd.github.io/up/en/templates/artifact-brief) · Manuscript updated: 2026-08-31. Content: [CC BY-NC 4.0](https://creativecommons.org/licenses/by-nc/4.0/).