Someone built RCF from the docsCopy link

Everything I've published about RCF so far has come off my own builds. That's fine as far as it goes, but it leaves an obvious hole. I'm the only one who has ever run it, so I'm also the only one who could tell you whether it works, and you'd be right to discount that. This month the hole closed.

Sebastian Beaton runs BrightIQ: UK, one human doing strategy and clients and sales, an AI operations team on Claude Code doing most of the rest, selling SEO audits, AI automation and AI assistants without the agency overhead. Seb and I talk shop most weeks and trade tooling ideas constantly. He did not build this by asking me questions. He scraped the RCF corpus off this site (19 methodology pages, 5 blog posts), distilled it, and built a working PRD engine on top of it. Then he wrote up what happened, defect log included, and sent it over.

So this is the first implementation of RCF by someone who isn't me. What held, what he bent, and the criticism he came back with.

What he builtCopy link

A single Claude Code skill, invoked as /prd, with five modes. Create runs an AI-led extraction interview, one question at a time, four passes (intent, behaviour, architecture, the last twenty percent), then drafts the chain section by section with a human gate after each. Audit is read-only: it scores an existing PRD against a 29-check weighted checklist and hands back a confidence score out of 100 and, far more usefully, a line-cited gap list. Enhance restructures an existing document into the full chain without touching the original file or renumbering a single ID. Grill is an adversarial interrogation (pre-mortem, inversion, stakeholder walk) that always finishes as the build agent reading one slice cold, and every answer has to land as a concrete edit or the question wasn't worth asking. Sync re-audits the PRD against what actually shipped.

Under that sits a 13-section template carrying the whole Y-chain in one document, and a set of hard rules baked into the skill's contract: never invent business facts, so gaps become named questions rather than made-up answers; stable opaque IDs, never renumbered; drift only through Decision Traces; human-only approval, recorded with version and gaps acknowledged.

Some of my own sentences ended up as load-bearing instructions inside his tooling. "One acceptance criterion, one test suite, no negotiation." "Out-of-scope is as load-bearing as in-scope." "The trust sits with the contract, not the agent." I wrote those lines to persuade people. Reading them back as string constants in someone else's code is a strange feeling, and a good one.

The best call in the build is two hundred lines of PythonCopy link

Seb wrote a deterministic chain linter, stdlib Python, roughly two hundred lines, and it runs before any LLM judgement gets a look in. ID uniqueness. Chain closure from REQ to US to AC. Every AC owned by exactly one build slice. All five FBS fields present. Dependency resolution and DAG (directed acyclic graph) acyclicity. Traceability consistency. "TBD" smells. Exit codes and a JSON mode so it drops into a pipeline.

He calls it his small-scale version of rcf validate, the chain linter in rcf-build-lite, the open-source RCF tooling I'm building and still early at v0.2. He rates it the cheapest component in the system and the one that pays back most. I'd put it stronger than he does. Everything mechanically checkable gets proven by a script that cannot hallucinate, and the model only gets asked the questions a script can't answer. IMHO that ordering, deterministic first and judgement second, is the one I'd hold to on anything built on top of an LLM.

Where he bent itCopy link

Two deliberate adaptations, and I like both of them more than I expected to.

He collapsed eleven artefact files into one document. A solo operator with an AI team maintains one file per product better than a document set, so the file boundaries went and the chain's structure stayed: IDs, pointer fields, cardinality, all intact. For larger products specced as numbered document spines, his tooling treats the folder as one logical PRD with a shared ID namespace. That isn't a dilution of RCF. That's RCF sized to a one-person shop, and the fact it survives the resize tells me more than strict fidelity would have.

Then he added a numeric confidence score out of 100, and his own adversarial review shot it. Ask an LLM to score the same document twice against the same rubric and you get two different numbers; plus or minus five points is noise. So the standing rule became "the gap list is the deliverable; the score is triage", and no decision fires off the number alone. He demoted his own feature on the evidence rather than defending it. I'd have argued for exactly that, and I didn't have to.

The first runCopy link

The test subject was a real internal fix-plan for a usage-tracking feature. A good prose plan with no testable structure in it at all. Before: 14 linter errors, zero requirement IDs, zero stories, zero acceptance criteria, zero build slices. A human could build from that. An agent would guess.

One enhance pass produced 4 requirements, 4 user stories, 19 Given/When/Then acceptance criteria and 3 build slices, and the linter came back clean. Every ID connects, every AC has exactly one owner, the DAG is acyclic. Zero invented facts. Everything the source plan was silent on became a named open question instead of a fabricated answer. The ACs also surfaced boundary behaviour the prose only implied, the sort of decision an agent otherwise makes silently and never tells you about.

Then the part I keep re-reading. During the pass, the system checked one of the plan's verification claims against the live data file the plan referenced, and found the plan was wrong. The plan cited a quality score of about 9.3 and a "parked" status. The real ledger held 8, and no such field existed. It didn't copy the error forward and it didn't silently correct it either. It filed a Decision Trace: trigger, evidence, affected IDs, three options, with "hardcode the assumed values" explicitly rejected as inventing data. A human ruled. An ADR was amended. A new gap was filed. It also noticed the ledger carried two incompatible record schemas and wrote a normaliser ADR for that too.

That's the theatre defence working on real data on day one, in a business that isn't mine, on a plan I have never seen. A factual error caught before a line of code was written. I've been making that argument for a year on the strength of my own builds, and this is the first time I can point at someone else's.

The layer nobody else shipsCopy link

Before using any of it, Seb ran the design against the July 2026 spec-driven-development field: GitHub Spec Kit, AWS Kiro, BMAD, OpenSpec, Tessl. Two findings worth carrying if you're weighing RCF against those.

First, the sharpest published critique of SDD, that a spec answers what while a requirement answers what we need and why, lands precisely where RCF sits. The requirements layer above the spec is the layer the tooling doesn't have. He chose RCF for that reason specifically, not because he liked the prose.

Second, and this is the one that moved his own roadmap: the loudest unsolved practitioner complaint across all of those tools is post-build spec-code drift. Specs describing flows the code no longer implements. Nobody ships enforcement for it, including the best-funded player in the space. Which re-ranked /prd sync, the living-spec layer he'd built off my living-spec and traceability pages, from afterthought to the differentiating component of his whole system.

I'd steal one more thing from his five-persona adversarial council, because it's a better acceptance test than any score. Hand one build slice cold to an agent and count the clarification questions it asks. Target zero.

The gap I left open on purposeCopy link

His report carries a criticism, and it's the right one.

Post-run QA on that first PRD found two finishing defects. One matters. A Decision Trace revision was applied in one section and left stale in another: the linter passed while the prose lied. That is semantic drift demonstrated precisely, and RCF has no detection for it today. Seb names the absence and asks for the ripple discipline to get first-class treatment, so every value a revision touches gets updated everywhere, greppably.

He's right that the capability isn't there. The reason it isn't is worth stating plainly, because this is sequencing rather than oversight.

RCF as it stands is pointed at build. Semantics is a much larger subject than a lint rule, and it belongs upstream of where RCF currently starts. The work I'm on now covers generation, analysis, improvement and impact across the whole document set: PRD, REQ, US, AC, TAD, TAC, ADR. Once semantics is handled properly in the upstream layer, understanding what a document means rather than checking that its IDs connect, the capability feeds back down into the build layer and drift detection comes with it. Bolting a semantic checker onto the current chain would have caught the easy half and missed the half that actually hurts, which is worse than not having it, because you'd trust it.

In the meantime Seb's mitigation is the one I'd give anyone else. A deterministic linter for what's mechanically checkable, a named ripple rule for what isn't, and a human on the gate.

What I take from itCopy link

His tool is live in daily operations now, wired into the dev-agent's workflow with a standing rule that no autonomous build starts from an unscored PRD. Next he's running enhance and grill across the active build queue, then handing one slice cold to the harness and counting the questions.

What I got out of this is the thing you cannot get from your own builds. RCF bent in two places to fit a business shaped nothing like mine, and it bent without breaking. The parts Seb ranked most load-bearing from actual practice (never invent business facts, the AC wish test, stable IDs and pointer fields, out-of-scope stated positively) are the parts I'd have ranked myself, which is more of a relief than I'd like to admit. And the one gap he found is the one I already know about and am already working upstream of.

Thanks to Seb for doing the work, and for writing it up straight rather than writing it up flattering. If you want to see what a one-person shop running an AI team actually looks like in daily operation, he's worth your time.