In the spring of 2023, a lawyer filed a brief in the Southern District of New York citing six judicial decisions in support of his client's position. None of the decisions existed. They had been produced by a generative system, complete with docket numbers, quoted passages, and internal citations to other decisions that also did not exist. The lawyer asked the same system whether the cases were real, and it told him they were. Screenshots of that exchange were later filed with the court. The court sanctioned both the lawyers involved and their firm.1
That is the pattern this chapter is about. A generation layer cannot certify its own output, no matter how completely it records what it did.
The sanctions opinion is usually read as a story about a professional who trusted an unfamiliar tool. The more durable lesson sits one step further back. The brief contained a defect that a check would have caught, and a check was performed; it was performed by the system that had produced the defect, and its answer was then treated as independent verification.
The Transformations layer is where this class of failure originates in an engineering record, and where the conditions that permit it are set.
Every artifact passes through this layer at least once
The Transformations layer is the second of the four process layers that operate on the Knowledge Substrate. Its function is to act on artifacts admitted to the substrate and produce new ones. Requirements are authored here, refined here, and decomposed here. An artifact the model eventually presents to a certification authority, a customer's assessor, or an internal gate has passed through this layer at least once, and usually more than once, whatever reviews it also passed on the way.
The layer writes proposed artifacts to the substrate. It does not evaluate what it has written. That constraint is the subject of the second half of this chapter, and it is the reason the layer is defined narrowly.
Chapter 3 established admission as the act by which an external artifact enters the Requirements Operating Model. A transformation performed inside the model produces something that occupies the substrate, carries its provenance, and has not yet been evaluated. The Governance layer changes that status. It does not retroactively change how the artifact was produced.
Chapter 3 also described the conditions under which an artifact is admitted. An admitted artifact carries its provenance and an explicit representation of what is missing from it. The Transformations layer inherits both. A transformation performed on an artifact with recorded incompleteness may resolve it, carry it forward, or introduce new incompleteness of its own, and the model requires that the transformation make which of these occurred visible; the record of what was not known survives in every case. Provenance can be preserved or lost, and it can be added to only by recording the work that added it.
This is the layer where generative activity concentrates. In a manual practice, the generative actors are engineers. In current practice, they are increasingly engineers working alongside systems that produce candidate text at a rate human-paced review was not designed to absorb. The architecture of the layer does not change depending on which is the case. What changes is the volume of artifacts requiring the provenance the layer is responsible for attaching.
Authoring, refinement and decomposition each record something different
Three types of transformation occur in this layer. They differ in what they produce, in what they preserve, and in the provenance each must attach for the substrate to remain queryable afterwards.
Authoring
Authoring varies mostly in where it starts. The input may be a stakeholder need, a regulatory clause, a design decision taken in a meeting, or a requirement written for a prior program and used as the starting point for this one. It may equally be an engineering judgment held by the person writing, formed over years of work on similar systems and never before committed to a document. Wherever it begins, the requirement is new to this program's record.
That last input is the one the written record handles least well. A requirement written from an engineer's knowledge of what has failed before carries a rationale that exists in no document. The requirement is often correct, and its basis is not available to anyone else.
At authoring, the model records the actor, the timestamp, the source artifacts from which the requirement derives, and the standard, template, or pattern applied where the organization's policy specifies one.
This is a description of the Requirements Operating Model, not of current practice. In the requirements documents we have worked with, the statement is usually all that travels. In those documents, responsibility is recorded at the document level rather than the requirement level or not at all, the source is a section heading, and the rationale field is absent, empty, or filled with a program name. The knowledge that produced the requirement is retained by the person who wrote it, and remains available for as long as that person remains reachable.
An operating model does not repair those documents. What it changes is where the knowledge is expected to live. In the document practices we have seen, the surrounding knowledge is called for and seldom supplied, and nothing in a document makes its absence visible until someone needs it. In an operating model, the absence is recorded at the moment of authoring, and the requirement enters the substrate carrying an explicit statement of what is not known about it. Chapter 3 established visible incompleteness as a discipline at the point of admission, and it applies here for the same reason and with the same mechanism. A requirement written without a recorded derivation is not refused; it is held in Quarantine (Chapter 3) with the status Not Yet Known until Governance has evaluated it.
With generated requirements the point becomes operational. Where a system produces a candidate requirement, what can be recorded is the configuration that produced it and the source material it was given, and what cannot be recorded is the experiential judgment a human writer would have brought, because it never formed. The provenance can be complete while the rationale is absent, and a record that does not distinguish the two invites the first to be mistaken for the second.
A rationale written by the generator is itself a generated artifact. It records the generator's statement about its own output, and it is not evidence of a judgment behind the requirement. A rationale is evidence of judgment only when it is authored independently of the generator, whether by a person or by a deterministic rule.
Refinement
Refinement changes the content of a requirement whose identity persists. The requirement keeps its identifier, its downstream links survive, and its position in the count is unchanged; only its text is different.
On the mature programs we have looked at, refinement is the transformation type that occurs most often, and it attracts the least architectural attention. A requirement that has been reviewed, approved, and linked to a verification method is treated downstream as approved and stable. Where the environment raises a suspect-link flag on change, the flag reports that something changed rather than what changed, and clearing it is a manual judgment. Refinement operates on approved artifacts, and an edit to an approved requirement is a transformation of that requirement. The model treats it as one.
The mechanics of how a refinement is recorded differ sharply from the mechanics engineers encounter elsewhere. In a version-controlled environment, a change to a shared artifact is commonly made on a branch or copy, reviewed as a proposed difference against the original, and merged deliberately, with the difference itself preserved as a first-class object. Requirements management environments are usually configured the other way. A refinement is applied in place, and it is immediately the state of the requirement for everyone with access to the project. Change-set and branching mechanisms exist in some of these environments, and in the deployments we have looked at they were rarely in use; where they are absent, independent work on a copy is usually implemented as duplication, with comparison against a baseline taken at the point of divergence, and there is no equivalent of a merge that carries the reasoning for each accepted change back into the original.
The consequence is that an edit history, where the environment keeps one, records that the text changed and who changed it, without recording whether the change was semantic or whether the prior evaluation still holds. What a reviewer consults at a baseline is the difference between baselines, and that difference collapses one refinement and ten into the same result.
At refinement, the model records what the requirement said before, what it says after, and what produced the change, and it marks the prior evaluation as unconfirmed. Whether that evaluation still holds is decided in Governance. The marking is the element most often absent. A requirement that has been refined has been generated again.
Decomposition
Decomposition produces lower-level requirements from a parent, so that a system-level requirement yields subsystem requirements, and a subsystem requirement yields software and hardware requirements. The relationship between parent and child is itself an engineering claim, and it is one an authority or an assessor can be expected to probe, because a derivation whose reasoning is unavailable cannot be argued for when it is questioned.
At decomposition, the model records the parent, the children, the actor, and the derivation logic connecting them. Chapter 2 identified explainable derivation as one of the three conditions for defensibility. Decomposition is where that condition is most cheaply satisfied. A derivation whose reasoning is not recorded at the moment of decomposition has to be recovered later from memory or reconstructed by inference, and the record does not distinguish the two, which is the state the model exists to prevent.
Ungoverned generation fails in five distinguishable ways
Where generative systems participate in the three transformation types, the model distinguishes five failure modes in the engineering record. Three concern what is produced, and two concern what happens to the record around it. They are distinguished because they have different detection conditions, and a control that catches one may be blind to another.
The system produces a requirement that traces to no declared judgment and no source. The requirement is well-formed and may conform to the organization's template; it has no origin. A requirement written from an engineer's experience has no source document either, and it is distinguished by carrying an attributed human judgment, which a fabrication does not.
The system produces a citation, a parent requirement identifier, or a standard clause that does not say what the artifact claims it says, or does not exist. This is the mode the opening case illustrates, and it is legible to a reader who checks the citation, and invisible to a reader who does not.
The system proposes a test, an inspection, or an analysis that cannot be performed as described, or that does not assess the property the requirement states. The artifact appears complete, because the verification-method field is populated.
A refinement or decomposition produces a set of requirements with no change record and no derivation linking each new requirement to the one it replaces or extends. Thirty requirements may enter the transformation and sixty leave it, or thirty may enter and thirty leave, and in either case each is plausible and none has a parent. The count is a symptom; the missing link is the failure.
An approved requirement is refined in place. Its identifier persists, its links persist, its position in the count persists, and its substantive content is different. No semantic difference is recorded and no re-evaluation occurs. The replacement text can be an improvement in every respect a reader assesses at speed, being clearer, better structured, and more confident than what it replaced, while stating something the program did not agree to.
The fifth mode is the one the other four do not cover. Untracked proliferation concerns requirements arriving without parents, while silent mutation concerns a requirement changing while its identity and its links stay where they were. Fabricated requirements are detectable by missing provenance rather than by comparison against source material, since an expert-authored requirement has no source document either. Fabricated references are detectable by checking the reference. Fabricated verification methods are only partly detectable either way, because whether a test can be performed is a question about the test environment rather than about the record. A silently mutated requirement is not detectable that way at all, because it can be better grounded in the source material than the text it replaced. It carries potentially large downstream consequences in a traceability-heavy environment, because tests, hazard analyses, and prior approvals are linked to the requirement by identifier, on the assumption that approved content is stable.
Something produced each requirement, and the model records what produced it.
Where that is a person, the record holds the person. Where it is a system, the record holds the system, the version of it, and the configuration it ran under. Where both participated, the record holds both and the part each played. Where a transformation happens outside the model's reach, in a tool whose activity the record does not observe, the model cannot manufacture the attribution, and what it records instead is that the origin is unestablished. That is the discipline Chapter 3 applies at admission, and it holds the artifact in Quarantine with the status Not Yet Known. An artifact whose producing actor cannot be resolved can still be evaluated against a rule, and the finding covers that artifact alone. Nothing follows from it about the step that produced the artifact, so a systemic defect cannot be traced to its source, and the transformation cannot be re-run under the same conditions to see whether the result holds.
The conditions govern the record, not the method
The model places no constraint on how a transformation is performed. It places conditions on what enters the substrate.
The distinction matters, because a common reflex in regulated environments is to narrow the generating step, forcing the output through a template, restricting the vocabulary, permitting only pre-approved constructions. A generation function narrowed in this way produces requirements that conform, and conformance is a property of form. It is silent on whether the requirement is right, and constraints tight enough to guarantee form can exclude the formulations that capture intent best.
The conditions below are conditions on the record.
The producing actor is recorded, in the terms set out above.
The standard or pattern applied during generation, where one is applied, is external to the generating system and is recorded as an attribute of the transformation. A requirement written to an EARS pattern records the pattern and the version of the organization's specification of it. The record of each transformation identifies a rule whose authorship is separable from the generator, and a record that cannot show this is incomplete. Ownership of the rule, including its versioning and the authority to change it, sits with the Configuration Authority (Chapter 1).
The output occupies the substrate as a proposed artifact carrying its provenance, rather than as an approved one. The distinction is a lifecycle state, and it is the state on which the Governance layer operates.
An organization that satisfies these conditions has not established that its generated requirements are correct. It has established that the question of their correctness can be asked, of a specific artifact, produced by a specific actor, under a specific rule, at a specific time. That is the whole of what this layer can contribute to the answer.
The conditions above describe an envelope, though not one drawn around the generator. The envelope is the boundary of the substrate. Generation happens wherever and however the organization chooses; what crosses into the record carries the actor, the rule applied and its version, and a lifecycle state saying it has not yet been evaluated. An output that cannot carry those attributes crosses anyway, recorded as unattributed, and is held until Governance has run.
The Transformations layer cannot evaluate its own output
That constraint is the operational form of the Separation Principle introduced in Chapter 1 and developed in Chapter 2. The structural reason is the one the opening case illustrates. A system can detect some errors in what it has produced, and a syntactic check applied by the generating system to its own output will catch a class of defects. What such a check cannot establish is independent evidence that the output satisfies the rule being applied, because the assessment applies the same inference that produced the artifact, and agreement between them establishes only that the inference is self-consistent.
The constraint sets conditions on the evaluation function without specifying it. For an evaluation of a transformation to be an evaluation rather than a restatement, four properties are required.
- It sits outside the system that produced the artifact.
- It applies a rule that existed before the artifact did.
- It returns the same finding on the same artifact twice, under a fixed configuration of the rule.
- It can be inspected by a reader who did not run it, in a form that carries the rule applied, the version of that rule, and the time of application.
The four properties apply to the rule and the record of its application, not to every participant in Governance. A rule authored in advance, applied to a stable artifact, returns the same finding; the record of that application is reproducible by an outsider. The participant running the rule, whether a human reviewer, an AI assistant, or a deterministic engine, is not what makes the check reproducible. The rule is.
A finding is tied to the specific artifact and version to which the rule was applied. An evaluation performed on a requirement establishes nothing about a later version of that requirement, and a record that does not distinguish the two asserts more than the evaluation supports.
The constraint governs change as well as creation. A requirement that has been evaluated and is subsequently refined has passed through this layer a second time and has not been evaluated a second time. An evaluation function that runs at authoring and not at refinement satisfies all four properties and still permits the fifth failure mode, because it never examines the transformation in which that mode occurs.
One question is worth holding before the next chapter. A generating system produces candidate requirements at a rate that does not depend on how many engineers are available to read them. An organization can raise generative output faster than it can grow the pool of senior reviewers, and the reviewers it has are the same people the rest of the program depends on. If the evaluation function is performed by those people, reading each artifact in turn, then the rate at which requirements can enter the record is set by their available hours, and an increase in generative output converts, absent some other change, into either a longer queue or a shallower read. Nothing in this arithmetic determines who holds the judgment; it determines how much of the record a given quantity of judgment can cover.
Conformance to a pattern is not a determination of correctness
EARS defines patterns for requirement expression. The INCOSE Guide to Writing Requirements defines the properties of a well-formed requirement. ISO/IEC/IEEE 29148 defines requirements engineering processes across the lifecycle. EARS and the INCOSE Guide operate at the level of artifact definition, and all three are available to this layer as resources during generation.
Conformance to a pattern is a property of form. The Transformations layer can apply a pattern during authoring, and the resulting requirement is more likely to be legible in the sense Chapter 2 describes. Conformance is not a determination that the requirement is correct, that it derives from its stated source, or that its verification method can be performed. Those determinations are evaluations, and they are made elsewhere.
The separation this chapter describes is not specific to requirements engineering. Systems engineering has held it for decades under the name independent verification and validation, where the party performing the verification is defined by its distance from the party that produced the work, and where that independence is defined along technical, managerial and financial dimensions that a program can hold in varying combinations.4 The Separation Principle takes a position on technical independence. The architecture ensures that the evaluation mechanism is technically separable from the generating mechanism, with different rules, different authors, and different records. Managerial and financial independence have traditionally been organizational decisions, handled through the quality management system, and sit outside the scope of this book. The discipline has also long placed evaluation at points where the program stops and looks, in design reviews, peer reviews, and program milestones, where a separate set of readers examines work they did not produce. Those mechanisms were designed for a rate of production set by human authorship.
The contribution of the Requirements Operating Model is architectural, placing the principle where separation follows from the position of the functions, so that observing it is the default path rather than an act of remembering, and a transformation that bypasses it is recorded as unattributed rather than passing silently.
Chapter 5 examines the layer on the other side of that boundary, where the rules are held, applied, and recorded.
A system cannot independently certify what it has just written.
- Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023) (Castel, J.), opinion and order on sanctions, June 22, 2023.
- H. Cheng, J. H. Husen, Y. Lu, T. Racharak, N. Yoshioka, N. Ubayashi, and H. Washizaki, "Generative AI for Requirements Engineering: A Systematic Literature Review," Software: Practice and Experience (2026), DOI: 10.1002/spe.70029. Preprint: arXiv:2409.06741v3, October 14, 2025.
- O. Folorunsho and H. Reza, "AI-Driven Test Case Generation from Natural Language Requirements: A Survey of Techniques and Research Gaps," arXiv:2606.06563, June 2026.
- IEEE Std 1012-2016, IEEE Standard for System, Software, and Hardware Verification and Validation (New York: IEEE, 2017). The standard's treatment of independence distinguishes technical, managerial, and financial independence as separate conditions.