The three words get used interchangeably, which is how teams end up with a twelve-page document that is bad at everything. The clean way to tell them apart is not by length or template. It is by the job each one does.
The three jobs a PRD used to do
The most useful frame I have found, and the one a thread of twenty-one PMs converged on, is that the old PRD did three separate jobs inside one document:
Alignment. Getting the team to a shared picture of what we are building.
Commitment. The obligations we are on the hook for: regulatory, contractual, SLA, and business rules.
Memory. Why we built it this way, so future iterations do not drift from the original problem.
A wall of prose is the wrong format for all three. So the artifacts split, and each job goes to the format that actually holds it.
What belongs in the brief
The brief carries the why and the memory of purpose. It is one page, hard cap, and it is the thing you reread at every major decision. If it does not fit on a page, you are describing the solution, and the solution does not belong here.
A brief contains the problem (who has it, how often, what it costs them today), the specific user, why now, the bet stated as one sentence ("if we do this, then this measurable change"), one primary success metric plus one guardrail, the non-goals, and the open questions. That is it. A document you reread is memory. A document you do not is an archive.
What belongs in the spec
Here is the part most teams get wrong. In the AI era the spec is not a prose document. The commitments (the SLAs, the compliance rules, the acceptance criteria) are best encoded as evals that fail the build.
A paragraph that says "p95 latency must stay under 200ms" is a hope. An eval that fails the build when p95 crosses 200ms is a commitment. A GDPR data-residency clause on page nine is a liability waiting to be forgotten; the same clause as a guardrail eval blocks any build that routes EU data to a US endpoint. If it matters, it fails the build. That is what a spec is now.
What belongs in the prototype
The prototype carries the solution and does the alignment job. When the ambiguity is about flow or interaction, prose is lossy: every reader renders a different picture. The prototype is the shared render, and it removes ten rounds of interpretation. It is also the least valuable of the three artifacts, and that is by design. Its job is to align the team, then be rebuilt properly. Do not fall in love with it.
The one-line test
Six months ago I wrote my last twelve-page PRD. Two engineers read it. One asked me to just show him what I meant. I built it in forty-five minutes and they shipped it in a week. The document was not the thing keeping the context safe. It was the thing letting it rot quietly in a file nobody reopened.
So when you are about to write a "PRD," ask which of the three jobs you are actually doing. If it is the why, write the one page. If it is a commitment, write the eval. If it is the solution, build the prototype. Pick your next feature and run it that way.