A Handover Assumption Becomes False: Trigger Review Before Reusing the Old Release Plan
Link each important handover assumption to the claims that depend on it, an observable change trigger and a responsible reviewer. When the premise becomes false or can no longer be verified, reassess those dependent claims before reusing the old release plan. A product can leave its assessed operating envelope without any firmware bytes changing.
This article proposes an assumption-validity register for embedded integration. It is not an automated safety monitor, a warranty statement or permission to change a site’s systems. The example is fictional, and no field observations, monitoring or device actions were performed.
1. Separate assumptions from requirements and observations
A requirement states what must be achieved. An observation records what happened under identified conditions. An assumption is a premise used to make an engineering decision when it is not established as an invariant by the system itself.
For example, a release plan may assume that only one client initiates a particular maintenance sequence. A test showing one client worked does not establish that no second client will ever appear. The assumption needs an owner and a way to detect relevant change.
NASA’s technical-risk guidance, section 6.4.1.2, includes action triggers, monitoring and retained assumptions. The register below makes those concepts concrete for conditions supplied by other teams or the deployment environment.
2. Select assumptions whose failure matters
Review release rationale, integration notes, test exclusions and installation prerequisites. Look for premises about external load, network policy, available storage, time service, operator sequence, peripheral population and supplied component behavior.
Prioritize premises whose failure would undermine a supported claim. Do not create a large list of vague statements such as “the network works.” Replace that with the actual dependency, its required property and the evidence that currently supports it.
| Premise | Dependent claim | Observable review trigger |
|---|---|---|
| Only the approved client set uses an operation | Assessed concurrency behavior | New client identity or integration change |
| External workload stays within the assessed envelope | Queue and response behavior | Defined load metric exceeds its boundary |
| Required service remains reachable under site policy | Planned communication path | Policy/endpoint change or loss of relevant evidence |
| Installed peripheral matches the approved configuration | Applicable interface evidence | Replacement, revision change or uncertain identity |
These are example categories. Actual boundaries and response actions must come from the product’s approved engineering and risk decisions.
3. Give each premise a current evidence state
Use states such as supported within a named observation window, known false, unknown and superseded. Record the evidence source, observation time, configuration and limitations.
“Unknown” matters. A disconnected monitoring agent or missing inventory update does not prove the premise remains true. Equally, lack of evidence is not automatically proof that the physical condition failed. Route uncertainty according to the consequence of relying on the premise.
Choose review frequency and event triggers based on actual change mechanisms. A component replacement is event-driven; workload may need ongoing measurement; a site-policy assumption may require confirmation when the responsible owner changes it.
4. Define the trigger’s measurement semantics
Name what is counted, where it is observed, the observation interval and how gaps are handled. Average traffic can stay low while short bursts exceed the tested conditions. A useful workload trigger must reflect the property on which the original evidence relied.
Keep monitoring failure visible. If a counter resets or an observation window is incomplete, record that limitation rather than silently comparing incomparable values. Do not set an arbitrary universal threshold merely to populate the register.
Also identify who receives a trigger and who can decide the response. Collecting a metric without an owner and action path does not maintain the assumption.
5. Reassess the dependent claims, not the whole history
| New information | Engineering response |
|---|---|
| Premise still supported for the required scope | Retain the evidence link and next review trigger |
| Premise false in one identified configuration | Reopen claims dependent on that configuration and premise |
| Evidence stale or missing | Mark validity unknown and obtain the needed confirmation |
| Requirement or design removes the dependency | Retire the premise with a recorded replacement argument |
The original test report remains a record of its actual conditions. A changed external premise does not rewrite its observations. It changes whether those observations support the present use case.
Choose any operational restriction, additional test or design change through the applicable process. Do not automatically disable a system or change network settings solely because a generic checklist says an assumption expired.
6. Work through a fictional concurrency change
A fictional monitoring product was assessed with one maintenance client. After handover, another team proposes adding an automated service tool. The assumption register links the single-client premise to the maintenance-sequence evidence.
The new tool is a review trigger even before a failure occurs. The owner checks whether it can overlap the original client’s operations and whether the existing evidence covers that interaction. If not, the plan identifies a targeted concurrency assessment and any authorized interim restriction.
The review does not claim the new tool will fail, nor does it assume the old test proves it safe. It identifies precisely which earlier conclusion needs a new applicability argument.
7. Make the register usable by the receiving team
Each entry should contain the premise, dependent claims, owner, evidence, observable trigger, uncertainty handling and approved review route. Avoid references that only the original developer can interpret.
Close invalidated entries with a recorded disposition: restored premise, expanded evidence, changed design or explicitly changed supported scope. Preserve earlier states so a maintainer can explain why a previous release decision no longer applies.
The result is a practical early-review mechanism. It catches changed external conditions before an old release plan is reused by habit, without inventing field failures or promising that monitoring can discover every relevant change.
