Lossless Changelog
component

The Slide Stenographer — One Document Per Slide, and the Archive Renamed Around It

The deck analyst batches five slides per call and merges them, which destroys slide identity by design. A second agent keeps the slide as the unit: render, transcribe verbatim, emit typed content, one markdown file each — plus date resolution, deck lineage, and a renamer that puts a portfolio archive on convention.

Michael StatonMusic Editoraugmented with Claude Code (Opus 5)
new(slides): slide_stenographer — per-slide transcription into markdown
new(slides): slide_schemas — open slide-type vocabulary with typed content shapes
new(slides): date_resolution — cascade that types dates before dating a deck
new(slides): deck_lineage — version vs fork vs sibling, and animation-reveal detection
new(slides): slide_cdn — ImageKit mirror via the prep-images-for-embed skill
new(slides): archive_rename — convention renaming with a reversible manifest
new(tests): regression cover for every failure mode found against real decks

`deck_analyst.py` is untouched, including its JSON, its screenshots, and its
section drafts. The MemoPop workflow depends on it and nothing here changes
that. This is a second mode beside it, invoked deliberately.

The two agents read the same decks at different granularity. The deck analyst
batches five slides per API call and merges the results into one memo-shaped
object — efficient for producing section drafts, and it destroys slide identity
in the process. There is no point at which that pipeline knows what slide 7
said. For a corpus you can search, decks you want to rebuild, and memos that
cite a slide, the slide has to survive as a unit.

So: one render, one call, one document. Text layer first and authoritative for
wording — a PDF's own text is a better record of a heading than any
transcription of a picture of that heading — with Vision reading what the text
layer cannot carry: layout, charts, which people have photographs, what a
diagram depicts. Where they disagree the text layer wins and the disagreement
is recorded.

Four subsystems fell out of running this against real archives.

**Dates need typing, not just sourcing.** A date printed on a slide is not
necessarily the deck's date. One deck's closing slide reads "Closing Sept 30" —
a future deadline, four days after the file was last modified. Another's first
slide reads "BoD Meeting 06-13-2025", which *is* the deck's date; that same file
is named for 09-24 and carries a PDF title naming yet a third date. Same rung of
the cascade, opposite meanings. Dates are now classified by kind
(`deck_date`, `meeting_date`, `closing_deadline`, `as_of`, `mentioned`) and only
some kinds may date a deck. Every resolution records which rung produced it and
at what confidence, and says so out loud when the winner contradicts the
filename.

**Lineage needs three distinctions, and fuzzy matching to make any of them.**
Multiple versions of one deck per round and multiple rounds per company mean
time-series analysis only works if the same logical slide is recognizable across
versions — and if things that are not versions stay out of the series. A deck a
firm assembles from a company's slides is a *fork*, not v2: attributing its edits
to the company misreads the series. Two decks in one round sharing no slides are
*siblings*. A PDF export of a PPTX is a *duplicate*. Authorship is decisive over
overlap. The fingerprinting underneath has to be lenient: an early exact-hash
version reported that a deck and its own export shared 8 of 17 slides when they
share all 17, the differences being line-break placement between two text
extractors. Exact matching fabricates version churn.

**Animation reveals are not slides.** A slide animated so content appears in
stages, exported to PDF, writes each stage as its own page — one slide, five
pages. Untreated, one logical slide becomes five documents and pollutes both the
corpus and the series. The industry calls these "builds"; that word is avoided
throughout because in a codebase it means compilation.

**A portfolio archive is not a dataroom, and its filenames show it.** Files
arrive named for whoever exported them. `archive_rename.py` puts them on the
house convention — `<YYYYMMDD>_<Company>_<Collection>--<Round>/` with each file
carrying its own date — planning and applying as separate calls, every plan
written to a manifest before a file moves, and the manifest sufficient to
reverse the whole thing.

**What the taxonomy is for, and what it is not.** The slide-type vocabulary
exists so a corpus query for "every team slide" returns every team slide. That
requires most slides to land on shared names, not every slide. An earlier
version enforced it: validation rejected an unrecognized type and told the agent
to use `other` instead. Run against a long-form reading deck, that filed eight
slides of organizational design as `other` — a taxonomy gap reported as noise,
with the observation discarded. The vocabulary is now open. An agent that meets
something genuinely new coins a `lower_snake_case` type and explains why;
proposals accrete in `_proposed-slide-types.yaml` with an occurrence count and
the slides that produced them, for promotion into the canon. One sighting is an
oddity; the same coined type across three decks is a type the canon is missing.

**Also included:** `prep-images.mjs` in the `prep-images-for-embed` skill now
kebab-cases each path segment instead of flattening slashes, so `--repo` and
`--slug` can each describe more than one CDN folder level. Backward compatible —
a value with no slash behaves exactly as before.

What a slide document looks like

One file per slide. Machine-readable identity first, then a human description of the layout, then verbatim content as typed JSON, then opinion — the agent's, and below it a section reserved for the reader's. That ordering is the editorial contract: transcription is what the agent is for and comes first; commentary is secondary and stays below the fold, so a later reader can always tell which parts of the file the deck said and which parts an agent thought.

MARKDOWN
---
company: MeridianAI
round: Seed
deck_family: 20240913_MeridianAI_Seed_Reading
deck_variant: reading
deck_version: 1
authored_by: company
slide_uid: 20240913_MeridianAI_Seed_Reading--v1#10
lineage_id: meridianai-team-6af1699060
content_hash: 925c3e4e94095db3
index_position: 10/38
reveal_sequence: 1/3
reveal_canonical: false
reveal_confirmed_by_vision: true
reveal_evidence: vision
date_on_deck: '2024-09-13'
date_source: pdf-meta
date_confidence: medium
date_received: null
date_first_analyzed: '2026-08-23'
date_last_analyzed: '2026-08-23'
dates_mentioned:
- date: '2024-09-13'
  source: pdf-meta
  confidence: medium
  kind: deck_date
  precision: day
  context: PDF creationDate
slide_image_local: ./slides/10.jpg
slide_image_cdn: https://ik.imagekit.io/<id>/example-firm/portfolio/meridianai/20240913-meridianai-seed-reading-v1/MeridianAI__Slide-10--Team_20260823T175842Z.jpg
slide_image_alt: 'Team slide showing nine people with headshots in three columns:
  three PhD founders, three senior ML engineers, and three scientific advisors.'
slide_type: team
core_message: The founding team pairs three PhD neuroscientists with senior ML
  engineers from major technology companies.
tags:
- Team
- Founders
- Advisors
layout_rows: 2
layout_pattern: columns
transcription_fidelity: verbatim
claims_to_verify:
- Founder A is Director of the Computational Memory Lab at University X
- Advisor B received a Guggenheim fellowship in computer science in 2014
- Team spent 20 years on the underlying research
augmented_with: Claude Code on Opus 5 with Claude Vision
path_to_deck: ../../../MeridianAI/20241210_MeridianAI_Dataroom--Seed/20240913_MeridianAI_ReadingDeck--Updated--Seed.pdf
---

# Layout

The layout of the content body is a two row columns arrangement — content split
into equal vertical columns — composed of
1. Title and subtitle framing the team's research background
2. Three columns showing Founders, Engineering, and Advisors, each with
   headshots and credentials

## Row 1, Top

Heading: "FOUNDING TEAM | We Think Different Because We Are Different"
Subheading: "We spent 20 years discovering how the brain actually computes."

## Row 2, Main Body

Each person has a circular headshot, name with credentials, title, and bullet
points of affiliations.

```json-content
{
  "titleRow": {
    "titleTxt": "FOUNDING TEAM | We Think Different Because We Are Different",
    "subtitleTxt": "We spent 20 years discovering how the brain actually computes.",
    "eyebrowTxt": null
  },
  "executivesRow": [
    {
      "fullName": "Founder A, PhD",
      "currentTitle": "CEO+Founder",
      "blurb": null,
      "priorAffiliations": ["University X", "Research Lab Y"],
      "credentials": ["PhD"],
      "imagePresent": true
    }
  ],
  "advisorsRow": [
    {
      "fullName": "Advisor B, PhD",
      "currentTitle": "Consulting Scientist + Advisor",
      "blurb": "Director, Applied AI Lab\nGuggenheim fellowship (2014)",
      "priorAffiliations": ["Institute Z", "Applied AI Lab"],
      "credentials": ["PhD", "Guggenheim fellowship in computer science (2014)"],
      "imagePresent": true
    }
  ],
  "teamStatement": null
}
```

# Analyst Agent Commentary

Strong team pairing deep research credentials with blue-chip engineering
experience. The 20-year research claim positions this as science-first rather
than opportunistic. All three founders hold PhDs and academic positions,
suggesting a university spinout. Missing: specific roles for the engineering
hires, and whether advisors hold equity or are paid consultants.

# Users' Commentary

*No commentary yet.*

A deck.yaml sits beside the slide documents holding what belongs to the deck rather than to any one slide — source path and hash, how it was dated, its variant and version, its reveal groups, and the slide index.

Why

The pipeline could already read a deck. It could not answer "what did slide 7 say", "is this the same deck we saw in June", or "show me every team slide in the portfolio" — and those are the questions that matter once a firm holds more than one deck per company. Decks are also the most repurposable artifact a portfolio company produces: the deck states round context that the executed instruments never mention, and a firm assembling its own materials reaches for the company's slides constantly. Good slide coverage is what makes that legible.

Everything here was shaped by real archives rather than designed in advance, and most of the design decisions above are corrections. The failure modes were found by running the agent and reading what came out.

What's next

  • Rolling context across slides. Each slide is currently transcribed in total isolation — one image, one prompt, no memory of what preceded it. That makes reveal confirmation a guess from a single frame, leaves cross-slide references unresolved, and re-derives the company's vocabulary once per slide. Carrying the previous slides' titles and core messages fixes all three, and makes sequential execution permanent and correct.

  • Version diffing across decks. deck_lineage can classify a relationship and pair slides; nothing yet renders "what changed between v1 and v2" as an artifact.

  • Wiring slide documents into memo generation, so a section can cite a slide by slide_uid and a fact-checker can pull claims_to_verify directly.