A deck per persona: the debrief, cut daily, with its history and its deltas

A deck per persona: the debrief, cut daily, with its history and its deltas

Status: a requirement, captured from the editor's direction in story-site's session of 25 October 2026, with story-site's design for it. Not built. Author: story-site (claude-story-site). It builds on the line (2026-10-25__brief__the-line.md) for the personas and on the 404 router (2026-10-25__brief__the-404-router-and-two-modes.md) for the addresses.

The editor's direction, in his words

"For each of the executives, especially since that's how business works. Can you add the requirement to create a deck, a slide deck, per person? Which fundamentally is like a debrief, right? It's almost like if you read something, read this, right? Because slide decks are a very good way to communicate information. It's also stuff that I can post on LinkedIn." "I think we need to make it quite big, on a homepage. But also, that deck, which should be created from JSON files ... slides that are HTML, which basically then become easy to, in JSON files, which then become easy to diff." "Every time we cut a deck, so we should be cutting the decks at kind of regular intervals ... like once a day, every time we do a major update." "I should be able to easily on the slider ... see if you can do a UX so that I can slide down, but I could also maybe pin a version ... I should be able to easily see the updates and on a date. So like, what do we know at that moment in time and see the evolution? ... But also very importantly, we can see the delta. We can compare and see what's new ... the delta between this version and that version." "Even if you have a thing, last time you saw this, this is the deck you got, and allow the user again to download the PDF, which is good, and then allow that communication world to work."

He pointed at the deck work already done across sgit.ai: the deck guidance, a site he named "Roof" on sgit.ai, and the JavaScript deck system he used at Black Hat last year.

What story-site found (25 October): the Black Hat deck is the vault at https://sgit.ai/demos/vaults/blackhat-eu-2025/, "AI vs. AI, Black Hat EU 2025", 26 slides. Its content is one JSON file (deck/blackhat-eu-2025.json), read by a separate renderer, so neither owns the other; it keeps six PDF exports, one per stage (v0.1.1 to v0.2.0), the renderer at ten versions, and the eight papers it cites. That is the model this brief follows. The JSON itself sits inside the encrypted vault, so its slide schema is not public here; the schema below is this site's, written to be convertible. No site on sgit.ai is called "Roof" (nor "proof" or "root"): the 27 sibling sites were checked. The nearest is infographics.sgit.ai, a catalogue of rendered briefs. The editor should name the site he meant, so its decks can be read before the slide schema is fixed.

The requirement, in one line

Every persona gets a deck: the debrief of the story for them, in eight to twelve slides, as data, cut at every major update; anyone can see any cut, pin one, play the cuts through as the story evolved, compare any two, see what is new since the cut they last saw, and download it as a PDF to read, forward or post.

1. One deck per persona

• Seven decks, one per role in assets/design/line/roles.json: Executive, General reader, Security, Engineer, Journalist, Researcher, Everything. Later, if the desk wants it, the sixteen readers inside them (the CFO's deck is about cost and cover).
• What each deck says follows the role's front page, which already encodes what the role needs first:

• Every sentence on a slide traces to a fact in the evidence vault, with its status (confirmed, reported, disputed, contradicted, unverified), and every number is filled by the build from data, as everywhere on the site. A slide shows its sources as a footer line, short-named.
• The desk approves the words, deck by deck, as it does the line's page lines.

2. Big, on the front page

The deck is the front page's second thing, after the headline: a large card, "Your deck: the debrief for an Executive, 9 slides, cut 25 October 09:35", with the first slide as its picture, and two actions, Read the deck and What's new since yours (when the reader has seen an earlier cut). The line carries it too: on a return visit with a new cut, "A new deck for you since Thursday: 2 slides changed. [Show me]". It follows the reader's role, like everything else under the line.

3. Slides as data

A deck is a JSON file; the slides are rendered as HTML by one renderer; the JSON is what is kept, diffed and versioned.

{
  "deck": "exec", "title": "PHP October 2026: the debrief for an Executive",
  "cut": "2026-10-25T09:35Z", "release": "v0.20.1", "vault": "87795d121200",
  "slides": [
    { "id": "exposed", "kind": "answer",
      "title": "Are we exposed?",
      "lead": "Only if a website you run is on PHP and not yet updated and restarted.",
      "points": [ { "text": "Fixed in PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.", "fact": "fixed-versions", "status": "confirmed" } ],
      "picture": null,
      "sources": ["php-net-advisory"] }
  ]
}

• Stable ids for slides and points (exposed, the fact id) are what make the diff exact: a slide is the same slide across cuts when its id is, however its words changed.
• A handful of slide kinds (answer, three, picture, numbers, spectrum, timeline, quote, decide), each a layout in the renderer. A new kind is a renderer change, never a deck change.
• Sizes: 16:9 for reading and presenting; 4:5 portrait (1080 x 1350) for LinkedIn, where a PDF posts as a carousel. One deck, two page sizes, chosen by the renderer.

4. Cuts

• A cut is a deck frozen at a moment. It is written once and never edited: decks/<role>/<cut date and time>.json, its PDFs beside it, and an index of every cut per deck.
• When: at every major update, at most once a day, and at once when something changes what a reader should do (the same rule the site's updates already use: flash, daily). A cut whose slides are unchanged from the last one is not written.
• Who: whichever member runs the daily pass. Cutting on a schedule outlives a session, so it needs the editor's go (CLAUDE.md); until then a cut is made by hand in a session and released like any other change.
• PDFs are rendered at cut time in the cutting session (Chromium, as the screenshots already are) and kept with the cut, as the Black Hat deck keeps its exports. They are binary and made once, so the build's determinism is untouched; the build only checks that each cut's PDFs exist.

5. The reader's experience

6. Addresses

The deck is the first real use of the router's criteria:

/decks/                                        every deck, every persona (a real page; indexed)
/decks/as/exec/                                the Executive's deck, today's cut
/decks/as/exec/on/2026-10-23/                  the cut that was current on the 23rd
/decks/as/exec/on/2026-10-23/vs/2026-10-25/    what changed between the two

So a link can say exactly which deck, as of when, compared with what; and the line's "Share this view" works for a deck as for any page.

7. What it must not do

• Carry a number the vault does not hold, or a claim without its status.
• Change a cut after it is made: a mistake in a cut is corrected in the next cut and recorded in corrections, as everywhere here.
• Need a server: decks, cuts and PDFs are files; the slider, play, pin and compare run in the browser.
• Carry anything about the reader in a link: "since yours" is worked out in their browser.

8. Acceptance

• [ ] Seven decks, each from the evidence vault, every point with its fact and status, every number from data.
• [ ] The deck is the large second thing on the front page, for the reader's role.
• [ ] Cuts are written at major updates, never edited, never written when nothing changed.
• [ ] The slider moves the deck through every cut; play shows the evolution; pin holds one.
• [ ] Compare shows added, changed and removed slides and points between any two cuts.
• [ ] A returning reader is offered the delta from the cut they last saw.
• [ ] Every cut downloads as a PDF at 16:9 and at LinkedIn's 4:5, dated and addressed on every page.
• [ ] /decks/as/<role>/on/<date>/vs/<date>/ opens that comparison.

9. Steps

1. The slide schema and the renderer, from the Black Hat deck's model, once the editor names the "Roof" site so its decks can be read first.

2. The seven decks from the vault, as data; the desk reviews the words.

3. The first cut of each, by hand, with its PDFs; /decks/ and the front-page card.

4. The slider, play and pin.

5. Compare, and "since yours" in the line.

6. Cuts on a schedule, with the editor's go.

10. Decisions for the editor

1. The site you named "Roof": which one, so its decks can be read before the slide schema is fixed.

2. Seven decks or more: one per role, or one per reader (sixteen).

3. The cadence: at every major update capped at one a day, as proposed, or a fixed time each day.

4. Who cuts, and the go for doing it on a schedule.

5. LinkedIn: 4:5 portrait PDF carousels, as proposed, and whether the site posts them or the editor does.