Direct answer: When a GNSS-dependent platform changes receiver firmware, RF-path hardware, antenna installation, platform software, timing configuration or a related interface, treat the change as a new review boundary. Record what changed, preserve the previous configuration reference, collect the relevant evidence, and agree which verification activity is still required before drawing conclusions about the updated integration.
Start with a clear change boundary
Record the change request, the approved scope, the affected platform, the installation location, the receiver and platform software identifiers, and the time at which the revised configuration became available. Keep observed facts separate from expected outcomes. A change record is not proof that the integrated system has been revalidated.
Keep receiver, RF and platform ownership visible
Receiver, RF and platform teams often retain different evidence. The receiver owner can identify configuration and interface records; the RF owner can identify the installed path and connector state; the platform owner can identify software, power and operating-context records. A useful review packet names the responsible owner for each evidence source and the time range it covers.
Preserve the RF-path reference without recreating it
Use the existing GNSS RF path documentation to retain the cable, connector and installation reference. This article does not assign RF loss, interference or connector condition as the cause of an observed issue. It only establishes that a changed RF path should be identifiable to the engineering reviewers.
Capture interface and timing evidence
For a receiver or platform interface change, retain the relevant configuration export, interface mapping, timing reference and available raw records. The existing receiver interface control document guide can help teams identify the evidence they need to compare; it does not establish compatibility for an unreviewed configuration.
Link the change to monitoring and incident records
If monitoring or an incident record exists, preserve the event window and configuration version together. The GNSS integrity monitoring guide and the incident triage checklist describe complementary evidence practices. Neither article converts a log entry into a root-cause finding.
Define the revalidation decision explicitly
The engineering owner should state whether the available evidence is sufficient for document review only, whether an interface check is needed, or whether a controlled verification activity must be planned. Do not infer performance, resilience, interference tolerance or operational suitability from a change record alone. NIST’s PNT profile treats configuration change control and verification after integration or upgrades as risk-management activities; it is not a product certification or a ResiNav performance claim.
Build an evidence handoff that can be reviewed later
A concise handoff includes the before-and-after configuration reference, responsible owners, time window, retained source files, unresolved questions and the next review decision. If the required information is incomplete, use the RFQ channel to ask for the missing engineering inputs rather than completing the record with assumptions.
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.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.