Ask an LLM to write a PRD and it will often produce a beautiful lie.The headings are right. The tone sounds professional. User stories appear in a tidy list. Edge cases have names. The document feels complete because language models are exceptionally good at completing document-shaped patterns.Then engineering asks where the refund limit came from. Legal says the retention rule is wrong. Support says the workflow ignores a manual exception. Two acceptance criteria contradict each other. Nobody can tell which sentence came from an interview, which came from an old document, and which was invented to make the prose flow.The problem is not that the PRD needs a better prompt.The problem is that prose was treated as the system of record.A Requirements System Should Behave Like a CompilerA compiler does not beautify source text. It transforms input through explicit intermediate representations, validates constraints, reports errors, and emits artifacts.An AI requirements analyst should do the same:raw requests and evidence → claims → normalized domain model → conflicts and gaps → interfaces and acceptance tests → versioned specification viewsThe PRD becomes one output. Others might include:API and event changes;data classifications;permission changes;acceptance tests;migration requirements;unresolved questions;risk and dependency lists;traceability matrix.The durable artifact is a graph, not a paragraph.Build a Typed Claim GraphRepresent each requirement as a typed claim:{ "claim_id": "REQ-142", "type": "business_rule", "statement": "A customer may cancel before shipment begins.", "subject": "order", "predicate": "may_cancel", "conditions": ["shipment_state == NOT_STARTED"], "sources": [ {"type": "policy_doc", "ref": "policy://returns/v8#cancel"}, {"type": "interview", "ref": "interview://support/2026-07-20#18"} ], "confidence": "supported", "owner": "commerce-ops", "status": "proposed", "valid_from": null, "supersedes": null}Types matter. A business goal, legal constraint, user preference, technical limitation, design decision, and acceptance criterion are not interchangeable statements.The model can extract and normalize candidate claims. Deterministic code validates required fields, allowed relations, source references, ownership, and versioning.Evidence Must Be Addressable“The stakeholder said so” is not traceability.Evidence references should point to immutable or versioned artifacts:interview segment and timestamp;ticket comment and revision;policy section and version;analytics query and snapshot;incident report;architecture decision record;contract clause;existing code or API schema.Store hashes when content may change. Preserve access controls; a requirements graph can expose sensitive customer, employee, or commercial information.The model should never convert “no source found” into confident prose. It should mark the claim:SUPPORTED | INFERRED | CONFLICTED | UNSOURCED | REJECTEDThose states are more useful than an invented footnote.Normalize Terms Before Resolving RulesDifferent teams use different words for the same object—and the same word for different objects.An interview may say customer, account, member, buyer, or organization. “Cancel” may mean cancel an order, revoke a subscription, or void a payment authorization.Create a domain glossary with entity IDs and aliases. Link claims to entities. When the model encounters an unknown or ambiguous term, it proposes a mapping or opens a question.This prevents the PRD from quietly merging concepts.For example:customer → party with purchase relationshipaccount → authentication and billing containerorganization → multi-user tenantNow authorization and data models can derive from the correct entity rather than conversational similarity.Detect Conflicts as DataTwo claims can conflict by:opposite rule;incompatible numeric limit;overlapping ownership;impossible timing;permission contradiction;inconsistent state transition;source version mismatch.Record the conflict:{ "conflict_id": "CON-19", "claims": ["REQ-142", "REQ-209"], "type": "state_rule", "explanation": "One permits cancellation after packing; one forbids it.", "resolution_owner": "fulfillment", "status": "OPEN"}The model can explain the contradiction and suggest questions. It should not choose a winner because one sentence sounds newer.A PRD rendered with open critical conflicts should display an explicit blocked section, not blend both rules into vague wording.Compile Claims Into InterfacesOnce domain rules are explicit, derive implementation-facing deltas.If cancellation depends on shipment state, the system may need:a stable shipment-state enum;a read API with freshness guarantees;a cancellation command;an idempotency key;an authorization decision;a state transition event;error contracts for already shipped or unknown state.Each interface element links back to claim IDs. Each claim links forward to tests.This is where specification-driven development becomes practical. GitHub Spec Kit's current workflow structures work as Spec → Plan → Tasks → Implement, with each phase producing artifacts for the next. The valuable principle is not automatic code generation by itself. It is preserving intent as structured input through implementation planning.Generate Acceptance Tests Before Polished ProseFor every rule, derive scenarios:Given order O belongs to customer CAnd shipment state is NOT_STARTEDWhen C requests cancellation with key KThen the order becomes CANCELEDAnd inventory is released onceAnd a cancellation receipt is returnedAdd failure scenarios:another customer requests cancellation;shipment started between read and command;the same request is delivered twice;the state is unknown;an old policy version is used;the event is delayed.Tests expose ambiguity faster than prose. If the compiler cannot derive an observable pass condition, the requirement is not ready.Keep Human Decisions in the LoopThe AI analyst should automate extraction, comparison, linking, and drafting. Humans retain authority over:policy conflicts;legal interpretation;risk acceptance;ownership;prioritization;business tradeoffs;final scope.Record the decision as a new artifact with actor, timestamp, rationale, affected claims, and version. Do not silently overwrite the graph.The goal is not to remove product managers or architects. It is to stop making them reread ten documents to discover the same contradiction every sprint.Version the Graph, Then Render ViewsDifferent audiences need different representations:executives: goals, scope, risk, and unresolved decisions;product: journeys, rules, and acceptance;engineering: states, interfaces, data, and nonfunctional constraints;QA: scenarios and traceability;security/privacy: identity, data flow, retention, and threats;operations: SLOs, rollout, observability, and rollback.All views should render from the same versioned graph. A sentence in the PRD carries claim IDs behind it. A test failure can link back to the requirement. A production incident can create a new constraint for the next version.When a source changes, compute impact:source → claims → interfaces → tests → tasks → deployed componentsThat is requirements traceability that survives beyond kickoff.Measure the CompilerDo not grade the generated PRD by style alone. Measure:claim extraction precision and recall on reviewed samples;source-link correctness;conflict detection;unsupported-claim rate;glossary consistency;acceptance-test coverage;human resolution time;change-impact accuracy;downstream defects traced to missed or wrong requirements.Run adversarial tests: conflicting policies, obsolete documents, ambiguous pronouns, missing owners, and injected instructions in source material. The source corpus is untrusted data, not authority to change the compiler's rules.The Better OutputA good AI requirements system should be comfortable producing:17 supported claims3 inferred claims requiring confirmation2 policy conflicts5 missing acceptance conditions1 unresolved data-retention owner0 implementation-ready releaseThat output looks less impressive than a forty-page PRD.It is far more useful.Generate polished prose after the graph is coherent enough to deserve it. The document should make uncertainty visible, not erase it.Do not ask AI to write the perfect PRD. Ask it to compile evidence into a specification your team can challenge, trace, test, and evolve.