← back to the TrackRecord brief
TrackRecord · System diagrams

Anatomy
of a read.

How a public playlist link becomes a shareable personality read — in four diagrams. Each isolates a different layer of the system, drawn in one visual language.

01 / 04 — THE AI CORE

The model proposes,
the verifier disposes.

AI passes turn a raw tracklist into a shareable read. The two writing passes are each wrapped in a deterministic, code-based verifier — not another model — that either ships valid output or feeds the exact failure back and forces a corrective regeneration. The card deck ships first; the long-form essay is generated later, in its own worker.

deferred · own worker verifier · code ↻ regen on fail verifier · code ↻ regen on fail INPUT Tracklist normalized · ≥15 tracks PASS 1 · HAIKU Analyst source-anchored notes PASS 2 · SONNET Card-writer picks 1 of 5 voices SHIPS NOW ✓ The card deck the read · shareable PASS 3 · SONNET Essayist async · deferred LATER ✓ Deep dive appended later ship path verifier loop deferred / async
02 / 04 — THE ARCHITECTURE

The request never
waits on the model.

Intake returns in milliseconds. The slow work — fetching tracks, three AI passes, rendering a mosaic — is handed to detached CLI workers that run off-request while the browser polls for state. No queue, no Redis, no cron. The read self-drains; nothing is scheduled.

BrowserTHE READER process.phpINTAKE · THIN status.phpPOLL ENDPOINT MySQLPDO worker.phpDETACHED CLI ① THE REQUEST · returns in ~milliseconds POST · playlist URL INSERT pending_reads → processing spawn detached worker · async 303 → /profile.php?t=token whole request done in ~ms — nothing waited on AI ② OFF-REQUEST · seconds, all in parallel loop · poll every 2.5s GET /status.php?t=token read status { processing, step } DETACHED · OFF-REQUEST 1 · fetch tracksHTTP → 4 platforms 2 · Pass 1 — Haiku 3 · Pass 2 — Sonnet⟲ verifier retry loop 4 · store profiles 5 · flip consumed 6 · spawn 2 moredeep-dive + mosaic INSERT profiles UPDATE consumed GET /status.php read status { consumed } reload → render the card deck ✓ AND THEN, ASYNC Step 6 spawned the deep-dive + mosaic workers. They write to MySQL when ready; later polls reveal the essay and mosaic in place — the deck is interactive long before they land. call async / return key path / success
03 / 04 — THE STATE MODEL

Three little
state machines.

Every read carries three independent status fields, each advanced only by code. The main lifecycle streams fine-grained progress to the loader; the deep-dive and mosaic run on their own. An atomic claim stops two triggers double-running the same job — and a job stuck past 300s becomes reclaimable.

pending_reads · the read lifecycle processing · progress_step → queued fetching pass_1 pass_2 storing done consumed ✓ failed any step errors deep_dive_status The deep dive none atomic claim generating stuck >300s ↻ reclaim Pass 3 ✓ done error failed mosaic_status The mosaic none no mosaic platform owner · stays none else generating covers ✓ done few covers failed card omitted active / success failed neutral · no mosaic conditional / recovery (stuck-job reclaim)
04 / 04 — THE CRAFT PIECE

Sorted by light.

After the cards land, a detached worker builds the share image with zero AI — pure PHP GD. It pulls an album cover for every track, sorts them by brightness, tiles the brightest into the playlist's name in a flowing script, dims the rest into the backdrop, and composites the letterforms at pixel resolution so the cursive stays fluid.

0 AI TOKENS · PURE PHP GD no covers bright dim yes (editorial list) too few covers / any error DETACHEDworker_mosaicspawned post-cards platformowner? DEEZER · STEP 1resolve covers≤10 / batch · concurrent luminancesort BRIGHTEST COVERSTiled into the nameFreeType script font DIMMER RESTInto the fieldfull-bleed backdrop PHP GD · STEP 2alpha-compositeletterforms · pixel-res done ✓→ MEDIUMBLOBfilesystem is read-only skippedno card failedcard omitted craft path / success supporting / skipped failed