Part 1 — What is an Operating Model?

An operating model is the architecture that governs how a discipline works. It is not the methodology the discipline uses, nor the standards the discipline observes. It is the system beneath both. Every mature engineering practice has an operating model, whether it has been named or not.

Requirements engineering has a well-established methodology. It has EARS notation for writing structured requirement statements, the INCOSE Guide for Writing Requirements for form and style, ISO/IEC/IEEE 29148 for lifecycle process expectations, and a sector-specific literature spanning DO-178C for airborne software, ISO 26262 for automotive functional safety, IEC 62304 for medical device software, ISO 13485 for medical device quality management, and 21 CFR Part 820 for US medical device regulation. These standards describe what a good requirement looks like on the page. They describe artifacts.

An operating model describes something different. It describes how those artifacts behave in a system. How they enter the record. How they are transformed once inside it. How they are governed as they move. What the system produces as its final output. An operating model describes the substrate on which the standards operate and the process layers that operate on that substrate.

The distinction matters because standards do not, by themselves, operate. They must be interpreted, applied, and managed by an organization. That organization is either running an operating model deliberately or running one by accident. In regulated engineering environments, running one by accident produces the failure modes certification authorities have documented for decades: broken traceability between parent requirements and their children, rationale that cannot be reconstructed after the fact, verification evidence that has become inconsistent with the requirement it evaluates, artifacts that cannot be explained to an auditor without the engineer who wrote them present in the room.

The five elements of the Requirements Operating Model

A Knowledge Substrate is the foundation on which everything else rests. It is a structured representation of engineering knowledge from which requirements, decisions, constraints, and evidence are derived. The substrate is where the artifact-level standards land in the real work of an engineering organization.

Four process layers operate on top of the substrate: Inputs, Transformations, Governance, and Outputs. Each layer is responsible for a specific class of work: admitting external artifacts, shaping them within the substrate, evaluating them against organizational policy, and producing artifacts defensible to their downstream consumers.

The Separation Principle governs how the layers relate to one another. The system that generates an engineering artifact cannot also be the system that evaluates whether that artifact is correct. The principle predates artificial intelligence. It is the reason peer review exists, the reason certification authorities are external to the programs they certify, and the reason a scribe and a gavel have never been the same role. It applies to human authors, automated tools, and language models alike.

The Configuration Authority is the function responsible for maintaining the operational policy that governs the substrate. It is a role, not a job title. The role may be distributed across existing positions or assigned to a dedicated team. Its output is the set of rules by which the operating model runs at the scale of an organization.

The maturity path is the trajectory by which organizations move from ad hoc documentation to a governed system. It describes four levels of operation and provides a diagnostic by which readers can locate their own organization on the path.

Together, these five elements support a single claim: A requirement is a governed artifact with computable structure.

Not a sentence in a document. Not a row in a database. An object with attributes, relationships, provenance, and states, admissible to computation and inspection.

These five elements answer a question the existing standards do not answer. The standards say what a well-formed requirement looks like. The operating model says how well-formed requirements are produced, governed, and defended over the life of a program. Engineers who have worked in regulated environments recognize the difference: a program can pass every artifact-level check written in a standard and still fail its certification audit, because the artifacts do not add up to a system.

Everything in the Requirements Operating Model follows from this assertion. The assertion itself is what the existing requirements standards, read as a system rather than as a checklist, have been describing all along.

For the full treatment, including the architecture in detail and its positioning against the existing framework and against contemporary AI governance frameworks, read Chapter 1 — The Operating Model.

This is part one of a five-part series introducing the Requirements Operating Model. Coming next: What is a Knowledge Substrate?

Part 1 — What is an Operating Model? Understand the architecture that governs how engineering knowledge is created, managed, and defended.

Part 2 — What is a Knowledge Substrate? Explore the foundation that makes engineering knowledge structured, computable, and governable.

Part 3 — Why Inputs Matter More Than Documents. Learn why the quality of governance begins with how artifacts enter the system.

Part 4 — What Happens After Ingestion? See how admitted artifacts are transformed into traceable engineering knowledge while preserving meaning and provenance.

Part 5 — Why Governance Is Not Review. Discover how independent evaluation, policy, and oversight create engineering records that can withstand audit and certification.