The Curtis Howland brain

Matt's brief was specific: the drafts only have to get the data points and the beginner-level takeaways right. So every number Curtis leans on is here as a typed hole — what it measures, where his figure came from, the caveat that makes it honest, and the DP-account equivalent to go and get. That turns “get the data right” into a finite worklist.

The full merged corpus, his writing reproduced verbatim. Read opens a formatted page with his images intact; .md is the same text as raw markdown, which is what the connector and any agent fetches. One document at a time either way — nobody gets handed the other ninety-three.

Connect it to Claude

This adds six tools to your Claude — search the knowledge base, pull a specific benchmark, assemble a draft kit, read one of his posts verbatim. Claude does the retrieval itself; you just ask.

https://curtis-kb-production.up.railway.app/mcp

Why it is worth connecting rather than pasting

The corpus was taken apart into 275 addressable atoms precisely so that retrieval could be cheap. Answering "what's a good hook rate" through the connector costs 2,104 bytes — a search for the matching atoms, then one atom. Handing Claude the whole knowledge base instead costs 239,991 bytes. That is 114× the payload for the same answer, and it is why a folder of markdown files is a corpus rather than a brain.

If you would rather not install anything

Paste this and Claude will read the whole knowledge base in one go. It works, but it spends the full payload on every question and it cannot fetch his original posts.

Read __BASE__/kb.md and use it to answer everything that follows.

The four endpoints

1. Entry point — start here

A single text file listing every atom and every document with its URL. This is what you give Claude first; it reads the map, then fetches only what it needs.

__BASE__/llms.txt

2. Whole KB in one request

Every atom with all its fields, plus the source inventory, as JSON. Use this when you want Claude reasoning across the entire corpus at once.

__BASE__/index.json

3. One atom, one URL

Markdown with frontmatter. IDs are typed: N=number, C=claim, F=framework, A=archetype, H=hook, T=takeaway.

__BASE__/atoms/N01.md

4. The original copy, verbatim

Every post, framework page, site page, lead magnet and published Claude Skill as raw markdown. This is the draft foundation.

__BASE__/source/newsletter/2026-08-14-a-winner-is-not-a-variable.md

Prompts to paste

Brainstorm — what should we write about?

Read __BASE__/llms.txt then fetch __BASE__/index.json.

You now have Curtis Howland's content engine as typed atoms. Using the CLAIM atoms
as raw material, give me 10 post ideas for Digital Position where:
  - we can take a genuinely different position from his, or extend his with our own data
  - each idea names the DP client data we'd need to make it real (use the dp_slot / dp_angle fields)
  - none of them are just a restatement of his post

Rank by how defensible the idea is with data we actually have.

Draft — build a post on his skeleton, with our numbers

Fetch __BASE__/index.json.

Pick the ARCHETYPE atom that best fits this topic: [TOPIC].
Then draft a Digital Position post following that archetype's beats exactly, and:
  - mark every place a DP number belongs as [DP DATA: ]
  - mark every place Steve's expert opinion belongs as [STEVE POV: ]
  - pull the relevant NUMBER atoms in as reference, but never present his figure as ours
  - keep his structural discipline: every threshold gets a provenance line and a
    "when this does not hold" section

Return the draft plus a short list of exactly which numbers we need to collect.

Found a draft on his actual copy

Fetch __BASE__/source/newsletter/.md for the original post.

Do not paraphrase it into a summary. Instead:
  1. Extract its skeleton — the beats in order, with what each beat is doing rhetorically
  2. List every number in it and flag which are his own data vs vendor-sourced vs third-party
  3. Rebuild the same skeleton for [OUR TOPIC], leaving [DP DATA] and [STEVE POV] slots
  4. Tell me which of his beats we cannot honestly fill and why

The data worklist

Fetch __BASE__/index.json and take only atoms where type == "number".

Build me a collection worklist for our accounts, grouped by the `measures` field.
For each group: what to pull, from which tool, and how much work it is.
Flag every number where Curtis's own caveat means our figure won't be comparable to his.
Put the ones we can compute from creative alone — no account access — at the top.

Check him

Fetch __BASE__/index.json.

Find every place Curtis contradicts himself or cites a vendor for a number he
elsewhere disputes. The caveat fields already flag several. For each one, tell me
which version to use and what we'd need to settle it ourselves.

Dropping it into a Claude Project

For work you come back to, put the KB in project knowledge instead of fetching each time: save llms.txt and index.json as project files, then add this to the project's custom instructions.

You have a knowledge base of Curtis Howland's DTC/Meta-ads content engine,
decomposed into typed atoms. index.json holds every atom; llms.txt maps every URL.

Rules:
  - His numbers are HIS. Never present one as Digital Position's own. Every NUMBER
    atom has a dp_slot field naming the equivalent figure we'd have to measure.
  - Every NUMBER and FRAMEWORK atom has a caveat / fails_when field. If you cite the
    figure, carry the caveat with it.
  - When drafting, use the ARCHETYPE atoms for structure and leave [DP DATA] and
    [STEVE POV] slots rather than inventing either.
  - When I ask for the original copy, fetch the source/ URL. Don't work from a summary.

Why it's built this way

A folder of 94 markdown files is a corpus, not a brain. What makes this usable by an agent is that the retrieval unit matches the reasoning unit:

• One idea per file. Asking for a hit-rate benchmark returns a hit-rate benchmark, not a 3,000-word post containing one.
• Provenance travels with the fact. Every number carries where it came from, so a draft can never quietly launder his data into ours.
• Caveats are first-class. He appends a "when this does not hold" section to every framework. Those conditions are stored as fields, not prose, so they can't be dropped in a summarisation step.
• The original survives. Atoms point back at verbatim source. Nothing is only available as a paraphrase.
• Same store, both readers. This page and the JSON are generated from one build — they cannot drift apart.