On January 5, 2024, a door plug detached from Alaska Airlines Flight 1282 shortly after takeoff. During its investigation, the National Transportation Safety Board identified multiple contributing factors, among them gaps in Boeing's maintenance documentation, including missing records related to the removal and reinstallation of the door plug assembly.1 Work had occurred. The artifact trail needed to reconstruct that work was incomplete.

The documentation gap illustrates the condition the Inputs Layer of the Requirements Operating Model exists to prevent. Any artifact affecting the engineering record must enter the system with enough context to be examined later. When that condition is not met, the artifact still exists in the physical world, but the record cannot represent it. Every downstream process then operates on incomplete information without knowing that it is doing so.

What the Inputs Layer Is

The Inputs Layer is the first of the four process layers that sit on top of the Knowledge Substrate. Its function is to admit external artifacts into the operating model and to ensure that each admitted artifact is complete enough, sourced enough, and classified enough to participate in the substrate's queries, evaluations, and audits.

An external artifact is any object that carries requirements-relevant content originating outside the current program. A customer specification. A regulatory clause. An inherited requirement from a prior program. An internal memo referencing a change. A supplier's compliance assertion. All arrive at the boundary of the operating model in their native form, and all must be admitted, classified, and made legible before they can be operated on.

The Inputs Layer is not a document management system. Its work is to ingest the content of an external artifact into a form the substrate can query, and to attach at ingestion the metadata that later governance activities will require. Storing the customer's PDF or archiving the regulator's citation is a separate concern the operating model does not conflate with ingestion.

The Three Input Classes

Three classes of input pass through this layer, and they do not arrive on equal terms. Provenance concerns, failure modes, and regulatory obligations vary by class. The classification determines which downstream pathways apply to an admitted artifact, and which level of incompleteness the operating model permits at entry.

The classes are stakeholder and customer requirements, regulatory and standards inputs, and legacy and inherited requirements. A given artifact may belong to more than one class. The classification is not a filing decision. It is a set of attributes that determine how the substrate treats the artifact from the point of ingestion forward.

Stakeholder and Customer Requirements

Stakeholder and customer requirements are artifacts originating with the parties whose needs the engineered system exists to serve. In defense contracting, these are the customer's requirements documents and statements of work. In commercial aerospace, the airline's operational requirements and the certification authority's expectations of the operator. In medical devices, the intended user's clinical needs, the healthcare institution's workflow constraints, and the patient population's safety expectations. In automotive, the vehicle manufacturer's specifications passed to a supplier.

Two conditions distinguish this class. First, the source is external to the engineering organization and typically outside its editorial control. A customer requirement cannot be rewritten by the receiving engineer without a formal change process that returns to the customer. Second, the artifact carries authority derived from a contractual or clinical relationship. A stakeholder requirement is not an engineering claim. It is a claim about the world the engineered system must satisfy.

At ingestion, the operating model records who authored the requirement, when, under what version of what document, and against what contract or program identifier. The substrate treats this metadata as first-class. A requirement without a resolved author is not a requirement in the substrate's sense. It is an unresolved artifact awaiting attribution.

Regulatory and Standards Inputs

Regulatory and standards inputs are the second class. These carry authority derived from law, regulation, or industry consensus. They are the DO-178C objectives, the ISO 26262 work products, the IEC 62304 processes, the 21 CFR references, the ISO 13485 clauses, the EU AI Act provisions.

The distinctive feature of this class is that regulatory context is no longer static. The written standards evolve slowly. Regulatory interpretation of those standards evolves quickly. A DO-178C objective can remain unchanged in text for a decade while the certification authority's expectations of how compliance with that objective is demonstrated shift several times over the same period. A 21 CFR reference can survive verbatim through multiple revisions of the enforcement guidance that applies to it.

The Inputs Layer therefore cannot ingest only the clause. It must ingest the regulatory context that governs the clause's application at the time of admission. This is the architectural claim of the regulatory input class.

At ingestion, the operating model records the citation, the effective date, the specific applicability to the program in question, the version of the standard from which the clause was drawn, and the applicable interpretation the organization has adopted for that clause under the current regulatory environment. The substrate treats a citation without an effective date, applicability, or governing interpretation as an unresolved artifact.

Legacy and Inherited Requirements

Legacy and inherited requirements are the third class. These arrive from prior programs, prior product versions, prior engineering organizations, or acquired portfolios. They are the requirements written for a system that has already been certified, released, or retired, and that are being reused as the basis for a new program.

The distinguishing property of this class is that the artifact often carries knowledge its written form does not fully contain. A legacy requirement was written by an engineer who knew what standard the requirement traced to, what verification method had been accepted, why a particular threshold had been chosen, and what alternatives had been rejected in review. That engineer may no longer be at the organization. The requirement itself may cite documents that no longer exist. The rationale field may say "per program X" without further detail.

Research on legacy system evolution has documented these conditions systematically. Terry's 2025 analysis in Systems Engineering identifies the reconstruction of tacit engineering knowledge as a barrier that reverse systems engineering methods can partially address but not fully resolve.6 The barriers are structural. Engineers who have worked to reverse-engineer a prior program will recognize the state Terry describes. Legacy requirements arrive without the surrounding knowledge that produced them, and the operating model must decide at ingestion how to handle that absence.

At ingestion, the decision is what to attach to the requirement so that its incompleteness is visible. Every legacy requirement with potential engineering relevance enters the substrate; the question is under what status. Three named strategies exist, and later chapters refer to each by name.

The three strategies have different consequences, and none is equivalent to ingesting a fully attributed requirement. The substrate's task at this stage is to make the incompleteness visible and legible to later work; masking the incompleteness is a failure of governance. A requirement that entered under Explicit Acceptance and is later challenged during certification is a different case from one that entered under Reconstruction, and the substrate carries the distinction.

Transformation to Substrate-Legible Form

Each class of input arrives in its native form. A customer specification arrives as a PDF or a Word document. A regulatory clause arrives as a section number in a published standard. A legacy requirement arrives as a row in a spreadsheet or a paragraph in an obsolete tool. The substrate cannot query these forms directly. The limitation is familiar to any engineer who has tried to search across a program's requirements repository: the artifacts are present, but the questions the engineer wants to ask cannot be posed to them directly.

The Inputs Layer performs a transformation. The transformation preserves the artifact's meaning while adding the structure required to render the artifact substrate-legible. Translation is not required, and would corrupt the record if attempted.

For a stakeholder or customer requirement, this means extracting the individual requirement statements, attaching authorship, date, source document, contract identifier, and applicability, and recording the extraction itself as a derived act with its own author and timestamp. The original document is retained by reference. The substrate operates on the structured extraction, not on the document.

For a regulatory citation, this means extracting the specific clause text, attaching the standard identifier, edition, effective date, applicability, and the interpretation applied to make the clause operationally relevant to the program. Where the citation is one of many possible interpretations of an ambiguous clause, that fact is recorded as a property of the ingestion.

For a legacy requirement, this means extracting the statement, attaching whatever provenance can be established, and recording explicitly what is not known. If the verification method is unknown, the requirement is admitted with an empty verification-method field and a status that flags the emptiness. If the rationale is absent, the rationale field records that absence rather than being left blank.

Visible Incompleteness at the Point of Entry

Chapter 2 introduced visible incompleteness as one of the three defining properties of the substrate. At the Inputs Layer, that property functions as an operational discipline. Every admitted artifact must either be complete, in the sense that all substrate-required fields are populated, or must be admitted with an explicit representation of what is incomplete and why.

The pressure on this discipline has grown as LLM-assisted extraction from source documents has entered practical use. Industrial research has begun to quantify the state of ambiguity detection. Ezzini and colleagues report an industrial study at the 2025 IEEE International Conference on Software Maintenance and Evolution in which few-shot LLM prompting achieved a 20.2 percent average gain in identifying ambiguous requirements over prior baselines.7 Endres and colleagues, at the 2025 ASE conference, examined automated repair of ambiguous natural-language requirements and demonstrated that LLMs can propose disambiguations that human reviewers accept at measurable rates.8

These results establish two facts. First, ambiguity in inbound requirements can now be measured on real programs. Second, LLM-assisted detection is sufficiently mature to support operational use. Neither result changes the position the operating model takes on this work. The Separation Principle established in Chapter 2 requires that the system generating a disambiguation cannot also be the system evaluating whether that disambiguation is correct. The Inputs Layer may use LLM-assisted extraction as a generative aid. The determination that an extracted requirement is substrate-legible is made against a deterministic, human-authored specification of what substrate-legible means for that class of input.

The operational discipline that follows is this. Detected ambiguity, whether identified by an engineer or by an LLM-assisted tool, is recorded at ingestion as a property of the artifact. It is not silently resolved. A requirement admitted with a recorded ambiguity is a valid substrate object. A requirement admitted with an unrecorded but present ambiguity is a defect in the ingestion process.

Handoff to Transformations

The Inputs Layer ends when the artifact is inside the substrate with its attributes attached. Two conditions must hold at the handoff. First, the artifact's provenance is recorded: who authored it, when, from what source, under what authority. Second, the artifact's incompleteness is representable: what is known to be missing is attached to the artifact in a form that later processes can read.

An artifact that meets these conditions is not a certified requirement. It is not yet verified, not yet decomposed, not yet allocated. It is an admitted input, present in the substrate, available for the transformations that will produce the engineering record.

The Inputs Layer determines how artifacts enter the operating model. Every subsequent capability of the operating model rests on the quality of that admission. Traceability, governance, transformation, certification, and evaluation all operate on artifacts that were first made substrate-legible here. The operating model treats ingestion as the point at which engineering knowledge first becomes governable.

Chapter 4 examines the discipline that governs the transformations that follow, in an environment where those transformations may now be produced by systems that do not themselves know what they know.