Skip to main content
← PROGRAM ARCHIVEFULL ARCHIVE RECORD
ALLOWLISTED DURABLE SOURCE

005-linkedin-production.md

docs/builds/005-linkedin-production.md

This is the retained record itself—not a chat summary. It is exposed because it materially documents the research, method, evidence, audit, production, planning or release history of The 100.

# Build 005 — LinkedIn Film Production Record

Status: GENERATED / sampled-frame QA complete / physical phone playback + repository binary transfer remain manual

## Canonical artifact
- filename: `build-005-linkedin.mp4`
- format: H.264 MP4
- dimensions: 720 × 900 (4:5)
- frame rate: 24 fps
- duration: 18 seconds
- audio: none / silent-first
- SHA-256: `3ae0f0d33b514a167eefbbbd3f23804f6f6997d2701027c2da6025830e6810fc`
- generated: 2026-08-16

## Story mechanism
The film is not a screen recording of 005-A or 005-B. It turns the governing service-to-software argument into a feed-native motion sequence:
1. `DON'T AUTOMATE THE SERVICE.` / separate the steps first;
2. one service opens into three futures — AUTOMATE / KEEP HUMAN / REMOVE;
3. removal is shown as the correct outcome for low-value work, human responsibility for judgment/exception/consequence-heavy work, and automation only after those gates;
4. `AUTOMATE ≠ DEPLOY` introduces repeatability, rule clarity, judgment and exception checks;
5. the saveable closing proposition is `MAP THE WORK BEFORE YOU AUTOMATE IT.` with the three candidate outcomes defined.

## Sampled-frame QA
Opening and final frames were directly inspected after generation. They are readable at the source 4:5 frame, carry no critical collision, and communicate the argument without audio. The final frame preserves the three distinct dispositions in text rather than color alone.

## Remaining manual/device requirements
- physical-phone playback/readability at typical LinkedIn feed size;
- platform compression/upload QA;
- repository/media-path transfer of the exact binary when an authenticated binary write path is available without breaking the recorded checksum.

The hash above is the identity of the generated candidate. Any regenerated file must receive a new hash and a new QA record rather than silently replacing this artifact.