Every month, a report called The State of AI appears on this site. I don't write it. A scheduled task in Perplexity researches the month, writes it up, builds the charts, publishes it, updates the archive, and emails me the highlights — start to finish, unattended. As of July 2026 it has eleven sibling briefings researched, written, and published by Eidos, my Claude-based agent, and a twelfth being stood up as I revise this.

When I shared the short version, everyone asked the same thing: okay, but how does it actually publish? Fair — that's the part with the sharp edges, and it's the part most "automate my newsletter" guides wave past. So this is the long version, with the real mechanics: the exact steps, the tools, the file paths, the commands, and the bugs that made "finished" reports invisible to the public for weeks.

A note on how to read this post. It's an operator manual, and the machine it documents keeps evolving, so I revise it instead of letting it rot. It's in three parts. Part 1 is the original single-report recipe from early 2026 — most of it still stands, but a few steps are now historical, and I've marked each one historical or still operational rather than silently rewriting history. The traps in Part 1 are real traps I paid for; the fixes live in Part 2. Part 2 is the system as it actually runs today: twelve briefings, a research-to-ship pipeline, verification gates, and the deploy mechanism that replaced the one in Part 1. Part 3 is the newest layer: the same reports publishing under two different mastheads — my site and my firm's — and the first series designed from day one to walk both tracks.

The subject happens to be AI and its supply chains. The machine doesn't care. Point it at your industry, a competitor, your city's housing market — anything that changes monthly and deserves a sharp briefing.

The one idea

You don't automate the writing. Writing was never the bottleneck — showing up every month is. You automate the showing up: a recurring task, not a one-off prompt, that on a fixed day each month goes and finds what changed, renders it the same way as last time, gets it in front of readers, and tells you it's done. The value isn't any single issue; it's a numbered series that never skips and compounds into an archive nobody else had the discipline to keep.

Part 1 — The original machine (March 2026)

This is the recipe as I first built it, one report on one engine. The State of AI still runs on this Perplexity task today, so parts of it remain live infrastructure — but several steps have been superseded by the Part 2 system, and I've flagged which is which.

Step 1 — Figure out which issue this is

Status: still operational — with a correction that matters more now than it did.

The first thing the task does is compute the current month, the year, and the volume number. The State of AI's clock is pinned: Vol. 1 = March 2026, add one per month, so July 2026 is Vol. 5. I write that rule into the instruction verbatim, because an AI left to infer a sequence will eventually miscount — and a wrong volume number stamped onto a permanent archive is exactly the kind of small, load-bearing error that quietly erodes trust in everything else.

Here's the correction, for anyone copying this pattern in a family of publications: there are now two clocks, and confusing them is the miscount waiting to happen. The State of AI counts from March 2026 because that's when the Perplexity task shipped its first issue. Every Eidos-run series counts from Vol. 1 = July 2026, because that's the founding month of the wider family. So in July 2026 the flagship prints Vol. 5 while its eleven siblings all print Vol. 1, and both are correct. If you run more than one series, pin each series' epoch in its own instruction, in plain words, every single time. Never let a model infer a volume number from another series' masthead.

Step 2 — Research five fixed lanes

Status: still operational — and now the template for every series.

I don't tell it to "cover AI." I give it five lanes it must fill every issue, in the same order: Capabilities (models, benchmarks, releases), Funding (rounds, valuations, deal flow), Safety & Risk (incidents, jailbreaks, regulation), Geopolitics (export controls, talent, national strategy), and Robotics (humanoids, embodied AI, automation).

The lanes are a contract, not a suggestion. Their entire job is to make Vol. 5 comparable to Vol. 1. The month a huge story doesn't fit, you'll want to add a sixth lane — don't; fold it in or leave it out. Consistency across issues beats completeness in any one of them. Every newer series got its own version of this contract: Memory Hardware runs lanes for HBM, DRAM/NAND pricing, China, capex; Commercial Real Estate runs office, industrial, the maturity wall, the data-center land rush. The lanes differ by sector; the discipline is identical.

Step 3 — Pull from real data, not just "the web"

Status: still operational.

Web search alone drifts toward whatever was loudest that week, and you end up summarizing the hype cycle. The flagship also queries paid data connectors — CB Insights, PitchBook, and Statista — so the funding figures and market sizes trace back to something accountable. And it must cite every non-trivial claim with a link. Citations do double duty: they let a skeptical reader check you, and they force the model to actually have a source instead of confabulating a clean-looking number. Unsourced stat = liability; linked stat = asset. This rule survived every generation of the machine unchanged, and Part 2 hardens it further.

Step 4 — Render one self-contained HTML file

Status: half historical. The "one self-contained file" half is doctrine; the specific dark-dashboard design it describes has been retired — see the paper house style in Part 2.

The report is a single HTML file written to a fixed path. Two choices worth copying:

Self-contained. Styles, layout, and data all live in that one file with no external dependencies. It renders identically in five years, hosts anywhere, and can be emailed or archived without breaking. That portability is what makes everything downstream trivial.
Locked design. You style it once and every future issue reuses the exact template with new numbers. The urge to "improve the design a little" each month is how you get an archive where every issue looks slightly off. Content is the only monthly variable.

The original look was a dark intelligence-dashboard — glowing KPI cards, neon accent, Space Grotesk. It photographed well and read badly. In July 2026 the whole family moved to a paper broadsheet style (Part 2 has the details); the lesson — lock the design, whatever it is — stands.

Pin the branding explicitly in the instruction, because models drift. Mine literally says to use my name and not an earlier project's brand — because one month, without that line, it cheerfully re-branded the whole thing to a name I'd retired.

Step 5 — Publish, and understand it's two systems, not one

This is the step everyone underestimates, so here's exactly what happened, where it broke, and what each piece got replaced by.

5a. Push the file into the site's repo — via the GitHub API, not `git push`

Status: still operational for the Perplexity task specifically.

The task runs in a sandbox with no local clone of my repository, so there's nothing to git commit against. Instead it drives GitHub's Git Trees API through the gh CLI: it creates a blob from the report HTML, builds a tree that places that blob at web/public/stateofai/reports/{YYYY-MM}.html, creates a commit pointing at the tree, and then updates refs/heads/main to that commit. That four-call dance (blob → tree → commit → update-ref) is how you commit to a repo you don't have checked out. It's not obvious, and it's the single most-asked-about piece. The Eidos pipeline doesn't need it — it works in a real checkout — but any sandboxed cron still does.

5b. Register the issue in the archive index

Status: historical — this section describes a trap, and the trap has been fixed. Read it as the "before" picture.

In the original design, the archive page (web/app/stateofai/page.tsx) kept a REPORTS array in the React source, and the task prepended each new issue to the top of it. That is publishing by editing source code as if it were data. A malformed entry — one stray comma — breaks the site's build. I wrote at the time: "If I were starting over, I'd have the index list itself, so publishing never touches code. Editing a registry by hand is a bug with a delay on it."

I was starting over sooner than I thought. Today every series' archive — the flagship included — reads a plain data file: web/public/<series>/reports/index.json. Publishing a new issue means prepending one JSON object to that file. No React, no build, no code path at all. The site's build never sees a new issue, so a new issue cannot break the build. The full "series are config, issues are data" split is in Part 2; the point here is the honest history: the v1 design shipped with a known structural flaw, the flaw was real, and the fix was worth a migration. (Migration footnote: the Perplexity task's instruction had to be rewritten to prepend to index.json instead of editing the array, and until a changed instruction has run a few cycles you verify each month that the new issue actually landed in the index. Automation changes are not real until you've watched them succeed unattended.)

5c. Committing is not deploying

Status: the lesson is permanent; the specific fix described here has itself been replaced — see "How deploys actually work now" in Part 2.

My site runs on Railway, and Railway here deploys from a token-uploaded build — it does not auto-deploy when GitHub receives a push. So the cron faithfully pushed each new issue to GitHub… and nothing happened. The file sat in the repo, perfectly finished, while the live site kept serving the old version. Two entire monthly issues were invisible to the public for weeks — present in the repository, absent from the internet — and I only found out when I went looking for June and couldn't reach it.

The v1 fix was a GitHub Action running railway up on every push to main, with the Railway token stored as a repository secret. That was the right shape of fix — make "deploy" part of the same motion as "commit" — and the wrong long-term mechanism for this stack; the current one (a wrapper called railguey, with its own trap) is in Part 2. The universal lesson didn't change and never will: content existing in your system is not the same as a visitor being able to see it. Find that seam and automate across it — then verify from the public side.

5d. Mirror it

Status: still operational for the flagship.

The task also deploys a copy to Perplexity's own hosting as a backup, so even if the primary deploy stumbles, the issue is reachable somewhere public the moment it's done.

Step 6 — Make sure the links actually open

Status: still operational; the bug class is universal.

Each issue is shown on the site inside a sandboxed <iframe>. My first version set sandbox="allow-scripts allow-same-origin" — and every one of the ~160 source links (all target="_blank") was dead on left-click, because a sandbox without allow-popups silently blocks new-tab navigation. Right-clicking "open in new tab" still worked, which made it maddening to diagnose. Adding allow-popups allow-popups-to-escape-sandbox fixed it. If you embed your report anywhere, click a real link before you trust it.

Step 7 — Email yourself a receipt

Status: still operational, and generalized: every pipeline stage now reports proof, not just the last one.

When the run finishes, the task emails me the new issue plus a summary of the key findings. That email is two things: proof the run happened, and a thirty-second read of what changed without opening anything. Automated jobs fail silently — a task that quietly stopped running looks identical to a slow news month. The receipt is how you tell the difference, so make it detailed enough that its absence alarms you.

Part 2 — July 2026: one report became a system

Everything above still stands as history, and the Perplexity task still faithfully produces The State of AI every month. But in July 2026 the pattern stopped being a report and became a publication: eleven sibling briefings — Robotics, Open Source AI, Private Equity, Energy, Computer Chips, Memory Hardware, Voice Assistants, Commercial Real Estate, AI Misinformation, Consumer Confidence, and AI Autonomy — researched, written, and published by Eidos, my Claude-based agent, while the original stays on Perplexity as a deliberate head-to-head. Same format, same cadence, two engines; the archive itself will show which one holds up.

Standing up that many series forced every corner of the original recipe to grow up. Here is what the grown-up version looks like, with the actual commands.

Series are config; issues are data

The single worst decision in v1 was publishing by editing source code. The fix has two halves, and the halves are different kinds of things:

A series is one config entry. There's a single registry file, series-config.ts, and each briefing is one block in it: an id (the legacy folder name, like stateofmemoryhardware), a short (the canonical URL segment), a section (the family taxonomy — AI, Hardware, or Markets), title, eyebrow, subtitle, an accent color pair (accent for dark chrome, accentLight — a darker variant of the same hue — for paper and light surfaces), an inline SVG icon, and a credit line. The archive page, the report viewer, the section fronts, the nav, the PDF cover, even the legacy-URL redirects — all shared components that skin themselves from that one entry. Canonical URLs are /stateof/<short> (so /stateof/memory, /stateof/chips), and the old /stateofmemoryhardware-style paths 308-redirect via middleware that reads… the same config. Register the series once and the whole site knows about it.
An issue is three data files. The report itself ({YYYY-MM}.html, fully self-contained), a machine-readable spine ({YYYY-MM}.json — KPIs, forecasts with probabilities and resolve-by dates, the running timeline, the scorecard), and one entry prepended to the series' index.json registry, which the archive fetches at runtime. Publishing an issue touches zero code. Nothing can break the build, because the build never sees it.

Config versus data is the whole trick. Things that change when you add a series (a title, a color, a URL) live in one code file you edit a few times a year with a human watching. Things that change every month (issues) live in JSON a robot can write with no blast radius. v1's sin was putting monthly writes on the code side of that line.

The JSON spine matters more than it looks: every issue's KPIs, forecasts, timeline, and scorecard live there as structured data, so the archive isn't just a shelf of documents — it's a queryable dataset that grows by one row a month.

The staggered calendar: data decides the publish date

v1 published on "a fixed day each month." With twelve series that becomes a stampede on the 1st — and, worse, it's wrong for the data. Each sector's source numbers land on their own schedule: TrendForce's memory contract prices print early month, the EIA's Short-Term Energy Outlook lands around the 7th, Trepp's CMBS delinquency prints near the 1st, Michigan's preliminary consumer sentiment around the 17th. Publish before your anchor data lands and you're writing about last month twice; publish long after and you're stale. So the calendar is staggered, one series per publish day, each pinned to when its inputs actually exist:

Day  Series                  Anchor
 1   AI (Perplexity)         legacy cadence, unchanged
 3   Open Source AI          month-start leaderboard/token data
 5   Computer Chips          prior-month vendor prints digested
 8   Memory Hardware         TrendForce early-month contract prices
10   Energy                  EIA STEO lands ~7th
12   Digital Storage         TrendForce NAND/SSD prints + vendor earnings
13   Robotics                mid-month shipment/funding roundups
15   Voice Assistants        —
18   Private Equity          mid-month deal/fund data digests
21   Commercial Real Estate  Trepp delinquency (~1st) + MarketBeats
24   Consumer Confidence     UMich prelim (~17th)
27   AI Misinformation       audits the month's press once it exists
30   AI Autonomy             month wrap: friction + incident ledger

Two second-order benefits: the site gets something new roughly every 2–3 days instead of one monthly dump, and the pipeline only ever runs one full series cycle per day, which keeps any single failure small and diagnosable.

The pipeline: research → digest → write → gate → ship

Each issue is an assembly line of specialized agents, not one heroic prompt:

Research fan-out. Two or three agents per series, each owning named lanes ("HBM", "robotaxis", "private credit"). Ground rules that are non-negotiable: every claim carries a source URL; never invent a number; when sources conflict, report both with the discrepancy flagged; when the only source is an aggregator or a headline you couldn't open, say so. The agents return raw dated fact-lines, not prose, and their briefs are saved to disk — so a killed agent costs minutes, not the morning.
Digest. One document per series fusing the research: facts organized by section, conflicts adjudicated (pick the conservative figure, footnote the other), hedge flags propagated, the issue's editorial spine named in one sentence. The digest is the contract between research and writing — the writer never sees the raw web, only vetted material.
Write. One agent per series renders the digest into the locked house template. It's free to invent sector-native furniture — league tables for PE, a price strip for Energy, case files for Misinformation — but the components, type, and layout system are fixed. Content is the only monthly variable.
Gate. Schema validation on the JSON spine, link checks, a scan for leftover template branding, and two purpose-built doctors described below.
Ship. Build, commit, deploy, then verify from the live URL — the pipeline checks that the public archive lists the new issue and that a real link inside the report opens. Commit ≠ deploy remains the most expensive lesson of v1; a SUCCESS status from your deploy platform is not verification either.

The paper house style

The dark dashboard was v1's look. In late July 2026 the whole family moved to a paper format: paper-stock background, ruled boxes instead of glowing cards, serif text (Newsreader and Source Serif 4) with JetBrains Mono as the data voice, a slim section-links-only nav, and exactly one saturated hue per series — its accentLight — doing all the accent work. The site chrome carries the identity, so the report doesn't need a wordmark shouting from inside the iframe.

Why it matters beyond taste: a single-accent, print-shaped page is enforceable by machine. Which brings us to the doctors.

The gates, with real commands

Two linters stand between a "finished" report and the public. They exist because AI defaults to maximalism and cannot feel that a page is exhausting — the gates are how it catches itself.

pdf-doctor. Every issue ships a light-mode, iPad-shaped PDF, generated with the same script across all series:

node web/scripts/gen-stateofai-pdf.js <in.html> <out.pdf> <vol> "<Month YYYY>" \
  "<Series Title>" "stateof/<short>" <accentLight> "<Eyebrow>"

Then web/scripts/pdf-doctor.py inspects the render: clipped text, dropped content, broken pagination. P0 findings block release. One hard-won discipline: the doctor has known false-positive classes (phrases split by styled badge spans, uppercase CSS transforms, sentences broken across page footers), and when a gate fails you diagnose the gate before shredding the work — but never just mute it. A gate you've stopped trusting is worse than no gate, because it launders real failures.

design-doctor. The front page and any new layout run through node web/scripts/design-doctor.js <url> --genre=frontpage, a style linter built on computable psychology proxies: an above-the-fold element budget (≤30), a word budget (≤120), a Hick's-law choice count (≤5 competing calls to action), a von Restorff accent check (≤2 minority-hue roles — if everything pops, nothing does), a type-scale audit (≤5 sizes), an ink-coverage ratio, and a squint-test focal share. Exit code 0/1/2 = pass/warn/fail. It sounds absurd to lint aesthetics; it works, for the same reason the volume-number rule works — anything a model drifts on eventually needs a machine check, and "the page is exhausting" is a drift.

How deploys actually work now

The Part 1 fix (a GitHub Action running railway up) gave way to a purpose-built wrapper, railguey, and the current motion is:

railguey upload-source <workspace> djs-personal    # ship a source snapshot
railguey deployments <workspace> djs-personal --limit 1   # poll status
cd web && npm run smoke                            # verify the public contract

Two traps, both paid for:

railguey deploy is a restart, not a release. It rebuilds the service's existing source snapshot and happily reports SUCCESS without shipping a single new commit. Only upload-source ships code. If your platform has both a "redeploy" and a "release" verb, learn which is which before your archive teaches you.
Deploy from a clean clone. A working tree full of build artifacts and node_modules blew the upload cap (HTTP 413). The pipeline clones fresh and uploads that.

And the verification step is a real script, not a vibe: npm run smoke asserts robots.txt and sitemap return 200, that no public page bounces to the login screen, that OG tags and the social image resolve, and that legacy redirects still work. A GitHub Action runs the same smoke test daily against production, because regressions don't wait for deploy day.

The forecast ledger: the whole point

A monthly snapshot is journalism. A dated series of snapshots with graded predictions is an instrument. Every issue carries three fixtures:

Our forecasts — six to eight falsifiable claims, each with an explicit probability and a resolve-by date. Not "robotics will grow" but "P=0.65 that X ships fewer than 20,000 units by December 31."
Forecast Watch — the notable public predictions in that sector (CEOs, banks, agencies), logged with the exact claim, when it was made, and when it resolves.
The Scorecard — everything that has resolved, graded hit / miss / partial with evidence links. The first issues already grade 2025's promises; from Vol. 2 each series grades its own prior calls, and once the sample is big enough, calibration curves: when we say 70%, does it happen 70% of the time? Where does each forecaster systematically overshoot?

That's the reason this family exists: not to describe months, but to accumulate a record of who keeps being right, who keeps overshooting, and by how much.

The cumulative timeline

Each issue carries the sector's full milestone history since Vol. 1 — a timeline array in the JSON that every new issue copies forward and appends. Milestones only: firsts, records, regime changes. Twelve issues in, a reader opens the latest one and sees the whole arc without touching the archive. It's the time-capsule property made physical.

The honesty layer: three dates, hedge flags, and unblended datasets

Building the AI Misinformation briefing taught the whole family its sourcing discipline. Every claim has three dates — when the data was collected, when the study published, when the article ran — and collapsing them into "recent" is how misinformation is actually made. So the house rules are:

Date-stamp evidence by its data window, not its publication buzz. A 2023 stat cited in 2026 gets labeled a 2023 stat.
Anything sourced from a headline, an aggregator, or a feed you couldn't open ships as "reported, per <outlet>" — or ships not at all. No fabricated URLs, ever.
Never blend datasets with different methodologies. Two vacancy surveys that disagree get presented as two labeled numbers, not averaged into fiction.
When your own research can't find a number, print the gap. "No confirmed figure exists" is information; a plausible invention is poison in a permanent archive.

What it costs

The founding day — eight full issues, the shared infrastructure, the whole family scaffolded — ran roughly six million tokens across ~35 agents. Steady state is far less: one series-month is two or three research agents, a digest, a writer, and a grading pass. On a subscription those tokens are already paid for; at API list prices the same series-month prices out between under a dollar and ~$15 depending on model tier. The marginal cost of the next briefing is one config block and the research fleet's afternoon. The bottleneck was never ideas or writing — it's orchestration discipline, and that's exactly what the pipeline encodes.

The traps, in one place

The v1 traps, still true:

Commit ≠ deploy. Pushing to your repo is not shipping to your site. Two invisible issues proved it. And its modern corollary: redeploy ≠ release — know which verb ships code.
Publishing by editing code. Fixed structurally: issues are data files now. If your publishing path touches source code, you've scheduled an outage.
No local checkout. A sandboxed cron drives the GitHub Trees API (blob → tree → commit → update-ref) instead of git push.
Sandbox eats your links. An <iframe> without allow-popups kills every target="_blank" link on left-click. Test a real click.
Design & branding drift. Lock the template; pin the brand name and the volume epoch in the instruction. Models will "helpfully" wander.
Unsourced numbers. Demand a link per claim, and wire in real data sources, not just web search.
Silent failure. No receipt means a dead task and a healthy-looking site are indistinguishable.

And the ones scaling added:

Auth middleware eats new routes. New archives 307-redirected to a login page because the site's public-route allowlist didn't know them. Every new public path gets registered in the allowlist and in the smoke test — and you test with curl, not your own logged-in browser, because your cookie will lie to you.
Deploy payloads bloat. Clean clone, always (the 413 story above).
Agents die mid-flight. Session limits, rate resets. Design every stage to be relaunchable from its inputs — research briefs and digests on disk mean a killed agent costs minutes.
Search budgets exhaust. Research agents that lose web search fall back to RSS endpoints and direct fetches of primary sources — and label which items came from feeds they couldn't open.
Verification tools cry wolf. When a gate fails, diagnose the gate before shredding the work — but never just mute it.
Your own research can catch zombie stats. The misinformation hunters found a three-year-old jobs figure drawing five fresh headlines in a single week of 2026. Assume the stat you just found is stale until its date chain proves otherwise — including in your own briefings.

Why a family beats a report

The series cross-feed. The memory shortage shows up in Chips; the ECB's surprise hike shows up in PE's dealmaking and CRE's cap rates; datacenter power appears in Energy, CRE, and Chips from three different angles, and when three independent research fleets converge on the same fact, that's confirmation — when they diverge, that's a story. One briefing audits the information layer the other ones swim in. A single report tells you what happened in a sector. A family of them, with graded forecasts and shared timelines, starts telling you how the whole machine moves — and how reliably anyone, including us, can see it coming.

Part 3 — One paper, two mastheads

The newest layer, and the one I'd have called overkill a year ago: the same reports now publish under two different identities, because the same intelligence serves two different audiences.

On this site, the family is "The State of X" — my byline, my palette, public, indexed, free. At my firm, the identical briefings are being stood up as The AIC Ledger: same paper, rebranded masthead, living behind authentication on the company's internal portal, with each series carrying a Ledger name — the storage briefing below, for instance, ships internally as the Digital Storage Ledger. Two products, one pipeline.

Copy + skin, not fork

The tempting design is a fork: duplicate the pipeline, point it at the second site, let each evolve. That's how you end up maintaining two publications that slowly stop agreeing with each other. The actual design is copy + skin, specified in a short internal doc the way the paper format itself is specified:

The content is byte-identical. Reports are copied from the personal site's folders into the Ledger's, untouched — same facts, same forecasts, same timelines. There is exactly one transformation: each series' accent hex is swapped for the firm's crimson (#B33244), and a grep sweep verifies zero stragglers of the old hex. If the diff between the two editions is ever more than a color, something has gone wrong.
The chrome is the brand. The Ledger gets the firm's navy as a structural color (top bar, section headers, table headers — never as a second accent; the paper doctrine's one-saturated-hue rule survives rebranding), the firm's quill mark, its wordmark type with the letter-spacing the brand guide calls essential, its serif for headlines and sans for body. JetBrains Mono stays as the data voice in both editions — that's part of the product, not the costume.
Attribution is never stripped. The Eidos research credit, the Perplexity credit on the flagship, my byline — all carried over verbatim, with a "for AIC Holdings" line added in the colophon. Rebranding the chrome is legitimate; laundering the provenance is not.
Gating is a choice, not an accident. The Ledger is deliberately not on the public allowlist — the reverse of the Part 2 trap. Same mechanism, opposite intent, and both editions get verified: the public one must never bounce to login, the internal one must always.

The deeper point: because issues are data files (Part 2), a second publication is a copy job with one color swap — not a second pipeline. Every hour spent moving publishing out of code in July paid out again the first time the paper needed to wear a second masthead.

The worked example: standing up series #12

As I write this revision, the twelfth series — The State of Digital Storage — is mid-flight, and it's the first one designed from day one to walk both tracks: it launches on this site first, then gets the Ledger skin. It also doubles as the current answer to "what does adding a series take?" — so here is the complete, honest list of what it took to go from "we should cover storage" to a research fleet in the field:

One config block in the series registry: id stateofdigitalstorage, short storage (canonical URL /stateof/storage), section Hardware, a teal accent pair no sibling uses, a drum-stack icon, the standard Eidos credit. The archive page, viewer, redirects, and PDF cover all exist the moment the block does.
One line in the auth middleware's public allowlist — because I've been bitten by that trap before (Part 2), it's now a checklist item instead of a two-week outage.
One row in the cadence table: day 12, slotted after TrendForce's early-month NAND/SSD contract prints and the prior month's vendor earnings have landed, and clear of the day-10 and day-13 neighbors.
A research fleet's afternoon: three agents in parallel — one on NAND flash and SSDs, one on hard drives, tape, and the cold-archive frontier, one on hyperscaler and enterprise storage plus the consumer edge — each under the Part 2 ground rules: dated facts, source URLs, conflicts reported not blended, hedge flags on anything unconfirmed.
Then the standard line: digest → write → pdf-doctor → ship on the staggered calendar.

That's the whole bill. No new components, no new routes written by hand, no new deploy machinery. When Vol. 1 clears the gates it will appear at /stateof/storage; until it does, it isn't claimed as live — a rule this post now follows about its own subject matter, because a how-to that fudges its own status is exactly the kind of unsourced claim the pipeline exists to prevent.

Credit where it's due

The State of AI remains built and run by Perplexity, exactly as described in Part 1. The eleven newer briefings — twelve, once storage ships — are researched, written, gated, and published by Eidos, and the head-to-head is the experiment. Write the most specific instruction you can stand to write. Then build the machine that holds itself to it, revises its own manual when the mechanics change, and publishes the scorecard.