Five range claims, five different questions
Five people say “Bluetooth range.” Are they discussing the same engineering quantity?
The systems engineer needs complete reports on time. The RF designer needs a receiver criterion. Marketing has a demonstration, and procurement has a qualification record. Each document may be accurate within its scope while supporting none of the other conclusions. First extract the claim; only then decide which document could establish it.
PHY means physical layer; MAC means medium access control. Packet error ratio (PER) is the fraction of expected test packets that fail the stated packet criterion. Bit error ratio (BER) counts erroneous bits against the tested bit population. Neither automatically equals the fraction of complete application reports delivered before a deadline.
Use Path 02’s waveform and decision conventions, Path 05’s requirement grammar, and Path 06’s port, chamber and field evidence. Here we own document authority and applicability. Measurement execution belongs to Path 08; jurisdictional determinations to Path 09.
| Claim | What was said | Stated conditions | What is missing? |
|---|---|---|---|
| A · nominal PHY sensitivity | “This Bluetooth mode has a −70 dBm reference sensitivity, so our node has long range.” | Hypothetical statement about LE 1M receiver requirements; input criterion named, no antenna or deployment specified. | Which Core revision, maximum supported test payload, signal conditions, and receive plane? Where is the product trial? |
| B · conducted vendor result | “Our receiver reaches −96 dBm at 1% PER.” | Fictional board V1, LE 1M, 25 °C, 50 Ω R1-RX connector, 1000 test packets. | Missing packet length/pattern, calibration uncertainty, firmware, blockers, and unit population. This is invented example wording, not measured data. |
| C · outdoor demonstration | “Bluetooth works at 800 m.” | Hypothetical line-of-sight demonstration; two raised antennas, LE Coded S=8, one successful message. | No delivery probability, deadline, interference distribution, antenna orientation, power or repeatability basis. |
| D · mounted percentile result | “The mounted node delivers 99% of reports within 2 s at 30 m.” | Hypothetical 32-byte D0 reports; 100 sites, one orientation per site, ten reports per site, indoor gateway. | Potentially relevant service metric, but site selection, orientation strata, firmware and confidence remain unspecified. |
| E · qualification listing | “This Bluetooth-qualified design guarantees our product’s range.” | Hypothetical design record Q-EXAMPLE; no actual listing is claimed. | Which qualified design/layers and product? Listing scope does not establish this mounting, channel, deadline or jurisdiction. |
Think about itWhich statement looks strongest for the node’s required delivery statistic?
D is closest because it names complete reports and a deadline. It still needs representative mounting/orientation strata and statistical uncertainty. A very precise sensitivity or a much longer demonstration distance is not stronger evidence for a different quantity.
Reading task: underline the quantity, circle the population, and mark the plane in each row. Treat every unfilled condition as unknown. Do not convert a missing report into a measured failure, and do not convert absent evidence into a passing value. The consequence is practical: a team that buys the “best range” number may optimize a receiver mode its gateway never uses.
Define the product mode before opening the standard
What must the node deliver before any technology name is useful?
Freeze a local service variant: one 32-byte application report every 60 s, with at least 99% of complete reports delivered within 2 s in each declared mounting/site stratum. D0 is the application boundary; latency begins when the node releases the report and ends when the gateway delivers it. Duplicates count once; late reports miss the deadline. These are chosen teaching requirements, not standard limits or measured achievements.
| Dimension | Frozen choice / unresolved evidence |
|---|---|
| Topology / infrastructure | Fixed sensor node to mains-powered gateway; gateway backhaul is outside the stated D0 endpoint. |
| Telemetry | Bluetooth LE 1M candidate; non-connectable, non-scannable extended advertising. Gateway must support scanning and decoding that exact mode. |
| Commissioning | Separate operator-triggered legacy ADV_IND discovery then a connection. A short discovery identity is advertised; the full telemetry report is not forced into that packet. Commissioning service and security remain to be specified. |
| Environment / mobility | Mounted equipment and fixed gateway; moving people/interference are environmental variables. Sampling strata and observation interval still need a test plan. |
| Band / market | 2.4 GHz; CH candidate market. Power class, actual antenna and regional applicability remain unresolved. |
The portfolio’s 2.450 GHz QPSK waveform remains a generic earlier example. It is not renamed Bluetooth. This module introduces a named LE variant; it carries the earlier antenna evidence IDs without changing their values or turning them into evidence for the new waveform.
Read the host boundary: Core 6.2 GAP §11 defines AD structures with a length byte and type byte. Supplement v14 §1.4 defines manufacturer-specific data with a two-byte company identifier followed by manufacturer-defined content. For a bare 32-byte report, that single AD structure would therefore occupy 36 bytes; no identifier is assigned here. Extra schema/security fields would add bytes. BT-GAP, BT-CSS.
D1 includes framing/coding, and an advertising event can involve multiple transmissions. Freeze the complete encoding and state sequence before estimating airtime or current. No adopted application sensor profile is claimed: the private schema must be specified by both node and gateway teams.
Read requirements in their actual scope
Can a keyword search for “shall” replace reading the requirement?
A requirement is a conditional statement with a subject and scope. A sentence can be mandatory for one selected feature and irrelevant to another. Read the preceding conditions and following exceptions, then follow normative references. An informative annex can explain intent without adding a requirement; confirm its designation rather than assuming that all annexes have one status.
Bluetooth Core 6.2 Vol 1 Part E §1 uses “shall” for requirements, “should” for recommendations and “may” for permission. Optional implementation choices still carry the specified behavior when implemented. “Must” has a separate factual/consequence usage in this document; do not import another publisher’s vocabulary mechanically. BT-LANGUAGE, Table 1.1 and following paragraph.
| Statement | Bounded interpretation |
|---|---|
| “If the short-timer feature is supported, the node shall expose timer state.” | First establish whether that feature is selected; then check its state behavior. |
| “The gateway should keep recent delivery logs.” | A recommendation here; not an invented mandatory interoperability test. |
| “The node may omit the optional display.” | A permitted product choice; it does not permit omitting an unrelated receiver requirement. |
Think about itA clause is copied into the trace with a locator and today’s review date. Is support established?
No. If nobody read the relevant text and dependencies, the evidence is still unreviewed. The complete-looking row is a request to inspect, not proof. The mapper checks this distinction explicitly.
Reading task: rewrite the first fictional sentence as “condition → actor → required behavior.” Attach the feature/conformance-class declaration. The consequence of skipping that step is either overtesting an absent option or overlooking a requirement for a feature you did enable.
Go deeperNormative is a document relationship, not a universal legal label
A referenced requirement can become necessary to satisfy a selected specification without becoming a national legal requirement by itself. Conversely, a regulator’s current route may incorporate a technical standard. Trace each relationship; the publisher’s name and the word “shall” do not determine market applicability.
Build a compatible version chain
Should every document in a valid chain have the same version number?
A base revision can consolidate earlier amendments. An amendment changes selected material; an erratum corrects identified text. A profile selects application behavior; a release groups features on its own schedule. A test package and regional document can evolve independently. Pin complete identities and curate compatibility for the exact endpoints.
Think about itThe teaching sensor profile is 2.0 and its base is 1.2. Reject the chain?
No. D-PROFILE 2.0 explicitly depends compatibly on D-BASE 1.2 in this fictional fixture. The edge is the evidence. A move to base 1.3 needs another reviewed edge; numeric similarity supplies no answer.
A real different-numbered relationship appears in the Supplement version history: v14 was adopted alongside Core 6.2. For layer mixing, Core 6.2 Vol 0 Part D §3 permits different Host and Controller versions subject to its constraints; all included Controller layers must share one Controller version. A claim that combines PHY 6.2 with Link Layer 6.1 in one Controller violates that rule. Feature dependencies in §4 still need checking. BT-CSS-HISTORY, BT-CONFIG.
Reading task: draw the arrow and write “requires,” “amends,” “tests,” or “explains.” Do not infer that two independently adopted specifications are compatible merely because one is newer. Preserve the evidence that established the old pair so a later reviewer can see what actually changed.
Specification Evidence Mapper
Accept a bounded trace, challenge its source, or name the next evidence. Six synthetic documents; three starting claims. Nothing is scraped, measured, saved, or certified.
specification-evidence-mapper/2.0 · p07-m01-trace-rules-v1 · p07-m01-document-chain-v1. Frozen default evaluation: 2026-09-08 UTC.
Guided sequence: predict whether 2.0 and 1.2 conflict → show dependencies → unread source → informative-only support → apply one repair → inspect C-MARKET. Compare each state with the canonical baseline below.
Custom copy · edit bounded teaching metadata
Draft edits do not change the committed results until Apply draft. Blank mode/region mean unknown. Required dates reject blanks. Exact version choices are synthetic; selecting compatibility records a fictional human review.
| Claim | Canonical baseline | Selected trace |
|---|---|---|
| C-PHY | trace complete | trace complete |
| C-DEVICE | inspect | inspect |
| C-MARKET | inspect | inspect |
base · exact version 1.2
Evidence: normative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-BASE · D-BASE teaching row A (synthetic)
Owner: Standards owner
profile · exact version 2.0
Evidence: normative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-PROFILE · D-PROFILE teaching row A (synthetic)
Owner: Standards owner
test · exact version 4.1
Evidence: informative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-TEST · D-TEST teaching row A (synthetic)
Owner: Standards owner
region · exact version 3.0
Evidence: informative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-REGION · D-REGION teaching row A (synthetic)
Owner: Standards owner
vendor · exact version 0.8
Evidence: informative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-VENDOR · D-VENDOR teaching row A (synthetic)
Owner: Standards owner
qualification · exact version 1.0
Evidence: informative. Lifecycle: current. Access: read.Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-QUAL · D-QUAL teaching row A (synthetic)
Owner: Standards owner
Canonical fictional node · evaluated 2026-09-08 UTC. Fictional metadata exercise.
Fictional implementation performance under fixture-conditions-v1.
Mode: telemetry · Region: region-independent definition. packet delivery · ratio · D0 · fraction by 2 s deadline.
Next: A measured receiver report with matching mode, plane, conditions, and statistic. Owner: RF systems owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.
No trace acceptance. Inspect every applicable reason below.
Which requirements apply to placing this product in CH?
Mode: telemetry · Region: CH. packet delivery · ratio · D0 · fraction by 2 s deadline.
Next: Authoritative applicability review for the final product and CH market. Owner: Compliance owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.
No trace acceptance. Inspect every applicable reason below.
Hypothetical normative channel/timing requirement in the declared mode.
Mode: telemetry · Region: region-independent definition. channel/timing definition · Hz / s · R1 / D1 · defined interval, not delivered service.
Next: Compare the declared trace against the actual document text before real use. Owner: RF systems owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.
The declared required metadata chain is complete. This does not establish product conformance, measured performance, certification, or market authorization.
All rule reasons, in deterministic order
- inspect · R09 · C-MARKET / C-MARKET — Missing required authority evidence. Next owner: Compliance owner.
- inspect · R09 · D-VENDOR / C-DEVICE — Measured implementation evidence is absent; an informative note is not a result.
- inspect · R10 · C-MARKET / C-MARKET — Authoritative product applicability review remains outside this mapper; no market authorization is computed.
- note · R05 · E-DEVICE-PAIR / C-DEVICE — Explicit compatibility for 2.0 → 1.2; unequal numbers are not a conflict.
- note · R05 · E-PAIR / C-PHY — Explicit compatibility for 2.0 → 1.2; unequal numbers are not a conflict.
- note · R05 · E-TEST-PROFILE / C-DEVICE — Explicit compatibility for 4.1 → 2.0; unequal numbers are not a conflict.
- note · R09 · C-MARKET / C-MARKET — qualification: optional. Separate industry-program lane. Owner: Standards owner.
- note · R09 · C-PHY / C-PHY — authority: not applicable. Region-independent definition; market authorization is a separate claim. Owner: Compliance owner.
- note · R09 · C-PHY / C-PHY — vendor: optional. An implementation comparison cannot set the rule. Owner: Standards owner.
- note · R09 · E-QUAL / C-MARKET — Optional or disconnected support does not satisfy the required trace.
- note · R09 · E-REGION / C-MARKET — Optional or disconnected support does not satisfy the required trace.
| Claim → dependency | Source / relationship | Review / exact compatibility |
|---|---|---|
| C-PHY: D-BASE → C-PHY | required; requires. base; D-BASE teaching row A (synthetic) | supports; direct claim support; no version pair |
| C-PHY: D-PROFILE → C-PHY | required; requires. profile; D-PROFILE teaching row A (synthetic) | supports; direct claim support; no version pair |
| C-PHY: D-PROFILE → D-BASE | required; requires. profile; D-PROFILE teaching row A (synthetic) | supports; 2.0 → 1.2: compatible; Teaching fixture author |
| C-DEVICE: D-TEST → C-DEVICE | required; tests. test; D-TEST teaching row A (synthetic) | supports; direct claim support; no version pair |
| C-DEVICE: D-VENDOR → C-DEVICE | required; explains. vendor; D-VENDOR teaching row A (synthetic) | supports; direct claim support; no version pair |
| C-DEVICE: D-TEST → D-PROFILE | required; tests. test; D-TEST teaching row A (synthetic) | supports; 4.1 → 2.0: compatible; Teaching fixture author |
| C-DEVICE: D-PROFILE → D-BASE | required; requires. profile; D-PROFILE teaching row A (synthetic) | supports; 2.0 → 1.2: compatible; Teaching fixture author |
| C-MARKET: D-REGION → C-MARKET | optional; explains. region; D-REGION teaching row A (synthetic) | supports; direct claim support; no version pair |
| C-MARKET: D-QUAL → C-MARKET | optional; explains. qualification; D-QUAL teaching row A (synthetic) | supports; direct claim support; no version pair |
| Claim / role | Requirement and reason | Review owner |
|---|---|---|
| C-PHY / base | required: Owns the PHY/MAC rule. | Standards owner |
| C-PHY / profile | required: Selects the teaching mode. | Standards owner |
| C-PHY / vendor | optional: An implementation comparison cannot set the rule. | Standards owner |
| C-PHY / authority | not applicable: Region-independent definition; market authorization is a separate claim. | Compliance owner |
| C-DEVICE / test | required: Owns the test conditions. | Standards owner |
| C-DEVICE / vendor | required: Must supply measured implementation evidence. | Standards owner |
| C-MARKET / authority | required: Product-specific authoritative applicability review is outside the mapper. | Compliance owner |
| C-MARKET / qualification | optional: Separate industry-program lane. | Standards owner |
| Identity / evaluation | Decision / next owner |
|---|---|
| p07-m01-document-chain-v1; Canonical fictional node; 2026-09-08 UTC | C-DEVICE: inspect; C-MARKET: inspect; C-PHY: trace complete |
| Boundary | Metadata review only; no conformance, certification, measured performance, or market authorization. |
| Next evidence | C-PHY: Compare the declared trace against the actual document text before real use. RF systems owner. C-DEVICE: A measured receiver report with matching mode, plane, conditions, and statistic. RF systems owner. C-MARKET: Authoritative applicability review for the final product and CH market. Compliance owner. |
Static broken / repair examples
| Broken trace | Outcome and next action | After the stated repair |
|---|---|---|
| C-PHY has no mode | Inspect · R03; specify the intended operating mode. | Restoring telemetry makes the default synthetic C-PHY trace complete. |
| Base 1.3, explicitly incompatible pair | Challenge · R06; restore the chosen base or obtain a reviewed different mode chain. | Restoring 1.2 alone leaves the 1.3 pair attestation stale: inspect · R07. Repair that exact edge too. |
| Catalogue-only D-BASE | Inspect · R09; read the relevant body and dependencies. | The synthetic read attestation repairs this fixture only; real reading must occur. |
| D-VENDOR alone sets C-PHY | Challenge · R08 plus missing-role reasons; restore normative support. | Restoring the original base/profile chain makes synthetic C-PHY complete; device measurement remains absent. |
| D-QUAL closes C-MARKET | Challenge · R10; qualification is the wrong authority. | Request authoritative applicability review. C-MARKET remains inspect, never an automated legal pass. |
| Review due 2026-09-07, asOf 2026-09-08 | Inspect · R12; recheck affected claims. | A real recheck can justify a new date. Merely changing a date does not do it. |
Trace an RF number with its conditions
Where exactly does an RF number begin and end?
The quantity and its conditions travel together. Channel spacing is not occupied bandwidth; a receiver input criterion is not an OTA distance. Look up the selected mode and test definition before moving a value into the product budget. R1 is a component RF port, R2 the antenna feed, S0 the spatial/OTA reference, and R3 the receiver decision boundary. An antenna connector in a source must be mapped to the actual test fixture; it is never automatically R3.
GFSK is Gaussian frequency-shift keying. Its dimensionless shaping product BT uses Gaussian-filter bandwidth B in hertz and symbol interval T in seconds. That filter parameter does not name the occupied RF bandwidth. The timing symbol T_MAFS below denotes minimum auxiliary frame space, an interval at the packet boundary.
| RF quantity / locator | What the text establishes | What it does not establish |
|---|---|---|
| Channel · Vol 6 A §2 | 40 RF channel centers, 2402–2480 MHz at 2 MHz spacing. | 2 MHz is channel spacing, not a measured occupied bandwidth. |
| Waveform · Vol 6 A §§1, 3.1 | LE 1M: uncoded 1 Mbit/s; GFSK, BT=0.5. | Application goodput, RF spectral-mask measurement, or the prior QPSK waveform. |
| Power · Vol 6 A §3 | Read the source’s antenna-connector/reference-antenna power convention. | Installed EIRP/ERP/OTA or permission to use a national power limit. |
| Sensitivity · Vol 6 A §§4–4.1 | LE uncoded sensitivity ≤ −70 dBm under the prescribed signal variations; BER depends on maximum supported payload, evaluated via the corresponding PER. | A typical chip result, fixed 1% PER for all packets, or mounted product range. |
| Auxiliary timing · Vol 6 B §4.1.2 | T_MAFS = 300 µs, minimum end-of-packet to start-of-auxiliary-packet interval. | A report deadline, repetition interval, or end-to-end discovery time. |
BT-RF: actual normative text read; BT-LL: actual timing definition read. This is a small set of annotations, not a reproduction of the standard’s tables.
Checked comparison: the fictional vendor’s −96 dBm result and the −70 dBm requirement cannot be subtracted into a 26 dB “product range margin” until their mode, signal, criterion and planes match. Even then, the difference would be a conducted receiver comparison. Feed, antenna and channel evidence would still be needed to connect it to D0.
The separately curated real trace
| Claim / source IDs | Exact locator | Supported reading | Unresolved dependencies |
|---|---|---|---|
| BT-CHANNEL / BT-RF | Core 6.2, Vol 6 A §§1–3.1, 4–4.1 | LE 1M channel/waveform definitions and conditional receiver requirement. | Device performance, actual test payload class, RF fixture and OTA delivery unknown. |
| BT-MODE / BT-LL + BT-GAP | Core 6.2, Vol 6 B §§2.3, 2.3.1.6, 2.3.4, 4.1.2; Vol 3 C §11 | Selected non-scannable extended advertising format and auxiliary timing. | Gateway capability, complete AD encoding, schedule and packet capture required. |
| BT-AD / BT-GAP + BT-CSS | Core 6.2, Vol 3 C §11; Supplement v14, Part A §1.4 | Manufacturer-specific data structure; no assigned company identifier is invented. | Private schema and identifier allocation must be supplied by the product owner. |
| BT-VERSION / BT-CONFIG + BT-CSS-HISTORY | Core 6.2, Vol 0 D §§3–4; Supplement v15 version history, v14 row | Layer mixing rules and the documented v14 / Core 6.2 adoption pairing. | No inference that a newer optional feature works on a selected older layer. |
| BT-TEST / BT-DTM + BT-QPRD + BT-TS | Core 6.2, Vol 6 F §1; QPRD v5 §§3.2.2.4–3.2.2.5 | Test-control alternatives and the ICS/TCRL-to-test-plan dependency. | RFPHY TS p22 download returned a landing page; test text, exact applicability and device results unread/unknown. |
| BT-CHANGE / BT-INDEX + BT-UPDATE | Core 6.2 catalogue notice for Expedited Specification Update 28108 | Notice identifies the update as required for a Core 6.2 compliance claim. | Update PDF returned a landing page; detailed clause impact remains unresolved. No compliance claim. |
| NODE-MARKET / CH-OFCOM | Market access overview, published 2025-01-16 | Routes the CH applicability question to authoritative requirements. | Final product/configuration and specialist review still required; no market decision. |
Engineering handoff: preserve the original source plane and explicitly name every feed, mismatch, gain or processing transformation. Count each loss once. RF output power and DC energy are different quantities; a conducted limit does not become EIRP by changing its label.
Connect PHY claims to MAC and state behavior
If 256 payload bits take little PHY time, why might the gateway miss a two-second deadline?
The receiver must be listening to the right transmission. Discovery, scan scheduling, host queues, access collisions and retransmission policy all sit between the PHY and delivered service. Aggregation can reduce overhead per report while increasing the time a report waits. Adaptation changes the selected operating point. A fixed nominal rate cannot describe those states.
For this variant, extended advertising carries the report in an auxiliary PDU. The selected non-scannable mode does not request a scan response; repeated broadcasts are not acknowledged application delivery. Commissioning is a separate state. Read the PDU/event conditions in Core 6.2 Vol 6 Part B §§2.3.1.6 and 2.3.4 and the host format in GAP §11 before borrowing timing from a connection. BT-LL, BT-GAP.
At one complete report per 60 s, the offered D0 rate is 256/60 = 4.2667 bit/s, independent of whether the receiver succeeds. Actual goodput is unique delivered D0 bits divided by the declared observation interval. The 99% deadline target is a different statistic again. A short payload does not prove low energy or reliable discovery.
| State / owner | Needed evidence | Decision it enables |
|---|---|---|
| sleep | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | State duration and DC energy contribution under the traffic plan. |
| wake/encode | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | State duration and DC energy contribution under the traffic plan. |
| primary advertisement | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | State duration and DC energy contribution under the traffic plan. |
| auxiliary advertisement | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | State duration and DC energy contribution under the traffic plan. |
| gateway scan | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | Whether the report can be discovered by the deadline. |
| commissioning connection | Synchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero. | State duration and DC energy contribution under the traffic plan. |
Go deeperThe energy equation can be known while its answer is unknown
No current or duration is supplied for the actual product, so no battery number is calculated. Ask for wake, discovery, receive, retry and sleep traces under the same deadline requirement; sleep current alone cannot answer the question.
Separate qualification from market authorization
What does the qualification record leave for the product team to do?
Keep parallel evidence lanes. A qualification record identifies a program submission; a module note describes an implementation; a host change alters the product configuration; a regulator’s requirements address a market. Match identities within each lane and record the joins. A familiar logo cannot fill missing rows.
QPRD v5’s test-plan process uses the declared Implementation Conformance Statement (ICS) and Test Case Reference List (TCRL) package. The executed plan depends on the design and changes being submitted. Core 6.2 Vol 6 Part F §1 explains RFPHY test-control alternatives; it is not a completed device test report. BT-QPRD §§3.2.2.4–3.2.2.5, BT-DTM.
| Lane | Known / unknown | Next owner |
|---|---|---|
| Industry qualification | Program source read; actual design/layers, product listing and generated test plan unknown. | Qualification owner: obtain the exact design and product records. |
| Vendor / module | No actual conducted result, firmware capability record or integration instruction has been supplied. | Vendor/RF owner: obtain revisioned evidence and conditions. |
| Host integration | Final antenna, enclosure, feed, coexistence states and firmware are unfrozen. | Product owner: freeze a configuration matrix and affected tests. |
| CH applicability | OFCOM overview read. Exact obligations for the final product remain unresolved. | Compliance owner: review current official requirements and applicability. |
Reading task: cross out the sentence “qualified therefore legal everywhere” and replace it with two evidence requests. OFCOM’s overview explicitly concerns applicable requirements and distinguishes its telecommunications scope from other legislation. No CH limit or authorization is inferred here. CH-OFCOM, 16 January 2025.
C-PHY deliberately does not require national authorization to define a timing quantity. C-MARKET deliberately requires an authoritative applicability review. Requiring every role for every claim would obscure this distinction; omitting the market lane would hide it.
Review changes without rewriting history
A new version appears. Which conclusions actually need reopening?
Publication records when a document was issued; adoption records a publisher’s approval status. Supersession, deprecation and withdrawal describe distinct lifecycle events under the relevant policy. Access records when a reader obtained the source; review records when the claim was assessed and when to revisit it. Do not collapse those dates into “latest.”
On 8 September 2026, the official index listed Core 6.3 as adopted and still listed Core 6.2. The selected 6.2 page identifies Expedited Specification Update 28108 as required when claiming 6.2 compliance. Its download and the RFPHY TS p22 download returned landing pages in this research session; the underlying text was not read. Their detailed applicability stays unresolved, even though the public notice and Core text were read. BT-INDEX, BT-UPDATE, BT-TS.
| Condition | Deterministic result | Required response |
|---|---|---|
| asOf 2026-12-07; review due 2026-12-07 | Within review through the due date. | Retain the reviewed claim and its conditions. |
| asOf 2026-12-08; review due 2026-12-07 | Inspect · R12, one UTC calendar day overdue. | Recheck affected evidence; do not automatically delete the previous record. |
| Superseded; explicit legacy applicability and current review | Trace complete with visible legacy note, if every other required condition holds. | Keep the pinned mode and reason; a newer publication does not silently rewrite it. |
| Unknown, deprecated or withdrawn status | Inspect · R11; program/applicability question. | Find a pinned relevant rule before claiming an actual prohibition. |
| Invalid 2026-02-29 or future access | Invalid input; no evaluated result. | Repair the date. Never roll it to March or use browser time. |
Change task: suppose the firmware owner enables a different advertising mode. Reopen packet-format, gateway capability, timing/current and relevant test claims. An enclosure change instead reopens antenna/OTA evidence and integration applicability. Keep the old reviewed card as history and issue a named variant; do not make every earlier product invalid by declaration.
Complete and audit the evidence card
Can another engineer reconstruct both your conclusion and your next evidence request?
A useful audit makes three things visible: what is supported, the conditions under which it is supported, and the next unresolved decision. Start with the eight flawed statements below. Rewrite each before opening the answers; preserve any supported part rather than rejecting the entire source.
Repair the technology summary
| Flawed claim | Corrected interpretation · reveal below |
|---|---|
| 1 · “−70 dBm means long range.” | Identify quantity, scope, source role and missing evidence. |
| 2 · “−96 dBm at the connector is our OTA sensitivity.” | Identify quantity, scope, source role and missing evidence. |
| 3 · “One packet at 800 m proves reliable coverage.” | Identify quantity, scope, source role and missing evidence. |
| 4 · “99% at 30 m covers all installations.” | Identify quantity, scope, source role and missing evidence. |
| 5 · “The qualification listing proves range.” | Identify quantity, scope, source role and missing evidence. |
| 6 · “Profile 2.0 must use base 2.0.” | Identify quantity, scope, source role and missing evidence. |
| 7 · “Qualification authorizes the CH market.” | Identify quantity, scope, source role and missing evidence. |
| 8 · “A clause number proves we checked it.” | Identify quantity, scope, source role and missing evidence. |
Reveal all eight corrected interpretations
1 · “−70 dBm means long range.” A receiver requirement is conditional input evidence; require the installed link and D0 service model.
2 · “−96 dBm at the connector is our OTA sensitivity.” Retain the conducted result at R1-RX; account for R2/feed, S0 pattern and actual RX configuration.
3 · “One packet at 800 m proves reliable coverage.” A demonstration establishes that event only; demand a predeclared population, deadline and uncertainty.
4 · “99% at 30 m covers all installations.” Keep the tested sites/orientations and sampling basis; extrapolation to other installations is unresolved.
5 · “The qualification listing proves range.” Read the program/design scope; it does not replace a mounted-product delivery trial.
6 · “Profile 2.0 must use base 2.0.” Compare the exact declared dependency, not numbers from different series. The synthetic 2.0 → 1.2 pair is compatible.
7 · “Qualification authorizes the CH market.” Keep the qualification lane; separately request current product/market applicability from the compliance owner.
8 · “A clause number proves we checked it.” Read the text, dependencies and conditions; record the support review and access date. An unread locator remains inspect.
One completed authoritative definition trace: BT-CHANNEL → Core 6.2 identity → Vol 6 Part A §2 → forty channel centers with the stated spacing → arithmetic check in Section 6. This supports a channel-definition annotation for the selected LE mode. NODE-DELIVERY still needs a representative mounted trial; NODE-MARKET still needs an authoritative applicability review. The trace is complete for that definition, not for product conformance.
| Order / outcome | Interpretation |
|---|---|
| 1–2 · identity then graph | R01 validates schema, dates and duplicate identity; R02 validates required endpoints and cycles. Invalid input produces no evaluated claims. |
| 3–4 · scope then compatibility | R03/R04 match mode, conditions and region. R05/R06/R07 use exact curated endpoint records; they do not guess version semantics. |
| 5 · authority and reading | R08/R09/R10 check role, required evidence, human review and limits of qualification. Every applicable reason is preserved. |
| 6–7 · lifecycle, freshness, explanation | R11/R12 evaluate applicability and review due dates. Display reasons by severity, rule ID, entity ID, then claim ID. |
| Challenge / inspect / trace complete | Challenge: explicit contradiction, incompatible required pair or wrong authority. Inspect: unknown/incomplete/overdue evidence. Trace complete: required declared metadata is consistent, read, scoped, supported and in review only. |
One-page mode handoff
Illustrative engineering case. Owner: RF systems owner. Evaluation 2026-09-08 UTC; review due 2026-12-07.
| Field | Evidence and decision |
|---|---|
| Scenario / requirement | Illustrative condition-monitoring node; fixed mounted units and a mains-powered gateway; separate operator commissioning state. At least 99% of complete 32-byte reports received by D0 at the gateway within 2 s of release, in each predeclared mounted-orientation/site stratum; 60 s report period. This is a new illustrative requirement, not a result. |
| Family / exact identity | Bluetooth LE candidate; the earlier 2.450 GHz QPSK example is preserved as a generic baseline. Core 6.2 LE 1M and Supplement v14 data format (BT-CSS); telemetry: non-connectable, non-scannable extended advertising (ADV_EXT_IND → AUX_ADV_IND). Commissioning: separate legacy ADV_IND discovery, then a connection; commissioning service/security remains to be specified. GAP is in Core; no adopted application sensor profile is claimed. |
| Band / region / device class | CH candidate market; 2.4 GHz band; final antenna, power class, device category, and applicability unresolved. |
| D0 payload / service | 256 bit (32 bytes), period 60 s, deadline 2 s. Release of a complete D0 report at the node to delivery of that same complete report at gateway D0; duplicate reports count once, omissions and late arrivals fail the deadline statistic. |
| PHY/MAC / infrastructure | LE 1M candidate; proprietary advertising data encoding and total protocol overhead require a frozen schema. The complete report is not placed in a single legacy advertisement. Gateway must scan/support the selected extended advertising mode and decode the private data schema. Gateway backhaul is outside the stated D0 endpoint. |
| States / DC assumptions | sleep: duration unknown, current unknown; wake/encode: duration unknown, current unknown; primary advertisement: duration unknown, current unknown; auxiliary advertisement: duration unknown, current unknown; gateway scan: duration unknown, current unknown; commissioning connection: duration unknown, current unknown. No battery result. |
| Antenna / RF interfaces | R1 transceiver port → feed/match → R2 antenna feed → radiation at S0 → R2-RX → receive chain → R3 decisions → D0 report. R1-TX/RX and R2-TX/RX are directional aliases. Each feed loss is counted once; no loss numbers or EIRP are asserted. |
| Evidence / uncertainty | BT-CHANNEL [BT-RF]: Normative text read, bounded definition; BT-MODE [BT-LL, BT-GAP]: Selected mode documented; implementation unknown; BT-TEST [BT-DTM, BT-QPRD, BT-TS]: Test applicability incomplete; BT-CHANGE [BT-INDEX, BT-UPDATE]: Required update notice read; detailed impact unresolved; NODE-DELIVERY [no source]: Unknown; representative measurement required; NODE-MARKET [CH-OFCOM]: Unknown; authoritative applicability review required. No device sensitivity, installed antenna, scan duty, deployment distribution, timing/current trace, or confidence interval has been measured. |
| Qualification / regulation | Read QPRD v5; selected design/layers, ICS, TCRL, test plan, and product record still unknown. CH applicability assigned to compliance owner; OFCOM orientation is not a product determination. |
| Decision / next evidence | Retain the LE extended-advertising variant for investigation; accept only the bounded document definitions. Product service feasibility remains unknown. Firmware owner: freeze advertising schema/capabilities and commissioning mode. Lab owner: synchronized D0/packet/current logs in mounted strata. Standards owner: read TS/update and generate applicable test plan. Compliance owner: review final CH configuration. |
| Continuity / review trigger | Inherited IDs (unaltered prior evidence): p06-evidence-map-v1, M01-A, M01-B-LOSS, M01-INSTALL-UNKNOWN. Earlier of review due, new Core/update/test program, or change in mode, host, firmware, antenna, gateway, installation, or market. |
Handoff to 07.2: compare short-range candidates using this same D0 service definition. Carry the unresolved scan schedule, schema, gateway capability, current trace and market questions with their owners. Changing a number or checking a box cannot manufacture the missing evidence.
Check your understanding
Answer each question in your own words, then reveal the model answer.
01Which document can establish a normative PHY rule?
Model answerThe applicable normative base/profile text and its dependencies. A vendor measurement can establish implementation behavior under its conditions, but cannot rewrite that rule. The product still needs its own evidence.
02Does “may implement” permit a feature to behave however the designer chooses?
Model answerNo. Selection may be optional while behavior, once selected, is constrained. Read the feature condition, drafting conventions, and conformance declaration. The family name alone does not tell you whether the feature is implemented.
03Is profile 2.0 with base 1.2 necessarily incompatible?
Model answerNo. The fictional pair is explicitly compatible; these are different document series. The conclusion applies only to those exact endpoints. An unreviewed base 1.3 pair remains unknown.
04Does a conducted sensitivity result establish a mounted node’s range?
Model answerIt supports only the tested receiver configuration and decision criterion at the declared input plane. Antenna/feed behavior, interference, orientation, environment, and D0 delivery statistics still need evidence.
05How do an unread clause and an overdue review differ?
Model answerUnread means the supporting text has not been inspected; a locator does not repair it. Overdue means the previous review needs rechecking as of the frozen date. Neither is a measured failure; extending a date alone does not do the review.
06What closes the next market-applicability question?
Model answerA qualified owner must match current authoritative requirements to the final product, modes, antenna, responsible party, and region. Qualification and a complete PHY trace are separate evidence lanes. This mapper cannot produce that determination.
What was actually consulted
Access date: 8 September 2026, matching the frozen example evaluation date. Real-source review due: 7 December 2026, or earlier on a source/product change. Source roles and limits are recorded separately from fictional fixture values.
- Bluetooth Core Specification 6.2, version date 3 November 2025. Actual HTML text: Vol 1 E §1; Vol 0 D §§3–4; Vol 6 A §§1–4.1; Vol 6 B §§2.3, 2.3.1.6, 2.3.4, 4.1.1–4.1.2; Vol 3 C §11; Vol 6 F §1. Read only the stated material; no claim of whole-Core review.
- Core Specification Supplement v14, Part A §1.4, 3 November 2025; v15 title/version history, 5 May 2026, used to check the adoption pairing and newer revision. The v14 manufacturer-data definition is pinned for the example; newer changes require review.
- Qualification Program Reference Document v5, approved 21 April 2026, §§3.2.2.4–3.2.2.5 and version history; qualification overview. Public program text, not an actual qualified-product record.
- Specification index and Core 6.2 update notice, status snapshots. The linked update and RFPHY TS p22 bodies were not obtained; exact test/update applicability remains open.
- Swiss OFCOM, Market access of radiocommunications equipment, published 16 January 2025. Official orientation only; verify final product applicability with the current authoritative route.
Evidence labels: Definition names a convention; Derived means calculated from shown inputs; Illustrative means fictional teaching choices; Normative means the stated source requirement; Informative explains a source. No Simulated RF measurements, actual Measured results, certification or market approvals are produced by this lesson.