Specroot Waitlist open · ⟨N⟩ teams

One specification. One graph. Every document a read of it.

Business intent down to work items, held as linked records. Nothing is a copy, so nothing can drift — and nothing enters it until the people who have to agree with it have seen it.

A pull request, for documentation.

One record · top to bottom traced
Business BR-004Private, reviewable specification
Use case UC-005Approve a baseline
Functional FR-040Approve a baseline
Criterion AC-118The approval records who and when
Work item TASK-036Comment, approve, decline

Our own specification, in the product

Why it matters

The way it works now, and the way it works here.

The way it works now

The way it works here

Documentation goes stale, and the agents reading it drift and invent.
Every document is a read of one record, drawn the moment you open it.
Big documents are noisy — the content buried in sources and context — and they get worse the more you have.
A record says one thing; links carry the rest. You read a slice, not the pile.
There is no history and no traceability. The reasoning was in a meeting.
Every version points at the decision that caused it, with the reasoning and who confirmed it.
Neighbouring statements contradict each other, and nobody finds it in time.
A conflicting statement is raised in the session, with both records shown.
Terms drift, because no agent will hold one word for long.
Terms are records in the same graph, linked like everything else.
Tickets go stale, and updating what sits above and below a change is a day's work.
A confirmed change marks every record it affects, and a work item is pinned to the versions it was built from.
Developer tools solve the developer's half, and stop at the developer.
One address, one sign-in, and nothing merges until the people who have to agree have agreed.

Every one of those is the same problem wearing seven coats: the specification exists in more than one place.

We surveyed 35 products before building this. None of them does the right-hand column. Ask and we will send you the list.

Six things that follow from holding it once

Rendering

No document is a copy.

Every document is a read of the graph, drawn the moment you open it. There is nothing to push anywhere and nothing to pull back down, so there is no version of the truth sitting in a wiki going quietly out of date.

A section nobody has captured yet says so, in place. A read that fails keeps the last content and marks it — it never shows you something wrong and stays quiet about it.

Functional specification · live 73 records
§ 1Repositories and analysis
7 records
§ 2The session and the interview
14 records
§ 3Review, approval and merge
18 records
§ 4Transcript import
not captured yet
§ 5Cost and metering
out of date · last good read 14:02

Our own specification, in the product

Scope

A record says one thing.

A record holds what the specification says and nothing else — no meeting context, no sources, no history stapled to the end. What it depends on and what depends on it are links, not paragraphs.

So you never read the pile. You read a slice: one record and everything under it, or one level for one reader. The document gets smaller as the specification gets bigger.

FR-040 · Approve a baseline accepted

Answers to

BR-004Private, reviewable specification
business
UC-005Approve a baseline
use case

Checked by

AC-118The approval records who and when
accepted
AC-119An approved baseline cannot be re-frozen
accepted
Document scoped to this record and everything below it
9 records

Our own specification, in the product

History

Nothing is edited. Everything is a version.

A record keeps one stable name with versions underneath it, and every version points at the decision that caused it — with the reasoning, the options that lost, and who confirmed it.

The reasoning is written at the moment somebody says yes, not reconstructed at the end of a long session. That is the step where every other tool loses it.

ADR-039 · decision accepted
v1→v2→ v3 · current confirmed 17 Aug
Context
Six months after approving, a client opens the address they were sent. Some records in it have moved on. It either shows what they approved, or what is true now — and those answer different questions.
Decision
What a client approved stays readable, unchanged, permanently — at the approved baseline's own address, which never reads current state.
Not chosen
Show current content with a note that the approval is out of date — it shows a client content they never agreed to.
Not chosen
Show current content with the differences marked — the best answer to both questions, and it needs a comparison the first release does not build.

Our own specification, in the product

Consistency

A contradiction is raised, not settled.

When something you say conflicts with a record, the interview stops and shows you both. It does not pick a winner, and it does not quietly overwrite the older one.

Terms are records in the same graph as the requirements, linked like everything else. When a word turns out to name two different things, it is withdrawn on the record — with what replaces it and why. That is what stops the drift.

Conflict · raised in session needs an answer
You said: “a set is what a session produced.”
TERM-002 says: a set is a line of work that stays open and gets merged. Both cannot be true.
TERM-002Set
withdrawn
TERM-011Baseline
a frozen point
TERM-024Change set
a line of work

On the withdrawn term

“The word named two things at once. Use baseline where the sentence points at a moment, change set where it points at work.”

Our own specification, in the product

Impact

You see what a change breaks before it lands.

A confirmed decision does not just get written down. It passes a gate that marks every record it affects — upstream and downstream — so the list of what needs revisiting is produced for you, not hunted for.

And a work item is pinned to the exact record versions it was built from. When those move, the item says so. Nobody builds last month's requirement by accident.

Decision applied · what it touches 11 records marked
FR-022Closing a session freezes its baseline
revisit
FR-032The author opens a review on the latest baseline
revisit
FR-033Nothing freezes while anything is unsettled
unaffected
AC-207A frozen baseline names one version of every record
revisit

Work item built from these

TASK-027Close and freeze
basis moved
pinned to FR-022 v2 · FR-032 v1 · FR-033 v1

Our own specification, in the product

Review and merge

The people who have to agree with it can actually read it.

You open a review when you are ready. One address lands your client on the document — no project tree, no tool to learn — with what changed marked and the state beside it.

They comment. You are emailed. They approve or decline, and that is recorded with who and when, at an address that keeps showing it for as long as the project exists. Nothing merges until they do.

Review · Payments, business level frozen 18 Aug
§ 2  A refund is issued against the original payment only.
+ § 2.1 A partial refund is allowed once, and never after 90 days.
§ 3  A failed payment is retried twice, then abandoned.
Maria (client): Ninety days is wrong for corporate accounts — those settle on 120.
Author emailed · correcting session started from this comment
automatic
Approve Decline Merge — blocked until approved
Baseline 12 AugApproved by Maria · 12 Aug
stale · basis moved

Our own specification, in the product

Proof

This product's entire specification was built with the product itself.

⟨FOUNDER — one or two lines: who is building this, and why they have run this loop before. Operator's own words.⟩

Questions we expect

Answers, not a sales call.

“Free tools already write specs.”

They do, and they are good at it. What no free tool gives you is a client who has agreed to the specification, or a mechanical answer to what a change would break.

“We already pay for Confluence.”

Keep it — the wiki is fine. This replaces the specification round-trip: pushing documentation up to be reviewed, pulling the edits back down. That loop disappears.

“Why not a requirements-management suite?”

Because your client will not log into one. The median buyer of the leading suite pays $76,500 a year for traceability wrapped in enterprise process.

“Does my client need an account?”

Yes — one sign-in from an email invitation, then a single address that lands them on the document. No anonymous links, on purpose: an approval is worth something only when it is provable who gave it.

“Is our data safe?”

Your code is read, referenced by commit, and discarded — never stored. Your specification is stored, private, visible only inside your own tenant, and never on a public page.

The first group is small on purpose.