Direct answer: a replacement part, receiver firmware update or changed setting does not automatically preserve—or cancel—every earlier acceptance result. Keep a result only where its requirement, configuration and test conditions still apply. For affected functions, select the checks needed to support the new configuration before accepting the substitution. If the supplier cannot identify what changed, the equivalence claim remains unresolved.
Separate a purchasing substitution from an engineering release
“Same model,” “newer firmware” and “form-fit replacement” answer different questions. A matching enclosure may fit the mounting holes but expose different defaults or features. A firmware change may leave the mechanical drawing unchanged while altering the data used by the host. Accepting a delivery date or revised part number is not the same decision as accepting its operation in the platform.
Compare the ordered identity with the proposed identity: hardware revision, firmware, enabled options and the applicable configuration. NovAtel’s firmware-update documentation distinguishes loading firmware from enabling purchased features through an authorization code. This is a concrete example of why a version number alone may not describe a receiver’s capability; it does not imply that ResiNav uses the same licensing mechanism.
Match the changed item to the claim you want to retain
The matrix below is a suggested change-review tool, not a universal retest prescription. Start with the approved requirements and expand the check where a dependency is uncertain. Safety-related or regulated functions remain subject to their applicable change process.
| Proposed change | Earlier evidence that may no longer apply | Focused check to consider | What may remain usable if unchanged |
|---|---|---|---|
| Receiver firmware or enabled option | Message definitions, startup behavior, reported status, or enabled functions tied to the old build. | Compare release/configuration information, then exercise the host functions that consume affected outputs, including startup and restart. | The mounting drawing and identified RF-path record, where their interfaces and requirements are unaffected. |
| Cable, inline component or antenna substitute | RF-path budget, bias arrangement and installation evidence for the removed configuration. | Check the changed path and its receiver boundary using the approved test method; do not rely only on connector fit. | Unchanged host-format evidence, provided the received output definition and its dependencies remain the same. |
| Mounting position, bracket or nearby equipment | View, support or interference observations taken with the previous geometry and operating state. | Compare the relevant motion states and installed surroundings, then test the affected conditions. | Unchanged part-identification and protocol documentation; these do not establish that the new location is acceptable. |
| Host parser, timing setting or controller software | Interpretation of receiver status, message age, timeout or recovery behavior. | Check the changed data path and its responses with defined valid, invalid, stale and interrupted inputs in a controlled test. | Physical installation records if no physical or electrical dependency changed. |
| Label or document correction only | Traceability may be wrong even if the delivered equipment did not change. | Establish whether this really is administrative; reconcile identifiers against the physical/configuration record. | Existing test results if the tested configuration and requirement can still be linked without ambiguity. |
The last column is conditional reuse, not a waiver. Preserve the original results and their scope; do not relabel a test of the old configuration as a test of the new one. NASA’s configuration-management guidance describes controlled changes to a known baseline. Its software regression-testing guidance connects test selection to affected requirements and risks. These are method references, not product certification or permission to omit a required test.
A practical example: the connector is unchanged, the output is not
Suppose a replacement receiver fits the existing connector, but its supplied configuration omits a status message used by the host. The mechanical fit evidence does not answer whether the host will recognize an invalid solution. A successful position display does not answer it either.
First establish whether the proposed receiver can provide the required documented status. If it can, agree the supplied configuration and verify that setting survives the intended restart procedure, then check the host’s use of it. If support is confirmed unavailable, select another documented configuration or formally change the platform requirement and integration design. If support is merely undocumented, keep the decision open rather than recording “unsupported.” This hypothetical example is not a ResiNav defect report or compatibility promise.
Choose a release outcome rather than an unqualified “passed”
- Retain an existing result: identify the unchanged requirement and explain why the original configuration and conditions still cover it.
- Verify the affected scope: name the changed behavior, the acceptance condition and the result needed; include dependent functions that could regress.
- Defer the substitution: state the missing configuration information or failed condition. A purchase schedule does not resolve a technical unknown.
A usable decision line is: old identity → proposed identity | changed requirement or dependency | retained result and reason | new check and outcome | unresolved item | release decision. Use one line per affected decision, not a single “equivalent” checkbox for the entire system.
Make the purchase describe the accepted configuration
For a proposed order or repeat purchase, ask whether the supplier can identify the delivered hardware, firmware and enabled configuration, disclose substitutions before shipment, and provide the agreed records. These are negotiation points to confirm, not standard ResiNav delivery terms. Agree who decides a substitution and what happens if the agreed configuration cannot be supplied.
Use the published product configurations and public datasheets for the starting identity. Detailed test reports, configuration exports, change notifications and rollback capability must be confirmed for the proposed supply; their mention here does not guarantee availability. Restoring old firmware is also a technical decision—verify that a supported recovery path exists rather than assuming every update can be reversed.
Use the relevant evidence without recreating it
Keep the existing RF-path record for a hardware change and the receiver interface definition for an output change. For location changes, use the antenna-placement guide. Link the accepted configuration to the monitoring record and any incident evidence; neither chronology nor a log entry alone establishes the cause of a failure.
Frequently asked questions
Does a configuration change prove that the platform must be retested?
No. The change record identifies a review boundary. The responsible engineering team decides whether document review, an interface check or a controlled verification activity is appropriate for the changed scope.
Which changes should be visible in the evidence packet?
Include the changes that affect the reviewed receiver, RF path, antenna installation, platform software, timing configuration or interfaces, together with the available before-and-after references.
Can a monitoring log establish the cause of an issue after a change?
No. A monitoring log can preserve observed events and their time relationship to a configuration reference. It does not by itself establish interference, a component fault or another cause.
What should happen when a required engineering input is unavailable?
Keep the item marked as unresolved, identify the required owner or supplier input, and avoid making a compatibility or performance conclusion until the evidence can be reviewed.
Reference framework: NISTIR 8323r1 Foundational PNT Profile. The framework supports general risk-management and configuration-control practices only; it does not support product-specific claims.