How Do You Manage Requirements for a System That’s Continuously Updated in the Field?

The V-model is elegant in its assumptions. You define requirements, design to them, verify against them, and deliver a product. Certification authorities review a fixed artifact at a fixed point in time. The problem is that assumption — fixed artifact, fixed point in time — no longer holds for a growing class of embedded systems.

A software-defined vehicle ships with one configuration of its ADAS stack and receives four over-the-air updates in its first eighteen months of operation. An autonomous inspection drone runs a perception model that its operator fine-tunes quarterly based on field data. A cardiac monitoring wearable adds a new arrhythmia detection algorithm between FDA submissions. In each case, the system your customer is operating on day 400 is materially different from the system you certified on day 0 — and your requirements process has to account for that.

Traditional requirements management tools were not designed for this. They manage documents, not living models. They version a requirement by creating a new row in a table, not by tracking a change in a connected graph that cascades through design, verification, and certification evidence. When a system evolves continuously, those tools break down — not because engineers use them wrong, but because their data model is wrong.

This article covers what continuous post-deployment evolution actually demands from a requirements process: how regulators are adapting, what delta certification means in practice, and how to structure a living baseline that can survive the tenth OTA update with its traceability intact.

Why the V-Model Breaks Under Continuous Evolution

The V-model’s certification logic is linear and terminal. You enter the right side of the V with a verified system and exit with a certificate. The certificate applies to a defined configuration. If you change the configuration, the certificate is conditionally invalidated — the degree of invalidity depends on the domain and the nature of the change, but the burden is on you to demonstrate that the new configuration is still compliant.

For a system that receives one major update per year, this is manageable. You run a change impact assessment, identify affected requirements, re-verify them, and submit a supplemental certification package. The document-centric process works because the pace of change is slow enough for humans to manage manually.

For a system that receives continuous updates — even minor model refinements, calibration adjustments, or feature flag toggles — the manual process collapses. The overhead of a full re-certification cycle per release makes continuous improvement economically impossible. The alternative, skipping the re-certification, is not legally or ethically viable for safety-critical systems.

The regulatory community has recognized this. The solutions they are developing share a common structure: you establish tight boundaries on what can change, define a verification plan that applies to any change within those boundaries, and execute delta certifications rather than full re-certifications each time a change occurs.

How Regulators Are Adapting

FDA: Predetermined Change Control Plans

The FDA’s 2021 guidance on artificial intelligence and machine learning-based software as a medical device introduced the concept of the Predetermined Change Control Plan (PCCP). The core idea is that a manufacturer can pre-negotiate with the FDA the types of changes that will be made to a device’s AI/ML component, the expected benefits and risk controls associated with those changes, and the performance monitoring that will confirm the change is safe.

If your PCCP is approved, you can implement changes within its scope without a new premarket submission. You document the change, demonstrate it falls within the approved boundaries, execute the pre-agreed verification protocol, and submit a summary. The FDA reviews at the summary level rather than from scratch.

The requirements implications are significant. A PCCP is not just a regulatory document — it is a formal model of what is allowed to change and what must remain stable. Every requirement in your system now exists in one of three states relative to the PCCP: it is a stable boundary (cannot change without a new submission), it is a controlled variable (can change within defined limits, with pre-approved verification), or it is out of PCCP scope (not expected to change). Maintaining that classification across releases, and keeping it synchronized with your actual design and verification artifacts, is a requirements management problem.

EASA: Software Update Guidance for Airborne Systems

EASA’s guidance on software updates for airborne systems — developed under the broader EASA AI Roadmap and supplemented by AMC/GM material under Part-21 — takes a similar structural approach. The concept of a Software Update Approval (SUA) pathway allows operators and type certificate holders to define a Software Configuration Index for each release and demonstrate that the delta from the prior approved configuration has been assessed for safety impact.

EASA’s framework puts particular emphasis on the traceability between the updated software and the original certification basis. You must be able to show, for each changed software component, which requirements it addresses, what verification was performed for the prior release, what changed in this release, and what new or regression verification was performed. This is not a manual process at the scale of continuous updates — it requires tooling that maintains that linkage automatically as artifacts change.

The Common Thread

Both frameworks share the same underlying demand: you must have a precise, machine-readable record of what your system was certified as at each prior release, what changed in the current release, and what verification covers those changes. The delta certification argument is only as strong as the baseline you are arguing from.

What Delta Certification Requires in Practice

A delta certification is a structured argument that says: the prior release was certified as configuration X, the current release differs from X only in the following ways, those differences are within the approved change boundary, and the following verification activities confirm the changes do not introduce new safety-relevant behavior.

That argument has three dependencies:

1. A well-defined prior baseline. You need an immutable snapshot of requirements, design artifacts, and verification records as they existed at the point of prior certification. Not the current state of those artifacts — the state at certification. If your requirements tool only stores current state, you cannot construct this argument.

2. A traceable change set. You need to identify, for the current release, every requirement that was added, modified, or removed relative to the prior baseline. Every downstream design element and verification activity linked to a changed requirement is a candidate for re-verification. Every element linked only to unchanged requirements is a candidate for reuse of prior evidence.

3. A boundary-aware traceability graph. You need to know which requirements are inside the PCCP or SUA-approved change boundary and which are not. A change to a requirement outside the boundary is a trigger for a new submission, not a delta. Your tooling needs to make that classification explicit and enforce it.

None of these dependencies are satisfiable with a document-centric requirements tool. A spreadsheet does not have immutable snapshots. A Word document does not have traceable change sets. A legacy RM database can approximate these things with significant manual overhead, but at the pace of continuous OTA releases, the overhead becomes the bottleneck.

Managing a Rolling Baseline: The Structural Requirements

A requirements process designed for continuous evolution needs to treat each release as a versioned node in a graph, not as a replacement document. The concepts that matter:

Baseline immutability. When a release ships, its requirements baseline is frozen. Subsequent changes happen in a new working branch. The frozen baseline remains queryable: you can run a traceability report against it at any time, years after the fact, and get the same answer.

Change attribution. Every modification to a requirement — text, rationale, verification method, classification — is attributed to a release and a change reason. The system can answer: what is different about requirement REQ-0312 in release 4.2 compared to release 3.7, and who approved that change?

Verification status inheritance. If a requirement is unchanged between releases, its prior verification evidence can be formally inherited. The new release’s compliance record reflects both newly executed verification and inherited evidence, with explicit links to the source. This is the mechanism that makes delta certification efficient — you are not re-running all verification, you are executing a targeted scope and inheriting the rest.

Certification boundary tagging. Requirements and change sets are tagged with their regulatory classification: PCCP boundary, within-PCCP variable, outside scope, or pending classification. The tooling enforces that boundary-crossing changes are flagged before they reach the release gate.

How Flow Engineering Handles Rolling Baselines

Flow Engineering is built on a graph-based requirements model rather than a document or table model. Each requirement exists as a node with versioned attributes, linked to design nodes, verification nodes, hazard nodes, and release nodes through typed edges. When a requirement changes, the graph records the change as a new version of that node, preserving the prior state and making the delta queryable.

For teams managing OTA-updated systems, the relevant capabilities are:

Release-stamped baselines. Each release is a tagged snapshot of the graph state. You can query the graph as it existed at any prior release, compare two releases to generate a delta report, and export the comparison as structured evidence for a supplemental submission or PCCP update.

Cascading impact analysis. When a requirement node is modified, Flow Engineering propagates the impact forward through the graph — identifying downstream design elements and verification activities that are linked to the changed node. Engineers see immediately what else needs attention before the release is considered closed.

Verification inheritance tracking. Verification records are first-class nodes in the graph, not just fields on a requirement row. A verification node can be linked to multiple requirement versions, with explicit metadata indicating whether the link represents new evidence or inherited evidence from a prior release. The delta certification package can be generated directly from this graph state.

PCCP and boundary annotation. Requirements can be annotated with change control classification, and the graph can enforce rules against releasing changes that cross the boundary without an explicit override and approval record. This is particularly useful in FDA-regulated medical device development where the PCCP approval scope needs to be continuously validated against actual changes.

Flow Engineering’s focused specialization is systems engineering traceability, not general program management or document authoring. Teams that need tight integration with hardware configuration management or manufacturing systems will need to evaluate those integrations explicitly. But for the core challenge — maintaining a living requirements baseline across continuous software releases with auditable change history — the graph model is structurally better suited than any document-centric alternative.

Practical Starting Points

If you are building a requirements process for a continuously updated system, the sequence that works:

Start with boundary definition. Before the first OTA release, classify every top-level requirement by its change control status. What is a certified boundary that cannot change? What is a controlled variable? What is out of scope? This classification drives every downstream decision.

Establish an immutable R1 baseline. Treat the initial certification baseline as the anchor point for all future deltas. Export it, archive it in a format you can query, and never modify it. Every future delta is argued from this point or from a subsequent certified baseline.

Instrument your change process. Every requirement modification should be captured with a reason code (corrective, adaptive, perfective), a release tag, and an impact assessment that identifies linked verification activities. This is not overhead — it is the evidence trail that makes delta certification possible.

Generate delta reports before, not after, regulatory contact. When you go to a regulatory authority with a PCCP update or SUA package, you should already have a complete, machine-readable delta report that compares the new release to the prior certified baseline. The conversation is then about the content of the delta, not the mechanics of producing it.

The Honest Summary

Continuous post-deployment evolution is not an edge case anymore. It is the default operating model for software-defined vehicles, autonomous systems, and adaptive medical devices. The certification frameworks are catching up — FDA’s PCCP and EASA’s software update guidance both provide viable pathways — but those pathways depend entirely on the quality of your requirements baseline management.

The tools that were built for a fixed-product world will require increasingly painful workarounds to support this model. The tools built for continuous evolution — graph-based, version-aware, with first-class traceability between requirements, verification, and releases — are the ones worth evaluating seriously.

The regulatory argument is only as strong as the baseline you argue from. Build the baseline correctly from the start, and delta certification becomes a tractable engineering problem. Build it in documents and spreadsheets, and every OTA release becomes an audit liability.