Direct answer: when antenna, RF-chain and receiver documents appear to disagree, do not solve the conflict by selecting the most convenient value or by assuming one document is newer. Create a small reconciliation record that identifies the exact source, revision, reference condition, known statement, unresolved point and responsible owner. That record lets an engineering team decide whether the available evidence supports the next integration step, needs clarification, or requires a pause.
This guide is for engineers, system integrators and technical buyers preparing a first GNSS integration review. It is not an electrical design guide, a connector-selection guide or a claim that a particular ResiNav product is compatible with a particular receiver. It explains how to make conflicting published or supplier-provided information reviewable without inventing the missing detail.
Why an interface conflict needs a record, not a quick assumption
Integration information commonly arrives in separate places: a receiver manual, an antenna or terminal data sheet, a cable drawing, a procurement submittal and a project note. Those sources may use different revisions, different reference conditions or different levels of detail. A statement can be valid within its own source and still be insufficient for the system decision now in front of the team.
The practical risk is not simply that a value is missing. It is that an undocumented assumption becomes part of the installation, purchase order or validation plan. Later reviewers cannot tell which source supported it, whether the source applied to the installed configuration, or who was expected to resolve the unknown. A reconciliation record preserves that boundary.
Use this guide for a specific decision
Start by writing one question that the record must help the team decide. Examples include whether the published documents are sufficient to begin a first integration review, whether a supplier clarification is required before specifying an interface, or whether a change has made a prior conclusion stale. Do not start with a broad question such as “Is the system compatible?” That wording hides the actual decision and encourages unsupported conclusions.
A good decision question names the interface boundary and the next action. For example: “Can the team proceed to a documented receiver-and-RF integration review using the current documents, or must the open fields be clarified first?” The answer may be proceed, clarify or pause. It does not need to be a declaration of product performance.
Separate the interface chain into reviewable boundaries
Use a simple chain: antenna, RF chain, receiver and the project-level evidence review. For each boundary, record only what a source actually states. Do not carry a value from one boundary into another just because the components are physically connected. A product photo, model name or informal email is not a substitute for a controlled source.
- Antenna boundary: identify the exact published source or supplier document that describes the candidate item. Record its revision and any explicit scope.
- RF-chain boundary: identify drawings, cable records or installation documents that describe the proposed path. Do not infer unprovided loss, connector or bias details.
- Receiver boundary: identify the receiver document and its revision, then keep receiver-side statements separate from assumptions about the antenna or RF chain.
- Project boundary: record the platform, installation context, intended review stage and owner of each unresolved item.
For an overview of how to document the physical route without estimating unpublished values, see the GNSS RF path documentation guide. For a broader review of a supplier package, use the integration documentation package review. This article begins only after the team has found a specific conflict or ambiguity across those sources.
Build the reconciliation record before discussing a conclusion
The record can be a controlled worksheet, a project document or a review table. Its purpose is not bureaucracy. It is to make the relationship between a claim, its source and its decision consequence visible to another reviewer.
| Evidence field | What to record | Why it matters |
|---|---|---|
| Decision question | The precise integration decision, not a general compatibility claim. | Keeps the review scoped to an actionable next step. |
| Source and revision | Document title, source organisation, revision or publication date, and the page, section or drawing reference. | Lets a later reviewer locate the exact statement. |
| Interface boundary | Whether the statement belongs to the antenna, RF chain, receiver or platform context. | Prevents values or responsibilities being transferred without evidence. |
| Reference condition | The stated configuration, operating context, test or installation condition, if the source gives one. | Shows when two statements may not be directly comparable. |
| Known statement | A short, neutral transcription or summary of what the source actually says. | Separates evidence from interpretation. |
| Unknown or conflict | The missing field, different revision, ambiguous term or incompatible scope. | Makes uncertainty visible instead of silently resolving it. |
| Owner and due action | The person or organisation expected to clarify the point, plus the requested document or confirmation. | Turns an open question into a managed handoff. |
| Decision status | Proceed to the next review, request clarification, or pause the affected decision. | Prevents an unresolved interface point from being treated as approved. |
NASA’s requirements-verification guidance uses a matrix to associate a requirement with a definitive source. NIST likewise stresses that a traceability claim depends on documented process and reference context. Those ideas are used here as a documentation method only; they do not make a ResiNav product, a customer installation or a measurement result traceable, tested or approved.
Compare reference conditions before comparing wording
Two documents can look contradictory because their stated boundaries differ. Before escalating the conflict, check whether they describe the same component identity, same revision, same intended configuration and same reference condition. Do not silently choose the most favourable wording. If a condition is absent, record it as absent.
This is particularly important when a purchase, installation or review decision depends on a detail that is not present in a public page. The correct status is requires confirmation, not an inferred technical value. Keep the exact field name in the record and ask the owner for the source that would resolve it.
Use a three-outcome decision path
1. Proceed to the next documented review
Proceed only when each statement used for that next step has a source, an applicable revision and a clear boundary. “Proceed” means the evidence is adequate for the defined review activity. It does not mean the team has demonstrated every electrical, mechanical or performance property of the complete system.
2. Request clarification
Request clarification when the project can continue only after a source owner confirms the missing field, resolves a revision conflict or identifies the applicable reference condition. Ask a concise question: cite the source, state the conflict and name the decision that remains open. This is more useful than asking a supplier to “confirm compatibility” without defining what that phrase means.
3. Pause the affected decision
Pause when the unresolved point is necessary for the next integration or procurement decision and no fact-safe interim conclusion exists. A pause is not a failure; it prevents a project assumption from becoming an uncontrolled configuration decision. The record should explain the specific blocker and the owner who can address it.
Four mistakes that make interface evidence less useful
- Copying a value without its source and revision. A number or label without context cannot be audited later.
- Combining independent claims into a new claim. An antenna statement and a receiver statement do not automatically prove a complete-path result.
- Calling an unknown “typical.” Typical is not a substitute for a source that applies to the project configuration.
- Leaving ownership implicit. If no person or organisation is responsible for clarification, the same ambiguity will return at the next review.
Keep published product information and project confirmation separate
A published ResiNav product catalogue can help a buyer identify documented product families and decide whether a product detail page is a useful starting point. For example, the RN-8AT published product page identifies a candidate configuration, but it cannot answer a project-specific interface question that the published source does not address. Treat every unconfirmed interface, installation or platform condition as an open item for engineering review.
If the current documents leave a platform, RF or system-level constraint unresolved, move the reconciliation record into a Custom OEM GNSS integration discussion. Include the decision question, sources, revision references, known facts, unknowns and the clarification owner. The team can then review published products and project-specific requirements without treating either as a guarantee.
Prepare a concise engineering handoff
Before requesting a discussion, attach or link only the material needed to review the unresolved decision: the current reconciliation matrix, the relevant document pages or drawing references, the platform context, the requested clarification and the decision deadline or project stage. If some details are not yet available, say so plainly. A useful handoff distinguishes unknown from unavailable rather than filling gaps with estimates.
Start with the Applications overview if the project still needs a broader selection path. Use the receiver compatibility guide for receiver-focused review questions. When the team is ready to document its needs, request an engineering RFQ and include the reconciliation record as the starting point.
Frequently asked questions
Does a reconciliation record prove that an antenna and receiver will work together?
No. It records what the available sources support, what remains unknown and what needs confirmation for the stated decision.
What should happen when two source documents use different revisions?
Record both revisions, their source references and the decision affected. Ask the applicable source owner which revision applies to the proposed configuration; do not silently select one.
Can a public product page resolve a project-specific interface question?
Only where the page explicitly documents the relevant fact and its scope. Missing project-specific information should remain an open clarification item.
Who should own an unresolved interface field?
The record should name the organisation or person responsible for the source or project decision. Ownership may differ for antenna, RF-chain, receiver and platform evidence.
When should a buyer begin a Custom OEM discussion?
Begin when published documents do not resolve a required platform, RF, mechanical or system-integration condition and a project-specific clarification is needed before the next decision.
Sources
- NASA: Requirements Verification Matrix — used only for the principle of identifying a definitive source in a review matrix.
- NIST: Metrological Traceability FAQ and Policy — used only for the importance of documented process and reference context; no traceability claim is made for this article or any product.
- ResiNav Engineering Insights — related published engineering guidance.
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.