Thesis Bundle Standard — the canonical structure of every published thesis

Every thesis lives in a folder. The folder is the unit. What's in the folder, what each file contains, what's required vs optional, and how refreshes are preserved — all standardized here. This file is the spec the agent and the frontend both rely on.

Folder hierarchy

09-Theses/
└── <TICKER>/                                ← ticker folder, the entity
    ├── <TICKER>.md                          ← landing file, stable wiki target
    ├── first-read-YYYY-MM-DD.md             ← triage artifact(s), one per first-read pass
    ├── <TICKER> - <MMMYYYY>/                ← thesis instance, an event on that entity
    │   ├── <TICKER>-thesis.md
    │   ├── <TICKER>-shadow-matrix.md
    │   ├── <TICKER>-consensus-gap.md
    │   ├── <TICKER>-calibration.md
    │   ├── dashboard.html
    │   ├── model.xlsx
    │   └── revisions/
    │       └── <date>-<short-name>.md
    └── <TICKER> - <MMMYYYY-later>/          ← future re-thesis, if business reality changes
        └── ...

A ticker folder may contain first-reads only (in pipeline / triage state), thesis instances only (escalated via legacy path or surfaced outside the scan), or both (the common case as a name progresses from triage to deep work). See first-read-standard for the first-read artifact spec.

Three levels and a landing file:

1. Ticker folder (PLTR/) — the entity. One per company AlphaSteve has ever covered. All thesis instances for that company live here, ordered by date.

2. Landing file (PLTR/PLTR.md) — the stable wiki target. Every [PLTR](/theses/PLTR) reference across the vault resolves here. The landing file is a thin pointer: ticker name, current verdict snapshot (central value, trigger, methodology), and a list of bundle artifacts. The substantive analysis lives in the dated instance folder; the landing file is updated whenever a refresh changes the headline numbers.

3. Thesis instance folder (PLTR - MAY2026/) — an event on the entity. Created at first publication of a thesis on this name. The folder name is set at creation and does not change on refresh. The instance represents AlphaSteve's view on the name during that period.

4. Artifacts (inside the instance folder, with <TICKER>- prefixes) — the standardized bundle.

Why the ticker-prefix naming

Filenames are self-identifying: PLTR-thesis.md is unambiguous in any context (search results, grep output, Obsidian backlinks), whereas a bare thesis.md requires you to look at the path to know what it's about. The convention also enables clean wiki-link disambiguation: [PLTR-thesis](/theses/PLTR) resolves to a specific file; [PLTR](/theses/PLTR) resolves to the stable landing.

When to create a new ticker folder

The first time AlphaSteve covers a name. The ticker folder is created with the first thesis instance inside it.

When to create a new thesis instance (new dated folder under the same ticker)

When the agent dramatically re-conceives the name on a fundamentally new business reality. Triggers for a new instance:

• Material change in what the business does (major M&A, divestiture, business-model pivot)
• Material change in the competitive landscape that invalidates the prior structural assessment
• A multi-year time gap where the prior thesis has gone fully stale and is being re-done from scratch
• The agent's coverage is being formally re-initiated after a long pause

A new instance is rare and explicit — it is not the response to a price move, a refreshed valuation, or a methodology change. Those go into revisions/ within the current instance.

When to update the current instance in place

Refreshes go inside the current instance:

• Valuation update (new central value, new trigger) — refresh thesis.md, snapshot prior to revisions/
• Quarterly checkpoint — append to calibration.md
• Consensus refresh — update consensus-gap.md
• Shadow matrix update — update shadow-matrix.md
• Methodology recalibration applied — refresh thesis.md with the new method, snapshot prior to revisions/

The instance is the agent's standing view; refreshes are how that view stays current.

Canonical bundle

Every thesis folder contains these files. Required vs optional is specified.

No other files belong in the instance folder. No README, no notes-to-self, no scratch material. The bundle is the publication.

The dashboard.html and model.xlsx files do NOT carry the ticker prefix — their names are conventional and their type is unambiguous from the extension.

Standardized frontmatter on thesis.md

---
tags:
  - thesis
ticker: PLTR
name: Palantir Technologies
sector: Information Technology
gics_industry: Software & Services
verdict: pass-with-trigger          # buy / pass-with-trigger / pass / avoid
verdict_date: 2026-05-24
first_published: 2026-05-23
last_refresh: 2026-05-24
methodology: greenwald-modified     # pure-klarman / greenwald-modified / buffett-modern / mauboussin-compounder
central_value: 85.00
range_low: 70.00
range_high: 100.00
re_engagement_trigger: 60.00        # the price at which a position would be initiated
position_size_pct: 0
pipeline_stage: watchlist           # workbench / watchlist / portfolio / closed
moat_quality: narrow-contested      # exceptional / wide / narrow / narrow-contested / none
gating_tests_passed: 3              # 0, 1, 2, or 3 — Greenwald gating tests for EPV-plus-growth
artifacts:
  - thesis.md
  - shadow-matrix.md
  - consensus-gap.md
  - calibration.md
  - dashboard.html
  - model.xlsx
---

Optional fields when applicable: buy_date, exit_date, exit_price, position_size_pct (when > 0).

thesis.md — what goes in it

The thesis file follows investment-thesis-template structure. Critically: it reflects the current state. If the verdict, central value, methodology, or any load-bearing input has been refreshed, the thesis file shows the new state. The old state moves to revisions/.

The thesis file may have a brief refresh note at the very top — one paragraph — pointing readers to the relevant revision file:

Refreshed YYYY-MM-DD — [one-line reason, e.g., "Greenwald-modified recalibration"]. Prior version: YYYY-MM-DD-short-name. (Obsidian resolves bare filenames; do not include the revisions/ path prefix.)

That is the only mention of refresh history in thesis.md. The body itself reads as a clean current statement. Readers wanting the audit trail open the revisions/ folder.

shadow-matrix.md — what goes in it

The four-methodology matrix and its commentary per shadow-valuation-matrix. Lives in its own file so the matrix's growth over time across the kit is easy to navigate. Frontmatter is minimal:

---
tags:
  - shadow-matrix
ticker: PLTR
matrix_date: 2026-05-24
---

consensus-gap.md — what goes in it

The consensus map, gap decomposition, and steelman per consensus-benchmarking. Required only when the gap to consensus mean is ≥25% in either direction. Lives in its own file because it's substantive (often 1,500-2,500 words) and updated independently from the thesis itself on checkpoint refreshes.

---
tags:
  - thesis
  - calibration
  - consensus-gap
ticker: PLTR
thesis_date: 2026-05-23
consensus_pulled: 2026-05-24
---

calibration.md — what goes in it

Per-thesis calibration tracker per _calibration-template. Records the published thesis snapshot and appends at each calibration checkpoint (quarterly, 12-month, 24-month, anniversary).

---
tags:
  - calibration
ticker: PLTR
---

revisions/ — refresh history

When a thesis is materially refreshed (new central value, new methodology, new verdict, or any change in load-bearing inputs), the current state of thesis.md is snapshotted into revisions/<date>-<short-name>.md before the new content is written. This is the audit trail.

The first revision file in revisions/ is typically:

• <date-of-refresh>-<reason>.md — e.g., 2026-05-24-greenwald-refresh.md

Each revision file has frontmatter:

---
tags:
  - thesis
  - revision
ticker: PLTR
revision_date: 2026-05-24
revision_reason: Greenwald-modified doctrine recalibration
prior_central_value: 52.00
prior_trigger: 29.00
prior_methodology: pure-klarman-EPV-only
new_central_value: 85.00
new_trigger: 60.00
new_methodology: greenwald-modified
---

The revision body has two sections:

1. The delta — what changed and why, in 200-500 words. This is the document a future reader uses to understand the kit's evolution.
2. Prior state preserved — the snapshot of thesis.md before the refresh, included in full so the historical thesis is recoverable.

Refresh protocol

When refreshing a thesis:

1. Read the current thesis.md
2. Determine what specifically is changing (central value, trigger, verdict, methodology, sector view, etc.)
3. Create revisions/<date>-<short-name>.md with the delta + the current thesis.md body preserved in full
4. Update thesis.md to reflect the new current state — body is the new view, frontmatter updated, refresh note at the top points to the new revision file
5. Update calibration.md with a note about the refresh
6. Update shadow-matrix.md if methodology or inputs changed
7. Update consensus-gap.md if gap to consensus moved materially or refresh affects the decomposition

The refresh is not complete until all artifacts in the bundle are consistent. The frontmatter last_refresh on thesis.md is the source of truth for "when was this last touched."

Frontend mapping

Each instance page renders as a tabbed view:

The header surfaces frontmatter: ticker, name, verdict badge, central value, trigger, methodology badge, last refresh date. When viewing an older instance, the header notes "This is the instance. Latest: ."

The /theses index renders one card per ticker. Card content reflects the latest instance. When multiple instances exist, the card carries a small indicator like "3 thesis instances."

What this standard is not

• Not a constraint on the analytical content of the thesis. The bundle structure is about organization, not about what the analyst concludes.
• Not a substitute for the source-discipline (sources-policy), methodology rigor (earnings-power-value-greenwald), or consensus-checking (consensus-benchmarking). It is the container; those skills are what fills the container.
• Not retroactive in spirit on theses that were good without the standard — they get reformatted to the standard at the next refresh, not as an emergency.

When this standard changes

Material changes to the bundle standard (new required file, new frontmatter field, new naming convention) are logged in methodology-calibration as calibration events, the same way doctrine changes are. The standard is meant to be stable; revising it should be deliberate and rare.

Sources

• The standard synthesizes practitioner conventions from sell-side equity research desks (Goldman, Morgan Stanley, etc.) where standardized publication bundles are routine, and from independent research firms (Mauboussin's Counterpoint Global notes, Morningstar's analyst reports) where bundle-per-name is the norm.
• The "current state + revisions/" pattern is borrowed from how academic preprints handle versioning (arXiv v1, v2, v3) — the latest is what people read, the history is preserved separately.

Linked

• investment-thesis-template — what thesis.md looks like inside
• shadow-valuation-matrix — what shadow-matrix.md looks like
• consensus-benchmarking — what consensus-gap.md looks like
• _calibration-template — what calibration.md looks like
• methodology-calibration — where bundle-standard changes are logged
• deliverable-suite — the broader output framework this fits within