On this page

Related reading

← RCF

Concept

Theatre risk and the human signature

RCF reduces theatre risk through standards, AI-assisted extraction, visible gaps and human approval. These safeguards make documents harder to approve without checking their substance. They cannot eliminate the risk.

Last updated

Theatre risk is the failure mode where a methodology’s artefacts get written to satisfy the form rather than the function. RCF’s defence is structural: standards, AI-assisted extraction, the visible gap, and a human signature at the approval gate.

What “theatre” means here

The term comes from a critique of BDD: Gherkin scenarios written after the code can appear to have guided it, even though they only describe the existing implementation. Correct Given/When/Then formatting does not establish that the scenarios determined what was built.

The same failure can affect any methodology artefact. PRDs, TADs, acceptance criteria and test suites can satisfy a template without guiding the work. Tests written against existing code may verify its behaviour without verifying the intended criterion. This can happen without malice when time pressure and tooling allow teams to fill in documents after implementation.

No methodology can prevent a team from using it superficially. Short-term goals and reactive decisions can weaken the process without the team noticing. RCF makes these failures harder to produce and easier for a reviewer to identify.

The four parts of the defence

The same four safeguards apply at every layer of the chain.

Standards and checklists

Standards define what each artefact MUST and SHOULD contain. A PRD needs non-functional requirements, a TAD needs recorded decisions, and an AC needs an observable expectation. Organisations supply the content standards. Regulated work may require more mandatory checks than greenfield SaaS. Every project must have standards.

Standards distinguish a complete artefact from a document that merely uses the right title. A reviewer can check whether it meets the required content checklist.

AI-assisted extraction

AI gathers information through stakeholder conversations, supported by prototypes, existing documentation and research. It asks questions, identifies missing information and drafts content against the standards. The human commits to the resulting content.

Stakeholder involvement prevents the artefact from becoming a copied template or an AI-generated document without human input. The AI asks questions that stakeholders may otherwise omit.

The diff between what’s present and what’s required

Compare the gathered information against the standards. Record each missing item explicitly. The artefact is incomplete until the team supplies the information or records a deliberate decision to omit it.

A filled template can appear complete while missing required information. Recording the gap makes that incompleteness explicit. A team may approve an incomplete artefact, but the record must identify what remains missing.

The approval gate

Approval is recorded on a commit. The record identifies who approved the artefact, when, which version they approved and which gaps they acknowledged. The human signs against the artefact, its standards and its recorded gaps.

The approval commit records the human signature on the artefact that will guide the next stage. That signature is auditable, attributable and tied to the approved version.

The four-part anti-theatre loop and its layer instances A four-part clockwise loop arranged as a two-by-two grid. Standards (top-left), Extraction (top-right), Diff (bottom-right), Approval gate (bottom-left). Solid burnt-orange arrows run around the perimeter from Standards to Extraction to Diff to Approval and back up to Standards, closing the cycle. Each card describes its role on one line and the theatre failure mode it prevents on a second line. Standards prevents self-declared artefacts. Extraction prevents template recycling. Diff prevents looks-complete deception. Approval gate prevents rubber-stamp sign-off. On the left of the figure sits a sidebar listing the layers of the document chain the loop runs at (PRD, TAD, AC, FBS, Tests, and Code, the code-node layer that forks off the acceptance criterion). The caption above the sidebar notes that the same loop runs at every layer, with layer-specific content; a dashed line connects the layer column to the loop diagram to make the visual link. The loop runs at every layer of the document chain: PRD, TAD, AC, FBS, Tests, and Code. The shape is the same at every layer; the content of each part changes layer by layer. At every layer same shape, different content PRD. The product requirements document layer. Standards: the org's PRD checklist. Extraction: product, stakeholders, sometimes customers. Diff: gaps against the checklist. Approval: human sign-off committing the PRD as the upstream contract. PRD product requirements TAD. The technical architecture document layer. Standards: architecture checklist. Extraction: tech architecture, security, devops, infrastructure. Diff: gaps in the architecture treatment. Approval: tech architect sign-off, co-signed where the decisions touch other domains. TAD technical architecture AC. The acceptance-criteria layer. Standards: a minimum schema of happy paths, error modes, failure paths, edge cases, observable expectations. Extraction: AI drafts ACs from REQ, TAD, US, against the schema. Diff: schema coverage check. Approval: product owner signs off the AC set against the schema. AC acceptance criteria FBS. The functional build specification layer. Standards: FBS template (storyScope, dependencies, build context, testable outcomes, status). Extraction: AI assembles the FBS from the build sequence and in-scope stories. Diff: any missing field is visible. Approval: tech lead or accountable engineer commits the FBS as ready-to-build. FBS build specification Tests. The test layer. Standards: test cases cover the named happy paths, error modes, failure paths, edge cases declared on the AC. Extraction: the coding agent drafts the tests against the AC, in a separate context from the code. Diff: any AC category without a test case is loud. Approval: review and commit of the suite happens before the code-writing pass starts. Tests verification cases Code. The code-node layer (CN), the eleventh RCF document kind, forking off the acceptance criterion. Standards: every acceptance criterion a build delivers owes a Code Node. Extraction: the build agent authors the CN as it writes the code, while comprehension of the change is already paid for. Diff: the mark-complete gate refuses to close a build that leaves an AC with no Code Node. Approval: the CN is committed and rcf validate walks the spec-to-code edge, so a rename, move or delete that breaks the link is caught. Code code node (CN) Standards and checklists. The MUSTs and SHOULDs each artefact owes. A PRD that does not state its non-functional requirements is not a PRD; a TAD without its decisions is not a TAD. Standards make the form non-trivial. Prevents: self-declared artefacts (any document that names itself a PRD). 01 Standards the MUSTs and SHOULDs each artefact owes Prevents self-declared artefacts AI-assisted extraction. AI-led conversation that draws content out of humans, prototypes, prior docs, research. Asks the questions the human would have skipped; surfaces missing pieces; drafts text against the standards. Prevents: template recycling (last quarter's doc with names changed) and, paired with standards, prevents an AI-written novel. 02 Extraction AI-led conversation draws content from humans + inputs Prevents template recycling The diff between present and required. Standards declare what must be present; extraction produces what has been gathered; the difference is a structured gap, visible and named on the page. The artefact is not green until the gap is addressed, by gathering or by deliberate decision to defer. Prevents: looks-complete deception (form is filled in but content is missing). 03 Diff visible gap between gathered and required Prevents looks-complete deception The approval gate. Approval is a recorded act, not a meeting outcome. Signature on a commit, against the artefact version, with the gap acknowledged. Auditable, attributable, tied to the artefact version it actually signed. Prevents: rubber-stamp sign-off and the meeting-outcome version of the human signature. 04 Approval gate human signature committed against artefact + diff Prevents rubber-stamp sign-off The four-part anti-theatre loop (vertical layout) A vertical stack of four cards covering Standards, Extraction, Diff, and Approval gate, connected by solid downward arrows. A dashed burnt-orange arc on the left side loops from the bottom card (Approval gate) back up to the top card (Standards), closing the cycle. Each card names the part, its role, and the theatre failure mode it prevents. Below the loop sits a layer sub-section listing the layers of the document chain the loop runs at (PRD, TAD, AC, FBS, Tests, and Code, the code-node layer that forks off the acceptance criterion), captioned to indicate the same loop runs at every layer with layer-specific content. Return arc closing the cycle. Approval gate returns control to Standards for the next iteration or the next layer of the chain. Standards and checklists. The MUSTs and SHOULDs each artefact owes. Prevents: self-declared artefacts. 01 Standards the MUSTs and SHOULDs each artefact owes Prevents self-declared artefacts AI-assisted extraction. AI-led conversation draws content from humans and inputs. Prevents: template recycling. 02 Extraction AI-led conversation draws content from humans + inputs Prevents template recycling The diff. Visible gap between what was gathered and what the standards require. Prevents: looks-complete deception. 03 Diff visible gap between gathered and required Prevents looks-complete deception The approval gate. Human signature on a commit, against the artefact and the diff. Prevents: rubber-stamp sign-off. 04 Approval gate human signature committed against artefact + diff Prevents rubber-stamp sign-off The same four-part loop runs at every layer of the document chain. The shape is the same; the content of each part changes by layer. At every layer same shape, different content PRD layer. Standards: org PRD checklist. Extraction: product, stakeholders, customers. Diff: gaps against the checklist. Approval: human sign-off committing the PRD as the upstream contract. PRD requirements TAD layer. Standards: architecture checklist. Extraction: architecture, security, devops. Diff: gaps in architecture treatment. Approval: tech architect sign-off, co-signed where decisions touch other domains. TAD architecture AC layer. Standards: schema of happy paths, error modes, failure paths, edge cases, observable expectations. Extraction: AI drafts ACs from REQ, TAD, US against the schema. Diff: schema coverage check. Approval: product owner signs off the AC set against the schema. AC criteria FBS layer. Standards: FBS template (storyScope, dependencies, build context, testable outcomes, status). Extraction: AI assembles the FBS from the build sequence and in-scope stories. Diff: any missing field is visible. Approval: tech lead commits the FBS as ready-to-build. FBS build spec Tests layer. Standards: test cases cover named AC categories. Extraction: coding agent drafts tests against the AC in a separate context from the code. Diff: any AC category without a test case is loud. Approval: review and commit of the suite before the code-writing pass starts. Tests verification Code layer (CN), the eleventh RCF kind, forking off the acceptance criterion. Standards: every delivered AC owes a Code Node. Extraction: the build agent authors the CN while writing the code. Diff: the mark-complete gate refuses a build that leaves an AC with no Code Node. Approval: the CN is committed and rcf validate walks the spec-to-code edge, catching a rename, move or delete. Code code node Same loop, every artefact
STANDARDS → EXTRACTION → DIFF → APPROVAL → (loops)

Why the four parts work together

The safeguards depend on each other. Standards alone can produce completed templates without stakeholder input. Extraction needs standards to define the required content. Recorded gaps need an accountable approver. Approval without these checks can record a signature without evidence of verification.

Together, the safeguards let a senior reviewer assess the artefact, its gaps and its commit history. Theatre remains possible, but is harder to produce accidentally and easier to detect when deliberate.

The same shape at every layer of the chain

Every artefact in the chain runs the same four-part pattern, with the content of each part changing layer by layer.

PRD. Standards: the org’s PRD checklist, covering sections like business goals, non-functional requirements, regulatory constraints, out-of-scope. Extraction: AI-led conversation with product, stakeholders, sometimes customers. Diff: gaps against the checklist, visibly recorded. Approval: human sign-off commits the PRD as the contract upstream of everything else.

TAD. Standards: architecture checklist (components, data, integrations, decisions, NFR posture). Extraction: AI-led conversation with technical architecture, security, devops, infrastructure. Diff: gaps in the architecture treatment, visibly recorded. Approval: tech architect sign-off, ideally co-signed by security and devops where the decisions touch their domain.

AC. Standards: a minimum schema covering happy paths, named error modes, named failure paths, derived edge cases, observable expectations. Extraction: AI drafts the ACs from REQ, TAD, US, against the schema. Diff: schema coverage check (which categories are represented; which are missing). Approval: product owner or accountable role signs off the AC set against the schema.

FBS. Standards: the FBS template (storyScope, dependencies, build context, testable outcomes, status). Extraction: AI assembles the FBS from the build sequence and the in-scope stories. Diff: any missing field is visible. Approval: tech lead or accountable engineer commits the FBS as ready-to-build.

Tests. Standards: test cases cover the named happy paths, error modes, failure paths, edge cases declared on the AC. Extraction: the coding agent drafts the tests against the AC, in a separate context from the code (different system prompt, instruction set, commit boundary). Diff: any case category on the AC without a corresponding test case is flagged. Approval: review and commit of the suite happens before the code-writing pass starts.

Code. Standards: every Code Node resolves to a real path in the working tree, and to a named symbol where it points at one, and every acceptance criterion a build spec delivers carries a Code Node or a recorded no-code exemption. Extraction: the coding agent authors the Code Nodes during the build, anchoring each to the file or symbol it just wrote and the acceptance criteria it built against, while the change is still understood. Diff: rcf validate walks every Code Node’s path against the working tree, so a link that no longer resolves is a named failure rather than a dangling reference nothing checks. Approval: the slice can’t be marked complete while a delivered criterion has no Code Node, so the sign-off that closes it is against code that actually traces back to the criteria it claims to satisfy.

The methodology requires all artefacts to follow these four safeguards. Each organisation supplies the checklists for its own work.

How this disposes of the AI-marks-its-own-homework critique

If AI drafts both the acceptance criteria and the tests, the outputs may agree with each other without confirming the intended behaviour. A human signature alone does not resolve that risk.

Two safeguards address this risk directly.

First, a human reviews the AC against a structured schema: happy paths, named error modes and observable expectations. Approval records that the criterion meets those requirements with substantive content.

Second, tests are drafted from the AC and its schema in a context that does not include the implementation. The tests are committed before code writing starts. The coding agent receives a fixed target; changing it requires a deliberate, visible commit.

Human approval of the AC against its schema and the commit boundary between tests and code interrupt AI self-confirmation. Neither safeguard is infallible. Both provide evidence beyond the agent reporting success.

What this page is and isn’t saying

RCF does not eliminate theatre risk. A team can still follow its forms without applying its checks.

RCF makes that failure harder to produce and easier to identify. Every artefact passes through standards, extraction, gap review and approval. Human approval records a decision against structured content and known gaps.

Upstream extraction workflows, gap visualisations and approval interfaces are planned. The scoping page records the current scope and roadmap. This page describes the safeguards that will support that tooling.

Where this shows up elsewhere

These pages explain where the safeguards apply.