Run one artifact experiment from brief to rollback

Published and revised: October 13, 2026 · Version 1.0.0

Create a small artifact, show where its facts came from, test it, and keep a version you can safely return to. This lab uses a fictional tool-library open day. Everything in the source packet is synthetic.

The included bundle contains a source packet, accepted host brief, deliberately rejected candidate, verifier, results, and integrity manifest. Five deterministic fixture checks were executed and met their expected outcomes. A local version-selection rollback was also checked. These are artifact checks, not a benchmark of ChatGPT performance.

What you need

Beginner path: read the source packet below, paste the prompt into one chat, and check the result by hand. A plain-text document is enough.

Professional path: use the downloadable bundle, preserve exact input versions, repeat the same acceptance checks on candidates, and record review effort. The optional verifier uses Python's standard library and no network. Inspect code before running it in an environment you control.

ChatGPT's file workflow and previews vary by surface. Current guidance describes creating and reviewing files in ChatGPT Work, but you should verify the tools actually available in your account. If a requested file type cannot be created, use text for the experiment and record that limitation. OpenAI: Work with files

The experiment contract

Question: Does a structured, source-linked host brief reduce correction work compared with a plain summary?

Scope: one fictional event; one host brief; three source records; one candidate revision after review. No live accounts, external messages, bookings, purchases, or publication.

Accept only if all supplied numbers reconcile, every factual claim has evidence, unresolved logistics remain unknown, and a new reader can identify the next decision.

IIEN means infer intent and extrapolate needs here. Use it to identify the host's likely need, compare divergent output options, and choose a bounded test. It is a user-directed working approach, not a certification, an OpenAI feature, or permission to take extra actions. WorkspaceOS is the conceptual arrangement of the brief, sources, checks, and versions; this lab does not change underlying model weights.

1. Freeze the synthetic source packet

Save this exact packet as input version 1.0.0:

• S1, approved open-day brief: 24 participants; three stations; eight seats per station; spending cap of 60 fictional credits; venue not provided; facilitator not provided
• S2, approved sequence: welcome 10 minutes; activity 25 minutes; wrap-up 10 minutes
• S3, illustrative material estimates: paper cards 18 credits; markers 12 credits; labels 9 credits

The credits are invented planning units. They are not real prices or a spending recommendation. No source says the event is ready to run.

2. Choose the output and baseline

Consider three formats: a host checklist, a participant handout, and a station-setup sheet. Select the host checklist because unresolved logistics are the immediate decision. Keep the other options as alternatives.

For a live comparison, first ask for a plain summary using the same packet. Save it as the baseline and record the time needed to correct it. Then run the structured prompt below in a separate chat with the same inputs. Record the visible product, model setting if shown, and available tools. Do not claim to control settings you cannot see or reproduce.

The included accepted brief is an authored worked example. It is not an observed result from that live model comparison. Run the comparison yourself before making a productivity claim.

Copy-ready experiment prompt

Draft a one-page host brief from the synthetic source packet below.
This is a bounded, draft-only experiment.

Use IIEN to state the likely intent, label assumptions, and compare three
formats: host checklist, participant handout, station-setup sheet. Recommend
one for the unresolved logistics, then produce only that one artifact.

S1: Approved brief, version 1.0.0. 24 participants. Three stations.
Eight seats per station. Spending cap: 60 fictional credits.
Venue: not provided. Facilitator: not provided.
S2: Approved sequence, version 1.0.0. Welcome 10 minutes,
activity 25 minutes, wrap-up 10 minutes.
S3: Illustrative estimates, version 1.0.0. Paper cards 18 credits,
markers 12 credits, labels 9 credits. All data is synthetic.

Output:
- Approved plan with a source ID beside every factual claim
- Venue and facilitator visibly marked “not provided”
- Suggested next steps, clearly labeled as proposals
- A short evidence map and calculations

Check that capacity matches station seats, the agenda sums correctly,
materials fit within the cap, and the remaining reserve is correct.
Do not invent logistics or imply that any proposed action has happened.

Return a version 1.0.0 draft and a check report. If any critical check fails,
label it failed and stop before calling the draft accepted. Ask for a decision
if sources materially conflict. Do not contact anyone, publish, book, buy,
edit sources, install tools, change settings, or use live account data.

3. Inspect the expected artifact

A correct approved-plan section contains:

• 24 participants across three stations with eight seats each [S1]
• 45 minutes in total, preserving the 10/25/10 sequence [S2]
• 39 credits for materials [S3]
• 21 credits unallocated under the 60-credit cap [S1, S3]
• Venue and facilitator both not provided [S1]

Keep the next steps separate: confirm the missing logistics, check the layout, and prepare materials. They are suggestions, not claims of completed actions.

The downloadable Markdown brief contains this accepted worked example. Its companion JSON exposes the fields used by the verifier. A person must still check that the prose and JSON agree.

4. Verify and challenge it

The included verifier checks source revision, capacity, layout, agenda arithmetic, cost arithmetic, reserve, cap, unresolved logistics, and the evidence map. Its five fixture outcomes are:

1. Accepted release: valid
2. Capacity changed to 30 without changing the sources: rejected
3. An invented venue added: rejected
4. An older source-version label substituted: rejected
5. Material cost changed to 65 credits: rejected

All five actual outcomes matched those expectations. A passing check confirms only what was tested. It does not establish completeness, good writing, accessibility, or suitability for a real event.

Human review must check:

• Every factual sentence against the source packet
• Proposed actions versus completed actions
• Whether unknown fields are obvious to a hurried reader
• Whether the output solves the host's actual problem
• Whether source instructions or unrelated content redirected the task

5. Version the evidence, not just the filename

Keep the source packet, prompt, output, check report, and reviewer decision as one release record. Use a unique version label and explain the change. Store a known-good copy before editing.

The lab's manifest identifies accepted version 1.0.0 and rejected candidate 1.1.0. It includes SHA-256 hashes for the source packet, artifacts, and verifier. A matching hash confirms byte identity, not truth, authorship, permission, or safety.

A filename saying “final” is not approval. Record who reviewed it and which checks were completed when you run your own experiment. The tutorial bundle does not invent a human sign-off.

6. Exercise rollback

The included exercise selects the deliberately faulty candidate, detects its capacity error, then selects saved version 1.0.0 again and reruns the checks. The result records restored version 1.0.0 as valid. The active-version file points to that copy.

This demonstrates a local artifact-selection rollback only. ChatGPT is not being asked to revert its model, reconstruct an unsaved state, retract a sent message, or undo a purchase. For a real external change, define a separate recovery procedure before authorizing it.

7. Decide whether reuse is worthwhile

Measure human effort, not output length. Record setup, review, corrections, maintenance, and any actual incremental tool costs. Separate observed values from estimates. Unknown cost is not zero cost.

Illustrative calculation, not measured results:

• Workflow setup: 35 minutes
• Baseline creation plus review: 18 minutes per accepted brief
• Structured creation plus review: 10 minutes per accepted brief
• Maintenance allocation: 2 minutes per run
• Net saving: 18 − 10 − 2 = 6 minutes per run
• Break-even: 35 ÷ 6, rounded up, is six accepted runs

If correction time rises, the task rarely repeats, or a serious error appears, the supposed saving can disappear. Keep a simpler prompt when the extra structure does not pay for itself. Compare cash costs separately unless you deliberately choose and disclose a value for your time.

Copy-ready experiment record

Experiment and owner:
Question and audience:
Scope, exclusions, and action boundary:
Input source versions and rights status:
Baseline prompt/output reference:
Candidate prompt/output reference:
Visible product/model settings and verified tools:
Acceptance checks and expected results:
Actual results, evidence, and reviewer:
Unresolved defects:
Setup minutes:
Baseline creation + review minutes per accepted output:
Candidate creation + review minutes per accepted output:
Maintenance minutes per run:
Incremental cash cost and currency, or “unknown”:
Net time saving per run:
Break-even accepted runs, or “no positive saving”:
Accepted version and reason:
Known-good rollback copy and restore-check result:
Decision: keep / revise once / abandon

Stop conditions

Stop when any essential accuracy check fails, source rights are unclear, the necessary tool is unavailable, the time or spend limit is reached, or the task needs a new action permission. Keep a failed candidate clearly labeled. Do not average a serious factual or permission failure into a passing score.

The experiment is finished when you can inspect one accepted artifact and its evidence, or record a clear reason to abandon it. Wider automation or publication requires a new decision.