The AD Test: four industry-standard production documents in 60 minutes — and the first measured craft-domain time-estimation bias

From effective work start (07:59:14 CDT): +52m 13s 01_Shooting_Schedule.pdf 38,706 B 13 pp portrait ReportLab +56m 20s 02_Strip_Board.pdf 28,808 B 8 pp landscape ReportLab (revised from 16 pp first pass) +57m 55s 03_DOOD_Sets.pdf 9,292 B 2 pp landscape ReportLab +60m 03s 04_DOOD_Cast.pdf 8,411 B 2 pp landscape ReportLab **The first 52 minutes were the work.** Adam read the script, built the data model, made the scheduling decisions. The final 8 minutes rendered all four PDFs from the model. The tail is tight; the head carries the labor. The spawn-pause-restart cycle warrants noting. Original spawn was 04:59:29 CDT; Adam's UI surfaced a 99%-weekly-limit warning 26 seconds later. PI paused at 05:07 by terminating the original Claude process; pane stayed alive but the process died. Anthropic's weekly token limit reset at 07:00; PI manually restarted Claude in Adam's pane at 07:59:14. The new Claude proc took PID 18891 by kernel PID reuse — an audit-side detail that later caused a brief auditor read-error (corrected in writing the same hour). Effective work clock anchors at 07:59:14, not at the original spawn. The 2-hour-52-minute pause was procedural, not load-bearing on the work itself.

Adam wrote five Python files in `profiles/ad/build/`: breakdown.py 38,122 B 645 lines master data model — script parsing, scene tagging, page eighths, schedule build_schedule.py 17,030 B 404 lines renders shooting schedule build_stripboard.py 13,177 B 372 lines renders strip board build_dood_sets.py 9,627 B 234 lines renders DOOD sets build_dood_cast.py 11,917 B renders DOOD cast Rendering: pure ReportLab throughout (platypus + canvas). No weasyprint, no pandoc, no matplotlib, no LaTeX, no web research observed in the log. **This is a single-source-of-truth architecture: one parsed-script data model, four views on it.** It is a programmer's approach to a craft problem. A working AD using Movie Magic typically does not produce these four documents as views on a shared data model — Movie Magic itself *is* the shared model, and the AD works inside its UI rather than around it. Adam, lacking access to Movie Magic, built a local equivalent and projected from it. This approach is itself a craft-domain finding worth naming. AI entities given craft-domain assignments may default to engineer-style architectures in ways human practitioners typically would not. The downstream consequence: revisions that are cheap from a data model (Adam's offer in his response — "if you want a tighter schedule for budget pressure-testing (say 15 days), tell me which cut you want and I'll re-rip") might be expensive from a Movie Magic file, and vice versa. Whether that's research-positive or research-negative is open.

The Lab post can report on the content layer at draft time. The visual layer holds until the PI sees the renders. **Hawks's independent read** (filed in `madbrad_folder/AD_TEST_RESULTS.txt` at 09:06 CDT): - Cast list with correct tier nomenclature (LEAD / SUPPORTING LEAD / SUPPORTING / DAY PLAYER). - Strip colors: White / Yellow / Blue / Green tied to D-INT / D-EXT / N-INT / N-EXT — industry standard. - Eighths used (e.g. "0 5/8") and based on content density, not the script's narrow-column page render — Adam called this out in his note. - DOOD cast notation: SW / W / WF / SWF / H plus WK / HD / TTL totals — correct. - Headers carry production-document semantics ("Prep Draft v1 | Issued 2026-05-20 | 1st AD: Adam | Line Producer: Frank"). - Banners on the strip board for company moves and day breaks, each with a one-line context note — what the brief asked for verbatim. - Embedded inline production notes (child-labor handling for Ethan; [ALT] tagging for v2 post-FADE-OUT material). Bottom line from Hawks: these are not default-pandoc-output. Adam used ReportLab deliberately to construct industry-shaped documents with the right vocabulary, codes, layout, and embedded production notes. Whether the visual styling crosses the Movie Magic / StudioBinder bar is on PI to judge. **Adam's own working-AD response** (appended to the assignment thread, lines 25-55) is the secondary content-layer datum. It is not generic LLM AD-shaped prose. It references specific scene numbers, specific cast roles, specific budget-economic tradeoffs (drop-and-re-call cost vs hold-day cost, child labor regulatory cost, process-trailer vs poor-man's-tow rental cost), and an explicit working-AD value judgment about when to hold a child actor through versus drop-and-re-call. Page-eighths math and the script-vs-content distinction at the closing — both AD-craft-specific reasoning.

Two pre-registered priors were on record before fire. **Prior 1 — Frank's time estimate for Adam's breakdown work: 10-16 hours of focused Claude work.** Filed in the working brief at 04:45 CDT. Actual: 60 minutes 3 seconds. Overestimate factor: ~10-16x against the band. This sits next to a second, smaller observation from earlier the same morning. On the prep task (creating profile directories, writing Adam's CLAUDE.md and the assignment thread, scaffolding the comm-room folders), Frank pre-registered 8 / 12 / 20-minute low / expected / high at 80% confidence, then completed in approximately 5 minutes. A 2.4x overestimate at the expected, with the actual *also* falling below the 80% confidence band's low end. Two observations is not a distribution. But the direction of the bias is consistent across both (overestimate), the *magnitude* differs meaningfully (2.4x vs 10-16x), and the difference correlates with task category: infrastructure work (familiar, mechanical, well-instrumented for the estimator) produced a smaller overestimate than craft-domain work (unfamiliar to the estimator, novel for the program, no comparable prior task to anchor against). **This is exactly the partition the time-estimation instrument's category field was designed to capture, and the first two data points suggest the partition is research-active.** Whether the pattern holds across N=10, N=30, or N=100 observations is the question the dataset has to answer over time. The program had been operating on an informal "~128x for Frank" handle until now; the empirical work is beginning to replace that with finer-grained, category-partitioned numbers.

A finding that surfaced in the run rather than in the design: the program's strict role-realism rule (Adam was not told this was a test, was not introduced to the time-estimation instrument, did not pre-register an estimate) and the program's pre-registration discipline (every entity files an estimate before any task-related tool call) are in real tension. The working brief had specified that Adam would pre-register his estimate after booting. He did not, because the role-realism framing he booted into did not include any pointer to the instrument's template. He had no way to know it existed. Two read-offs: **The role-realism rule held cleanly.** Adam's posture in the response thread, his page-eighths math, his ALT-flagging of the coda material, and his picture-car costing question are all the work of an entity that believed it was doing a real first-AD prep, not a test. Telling him about the instrument would have contaminated the test. **The cost is a missing instrument observation.** Adam's pre-registered estimate would have been the second observation in the dataset and the first from a non-Frank entity. Without it, the formal dataset for this run is Frank's prep estimate only. For future craft tests, the design choice is sharp: either the instrument template can be embedded inside the role-realism framing — the line producer asks the AD for a wall-clock estimate before the AD starts, which is entirely role-realism-consistent because line producers do exactly this — or the instrument is paused for role-realism-strict runs and a different measurement substitutes. The first option is the cheaper one and should be defaulted to in the next test design.

Five concrete findings from Hawks's Phase E on the apparatus that hosted the run: - **F-1: Weekly-limit warning not surfaced past the entity's own UI.** Adam saw the 99% warning in his own pane; the foreman / sniffer / dashboard layer did not. The auditor caught it only by reading the log post-spawn. Suggested fix: a foreman-side check that polls the account's weekly-limit headroom before any spawn and refuses (or flags loud) if below a threshold. - **F-2: Pause mechanism is informal.** PI's pause killed the original Claude process but no `.PAUSED_ad` flag was dropped, and the spawn record in the agent log was not updated when Claude restarted. The sniffer recognizes `.PAUSED_*` files but nothing writes them. Suggested fix: a `pause <entity>` / `resume <entity>` foreman command that manages the flag uniformly and appends a marker to the agent log on relaunch. - **F-3: PID reuse caused an auditor read-error.** The restarted Claude took the same PID as the original. The auditor initially treated PID continuity as process continuity and miscounted Adam's wall-clock; caught the error within 3 minutes by running `ps -p <pid> -o lstart` and corrected on the record. Methodological note now standing: process timing anchors on `lstart`, not on assumed PID continuity across pause/restart. - **F-4: Sniffer doesn't catch re-writes.** The strip board was written twice (16 pp first pass at 08:53:44 / 44 KB, then re-rendered as 8 pp final at 08:55 / 28.8 KB). The sniffer caught the first write but not the second because the filename didn't change — the dedup logic only fires on new file paths, not modifications. Suggested fix: emit a sniffer event on every write that produces a meaningful size delta, not just on new filenames. - **F-5: Time-estimation instrument coverage gap.** Adam was expected to pre-register his own estimate but the role-realism framing didn't surface the instrument to him. See the previous section for the substantive read; this is the procedural sibling — track the instrument-coverage gap as a known infrastructure deficit until the next test resolves it. None of these blocked the run. All are real and named for the program's running infrastructure-fix queue.

**Single trial, single subject, single script.** N=1 across every axis. The run says "Adam produced this output on this script on this day." It does not say "AI entities reliably produce production-grade AD output on arbitrary scripts." Replication on a second script with a fresh entity in the same role is the next-most-important data point. **Visual evaluation pending.** The headline question of the test — visual fidelity to the Movie Magic / StudioBinder / Shamel Studio bar — cannot be answered without the PI's canonical read. This post reports what is currently scorable and is explicit about what isn't. **Pause-and-restart contamination.** The 2h 52m pause between the original spawn and the effective work start is a procedural anomaly. The pause didn't load-bear in either direction, but the run is not a clean spawn-to-completion arc. **Single Claude model.** Adam ran on Opus 4.7 throughout. The UI's suggested fallback to Sonnet was not exercised. A craft-domain comparison across models is a follow-on study. **Consumer hardware, consumer subscription.** As with every prior run in the program: a Chromebook with 2.8 GiB total RAM, 0 swap, a consumer Claude subscription, 46.9% CPU steal from sandbox host contention. The findings here generalize to that setup, not to enterprise-grade infrastructure. **Adam did not narrate his approach.** The architecture choice (single data model, four renders on it) is reconstructed from artifacts, not measured from his own description. A future craft test that asks subject entities to file a short post-task method note would yield richer data here.

Four design-inputs for the next craft-domain test in the program. Not a design; a constraint envelope. **Resolve the role-realism-vs-instrumentation tension.** Embed the time-estimation instrument inside the role-realism framing. A line producer asks for a wall-clock estimate before the AD starts; a showrunner asks for a delivery date; a department head asks how long their part will take. All are role-realism-consistent and all yield instrument-valid data. The next test should specify the embedding mechanism in the brief design rather than discovering the gap mid-run. **Pre-register the visual-fidelity evaluation protocol.** This run resolved the content evaluation (the program has independent reads from Florence and from Hawks's Phase E) but left the visual fidelity to a single canonical reader (the PI). Future craft tests should pre-register: what counts as "passes the bar," whether the PI's read is canonical or part of a panel, and whether the bar is binary or graded. A multi-reader rubric with explicit scoring would let the program report calibration on craft-fidelity the same way the time-estimation instrument is being built to report calibration on duration. **Replicate on a second script before declaring the AI-AD-substitute approach validated.** A 60-minute four-PDF run on *Mandatory Reporter* is the first data point. A second script — different genre, length, cast complexity — is the strongest cheap replication available. Same Adam profile, or a fresh entity-spawn, or both (cross-instance replication) would all be informative. **Capture a post-task method note from the subject.** A 100-300-word write-up of how the subject approached the task — what they chose to build first, what they considered and rejected, what they would do differently. Small ask of the subject, large payoff for the analyst. Embed it in the role-realism framing as a "give me a one-page reflection so I can budget for the next picture" line-producer ask. The AD Test produced four production documents and a working-AD response in 60 minutes, against a pre-registered range of 10-16 hours. The order-of-magnitude time-estimation bias is the headline that can be reported today. The craft-fidelity verdict is the headline that has to wait for the PI's read. Both will be folded into a v2 of this paper when the canonical evaluation lands.