Every slide carries its rationale

The thing that rots fastest in a deck isn't the design. It's the reason a slide is in the deck at all.

You start with a clear story. Six months later you've moved the Why-Now slide three times, swapped the Solution slide's hero, added two slides for one specific investor, and forgotten which of those was supposed to land which point. The deck still looks fine. Nobody can tell you what each slide is for.

The fix is a small piece of metadata on every slide.

The shape

interface SlideContext {
  category: string         // short label
  principles: string[]     // which design rules this slide is following
  nailsThis: string        // why this slide earns its place
  storyThread: string      // how it picks up from the previous slide
}

Every slide in the registry has one. It's a required field on SlideDefinition, not optional. If you can't fill it in, the slide isn't ready.

What goes in `nailsThis`

Not "this slide shows our solution." That's title. nailsThis is the argument the slide is supposed to win.

The Solution slide nails the moment the investor realises the problem is one substrate they didn't know existed. It does this by naming the specific pain from the Problem slide ("ten tools, no thread") and replacing it with one image of the substrate ("one place where the thread lives"). If the investor doesn't lean forward here, the rest of the deck is fighting uphill.

Two or three sentences. Specific. Falsifiable in retrospect ("did the investor lean forward?").

What goes in `storyThread`

How does this slide pick up the previous one's open question?

Problem ended on "the work is in the chat thread, not the doc." Solution opens by claiming the thread is the doc. Why-Now answers "why didn't this exist already" — the specific technical shift that makes it possible now.

Each storyThread describes the join. Read them in order and you have the deck's narrative spine, in plain English, in the source.

The rule that keeps it honest

There is one rule, and it lives in DECK.md:

Whenever you edit a slide's component, you must also update its nailsThis and storyThread fields to match. If they no longer match, the slide is broken.

This is a rule for humans, but it's mostly a rule for Claude Code. The agent is the most prolific editor of the deck. If it edits a slide and doesn't update the context, the rationale rots silently. So the rule is in the file the agent reads.

In practice, you tell the agent:

Edit the Solution slide to lead with the substrate diagram instead of the bullets, and update nailsThis and storyThread to reflect the new emphasis.

It does both. The metadata stays current.

At runtime, a small panel in the corner of each slide reads nailsThis and storyThread and shows them. Press C and they appear. Press C again and they hide. It's not a presenter mode — it's a reading mode for the deck author.

When you walk back to a deck after a month, the widget is the first thing you read. It's also the first thing you fix when it stops being true.

Why this beats notes

Slide notes are write-only. Nobody reads them. They live in a separate panel that nobody opens. They are not first-class.

SlideContext is part of the registry. It's typed. It's required. It renders. It's read by the AI editor. The whole point is that it cannot be ignored without it being obvious.

What it gets you

A deck where every slide knows why it's there.
An AI editor that can refactor with intent, not just with structure.
A reading mode that doubles as a working mode.
A deck that survives six months without rotting into a slide soup.

In nopoint, SlideContext is the smallest metadata shape that earns its weight. Nothing else has been worth adding.