Need, Scope & Verifiable Specification

A radio selected before the problem is bounded

Which missing fact could invalidate the radio you have already selected?

A condition-monitoring node sends a message to a gateway across the workshop. The reference board is inexpensive, the software example runs, and everyone can see the received value. The customer then asks for “100 m everywhere,” a multi-year battery, simultaneous gateway backhaul and updates without a service visit. Installation adds a metal bracket behind the enclosure.

That demonstration establishes a narrow fact in this fictional story: one setup delivered something. It does not establish a service envelope. The metal can change antenna currents and the installed pattern. Backhaul transmission can disturb the receiver. A long search or update state can dominate energy even when the average telemetry traffic looks small. These are possible changes to the product architecture, not missing decimal places in a radio datasheet.

Build on 05.1’s conditional RF requirements, 07.7’s coexistence and technology comparison, and 09.2’s configuration/market coverage. Here you will turn their open questions into an owned proof plan. Detailed architecture follows in 10.2; jurisdiction decisions remain in Path 09.

Observe the service the radio must deliver

What does the maintenance technician need to receive—and when?

Start at the sensor event, not the RF carrier. The sensor acquires a condition value, firmware creates a payload and records its transmit request at node D0. The radio transports a representation of that payload. The gateway makes receiver decisions at R3, reconstructs the message, and presents the complete payload at gateway D0. A technician can act only when the service exposes the information where it is needed.

Here the proposed endpoint is the gateway application. The site owner supplies power, installation access and upstream networking; remote cloud delivery is outside this local deadline. That boundary requires a customer conversation: if the actual need is a remote alarm during a backhaul outage, a gateway receipt is insufficient even when every RF requirement is met. NASA’s stakeholder and operating-context discussion supports establishing this context before allocating requirements.

Draw the system boundary and interfaces

A system boundary is a responsibility boundary. At the transceiver package, the RF lead can specify a port condition. At the antenna feed, feed loss and mismatch have intervened. In the installed geometry, the antenna, enclosure, mounting and environment affect what reaches the other device. Moving the reference plane changes which effects are inside the question.

The supply interface carries a different contract: voltage range, load-step response, cutoff, connector and owner. A control interface needs request/grant meanings and timing. Neither needs a fabricated dBm value, and neither inherits a 50 Ω RF reference. A complete contract marks inapplicable dimensions with a reason while keeping unresolved physical allocations visible.

Enumerate configurations before reducing tests

Which modes actually exist together?

“Supports telemetry, backhaul and updates” can describe three separate modes or simultaneous operation. Those are different products from the receiver’s point of view. A gateway transmitter may be silent in nominal reception and active in C-CONC. An update may suspend normal telemetry. A metal mount changes the physical configuration even when firmware and traffic remain fixed.

No Cartesian combination is implied. Region/frequency permission, part ratings and actual implementation remain unresolved.

The local N01-FR/G02-FR sample pair derives from the earlier node and gateway story. It has explicit new framing manifests; it is not a replacement for Path 09’s inventory. Hardware/BOM/stackup, firmware, antenna, feed, supply, enclosure and sample identity stay together. A changed firmware gets a new manifest, so an old review can remain historically correct while becoming inapplicable to the new claim.

For Switzerland, OFCOM’s conditions page names conformity and documentation obligations. EU RED documentation context and US §2.947 measurement scope are different source questions. They do not establish a universal radio limit. GB and Canadian applicability stay with their Path 09 territory records; this lesson selects no legal operating mode.

Write requirements that admit an observation

To make a requirement verifiable, imagine the observer disagreeing with the designer. What exactly would they count, at which boundary, in which configuration, over what interval? A number becomes useful only when that disagreement can be resolved by an agreed observation. NASA’s Appendix C/D provides informative guidance on traceability and planning a verification approach.

R-LIFE needs a different statistic and proof. Its 24 months mean 730 days under LIFE-FR-v1, including a versioned update/retry/sleep profile and a chosen usable-capacity assumption. The initial plan combines an energy model with current-profile and capacity evidence. Writing a 24-month target supplies no accelerated-life equivalence. R-UPDATE separately tracks image transfer, image identity and recovery; a complete transfer at 90 s with no valid heartbeat by 120 s does not meet its proposed service criterion.

Give facts and unknowns different jobs

A fact describes what was observed, with its scope. An assumption fills a gap so a model can be explored. A derived estimate follows from inputs and a model. A hard constraint limits the design space; a preference orders acceptable choices. An open question names what is not yet known. A reviewed decision states what someone concluded from a particular body of evidence. These jobs cannot be exchanged just by changing a status label.

In a real project, the observation would identify the actual specimen, instrument/settings, acquisition, raw data and uncertainty. This exercise supplies no such measurements or signatures. Its packets are fictional review premises. When C-CONC changes to firmware v2, its v1 packet does not mutate; the proposed new use becomes incompatible until reconciled.

Find the unknowns that can force redesign

Which unknown can make a decision expensive to reverse?

Mounting can change the antenna and enclosure. Concurrent operation can change filtering, isolation or the front end. Current peaks and state durations can change the power architecture. A territory/mode finding can change the product variants. Each is a causal path from uncertainty to a design commitment. Naming those paths is more useful than inventing a probability that the available evidence cannot support.

The local consequence tiers are architecture, scope and implementation. Uncertainty is high, medium or low. These are ordinal discussion classes, not measured probabilities or standard FMEA numbers. Multiplying their labels by effort would create apparent precision without a quantitative model. Instead, use the stated ordering and retain dissent about priorities.

Design proof while the design is still cheap to change

Plan proof while the design still has test access and reversible choices. R-RANGE needs a D0 observation sequence under S0 conditions; R-LIFE needs current and capacity evidence at the whole-node supply boundary; I-CONTROL needs request/grant and recovery correlation. A single “RF test passed” field cannot represent these different observations.

Uncertainty is part of the observation model. For this local timing exercise, count a payload as timely only if its recorded latency plus the declared expanded timing uncertainty is within the deadline. A 999 ms timestamp with U=1 ms meets the inclusive bound; 1000 ms with U=1 ms does not establish it under this conservative count rule. This is a chosen teaching rule, not a radio-standard test. NIST TN1297 §5 explains why the measurement model and its contributing uncertainties matter.

Verification asks whether the specified behavior was achieved. Validating the service asks whether that behavior solves the maintenance problem. The product could meet the gateway D0 criterion yet fail the customer during a remote backhaul outage. A site walkthrough and stakeholder service demonstration can expose that mismatch before another RF measurement is commissioned.

Choose the next discriminating experiment

Why can the cheapest available test be the wrong next test?

A coupon can characterize a selected transmission-line stackup class for one effort unit. But mounting and concurrency may change the architecture and therefore the class worth characterizing. Its cost does not make it eligible. First retire U-MOUNT and U-CONC with compatible, conclusive, current scoped review packets. Merely scheduling or executing the tests leaves the prerequisite questions open.

The canonical order is E-CONC → E-MOUNT → E-ENERGY → E-MARKET. After E-CONC alone, E-MOUNT still blocks the coupon. After both compatible conclusive packets, the remaining order is E-ENERGY → E-MARKET → E-COUPON. An inconclusive or stale concurrency packet leaves U-CONC open. An unknown cost stays unranked and visible; it never becomes zero.

Defend the framing baseline

A framing review should make it easy to challenge the proposal. The reviewer needs to see what is missing, which constraints truly conflict, which question a packet addresses, and what commitment remains restricted. A broad “done” flag would hide precisely the distinctions that protect the design.

1. Inspect the four canonical groups: R-RANGE, R-LIFE, R-MARKET and I-SUPPLY.
2. Supply only I-SUPPLY’s owner and compare: three requirement groups remain.
3. Apply the complete R-RANGE proposal and compare: R-LIFE and R-MARKET remain.
4. Compare same-scope, equality and disjoint current bounds. Keep the scopes visible.
5. Reset; predict the tied experiment order. Apply E-CONC alone, then E-MOUNT. Inspect the remaining framing gaps.
6. Select repaired framing. It replaces all custom changes with six complete proposals and five exact dispositions. Inspect ready-for-review, future verification and active restrictions, then reset.