PRAPI is a tool. brief.md is the substrate.

When you sign up for a PR tool, the first hour is the same every time. Pick a brand voice from a dropdown. Paste your one-liner into a text box. Upload a headshot to their CDN. Tag the outlets you care about. Save.

Six months later you cancel because the tool was not worth the monthly. Your settings disappear with the subscription. The voice rules you spent an afternoon refining, the outlet preferences you tuned by hand, the bio you wrote three times to get right. All gone. Or technically not gone, but trapped behind a login on a server you no longer have access to.

You start over with the next tool. Same dropdowns. Same text boxes. Same headshot upload.

This is the cost of treating brand context as something the vendor owns.

What an operator's brand context actually is

Strip away the SaaS framing for a second. What is your brand context, really?

It is your name, your role, your credentials, your one-liner, your two-liner, your three-paragraph founding story. Your headshot URL. Your short bio for journalist responses. Your long bio for podcast intros. Your visual identity. The phrases you refuse to use ("leverage", "unlock", "platform"). The claims you cannot make ("DCAA-certified" when DCAA does not certify your category). The outlets you respect, the outlets you decline.

That is operational state. It does not change much month over month. It changes when you ship a new credential, take on a new role, or prune your banned-phrase list because a draft kept tripping it.

It is also, structurally, a document. A short one. Maybe two pages of plain text if you write it down honestly.

So the question is not "what tool should hold my brand context." The question is: why is your brand context not just a file you control?

The tool frame is wrong

Every PR tool that exists today treats your brand context as configuration inside their product. PressPulse stores your brand voice in a proprietary database. Featured stores your pitching preferences in a different proprietary database. Qwoted stores your outreach history in a third. None of them talk to each other. None of them export to anything portable. Switching tools means re-entering everything from scratch.

The tool frame says: we are the system, your brand context is our config.

The substrate frame says: your brand context is a file you own, the tool reads it.

Those are not the same thing. The first is captive infrastructure. The second is open infrastructure. The first builds vendor moat. The second builds operator sovereignty.

When PRAPI shipped, we made a structural choice that costs us something: brief.md is the open spec, your file lives in a Git repository you can take anywhere, and other tools can implement the spec compatibly. We do not get to lock you in. The trade is that we have to be good enough that you stay anyway.

What "substrate" actually means in practice

A substrate is the layer underneath. The thing the application sits on top of. PR tooling has always treated brand context as application state: something the tool owns. brief.md treats it as substrate: something the tool reads.

Three concrete things change when brand context is substrate:

1. The same file works across tools. Your operator-brief.md and brand-brief.md files live in plain markdown with structured YAML frontmatter. PRAPI reads them. Any other tool that implements the spec reads them. If PRAPI gets acquired or shut down or stops being good, you fork the file into the next tool. No re-entry. No dropdown re-selection. No headshot re-upload.

2. AI assistants can ingest your brand context as first-class input. When you ask Claude to draft a pitch in your voice, you can hand it your brief.md as context and the output respects your voice rules. Today most operators paste a half-remembered version of their voice into a chat window every time. The substrate version is: there is a canonical document, it lives at a URL you control, and any AI assistant can read it.

3. Search engines and journalist tools can find you. When you publish your brief.md publicly (at yourcompany.com/brief.md or a URL we host for you), search engines index it. Future journalist-side tools that want to verify your credentials, your category, your outlet history can read it directly. Your brand context becomes part of the open web instead of trapped in a vendor database.

These are not future features. They are what plain markdown files in Git do for free, today, the second the tool stops trying to own your data.

Why an open spec instead of "we open-source the parser"

Open-sourcing a parser is the half-version of this commitment. Plenty of vendors have done that and still trapped customer data behind login walls.

The full version is: the file format is published as a spec, the trademark is held by a separate organization, the canonical implementation is one of many possible implementations, and the data lives in plain text the operator controls.

PRAPI does the full version. The brief.md spec is published. The reference parser will be open-sourced once the spec stabilizes. The trademark sits with The Integrity Framework, a separate org that stewards the specification independently of any single tool. Other tools that implement the spec can use the trademark under license. Compatibility is verified, not vibes.

The structural separation matters because it is the only thing that makes the portability claim credible. If PRAPI held the trademark and the spec and the parser, "open spec" would be a marketing line. With The Integrity Framework holding the spec separately, the claim is enforced by org structure, not by promise.

If we shut down tomorrow, the spec keeps going. Your brief.md keeps working with the next tool that implements it. That is the load-bearing commitment. Everything else is downstream.

What this means for an operator who has never heard "open spec" before

If you have not spent your career in software, "open spec" may sound like infrastructure language that is not relevant to you.

It is. Concretely:

You author your brief.md once. Spend an afternoon on the operator brief, then thirty minutes per brand on the brand brief. Drop in your headshot URL, your bios, your voice rules, your outlet preferences. Save.

You sign up for PRAPI. PRAPI reads your brief.md. As journalist queries that match your brand land in your inbox in real time, drafts arrive pre-written in your voice. Submission packages assemble themselves with the right headshot for the right brand attached. You read your inbox, hit send on what is worth sending, move on.

Six months later, hypothetically, you cancel PRAPI. Maybe a competitor showed up with better outlet diligence. Maybe you went back to doing PR by hand. Maybe you took a break. Whatever the reason: your brief.md is still yours. It still lives in your Git repository. The next tool you sign up for, if it implements the spec, ingests it directly. No re-entry.

That is the entire pitch. The subscription is rentable. The substrate is yours.

The dogfood

We publish PRAPI's own brief.md at prapi.dev/brief.md. Fetch it. Read it. The same surface every PRAPI customer gets when they choose to publish their own brief publicly.

This is not a demo. It is the actual operational document our drafting layer reads when PRAPI generates pitches for our own brand. The voice rules in there are the rules our drafts get checked against. The do-not-say list is the actual list. The asset URLs resolve.

If we used a proprietary database for our brand context instead, you would have no way to verify any of that. Because we use a markdown file at a URL, you can.

Where to start

If you want to see what brief.md looks like before you commit to anything: prapi.dev/brief-md explains the structure, the visibility scopes, the editing model, and the relationship to The Integrity Framework. The free brief-generator tool builds a starter brand-brief.md from your homepage URL. No signup. Downloads as plain markdown.

If you want PRAPI to use your brief.md to surface journalist queries, draft pitches in your voice, and ship submission packages with the right assets attached: sign up at prapi.dev. Solo at $49/mo runs one brand. Operator at $149 runs five. Intel at $249 runs ten. Same features at every tier; brand count is the only difference.

The brief.md format is yours either way. The protocol is yours either way. PRAPI is the tool. brief.md is the substrate. The protocol is open.

Use the version of that statement that fits where you are.