Flagship project / Offline group communication

Limited Underground Trail

One shared communication platform with a two-pair V1 Companion goal, an unmeasured four-node V1.5 interoperability gate, and a future self-contained V2 Integrated touchscreen goal.

Active development - single-pair BLE recovery testedEvidence updated September 4, 2026Work in progress

App first look / September 5, 2026

See how the Trail app is taking shape.

Real phone screenshots in portrait and landscape, using sample states for design feedback. Not a release or proof of field readiness.

Preview the app before field testing.

Explore setup, messages, groups, administrator controls, and support. No large download or account is needed.

View the app first look

September 4, 2026 / Current checkpoint

Periodic reconnect passes after an extended absence.

These are single-pair development results, not a supported release or a completed two-pair system.

Physically observed

Ownership survives app restart and a normal Heltec reset.

OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds.

Read the dated hardware evidence

Open work

Cold-power recovery and final app cleanup.

After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.

Completion remains calculated from the canonical milestone record; this update adds no score credit.

Overview

Useful when infrastructure is absent.

Trail is one project with shared LoRa, firmware, security, recovery, and location foundations feeding three explicit release tracks.

Purpose

Local group awareness beyond cellular coverage.

Bounded communication, location state, alerts, ownership, recovery, and transparent degraded behavior.

Planned product behavior; not a safety guarantee.

Release structure

V1 Companion first; V1.5 interoperability and V2 Integrated follow.

V1 uses exactly two supported Heltec devices and two approved Android phones, one phone per device. V1.5 is a separate four-supported-node gate; V2 moves the interface onto a dedicated touchscreen client.

Only V1 is measured; V1.5 and V2 remain unmeasured.

Historical development record through OT-133

Two experimental nodes have bounded direct-radio evidence; the complete V1 path is not implemented.

At the historical OT-085 checkpoint, the selected Heltec ran the exact verified OT-085 image. One authorized Android 13 / API 33 phone completed the fixed privacy-safe public read and the owner observed BLE CONNECTED followed by BLE ADVERTISING on both accepted disconnect paths. In OT-085B the phone made no disconnect request, the target disconnected inside the frozen timing window, and exactly one compatible service advertiser returned without a stable-identity claim. OT-087 adds an explicit non-debuggable unsigned Android release build at version code 1 / version name 1.0.0. OT-088 freezes offline/account-free/transient privacy and data-safety, first-release removal with no downgrade, and best-effort/no-SLA private-pilot support beginning only after a complete OTAR pass. Five of eight OTAR0/v0 prerequisites are satisfied; physical matrix, release identity, and signer/custody are the three that remain before private-sideload-v1-pilot execution. Both reviewed on-chip rollback-floor candidates are rejected; Decision 0033 retains rollback-proof ownership as optional stronger future hardening rather than a V1 gate. OT-089 permanently narrows V1 to exactly two supported Heltec-and-Android pairs and adopts practical fresh-six-digit-PIN BLE Secure Connections authorization under a disclosed factory-reset/reflash rollback limit. OT-090 freezes and host-tests that exact pairing, reconnect, replacement, cleanup, and restart-reconciliation state machine. OT-091 now freezes and host-tests OTSL0/v0, the separate algorithm-neutral secure-LoRa lifecycle/admission contract for exactly two current Heltec members using pairwise direct unicast only, with no V1 relay, group broadcast, server, internet, or V1.5 authority. It requires a secret-free single-use authenticated invitation, mutual device authentication, matching local human confirmation, exact durable commit/readback and peer activation, epoch-plus-one replacement with no old-epoch fallback, full-identity/direction/purpose binding, durable nonzero counter and nonce domains, cryptographic replay and durable inbox admission before plaintext or positive acknowledgement, protected reverse-direction acknowledgements, exact-sealed-byte finite retry, and restart reconciliation with no automatic retry. OT-093 now freezes a deterministic two-build pre-crypto baseline under exact source, configuration, toolchain, project-version, and cache-isolation locks. It is build-only evidence: no OT-005 candidate benchmark ran, no suite/library, handshake/KDF, or packet-v1 wire was selected, no device was accessed, and no support or score credit was added. The OT-005 plan remains draft_blocked. OT-109 closes mbedTLS/PSA API/configuration eligibility. OT-114 then admits the exact two-node US915 close-bench profile after 242/242 probe/data frames and 240/240 acknowledgements reconcile with zero loss, duplication, corruption, or unexpected traffic. It closes only the direct-radio requirement. OT-116 records all six historical readiness requirements closed and freezes the phased benchmark procedure. OT-117 then admits complete 8/8 libsodium API/configuration evidence. OT-118 admits strict 5/8 Monocypher comparison evidence. OT-119 admits the second node's exact profile and completes Phase 0. OT-120 admits all three retained candidate import/build anchors, advances source/API/import counts to 3/3/3, and completes Phase 1. OT-121 starts the bounded Phase 2 measurement history. OT-122 continues it: both anonymous nodes pass all eight libsodium operations, including complete benchmark-only Noise XK, with 100 data-cache-conditioned and 100 warm samples per operation and exact Trail restoration. Both nodes measure 0 bytes peak dynamic heap, 4,312 bytes maximum stack use, and 0 watchdog resets. Phase 2 remains incomplete, no radio was used, and other-candidate, radio, matched linked-flash/static-RAM, independent-admission, and score gates remain open. OT-128 records the second Monocypher corrective retry as aborted without a validated capture: every touched node restored exactly to Trail, both endpoints returned after a non-writing reset, and the owner later confirmed both displays on. The physical capture failure remains unconfirmed, no result or score was admitted, and no further Monocypher hardware attempt was authorized under OT-128. OT-129 accepts a computer-only correction: retrying exact START/READY, partial-byte accumulation across read timeouts, verified re-enumerated or stable-continuous endpoint lifecycle, bounded startup chatter, privacy-safe failure categories and counters, the unchanged real 1,014-frame parser, and a pinned ESP-IDF 6.0.2 compile-only build all pass. OT-131 records the single executable Monocypher attempt as a controlled abort after Node A benchmark readback: capture failed closed as capture_failed / preamble_invalid. Node A was restored, readback-verified, and reset exactly to Trail; Node B was never benchmark-flashed and remained on Trail. Restoration completed and the owner confirmed both Trail logos. The one-attempt authority is consumed and nonreusable. The latest admitted benchmark result remains OT-122; no Monocypher result, frame, radio, selection, Phase 2 completion, or score was added. OT-132 supersedes that pre-READY correction requirement; the consumed OT-131 authority remains historical. OT-133 binds the OT-132 runner into a fresh immutable executable successor and consumes exactly one non-reusable application-only attempt. Node A passed benchmark readback; capture then failed closed as capture_failed / preamble_invalid after nine complete pre-READY records were observed in one 512-byte read, exceeding the frozen eight-record cap before any result frame. Node A restored, read back, and reset exactly to Trail. Node B was never benchmark-written and remained on Trail. Restoration completed and the owner confirmed both Trail logos. The authority is consumed and nonreusable. The latest admitted benchmark result remains OT-122; no Monocypher result, radio, selection, Phase 2 completion, or score was added. No further Monocypher hardware attempt is authorized. Next is host-only correction and adversarial testing of the nine-record boundary while retaining exact READY/frame strictness, privacy-safe diagnostics, and the real 1,014-frame parser; any later device access requires a new immutable successor and fresh authority. V1 Companion remains exact 43.75% / displayed 44%. Both OT-090 and OT-091 remain NOT-IMPLEMENTED; physical acceptance remains NOT-EVALUATED. The release gate and both V1/V1.5 acceptance gates remain NOT-EVALUATED; no signed, supported, distributed, production-ready, operationally accepted, fully paired, or secure-LoRa-complete candidate exists.

Work in progress - not production ready.

Historical OT-005 readiness at OT-138

OT-138 identifies the host/device control conflict; next is a quiet-target build.

OT-137 consumed the one-attempt authority on a fail-closed application-only attempt. Node A passed benchmark readback, but two 512-byte reads observed 1,024 transport bytes; 11 complete opaque records plus remaining partial pre-READY data crossed the cumulative 512-byte preamble bound before READY. Node A restored exactly to Trail. Node B was never benchmark-written after preflight and remained on Trail. Both logos were confirmed, and the authority is consumed and nonreusable. OT-138 then reproduces that complete public counter shape with fabricated bytes and proves the frozen runner can charge already queued startup traffic and post-START preamble to the same 512-byte budget before its 250 ms START retry becomes due. The accepted build structurally shares USB Serial/JTAG between startup console output and the later direct control protocol, but the unretained OT-137 bytes remain unconfirmed and are not labeled as boot logs. No Monocypher hardware attempt is currently authorized. Next is a host-only console-isolated quiet-target build with two fresh matching BIN/ELF/map/sdkconfig tuples while preserving the frozen protocol, privacy, parser, and byte/time limits. The latest admitted benchmark result remains OT-122; no Monocypher result, radio, selection, Phase 2 completion, or score was added. V1 Companion remains exact 43.75% / displayed 44%.

V1 Companion remains 44%; Phase 2 remains incomplete and no radio, suite selection, support claim, or score authority was added.

Roadmap

One platform. Three release tracks.

Shared work is recorded once; each release has distinct gates, and unmeasured tracks do not borrow V1 credit.

Current release goal44%

V1 Companion

Exactly two supported Heltec devices and two approved Android phones.

Interface: One physically authorized Android phone per Heltec
Primary proof: Bidirectional BLE to direct LoRa to BLE across both pairs, with pairing, replacement, restart, rejection, retry, recovery, and the exact signed Android release
Current boundary: Both experimental Heltec nodes now run the corrected OT-164 application. On each node, short press remains closed; a hold of at least three seconds plus release displays a fresh local six-digit PIN; the PIN clears after about 30 seconds; and reset conceals it. No PIN was captured or published. This accepts only the device-side local pairing window. Android passkey entry, durable bond ownership and persistence, reconnect, replacement, protected GATT, supported-device status, secure LoRa, signed Android release, field readiness, and coherent two-pair acceptance remain open. V1 Companion remains exact 43.75% / displayed 44%.

Next interoperability gate0% accepted completion

V1.5 Multi-node Interoperability

Four supported OpenTrail LoRa nodes using any compatible mix.

Phones: Four phones are not required
Primary proof: One authenticated protocol across four supported nodes; mixed hardware is preferred, not mandatory
Current boundary: No completion credit is assigned; its weighted plan is not yet defined. Any relay claim requires a physical three-radio sender-to-relay-to-receiver path

Future release goal0% accepted completion

V2 Integrated

LoRa device plus onboard touchscreen LCD.

Interface: Dedicated local touchscreen
Primary proof: Standalone display, input, power, enclosure, recovery, and field acceptance
Current boundary: No exact complete touchscreen hardware stack is frozen

Tracking rule: shared protocol, firmware, security, and recovery evidence is counted once inside the approved V1 Companion track. V1.5 and V2 receive their own measurements only after their milestones are approved.

Future concepts

Public assistance is an accepted post-V2 direction, not a promised feature.

Accepted direction — deferred until after V2 is fully functional and accepted. There is no promised version, schedule, delivery date, or progress credit. This is not implemented, available, scheduled, hardware tested, radio tested, or field accepted.

Public/default lane

A provisioning-independent regional public lane could coexist with private groups.

A future device without a configured private group could exchange ordinary public messages such as “Is anyone nearby?” Devices with private groups could service both logical lanes, but one LoRa radio must time-share; it cannot listen or transmit on two radio profiles simultaneously, and scheduled public-listening windows may miss alerts.

Public Assistance Broadcast

Compact assistance codes would be localized by receiving firmware.

A later packet design must include a catalog version, assistance code, unique alert ID, and expiration. Location may be included only after explicit approval of a fresh GPS fix with accuracy and fix age; unavailable or stale location must be stated. A deliberate hold and confirmation must preview exactly what becomes public. Only the selected code and approved location may derive from a private action; private message text must never be automatically decrypted, copied, summarized, or published.

Safety boundary

Broadcasting is not delivery or dispatch.

Delivery is not guaranteed: someone nearby must be listening, compatible, and able to respond. This is not a monitored dispatch service and does not replace 911, a PLB, a satellite messenger, cellular service, or another recognized emergency system. A device receipt means only that one compatible device heard the alert. The interface must never say “help dispatched” without explicit evidence from a real external service.

Radio and abuse boundary

Any future implementation must fail bounded and remain publicly honest.

Required future controls include bounded repeats, randomized backoff, expiry, duplicate suppression, regional airtime limits, correlated resolved or cancelled alerts, rate limiting, sender muting, stale and replay rejection, and abuse controls—without an automatic acknowledgement storm from every receiver. Public packets are not confidential; a valid signature would not prove a person’s identity or that an assistance claim is true. Exact packet, radio, security, privacy, abuse-prevention, localization, UI, regulatory, and physical-acceptance designs remain future work.

Capabilities

Current capability, clearly separated from intent.

Every item is labeled by evidence stage so planned behavior cannot be mistaken for a working field product.

Coded and host tested

Protocol, ownership, secure-LoRa semantics, alerts, persistence, and recovery contracts.

Fixed-memory components and cross-language contracts have extensive automated evidence. OT-091 adds algorithm-neutral lifecycle/admission semantics only, not cryptographic implementation or a working radio path.

Build tested

Deterministic pre-crypto baseline frozen; OT-005 execution blocked.

OT-093 accepted two independent, cache-disabled, zero-warning builds with identical seven-artifact tuples under exact source, configuration, project-version, ESP-IDF, tool, and Python-isolation locks. This is not a candidate benchmark, cryptographic selection, supported-target, runtime, radio, device, or score result.

Host tested

Strict OTCBR0 candidate-readiness contract frozen at readiness_blocked.

OT-094 binds the unchanged blocked OT-005 plan and OT-093 baseline, records six unresolved target, configuration, dependency, and radio requirements, and prevents a self-declared legacy ready plan from creating a result template or passing. It imported no source, ran no benchmark, selected no candidate, suite, or wire boundary, touched no device, and added no support or score credit.

Host tested

Strict OTCMSE0 pinned-comparator static assessment frozen with 5/8 source paths present.

Concrete source/API paths exist for 5/8 fixed operations: X25519, SHA-256, HKDF-SHA-256, and ChaCha20-Poly1305 encrypt/decrypt. OT-096 recorded that Ed25519 sign/verify and Noise XK composition were absent, generic PSA APIs and identifiers were not implementation evidence, and final configuration was unresolved at that checkpoint. It acquired or imported no source, accepted no source lock or readiness, closed none of the six OTCBR0 blockers, granted no authority, and added no score credit.

Host tested

At OT-097, strict OTCSL0/v1 license-aware source-lock admission froze with zero accepted locks.

OT-097 separated each candidate's upstream SPDX expression, project-license-choice field, complete license inventory, and inventory digest; at that checkpoint the Monocypher project choice was null and unselected. The predecessor v0 contract remains historically valid but permanently non-admitting. OT-097 made no legal clearance or compatibility determination, left all six historical readiness blockers open, and added no execution authority or score credit.

Host tested

At OT-098, exact libsodium and Monocypher sources were acquired and statically inspected without import.

OT-098 binds clean immutable source identities, tree manifests, license observations, signature limitations, and the fixed operation matrix: libsodium 7/8 and Monocypher 5/8. At that checkpoint neither source was imported or source-lock accepted; the project choice, complete inventories, locks, final configuration, API/config eligibility, build, benchmark, and selection remained unresolved or absent, and all six historical readiness blockers remained open.

Build tested

At OT-099, exact libsodium managed-import evidence compiled in isolation without source-lock admission.

OT-099 completed bounded managed-import evidence for Espressif libsodium 1.0.22 and passed one isolated generic ESP32-S3 computer build. The archive entered the link graph, but probe symbols were not retained. At that checkpoint accepted source-lock registries were empty and all six historical blockers remained open. This was not exact-target proof, crypto execution, a benchmark, a library selection, packet-v1 authority, device or radio evidence, or score credit.

Host tested

At OT-100, the exact OT-099 libsodium source anchor was accepted.

OT-100 recorded the prior five-blocker state after admitting only the exact libsodium source lock. API/configuration and import anchors were empty, readiness remained blocked, and no operational or score authority was added.

Host tested

At the OT-109 checkpoint, one direct-radio requirement remains.

OT-103 admits exact OTRTPE0/v0 identity evidence and strict OTRTPA0/v0, closing only exact_received_target_profile_unresolved. The documented HTIT-WB32LAF high-band profile is bounded to received revision V4.2; official Table 1.5 868-928 MHz and Table 3.5.1 863-928 MHz remain distinct, unreconciled source facts. At that OT-103 checkpoint, two source anchors were accepted; API/configuration and candidate-import anchors were empty, readiness was blocked, and no support, compatibility, regulatory, electrical-RF, direct-radio, final-config, device, benchmark, selection, or score claim was added.

Hardware tested

Both Heltec V4.2 bench nodes now exchange OpenTrail diagnostic frames.

OT-112 corrected the SPI lifecycle defect, flashed one identical receive-only image to both nodes, and passed valid structured frames A→B and B→A at 17 and exactly 163 total wire bytes. Each node ended at rx=2, tx=2, and armed=no. This is a bounded smoke check, not stress, measured ceiling/rejection, latency, RSSI/SNR, restart persistence, range, support, or regulatory acceptance.

Hardware tested

Both nodes passed all eight libsodium operations and runtime-resource measurement.

Phase 0 and Phase 1 remain complete at counts 3/3/3. OT-121 records the first seven-operation checkpoint; OT-122 executes all eight libsodium operations, including complete benchmark-only Noise XK, on both anonymous nodes with 100 data-cache-conditioned and 100 warm samples per operation. Both captures validate, both devices restore exactly to Trail, and both report 0 bytes peak dynamic heap, 4,312 bytes maximum stack use, and 0 watchdog resets. Phase 2 remains incomplete and no radio was used; other candidates, radio, matched linked-flash/static-RAM admission, separate Phase 3 admission, selection, support, compatibility, and regulatory acceptance remain open.

Build tested

Compact Heltec status footer integrated and build verified.

OT-106 links the exact 128-column footer into OLED page 7 and passes two fresh pinned computer builds with identical artifacts. Current runtime output is BAT:--% GPS:-- BLE:S/A/C/R/E with one blank traffic field because no live battery, GNSS, or LoRa-activity source is connected. No device was accessed or flashed, no physical display was observed, and no radio readiness, target support, or score credit was added.

Hardware tested

Public BLE link/status and Android companion foundation.

One authorized phone read the exact fixed public value, and the owner observed the connected-to-advertising display lifecycle after both phone-driven and target-initiated disconnects. OT-087 verified a non-debuggable unsigned version 1/1.0.0 release build, including its packaged manifest, exact permissions, backup rules, DEX surface, and exclusion of test helpers. OT-088 freezes policy promises only, and OT-090 freezes a host-only pairing/replacement contract. Physical matrix, release identity, signer/custody, pairing implementation and physical acceptance, a coherent pilot run, and release acceptance remain open.

Hardware tested

Selected-unit startup and status display.

A recognizable Trail logo and truthful BLE-advertising status were observed; the complete physical client and field workflow remain unmeasured.

Use cases

One modular system, several real-world contexts.

These are intended uses, not field-validated claims.

Underground routes

Group awareness where cellular service is unreliable.

Designed around explicit stale, unavailable, and degraded states instead of pretending continuous coverage.

Remote travel

Local coordination for small groups.

V1 uses an Android interface; V2 is intended to provide a dedicated self-contained interface.

Field work

Recoverable, inspectable tools with visible limits.

Modular boards, protocols, and companion tools are intended to remain replaceable.

Components

A system of bounded parts.

Components can progress independently, but a release advances only when its complete accepted workflow improves.

Shared device core

ESP32-S3 target, radio, GNSS, power, and recovery.

One retained Heltec V4.2 has exact OT-168 application write/readback and saved-owner warm-reset acceptance. Earlier two-node diagnostic radio and status-footer evidence remains historical; the second device has not passed this new same-pair gate. No supported or complete physical client exists yet.

Companion

Android application and protected BLE session.

Periodic reconnect passes on the retained pair; the final zero-tap launch/interface remains pending. V1 uses destructive factory reset rather than phone replacement; secure radio and release acceptance remain separate gates.

Maintenance

Windows firmware loader inspection shell.

Bundle inspection and limited read-only recognition exist. Firmware writing is not implemented.

Technology

The stack, protocols, and proof boundary.

Specific technologies are listed with the evidence limits that matter.

Device firmware

C++17 and ESP-IDF 6.0.2

Target: Exact received OT-DEV-001 identity: Heltec Automation WiFi LoRa 32 V4, HTIT-WB32LAF, revision V4.2, ESP32-S3R2 revision v0.2, 16 MiB flash, and 2 MiB PSRAM.
Architecture: Fixed-memory target-neutral components plus a bounded Heltec V4 bench target.
Evidence: Strict host tests, static admission, selected-unit startup/status OLED runtime, the OT-093 deterministic two-build pre-crypto baseline, three accepted source anchors, OT-103 exact received-profile admission, OT-105 pinned mbedTLS/PSA dependency lock, and OT-107 final per-candidate configuration admission, OT-109 mbedTLS/PSA API/configuration eligibility admission, and OT-114 admitted two-node US915 close-bench direct-radio profile evidence. OT-117 and OT-118 complete the three API/configuration admissions. OT-119 and OT-120 complete Phase 0 and Phase 1 at counts 3/3/3. OT-121 and OT-122 prove all eight libsodium operations, complete benchmark-only Noise XK, runtime heap/stack/watchdog measurements, and exact Trail restoration on both nodes. Phase 2 remains incomplete; remaining other-candidate, radio, matched linked-flash/static-RAM, separate admission, selection, support, compatibility, electrical-RF and antenna proof, and regulatory acceptance remain open.

Device link

Bluetooth Low Energy GATT

Current contract: Decision 0103 requires one 60-second fresh-PIN enrollment window on verified unowned boot, PIN-free saved-owner reconnect, and destructive factory reset rather than phone replacement.
Admission: The Android bond is a prerequisite; retained owner authorization, protected ProtocolInfo, and a fresh mandatory Snapshot must pass before Ready.
Evidence: OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds. After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.

Radio and position

LoRa-class transport and GNSS planning

Protocol: OTSL0/v0 host-freezes exact two-node pairwise direct unicast, invitation admission, mutual authentication, replay protection, acknowledgements, retry, and restart semantics. It grants no relay, broadcast, server, internet, or V1.5 authority.
Hardware: OT-114 admits the exact two-node US915 close-bench profile with 242/242 probe/data frames, 240/240 acknowledgements, exact timeout and oversize-rejection behavior, signal/RTT evidence, and restart profile retention. It closes only the direct-radio MTU/PHY/region requirement; RF/EIRP, range, support, compatibility, and regulatory gates remain open.
Evidence: OT-103 and OT-119 admit the two exact node profiles and complete Phase 0. OT-120 completes Phase 1 at counts 3/3/3. OT-121 and OT-122 prove all eight libsodium operations, Noise XK, and runtime heap/stack/watchdog measurements on both nodes; they use no radio and leave Phase 2 incomplete. Remaining other-candidate, radio, matched linked-flash/static-RAM, separate admission, selection, and score gates stay open. OT-114 is admitted physical profile evidence, not secure-LoRa implementation, target support, compatibility, legal/regulatory acceptance, cryptographic selection, or packet-v1 acceptance. No secure OpenTrail LoRa exchange or relay path is accepted.

Android companion

Kotlin, Android BLE, and JVM tests

Platform: Android min SDK 26, target SDK 35, explicit Nearby Devices permissions, and a connected-device foreground service.
Design: No fake fallback in Bluetooth mode; device-protected admission and bounded lifecycle ownership.
Evidence: APK, lint, JVM, bounded physical install, exact-service scan, and one fixed public read exist. OT-087 adds a non-debuggable unsigned release build at version code 1 / version name 1.0.0 and checks its packaged manifest, permissions, backup rules, DEX surface, and test-surface exclusions. OT-088 freezes the private-pilot privacy/data-safety, removal/no-downgrade, and best-effort/no-SLA support promises without executing them. OTAR0/v0 remains execution-blocked on physical matrix, release identity, and signer/custody; the release gate is NOT-EVALUATED.

Maintenance tool

.NET Windows desktop inspection shell

Validation: Bundle structure, SHA-256, and RSA-PSS-3072/SHA-256 verification when a signer is pinned.
Hardware: Limited read-only USB candidate recognition; no authoritative board selection.
Boundary: No browser flasher and no firmware writer.

Public project data

Typed records and generated progress

Authority: Canonical V1 milestones remain in the OpenTrail repository.
Website: Sanitized snapshots calculate progress and strip private workstation evidence paths.
Integrity: Weights, totals, dates, required fields, links, and public-only boundaries are validated.

Important: configured flash mode, memory profile, source completion, and build evidence are not substitutes for physical runtime, field range, endurance, or production acceptance.

Compatibility

Test evidence and planned devices, kept separate.

No OpenTrail hardware is validated yet. Bench evidence from other installed firmware is useful, but it is not an OpenTrail compatibility claim.

OpenTrail validated devicesNone yet

Bench-characterized and exploratory candidates

Hardware tested

Heltec V4 OLED bench units

V1 Companion LoRa-node candidates

Verified: OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds. Historical OT-147 populated BAT/GPS and OT-164 local-window evidence remain bounded earlier checkpoints, not current two-unit image identity.
Limits: After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.
Next test: Periodic recovery passes on one retained pair; next verify true cold-power recovery and current factory-reset/ownership gates. Separately validate battery accuracy, GNSS, secure radio, and the complete two-pair workflow.

OT-168 single-pair results and remaining gates

Bench characterized

SenseCAP Solar Node P1-Pro candidate

Possible V1.5 node or later relay candidate

Verified: The runtime reported Seeed SenseCap Solar under installed MeshCore repeater firmware. Bounded close-range forwarding and a GNSS fix were observed without retaining private identity or coordinates.
Limits: It is not an OpenTrail V1.5 node, repeater, or supported device. Exact received revision and internals, recovery, solar charging, endurance, weather exposure, field range, antenna, RF, and regulatory behavior remain open. Any future relay claim requires a physical three-radio path.
Next test: Record the exact received profile, then evaluate recovery, GNSS repeatability, power, weather, radio range, and OpenTrail behavior only when those gates are authorized.

Public hardware inventory

Exploratory candidate

Seeed Wio Tracker L1 candidate

Possible V1.5 node or future self-contained-device candidate

Verified: A read-only MeshCore USB/runtime/configuration pass identified the public USB family as Seeed Wio Tracker L1. The owner-reported purchase name is Wio Tracker L1 Pro.
Limits: The exact Pro SKU and revision are not independently established. OpenTrail compatibility, recovery, BLE, radio transmission, GNSS fix, endurance, antenna, and regulatory behavior are unproved.
Next test: Capture privacy-safe exterior identity and evaluate recovery and bounded hardware behavior before deciding whether it belongs on a supported test plan.

Public hardware inventory

Planned device testing

Hardware tested

Heltec V4 OLED experimental target

First bounded V1 Companion node

Evidence today: OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds. Historical OT-147 populated BAT/GPS and OT-164 local-window evidence remain bounded earlier checkpoints, not current two-unit image identity.
Limits: After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.
Planned test: Periodic recovery passes on one retained pair; next verify true cold-power recovery and current factory-reset/ownership gates. Separately validate battery accuracy, GNSS, secure radio, and the complete two-pair workflow.

Hardware tested

Limited Underground Trail App

V1 Companion user interface

Evidence today: OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds. Historical OT-147 populated BAT/GPS and OT-164 local-window evidence remain bounded earlier checkpoints, not current two-unit image identity.
Limits: After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.
Planned test: Periodic recovery passes on one retained pair; next verify true cold-power recovery and current factory-reset/ownership gates. Separately validate battery accuracy, GNSS, secure radio, and the complete two-pair workflow.

Planned

Integrated touchscreen Trail client

V2 Integrated standalone interface

Evidence today: The product direction is defined, but no complete touchscreen Trail client has been assembled or tested.
Limits: The exact board, touchscreen, controls, power, enclosure, GNSS, antenna, and production radio hardware are not frozen.
Planned test: Select the exact hardware stack, record received-unit evidence, and define recovery, display, input, power, enclosure, and field-acceptance gates before assigning a percentage.

Compatibility rule: a product family, successful generic build, matching connector, or bench result under different firmware does not establish OpenTrail support. A validated list will be published only after exact-device OpenTrail testing.

Development status

What is finished, what is coded, and what is still unknown.

Canonical evidence updated September 4, 2026. Percentages use canonical milestones where defined. Otherwise 0% means no separately assigned completion credit, not no work: tested work and remaining gates are listed below.

Host tested / canonical milestone

Architecture and Specifications

85%Evidence weighted

Protocol, recovery, privacy, degraded-operation, and owner-approved two-pair V1/four-node V1.5 scope rules are documented. OT-090 and OT-091 freeze host-only contracts. OT-093 freezes the deterministic candidate-free baseline; OT-094 preserves the historical six-blocker state; OT-095 through OT-099 preserve the admission and evidence history. OT-100 accepts only the exact OT-099 libsodium source lock, OT-102 accepts exact Monocypher 4.0.3 source evidence, OT-103 admits the exact received OT-DEV-001 profile, and OT-105 accepts only the pinned ESP-IDF v6.0.2 / mbedTLS 4.1.0 source dependency lock. OT-107 accepts the owner-approved final per-candidate configuration and closes only that requirement. OT-108 freezes the corrected per-candidate API/configuration acceptance boundary while accepting no evidence and closing no blocker. OT-109 admits exact mbedTLS/PSA evidence for five of eight operations as comparison-only and structurally nonselectable, closing only the API/configuration requirement. History is now historical six, prior five, prior four, prior three, prior two, and current one requirement; at OT-109 acceptance source/API-configuration/import counts were 3/1/0, OT-096 remains the historical 5/8 static result, and the direct-radio requirement is closed by OT-114; OT-116 records all six historical requirements closed and freezes the phased successor plan at source/API/import counts 3/1/0. OT-117 admits complete eight-of-eight libsodium API/configuration evidence at counts 3/2/0. OT-118 then admits strict five-of-eight Monocypher comparison evidence, populates all three API/configuration registries, and advances current counts to 3/3/0 while measurement remains blocked. OT-119 then independently admits the OT-DEV-002 exact profile, brings the exact-profile registry to two, and completes Phase 0 while counts stay 3/3/0; at OT-119 acceptance, measurement remained blocked only by absent retained candidate import/build admissions and fresh execution authority. Target/app implementation, support, regulatory acceptance, benchmark execution, selection, and coherent physical acceptance remain open. OT-112 preserves bounded smoke history; OT-114 closes only the direct-radio requirement through admitted exact two-node close-bench evidence. OT-116 freezes the successor review and phased plan at 3/1/0; OT-117 advances counts to 3/2/0 through complete libsodium API/configuration admission; OT-118 then populates all three API/configuration registries and advances current counts to 3/3/0 through partial Monocypher comparison admission while measurement and score remain blocked. OT-120 then atomically accepts retained host-only import/build evidence for all three candidates after two independent clean zero-warning builds per candidate, advancing source/API-configuration/import counts to 3/3/3 and completing Phase 1. Measurement remains false and blocked only by absent fresh benchmark execution authority; no benchmark, device, radio, key/entropy, selection, support, compatibility, regulatory, implementation, physical-acceptance, or score claim is added. OT-121 and OT-122 partially exercise the bounded Phase 2 session: both anonymous admitted nodes pass all eight libsodium operations, including benchmark-only Noise XK, with 100 data-cache-conditioned and 100 warm samples per operation, runtime heap/stack/watchdog measurements, and exact Trail restoration. OT-123 then prepares but does not execute the exact five-of-eight Monocypher comparison target, parser, recovery-safe runner, two reproducible zero-warning builds, and a matched-resource accounting contract. OT-124 records the subsequent Monocypher attempt as aborted after Node A benchmark write/readback and a bounded capture timeout; Node A was restored, readback-verified, and reset to exact Trail, Node B was untouched after the two-node installed-Trail preflight, and no Monocypher frame, timing, or benchmark result was admitted. Decision 0059 is consumed and nonreusable. OT-126 records the corrective retry as aborted with the touched node exactly restored and both devices returned to visible Trail runtime; Decision 0064 is consumed. OT-128 records the OT-127 attempt as aborted after Node A benchmark readback without a validated capture; every benchmark-touched node was restored exactly, Decision 0066 is consumed, and no result was admitted. The private receipt does not classify the capture failure, so no physical root cause is admitted. OT-129 accepts the computer-only Monocypher START/READY correction: the host retries exact START until the isolated successor target drains READY before the unchanged 1,014-frame stream; partial bytes survive read timeouts; endpoint lifecycle proves observed re-enumeration or stable continuous presence; bounded startup chatter and privacy-safe failure categories/counters fail closed without raw exception context; and native, static, real-parser, and pinned ESP-IDF 6.0.2 compile-only validation pass. No device, flash, benchmark, radio, execution authority, selection, Phase 2 completion, support, compatibility, regulatory, production, or score claim is added. OT-130 now freezes the exact firmware/runner/restoration-coordinator bundle after two matching fresh ESP-IDF v6.0.2 six-file builds and accepts a fresh non-reusable one-attempt authority; coordinator and preparation/authority tests each pass 11/11. The authority is not executed, and no device, flash, benchmark, or radio operation occurs. OT-131 then binds the concrete executable adapter and replacement one-attempt authority, records the single attempt as aborted at capture_failed/preamble_invalid after Node A benchmark readback, restores Node A exactly while Node B remains on Trail, and consumes that authority; the owner confirms both Trail logos. The latest admitted bounded benchmark result is OT-146 with phase_two_complete=false and radio_used=false. The combined measurement corpus still requires independent Phase 2 admission; candidate/library/suite, handshake/KDF, packet-v1 wire, support, compatibility, regulatory, production, secure-LoRa, end-to-end, and score claims remain open. OT-132 then accepts a new host-only successor runner that tolerates complete opaque pre-READY records only within the unchanged eight-record/512-byte limits while preserving exact READY, frame-before-READY rejection, post-READY strictness, fixed deadlines, privacy-safe counters, and the unchanged real 1,014-frame parser. Fourteen adversarial tests and all frozen OT-129 through OT-131 regression gates pass. No hardware, flash, benchmark, radio, execution authority, result, selection, Phase 2 completion, support, compatibility, regulatory, production, secure-LoRa, end-to-end, or score claim is added. OT-133 binds the OT-132 runner into a fresh immutable successor and consumes one non-reusable attempt on the nine-record/eight-record pre-READY boundary after Node A benchmark readback; Node A restores exactly, Node B is never benchmark-written after preflight and remains on Trail, both logos are confirmed, and no result or score is admitted. OT-135 accepts the host-only byte-bounded preamble successor while leaving OT-129 through OT-133 immutable: complete opaque pre-READY records are bounded by the unchanged cumulative 512-byte budget and fixed control deadline, with exact READY/frame/privacy behavior and the strict 1,014-frame parser preserved. No hardware, authority, result, Phase 2 completion, or score claim is added. OT-136 binds the exact OT-135 runner, unchanged strict parser/schema, fresh coordinator/private state, concrete adapter, benchmark application, and Trail restoration application into one executable bundle and accepts a fresh workspace-local non-reusable one-attempt authority without executing it; no hardware, result, Phase 2 completion, or score claim changes. OT-137 then consumes the OT-136 workspace-local authority on one fail-closed application-only attempt: Node A passes benchmark readback, bounded capture rejects remaining partial pre-READY data after two 512-byte reads, Node A restores exactly, Node B is never benchmark-written after preflight and remains on Trail, both logos are confirmed, and no benchmark result or score is admitted. OT-138 then classifies the shared startup-console/control conflict host-only, and OT-139 accepts a separate reproducible quiet target that disables both ESP-IDF consoles and bootloader/default/maximum application logging while retaining the direct USB Serial/JTAG driver and normal ROM logging. Two fresh builds reproduce the same six-file tuple; no executable binding, authority, hardware, result, Phase 2 completion, or score claim is added. OT-140 then freezes that exact tuple with the unchanged OT-135 runner/parser, fresh restoration-safe coordinator/private namespace, concrete adapter, and exact Trail restoration image, and accepts one explicit workspace-local non-reusable authority without executing it; no hardware, result, Phase 2 completion, or score claim changes. OT-142 records that the authority was consumed by one fail-closed attempt with exact restoration and no admitted result, traces the deterministic failure to a malformed RFC 8032 seed in the benchmark-only fixture, and accepts a separate host-only successor that changes only the seed, verifies the real pinned Monocypher implementation, reproduces two matching fresh builds, and passes the complete Windows host matrix. OT-143 then freezes the exact corrected target, six-file artifact tuple, unchanged strict runner/parser, fresh restoration-safe coordinator/private namespace, concrete adapter, and exact Trail restoration image, and accepts one explicitly approved workspace-local non-reusable authority without executing it. Two fresh host builds reproduced the exact accepted OT-142 tuple; no hardware, firmware write, benchmark result, radio, selection, Phase 2 completion, or score claim is added. OT-144 then rejects the OT-143 image-binding mismatch before device I/O, OT-145 accepts the corrected fresh one-attempt authority, and OT-146 consumes it on one successful two-node application-only Monocypher comparison. Both anonymous nodes complete 5/5 admitted operations with 100 data-cache-conditioned and 100 warm samples per operation, validate all 1,014 frames, and restore/read back/reset exactly to Trail; both displays return. Radio remains unused, independent Phase 2 admission and explicit cryptographic/wire selection remain open, and completion remains unchanged.

Remaining work: Close the remaining product-firmware architecture gates with target evidence.

Protocol and message contracts

Host tested

0% separately credited

Retain exact cross-language and target evidence as physical integration proceeds.

Host and cross-language protocol gates

Privacy and ownership rules

Host tested

0% separately credited

Validate the rules on an authorized physical target and real phone link.

Authorization and privacy policy tests

Recovery and degraded-operation contracts

Host tested

0% separately credited

Prove recovery and degraded behavior on a recoverable physical unit.

Recovery and fail-closed host evidence

Canonical V1 record and architecture evidence

Host tested / canonical milestone

Core Firmware

65%Evidence weighted

Hardware-neutral communication, status, alert, persistence, update, and recovery components exist, while authenticated complete-target composition remains open.

Remaining work: Bind the selected client hardware and prove the complete target composition.

Transport-neutral protocol core

Host tested

0% separately credited

Retain conformance while target bindings become active.

Native host test matrix

Status, alert, persistence, and update components

Host tested

0% separately credited

Replace injected test seams with accepted target services.

Component-level host evidence

Portable client composition

Coded

0% separately credited

Prove the complete composition on selected hardware.

Portable target composition

Canonical core-firmware milestone

Hardware tested / canonical milestone

Heltec Firmware Integration

25%Evidence weighted

The retained experimental Heltec V4.2/Note20 pair passes saved-owner authorization, app-process/warm-reset persistence, and periodic Android recovery after a 65.866-second ROM absence. Firmware remains the accepted 563,824-byte 91D4 application embedding 110e543-dirty; no clean-commit hash equivalence is claimed. Cold-power, factory reset, battery calibration, secure LoRa and complete two-pair/field/support acceptance remain open. See tests/hardware/OT-168-PERIODIC-2026-09-04.md.

Remaining work: After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.

Exact received OT-DEV-001 profile

Hardware tested

0% separately credited

Heltec Automation WiFi LoRa 32 V4 / HTIT-WB32LAF / V4.2, ESP32-S3R2 revision v0.2, 16 MiB flash, and 2 MiB PSRAM are bound for this experimental unit. Electrical RF, antenna, support, compatibility, and regulatory acceptance remain open.

OT-103 bounded identity plus earlier exact-profile build and selected-unit runtime evidence

Recovery-oriented partition layout

Hardware tested

0% separately credited

Factory-reset/erasure and true cold-power recovery remain open; physical reflashing can roll back ownership.

OT-168 verifies one exact application-only write/readback with retained recovery evidence and saved-owner persistence

Compact status footer

Hardware tested

0% separately credited

Connect and physically accept the remaining LoRa RX/TX activity source; calibrate battery behavior and validate GNSS fix quality and stale/unavailable states.

OT-147 installs identical live-status firmware on both units with populated BAT and GPS values; https://github.com/Limited-Underground/Trail/blob/e97ce71a7f9aa7c5d05960b5de7b96c9da520ecb/tests/hardware/OT-147-2026-08-26.md

Physical OpenTrail boot and startup display

Hardware tested

0% separately credited

Power, enclosure, battery calibration, and full operational acceptance remain open.

Normal display return and automatic warm-reset reconnect are accepted on one retained pair

OT-168 single-pair periodic-recovery evidence

Hardware tested / Completion credit pending

BLE Device-to-Phone Connection

0%Accepted completion · separate metric pending

Device public GATT read and link lifecycle

Hardware tested

0% separately credited

Broaden bounded operational acceptance without inferring stable device identity.

Exact 16-byte public value, READ-only characteristic, no phone disconnect request, target-initiated disconnect inside the frozen window, and one compatible advertiser returned

Android public read flow

Hardware tested

0% separately credited

Broaden bounded operational acceptance without claiming a supported phone.

One authorized Android 13 / API 33 phone completed the exact public read

Physical public link and disconnect

Hardware tested

0% separately credited

Repeat the bounded flow only as part of operational acceptance.

BLE CONNECTED to BLE ADVERTISING observed for both disconnect paths; one compatible advertiser returned without a stable-identity claim

Pairing and saved-owner recovery

Hardware tested

0% separately credited

Current V1 uses a 60-second unowned-boot enrollment window and destructive factory reset, not phone replacement. Complete both-pair reset acceptance remains open.

Historical OT-164 local-window evidence is retained; OT-168 now passes fresh protected saved-owner authorization and Snapshot on one pair

OT-168 single-pair periodic-recovery evidence

Hardware tested / canonical weighted total

Limited Underground Trail App

60%Evidence weighted

Application and lifecycle composition

Hardware tested

0% separately credited

Execute the accepted OTAR0/v0 plan only after physical matrix, release identity, and signer/custody are satisfied.

Five of eight prerequisites are satisfied; policy approval did not execute privacy, rollback, support, or release acceptance

Protected BLE runtime

Hardware tested

0% separately credited

Install and device acceptance

Hardware tested

0% separately credited

Approve and freeze exactly two private-pilot phones, then prove first-release uninstall/reinstall, promised data removal, downgrade handling, accessibility, and support without claiming in-place-upgrade credit.

OT-088 freezes policy and OT-089 narrows scope only; one Note20 test phone now has OT-168 single-pair evidence; the signed two-phone release matrix remains unaccepted

OT-168 single-pair periodic-recovery evidence

Build tested / canonical milestone

Firmware Loader

15%Evidence weighted

The shared desktop loader provides bounded offline inspection, while production trust, authoritative board matching, writing, and recovery remain absent.

Remaining work: Complete authorized hardware probes, independent trust review, signer custody, and pinned production trust before any writer is implemented.

Packaged Windows inspection shell

Build tested

0% separately credited

Retain read-only behavior until trust and hardware authority are accepted.

Packaged desktop evidence

Bundle digest and optional signature verification

Host tested

0% separately credited

Approve production signer custody and pinned trust.

Cross-tool vector evidence

Firmware writing

Planned

0% separately credited

No writer is implemented or authorized.

Not implemented

Windows loader inspection-shell contract

Hardware tested / Completion credit pending

Recovery and Safe-Flashing Workflow

0%Accepted completion · separate metric pending

Exact-profile ROM entry, bounded writes, verification, boot, and runtime have been accepted on one unit; a post-loss known-good restore has not.

Remaining work: Keep further write authority closed and prove a bounded restore only under a future explicit recovery gate.

ROM-entry and recovery preparation

Hardware tested

0% separately credited

Manual ROM entry/exit was rehearsed; a recovery-after-loss execution remains open.

Selected-unit ROM-entry evidence

Candidate identity and verification

Hardware tested

0% separately credited

Retain exact artifacts and fail-closed write boundaries for any later authorized operation.

Exact preflight and post-write region verification

Known-good restore

Planned

0% separately credited

Prove a bounded restore after explicit authorization.

No accepted completion evidence

Open physical recovery gates

Hardware tested / Completion credit pending

Status Display, Radio, and GNSS Integration

0%Accepted completion · separate metric pending

Current V1 uses an Android interface and Heltec nodes with bounded local status. OT-114 admits the exact two-node US915 close-bench profile; OT-147 physically accepts populated battery and GNSS-satellite footer values on both nodes; OT-164 physically accepts the local pairing window on both nodes.

Local status display

Hardware tested

0% separately credited

Battery percentage is approximate and its accuracy is under investigation; GNSS fix/staleness and menu behavior remain open.

Historical OT-147 populated BAT/GPS and OT-164 window evidence are retained; OT-168 adds the latest single-pair recovery evidence

OpenTrail radio behavior

Hardware tested

0% separately credited

Retain the admitted close-bench profile while treating EIRP, range, support, compatibility, secure transport, and regulatory acceptance as unresolved.

OT-114 admits 242/242 probe/data frames and 240/240 acknowledgements with exact 163-byte and 255-byte profiles, timeout enforcement, oversize rejection, signal/RTT evidence, and restart profile retention. It closes only the direct-radio requirement; score and readiness do not advance.

GNSS and location behavior

Hardware tested

0% separately credited

Prove fix acquisition, accuracy, stale, and unavailable states beyond the displayed satellite count.

OT-147 physically accepts a populated GNSS satellite-count field on both experimental nodes

OT-168 single-pair periodic-recovery evidence

Planned / canonical milestone

Historical Standalone Complete-Device Plan

0%Evidence weighted

The display, internal radio/GNSS module, power path, enclosure, and exact production target still require a frozen build and integration.

Remaining work: Retain this standalone planning record for continuity; it no longer defines current V1 Companion completion.

Selected exact hardware

Planned

0% separately credited

OT-103 and OT-119 bind the two experimental units as Heltec Automation WiFi LoRa 32 V4 / HTIT-WB32LAF / V4.2. Supported-device selection, electrical RF, antenna, and regulatory acceptance remain open.

OT-119 two-node exact-profile admission evidence

Recoverable target firmware

Hardware tested

0% separately credited

Boot and bounded runtime are accepted on one unit; post-loss restore and complete target composition remain open.

OT-061 and OT-064 selected-unit evidence

Standalone client acceptance

Planned

0% separately credited

Display, radio, GNSS, power, and enclosure are incomplete.

No accepted completion evidence

Historical canonical first-complete-unit milestone

Planned / canonical milestone

Two-Pair End-to-End V1 Acceptance

0%Evidence weighted

Exactly two supported Heltec/Android pairs must coherently pass fresh-PIN authorization, restart reconnect, cross-pair denial, destructive factory-reset recovery with old-phone rejection, authenticated/encrypted bidirectional direct-LoRa messaging, rejection/duplicate/retry/recovery, and the exact signed Android release on both phones. OT-093 freezes only the candidate-free pre-crypto build baseline, OT-094 freezes only the blocked readiness contract, and OT-095 freezes only zero-source source-lock admission semantics. OT-103 adds bounded exact received-target identity for OT-DEV-001. OT-112 preserves bounded smoke history. OT-114 closes only the direct-radio requirement through admitted exact two-node close-bench evidence. OT-116 freezes the successor review and phased plan at 3/1/0; OT-117 admits complete libsodium API/configuration evidence at 3/2/0; OT-118 then admits partial Monocypher comparison evidence, populating all three API/configuration registries and advancing current counts to 3/3/0 while measurement remains blocked. OT-119 then independently admits the OT-DEV-002 exact profile, brings the exact-profile registry to two, and completes Phase 0 while counts stay 3/3/0; at OT-119 acceptance, measurement remained blocked only by absent retained candidate import/build admissions and fresh execution authority. Supported-target, regulatory, crypto selection, secure-radio implementation, and coherent end-to-end physical evidence remain open. OT-120 then atomically accepts retained host-only import/build evidence for all three candidates after two independent clean zero-warning builds per candidate, advancing source/API-configuration/import counts to 3/3/3 and completing Phase 1. Measurement remains false and blocked only by absent fresh benchmark execution authority; no benchmark, device, radio, key/entropy, selection, support, compatibility, regulatory, implementation, physical-acceptance, or score claim is added. OT-121 and OT-122 partially exercise the bounded Phase 2 session: both anonymous admitted nodes pass all eight libsodium operations, including benchmark-only Noise XK, with 100 data-cache-conditioned and 100 warm samples per operation, runtime heap/stack/watchdog measurements, and exact Trail restoration. OT-123 then prepares but does not execute the exact five-of-eight Monocypher comparison target, parser, recovery-safe runner, two reproducible zero-warning builds, and a matched-resource accounting contract. OT-124 records the subsequent Monocypher attempt as aborted after Node A benchmark write/readback and a bounded capture timeout; Node A was restored, readback-verified, and reset to exact Trail, Node B was untouched after the two-node installed-Trail preflight, and no Monocypher frame, timing, or benchmark result was admitted. Decision 0059 is consumed and nonreusable. OT-126 records the corrective retry as aborted with the touched node exactly restored and both devices returned to visible Trail runtime; Decision 0064 is consumed. OT-128 records the OT-127 attempt as aborted after Node A benchmark readback without a validated capture; every benchmark-touched node was restored exactly, Decision 0066 is consumed, and no result was admitted. The private receipt does not classify the capture failure, so no physical root cause is admitted. OT-129 accepts the computer-only Monocypher START/READY correction: the host retries exact START until the isolated successor target drains READY before the unchanged 1,014-frame stream; partial bytes survive read timeouts; endpoint lifecycle proves observed re-enumeration or stable continuous presence; bounded startup chatter and privacy-safe failure categories/counters fail closed without raw exception context; and native, static, real-parser, and pinned ESP-IDF 6.0.2 compile-only validation pass. No device, flash, benchmark, radio, execution authority, selection, Phase 2 completion, support, compatibility, regulatory, production, or score claim is added. OT-130 now freezes the exact firmware/runner/restoration-coordinator bundle after two matching fresh ESP-IDF v6.0.2 six-file builds and accepts a fresh non-reusable one-attempt authority; coordinator and preparation/authority tests each pass 11/11. The authority is not executed, and no device, flash, benchmark, or radio operation occurs. OT-131 then binds the concrete executable adapter and replacement one-attempt authority, records the single attempt as aborted at capture_failed/preamble_invalid after Node A benchmark readback, restores Node A exactly while Node B remains on Trail, and consumes that authority; the owner confirms both Trail logos. The latest admitted bounded benchmark result is OT-146 with phase_two_complete=false and radio_used=false. The combined measurement corpus still requires independent Phase 2 admission; candidate/library/suite, handshake/KDF, packet-v1 wire, support, compatibility, regulatory, production, secure-LoRa, end-to-end, and score claims remain open. OT-132 then accepts a new host-only successor runner that tolerates complete opaque pre-READY records only within the unchanged eight-record/512-byte limits while preserving exact READY, frame-before-READY rejection, post-READY strictness, fixed deadlines, privacy-safe counters, and the unchanged real 1,014-frame parser. Fourteen adversarial tests and all frozen OT-129 through OT-131 regression gates pass. No hardware, flash, benchmark, radio, execution authority, result, selection, Phase 2 completion, support, compatibility, regulatory, production, secure-LoRa, end-to-end, or score claim is added. OT-133 binds the OT-132 runner into a fresh immutable successor and consumes one non-reusable attempt on the nine-record/eight-record pre-READY boundary after Node A benchmark readback; Node A restores exactly, Node B is never benchmark-written after preflight and remains on Trail, both logos are confirmed, and no result or score is admitted. OT-135 accepts the host-only byte-bounded preamble successor while leaving OT-129 through OT-133 immutable: complete opaque pre-READY records are bounded by the unchanged cumulative 512-byte budget and fixed control deadline, with exact READY/frame/privacy behavior and the strict 1,014-frame parser preserved. No hardware, authority, result, Phase 2 completion, or score claim is added. OT-136 binds the exact OT-135 runner, unchanged strict parser/schema, fresh coordinator/private state, concrete adapter, benchmark application, and Trail restoration application into one executable bundle and accepts a fresh workspace-local non-reusable one-attempt authority without executing it; no hardware, result, Phase 2 completion, or score claim changes. OT-137 then consumes the OT-136 workspace-local authority on one fail-closed application-only attempt: Node A passes benchmark readback, bounded capture rejects remaining partial pre-READY data after two 512-byte reads, Node A restores exactly, Node B is never benchmark-written after preflight and remains on Trail, both logos are confirmed, and no benchmark result or score is admitted. OT-138 then classifies the shared startup-console/control conflict host-only, and OT-139 accepts a separate reproducible quiet target that disables both ESP-IDF consoles and bootloader/default/maximum application logging while retaining the direct USB Serial/JTAG driver and normal ROM logging. Two fresh builds reproduce the same six-file tuple; no executable binding, authority, hardware, result, Phase 2 completion, or score claim is added. OT-140 then freezes that exact tuple with the unchanged OT-135 runner/parser, fresh restoration-safe coordinator/private namespace, concrete adapter, and exact Trail restoration image, and accepts one explicit workspace-local non-reusable authority without executing it; no hardware, result, Phase 2 completion, or score claim changes. OT-142 records that the authority was consumed by one fail-closed attempt with exact restoration and no admitted result, traces the deterministic failure to a malformed RFC 8032 seed in the benchmark-only fixture, and accepts a separate host-only successor that changes only the seed, verifies the real pinned Monocypher implementation, reproduces two matching fresh builds, and passes the complete Windows host matrix. OT-143 then freezes the exact corrected target, six-file artifact tuple, unchanged strict runner/parser, fresh restoration-safe coordinator/private namespace, concrete adapter, and exact Trail restoration image, and accepts one explicitly approved workspace-local non-reusable authority without executing it. Two fresh host builds reproduced the exact accepted OT-142 tuple; no hardware, firmware write, benchmark result, radio, selection, Phase 2 completion, or score claim is added. OT-144 then rejects the OT-143 image-binding mismatch before device I/O, OT-145 accepts the corrected fresh one-attempt authority, and OT-146 consumes it on one successful two-node application-only Monocypher comparison. Both anonymous nodes complete 5/5 admitted operations with 100 data-cache-conditioned and 100 warm samples per operation, validate all 1,014 frames, and restore/read back/reset exactly to Trail; both displays return. Radio remains unused, independent Phase 2 admission and explicit cryptographic/wire selection remain open, and completion remains unchanged.

Remaining work: Historical OT-164 accepted the local PIN window on both nodes. Current OT-168 single-pair acceptance and the remaining gates are described below. OT-168: one Heltec V4.2 and Note20 Ultra pair passes saved-owner authorization, fresh device Snapshot/Ready, app-process persistence, and automatic warm-reset reconnect. The measured 1.493-second interval is BLE link recovery, not full Ready latency. Periodic reconnect is implemented and physically passed after a 65.866-second ROM absence: one empty scan, then automatic recovery during the next scan, without phone input. Link returned 1.220 seconds after reset completion; authenticated Ready was observed within 8.373 seconds. After three quick retries, the open app waits 15 seconds between five-second saved-owner scans. Explicit disconnect stops recovery. The physical result covers one retained pair; true cold-power recovery, factory-reset erasure, production zero-tap launch, and coherent two-phone/two-Heltec secure-LoRa acceptance remain open. Battery-percentage accuracy and Android interface cleanup are follow-ups; no supported or production-ready release is claimed.

Exactly two supported Heltec devices

Planned

0% separately credited

Both experimental nodes have bounded direct-radio, live-footer, and local pairing-window evidence, but neither node is supported and the supported two-device matrix remains unaccepted.

No supported-device pair exists

Exactly two approved Android phones

Planned

0% separately credited

Approve the two-phone physical matrix and execute OTAR on one exact signed candidate.

No phone model is publicly selected or supported

Secure BLE to direct LoRa to BLE

Planned

0% separately credited

Prove the complete two-pair authenticated/encrypted radio path, rejection, duplicate handling, acknowledgements, retry, factory reset, and recovery; no phone replacement flow is part of current V1.

No coherent two-pair or secure-LoRa acceptance exists

OT-164 two-node local pairing-window evidence

Planned / canonical milestone

Historical Standalone Field Plan

0%Evidence weighted

This preserved historical baseline expected four identical standalone clients to pass recovery, range, endurance, usability, and repeatable field trials; Decision 0033 supersedes it as the V1 Companion completion gate.

Remaining work: Retain this four-unit standalone plan as history; current V1 uses the separate two-pair end-to-end gate, and four-node work belongs to unmeasured V1.5.

Range and packet behavior

Planned

0% separately credited

Measure range, latency, loss, duplicates, and degraded operation.

No accepted completion evidence

Endurance and recovery

Planned

0% separately credited

Measure power, uptime, recovery, and repeatability.

No accepted completion evidence

Four-person usability

Planned

0% separately credited

Historical standalone gate only; it does not define current V1 Companion completion.

Preserved planning history

Historical canonical four-person field-proof milestone

Mixed evidence / not yet measured

Trail Release Tracking

44%Evidence weighted

V1 Companion remains the measured current release. V1.5 Multi-node Interoperability and V2 Integrated are separate unmeasured tracks, and the standalone baseline remains historical.

V1 Companion

Mixed evidence

44%

V1.5 Multi-node Interoperability

Planned

0% separately credited

Four supported OpenTrail LoRa nodes, using any compatible mixture of hardware, run one authenticated protocol and communicate correctly together; heterogeneous hardware is preferred but not required, four phones are unnecessary, and any relay claim requires a physical three-radio path. Approve its evidence weights and exact supported-node plan; zero displayed credit does not mark the track measured.

Canonical V1.5 track remains unmeasured

Historical standalone baseline

Mixed evidence

32%

Retain for continuity without presenting it as the current Companion release.

Canonical historical baseline evidence

V2 Integrated

Planned

0% separately credited

Define touchscreen, input, power, enclosure, recovery, and field milestones.

No complete touchscreen hardware stack is frozen

Canonical baseline and release-track record

Demos and downloads

No installable Trail firmware is offered yet.

A safe public download must identify its target, size, digest, signature authority, source release, license, and evidence tier.

Device Tools are planned - not available.

The future browser route will document compatibility and maintenance boundaries. It does not expose USB, serial, HID, Bluetooth, firmware selection, write, or fake-success controls.

Review the planned boundary

Updates

Dated changes, with the percentage held honest.

Recent accepted increments improved evidence without pretending the physical gates were complete.

September 4, 2026

OT-168 passes periodic recovery after an extended absence.

Review the accepted test and limitations

August 25, 2026

OT-138 classifies the boot/control transport conflict host-only; the next gate is a quiet-target build.

Fabricated bytes reproduce the complete public OT-137 counter shape and show that the frozen runner can count already queued startup traffic and post-START preamble against the same 512-byte budget, aborting before the 250 ms START retry becomes due. The accepted build structurally shares USB Serial/JTAG between startup console output and the later direct control protocol, while runtime log suppression begins only in app_main. The unretained OT-137 bytes remain unconfirmed and are not labeled as boot logs. Next is a console-isolated quiet-target configuration plus two fresh matching BIN/ELF/map/sdkconfig builds. OT-138 creates no firmware successor, authority, hardware attempt, benchmark result, radio evidence, selection, Phase 2 completion, or score change. V1 Companion remains exact 43.75% / displayed 44%.

August 25, 2026

OT-137 consumes the sole authority on a bounded capture abort; both devices remain on Trail.

OT-135 first accepts the host-only byte-bounded preamble correction, and OT-136 binds the exact runner, parser, coordinator, adapter, benchmark application, and Trail restoration application into one executable bundle with one fresh workspace-local non-reusable authority. OT-137 consumes that authority on exactly one application-only attempt. Node A passed benchmark readback, but bounded capture failed closed as capture_failed / preamble_invalid when remaining partial pre-READY data would cross the cumulative 512-byte limit. Node A restored exactly to Trail; Node B was never benchmark-written after preflight and remained on Trail; both logos were confirmed. The authority is consumed and nonreusable. The latest admitted benchmark result remains OT-122. No Monocypher result, frame, radio, selection, Phase 2 completion, or score was added, and no Monocypher hardware attempt is currently authorized. Next is host-only investigation of partial-data and live boot-control behavior before any new immutable successor or authority. V1 Companion remains exact 43.75% / displayed 44%.

August 24, 2026

One immutable OT-133 attempt closes safely at a bounded pre-READY mismatch.

OT-133 binds the OT-132 runner into a fresh immutable executable successor and consumes exactly one non-reusable application-only attempt. Node A passed benchmark readback; capture then failed closed as capture_failed / preamble_invalid after nine complete pre-READY records were observed in one 512-byte read, exceeding the frozen eight-record cap before any result frame. Node A restored, read back, and reset exactly to Trail. Node B was never benchmark-written and remained on Trail. Restoration completed and the owner confirmed both Trail logos. The authority is consumed and nonreusable. The latest admitted benchmark result remains OT-122; no Monocypher result, radio, selection, Phase 2 completion, or score was added. No further Monocypher hardware attempt is authorized. Next is host-only correction and adversarial testing of the nine-record boundary while retaining exact READY/frame strictness, privacy-safe diagnostics, and the real 1,014-frame parser; any later device access requires a new immutable successor and fresh authority. V1 Companion remains exact 43.75% / displayed 44%.

August 24, 2026

Opaque pre-READY capture correction accepted host-only.

OT-132 accepts the host-only pre-READY correction. Complete opaque boot records are tolerated only within the unchanged eight-record / 512-byte limits; exact READY, frame-before-READY rejection, post-READY framing, fixed deadlines, privacy-safe counters, and the real 1,014-frame parser remain strict. Fourteen adversarial tests and all frozen OT-129 through OT-131 regressions pass. No hardware, flash, benchmark, radio, execution authority, result, selection, Phase 2 completion, or score was added. OT-131 remains consumed; before any device access, freeze a new immutable executable binding and obtain fresh explicit one-attempt authority. The latest admitted benchmark result remains OT-122 and V1 Companion remains exact 43.75% / displayed 44%.

August 24, 2026

One-attempt Monocypher execution closes as a controlled abort; both devices restore exactly to Trail.

OT-131 records the single executable Monocypher attempt as a controlled abort after Node A benchmark readback: capture failed closed as capture_failed / preamble_invalid. Node A was restored, readback-verified, and reset exactly to Trail; Node B was never benchmark-flashed and remained on Trail. Restoration completed and the owner confirmed both Trail logos. The one-attempt authority is consumed and nonreusable. The latest admitted benchmark result remains OT-122; no Monocypher result, frame, radio, selection, Phase 2 completion, or score was added. Before any future hardware attempt, correct and validate the pre-READY capture boundary host-only, then require a new immutable executable binding and fresh explicit authority. V1 Companion remains exact 43.75% and displays as 44%.

August 24, 2026

Monocypher capture protocol corrected and validated computer-only.

OT-129 accepts retrying exact START/READY, partial-byte accumulation across read timeouts, verified re-enumerated or stable-continuous endpoint lifecycle, bounded startup chatter, privacy-safe failure categories and counters, the unchanged real 1,014-frame parser, and a pinned ESP-IDF 6.0.2 compile-only pass. No device was accessed or flashed, no benchmark or radio ran, and no result, score, or execution authority was admitted. The next gate freezes the exact firmware, runner, and restoration coordinator together before fresh nonreusable authority.

August 24, 2026

Monocypher corrective retry aborts without a result; both devices restore.

OT-128 records a failed capture, not a benchmark result. Every touched node restored exactly to Trail, both endpoints returned after a non-writing reset, and the owner later confirmed both displays on. The physical root cause remains unconfirmed. Before another hardware attempt, the runner must gain an explicit start/ready handshake, partial-byte accumulation, verified endpoint lifecycle, and privacy-safe failure classification.

August 23, 2026

Both nodes pass complete libsodium Noise XK and runtime-resource measurement.

OT-122 records all eight libsodium operations on both anonymous nodes with 100 data-cache-conditioned and 100 warm samples per operation. Both nodes measure 0 bytes peak dynamic heap, 4,312 bytes maximum stack use, and 0 watchdog resets; both captures validate and both devices restore exactly to Trail. Phase 2 remains incomplete and no radio was used; other candidates, radio, matched linked-flash/static-RAM admission, separate Phase 3 admission, selection, support, and score gates remain open.

August 23, 2026

Both nodes pass the bounded libsodium local-primitives checkpoint.

OT-121 records all seven local operations on both anonymous nodes with 100 data-cache-conditioned and 100 warm samples per operation. Both captures validate and both devices restore exactly to Trail. Phase 2 remains incomplete and no radio was used; remaining candidates, Noise XK, radio, resources, separate Phase 3 admission, selection, support, and score gates remain open.

August 22, 2026

All retained candidate import/build admissions complete; Phase 1 closed.

OT-120 admits the reproducible retained libsodium, mbedTLS/PSA, and Monocypher builds and advances source/API-configuration/import counts to 3/3/3. Phase 1 is complete. Fresh benchmark execution authority is the only remaining pre-measurement blocker. No benchmark, device, radio, key operation, suite/wire selection, or score authority is added.

August 22, 2026

Second exact node profile admitted; Phase 0 closed.

OT-119 admits OT-DEV-002 as the second exact received Heltec V4.2 profile. Both node profiles are now admitted and Phase 0 is complete. One bounded read-only USB/ROM observation accessed OT-DEV-002; no persistent state changed, no firmware was flashed, no benchmark or radio operation ran, and no support, compatibility, regulatory, selection, or score authority is added.

August 22, 2026

Monocypher API/configuration comparison evidence admitted host-only.

OT-118 admits exactly 5/8 fixed operations for Monocypher 4.0.3: Ed25519 sign/verify, X25519, and ChaCha20-Poly1305 encrypt/decrypt. SHA-256, HKDF-SHA256, and Noise XK remain unavailable, so Monocypher is comparison-only and structurally nonselectable. Accepted source/API-configuration/import counts advance to 3/3/0, completing all three API/configuration admissions. Phase 0 now lacks only the second node's exact profile; every retained import/build admission and fresh execution authority also remain absent. No benchmark, device, radio, key operation, selection, or score credit is added. V1 remains exact 43.75% / displayed 44%.

August 22, 2026

Complete libsodium API/configuration evidence admitted host-only.

OT-117 admits all 8/8 fixed operations for the primary libsodium candidate, including the separately hash-bound benchmark-only Noise_XK_25519_ChaChaPoly_SHA256 composition. Accepted source/API-configuration/import counts advance to 3/2/0. Libsodium is structurally selection eligible, but no candidate is selected and no benchmark, device, radio, production key or entropy operation, or score credit is added. Measurement remains blocked pending Monocypher API/configuration, the second node's exact profile, every retained import/build admission, and fresh execution authority. V1 remains exact 43.75% / displayed 44%.

August 22, 2026

Successor crypto readiness review and phased benchmark plan frozen.

OT-116 records all six historical OT-094 requirements closed and freezes the exact fail-closed procedure. Measurement remains blocked at 3/1/0 until candidate-specific API/configuration and retained import/build evidence pass and fresh execution authority is granted. No benchmark or selection ran, and the exact 43.75% / displayed 44% score is unchanged.

August 21, 2026

Two-node US915 direct-radio profile evidence admitted.

OT-114 admits the exact close-bench profile after 242/242 probe/data frames and 240/240 acknowledgements reconcile with zero loss, duplication, corruption, or unexpected traffic. Exact 163-byte and 255-byte exchanges, per-length timeouts, local oversize rejection without transmission, signal and RTT evidence, and restart profile retention passed. Only direct_radio_mtu_phy_region_unresolved closes. Readiness and the exact 43.75% / displayed 44% score remain unchanged pending a successor readiness decision and new immutable executable benchmark plan; support, compatibility, secure LoRa, range, EIRP, and regulatory acceptance remain open.

August 21, 2026

US915 direct-radio evidence contract frozen; radio values remain unmeasured.

OT-110 accepts strict host-only OTRPF0/v0, raw SHA-256 8af36e000d5cd0478d1a829fb5a1f2b330cdf09bad188445d30579c348f7e2e1, as the future two-node contract for measuring the direct OpenTrail radio profile, 163-byte protocol-test payload, usable ceiling, packet integrity, latency, RSSI/SNR, restart persistence, and oversize rejection. A privacy-safe USB preflight observed both connected ESP32 candidates; the owner confirmed the generic candidate is the second Heltec and both radios have antennas attached. That is identification-only: the peer's exact profile, recovery path, antenna suitability, full PHY, and every radio measurement remain unresolved. No device state changed, no firmware was built or flashed, and no LoRa packet was transmitted. The sole readiness blocker remains open, accepted source/API-configuration/import counts stay 3/1/0, readiness stays blocked, and V1 Companion remains exact 43.75% / displayed 44%.

August 21, 2026

Compact Heltec status footer integrated and verified in two clean builds.

OT-106 promotes the accepted footer into the production UI component and links it to the Heltec V4 OLED target. BLE lifecycle and contained-error states render as S/A/C/R/E; battery and GPS remain explicit placeholders (BAT:--% and GPS:--), and the single traffic field remains blank because no live LoRa event source exists. Both zero-warning computer builds produced the same seven artifacts; the application is 473,024 bytes with 4,704,320 bytes of verified slot headroom. No device, flash, radio/BLE execution, physical-display observation, live telemetry, readiness, support, or score claim was added. V1 Companion remains exact 43.75% and displays as 44%.

August 21, 2026

Final per-candidate build configuration admitted host-only; two requirements remain.

OT-107 binds owner-approved proposal raw SHA-256 f9072a602a9c139b1e7728735db04cc270720bc37e0429c22bcdb0cd56202a15, reproducible configuration evidence raw SHA-256 0c1b8cb574a210c6123b82b565e6ea8e12cee59bacd6ab4b94b293ddf9d2dfbc, and append-only admission raw SHA-256 3d71dfb02b6fd25e0881ac63cc085174c2cdd7e5ac2cd1e12c320ec34928f5a2. Two fresh configuration-only runs per candidate reproduced exact generated sdkconfig digests. OT-107 closes only final candidate configuration; mbedTLS/PSA API/configuration eligibility and direct-radio MTU/PHY/region remain open. Counts remain 3/0/0, OT-096 remains 5/8, readiness stays blocked, and V1 remains exact 43.75% / displayed 44%. No candidate import/build, benchmark, hardware/device/radio/key action, selection, support, physical evidence, continuing authority, or score was added.

August 21, 2026

Pinned ESP-IDF mbedTLS/PSA source dependency lock admitted host-only; the same three requirements remain.

OT-105 accepts exact OTCSLE0/v1 evidence SHA-256 ae12ad7da6702ac85092e9cb8ad793b749871153fadee8b1a276e5a46b036e49, strict OTMPSLA0/v0 admission SHA-256 26b6acdc9928eb9510a0baed53c609a4f9a23288155636c6462747745f28ac85, project-lock SHA-256 12f8699d8d286a484e054df186fb0e8c97b75263d23caf4bd77ed48082e9c7ab, and result MBEDTLS-PSA-4.1.0-ESP-IDF-GITLINK-SOURCE-DEPENDENCY-LOCK-ADMITTED-HOST-ONLY-APACHE-2.0; THREE-OTCBR0-REQUIREMENTS-REMAIN; NO-NEW-SOURCE-ACQUISITION-COPY-API-CONFIG-IMPORT-BUILD-BENCHMARK-OR-SELECTION; OTCBR0-READINESS-BLOCKED. The already-installed clean pinned ESP-IDF v6.0.2 / mbedTLS 4.1.0 metadata covers every one of 3,551 source and 198 component-glue files exactly once. The owner-authorized project choice is Apache-2.0 while the upstream expression is Apache-2.0 OR GPL-2.0-or-later; neither legal clearance nor compatibility is determined. Historical six, prior five, prior four, prior three, and current three requirements remain; source/API-configuration/candidate-import counts are 3/0/0 and OT-096 remains 5/8. Only the dependency-lock portion of the composite mbedTLS/PSA requirement is supplied. The zero patch count covers only zero OpenTrail-applied patches after the exact pinned Espressif gitlink; Espressif/upstream divergence is unassessed. No source acquisition/copy, import/configuration/build, API/configuration eligibility, device/radio/key action, benchmark, selection, support, physical evidence, authority, or score was added. V1 Companion remains exact 43.75% and displays as 44%; the historical baseline remains exact 31.75% and displays as 32%; V1.5 and V2 remain unmeasured.

August 20, 2026

Exact received OT-DEV-001 profile admitted host-only; three current requirements remain.

OT-103 accepts exact OTRTPE0/v0 received-target evidence, raw SHA-256 517809caf31250d126cc3619f9d05386a92811a594dca0087d9acbf1b671147e, and strict append-only OTRTPA0/v0, raw SHA-256 98cce120cadc1bddf5851f1480ae181488e17277ba0a2c8c8c38a70a062be105, with result EXACT-RECEIVED-TARGET-PROFILE-ADMITTED-FOR-OT-DEV-001; THREE-OTCBR0-REQUIREMENTS-REMAIN; NO-SUPPORT-COMPATIBILITY-REGULATORY-RADIO-PROFILE-BENCHMARK-OR-SELECTION; OTCBR0-READINESS-BLOCKED. Five owner-provided photos and the official V4.2 datasheet bind OT-DEV-001 to Heltec Automation WiFi LoRa 32 V4 / HTIT-WB32LAF / V4.2 / documented high-band variant / ESP32-S3R2 revision v0.2 / 16 MiB flash / 2 MiB PSRAM while retaining no raw photos, PDF, local paths, EXIF/location data, or private identifiers. Official Table 1.5 868-928 MHz and Table 3.5.1 863-928 MHz remain distinct, unreconciled facts. OT-103 closes only exact_received_target_profile_unresolved: historical six-blocker and prior four-blocker states remain recorded, three current requirements remain, and source/API-config/import counts remain 2/0/0. No support, compatibility, regulatory or legal-region acceptance, electrical-RF or antenna proof, direct-radio profile, final configuration, firmware/device/radio/key action, benchmark, selection, packet-v1 authority, continuing authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Exact Monocypher 4.0.3 source lock admitted host-only; four current requirements remain.

OT-102 accepts strict OTMSLA0/v0, raw SHA-256 6dbeeac0266f9e6dd90265cdd71a721acfd36b4308dcb87180bd9d7c24c77e52, source-evidence SHA-256 fe037820304103f7ca2253665076e4dc41740598ca9742ba8d45f6ec64ebc06f, and result MONOCYPHER-4.0.3-SOURCE-LOCK-ADMITTED-HOST-ONLY-BSD-2-CLAUSE; FOUR-OTCBR0-REQUIREMENTS-REMAIN; NO-FIRMWARE-IMPORT-BUILD-BENCHMARK-OR-SELECTION; OTCBR0-READINESS-BLOCKED. Read-only reacquisition binds Monocypher 4.0.3 commit ab2b16dd619ad5f6979a4fbe69cfa324a6fcc35f, Git tree eccc366491fc98c4149401d580ce41081a7854b1, all 161 tracked upstream files, a 175-entry full-tree manifest, complete license and transitive-dependency inventories, SPDX 2.3 evidence, a zero-patch manifest, and a project dependency lock. The owner-selected BSD-2-Clause branch is a project choice, not legal clearance or a compatibility determination. Historical OT-094/OT-097 six-blocker and OT-100 prior five-blocker states remain recorded; four current requirements remain after closing only monocypher_source_lock_absent. Two source anchors are accepted in total, while API/configuration and candidate-import anchors remain empty. No firmware import/build, crypto execution, device/flash/radio/key action, benchmark, selection, packet-v1 authority, physical evidence, continuing authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Exact libsodium source lock admitted host-only; five current requirements remain.

OT-100 accepts strict OTCSLA0/v0, SHA-256 df595f2d07ba1b5d0a9bdf70237b1f0ea5a01fe8cb5a63ffb3575fe484faede0, and result LIBSODIUM-1.0.22-SOURCE-LOCK-ADMITTED-HOST-ONLY; FIVE-OTCBR0-REQUIREMENTS-REMAIN; NO-API-CONFIG-OR-IMPORT-ACCEPTANCE; OTCBR0-READINESS-BLOCKED. It binds unchanged OT-097 policy and OT-099 evidence and accepts only the exact libsodium 1.0.22 source anchor. Historical OT-094/OT-097 records retain six blockers; five current requirements remain and readiness stays blocked. API/configuration and import anchors remain empty. No target/final-configuration proof, device, flash, radio, key or crypto execution, benchmark, selection, packet-v1 authority, legal or physical acceptance, continuing authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Exact external candidate sources acquired and statically inspected; zero imports or accepted locks.

OT-098 accepts strict OTCAI0/v0, audit ID OT-098-OT005-EXTERNAL-CANDIDATE-ACQUISITION-V0, SHA-256 b7be03e305c6253e10f69f624132a736cce5aea3f559760cde4f948ae79abad6, and result EXTERNAL-CANDIDATE-SOURCES-ACQUIRED-AND-STATICALLY-INSPECTED; ZERO-SOURCES-IMPORTED; ZERO-SOURCE-LOCKS-ACCEPTED; OTCBR0-READINESS-BLOCKED. Exact clean libsodium 1.0.22 and Monocypher 4.0.3 sources were inspected read-only, showing 7/8 and 5/8 fixed operation paths. Signature trust remains unresolved; Monocypher's project license choice is null; complete SBOM/transitive inventories, project dependency locks, final configuration, API/config eligibility, import, build, benchmark, and selection remain unresolved or absent. All six blockers stay open. No legal clearance, compatibility determination, implementation, support, device/radio/key action, physical evidence, authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Libsodium managed-import evidence complete; source-lock admission remains pending.

OT-099 accepts strict OTLMI0/v0, audit ID OT-099-OT005-LIBSODIUM-MANAGED-IMPORT-V0, SHA-256 8285fa7308bfc83a5d55503a7a3e1fa4c21895a42b095197b3ec75f634411ec9, and result ESPRESSIF-LIBSODIUM-1.0.22-MANAGED-IMPORT-EVIDENCE-COMPLETE; SOURCE-LOCK-ADMISSION-PENDING; ISOLATED-COMPUTER-BUILD-PASSED; NO-DEVICE-OR-CRYPTO-EXECUTION; OTCBR0-READINESS-BLOCKED. Exact Espressif libsodium 1.0.22 managed lock, 733-entry source manifest, ISC license inventory, candidate-scoped SPDX, managed transitive inventory, and empty patch evidence is complete. The isolated generic ESP32-S3 computer build passed: the compile probe compiled, the candidate archive built and entered the link graph, and the application ELF linked, while probe symbols were not retained in the final map. Source-lock admission is still pending because the controlling OTCSL0/v1 accepted registries remain empty. All six blockers remain open. No exact-target or final-configuration proof, device, flash, radio, key or crypto execution, benchmark, selection, packet-v1 authority, physical acceptance, continuing authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

License-aware source-lock admission v1 frozen host-only; zero sources accepted, acquired, or imported.

OT-097 accepts strict OTCSL0/v1, admission ID OT-097-OT005-LICENSE-AWARE-SOURCE-LOCK-ADMISSION-V1, canonical and policy SHA-256 51639e1b9342dc9e501fb0682d044c0f7c05e691e1a26f463358a753f28a123a, and result LICENSE-AWARE-SOURCE-LOCK-ADMISSION-V1-FROZEN-HOST-ONLY; ZERO-SOURCES-ACQUIRED-OR-IMPORTED; OTCBR0-READINESS-BLOCKED. Version 1 preserves the predecessor policy boundary while separately requiring the upstream SPDX expression, project license choice, complete license inventory, and inventory SHA-256 for any future source-lock acceptance. OTCSL0/v0 remains valid historical evidence but is permanently non-admitting. The three candidates retain separate upstream-expression and project-choice fields; the Monocypher project choice remains null and unselected. All inventories remain incomplete and all inventory digests remain null. OT-097 makes no legal-clearance or license-compatibility determination. All accepted source, API/configuration, and import registries remain empty, all six blockers remain open, and OTCB0/v0 remains draft_blocked. No source lock, readiness, benchmark, selection, support, implementation, device/radio/key action, physical evidence, authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Host-only pinned mbedTLS/PSA static eligibility assessed; blocker 4 remains open.

OT-096 accepts strict OTCMSE0/v0, audit ID OT-096-OT005-MBEDTLS-STATIC-ELIGIBILITY-V0, canonical SHA-256 3034da5a9f21ed663f82dc45ba976f8b5d6ec4ff353c2f96a3d5de4b586c013e, and result MBEDTLS-STATIC-ELIGIBILITY-FROZEN-HOST-ONLY; FIXED-OT005-OPERATION-SET-INELIGIBLE; OTCBR0-BLOCKER4-REMAINS-OPEN. The read-only assessment binds clean, already-installed ESP-IDF v6.0.2 commit 7101770dc6db2667b3c477cc31365dd1acd6db4e and mbedTLS 4.1.0 gitlink 6cc42afad309e861f4c07e6f106e2ab14a9cb8e5. Concrete source/API paths exist for 5/8 fixed operations: X25519, SHA-256, HKDF-SHA-256, and ChaCha20-Poly1305 encrypt/decrypt. Concrete Ed25519 sign/verify and Noise XK implementations are absent; generic PSA APIs and EdDSA/TLS identifiers are not implementation evidence. Final configuration is unproven for every operation, so defaults and OT-093's pre-selection sdkconfig do not close eligibility. This is not a benchmark failure, global suitability claim, or permanent rejection. OT-096 acquired/imported zero source, accepted no source lock or readiness, and left blocker 4 plus all six OTCBR0/v0 blockers open. No benchmark, selection, support, implementation, device/radio/key action, physical evidence, authority, or score was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Host-only candidate source-lock admission contract frozen; zero sources acquired or imported.

OT-095 accepts strict OTCSL0/v0, canonical and policy SHA-256 c0bd923782d0977f8b375cbd2fe8cde5ff132a26b8b6a7ea34a62111bd101f1f, with result SOURCE-LOCK-ADMISSION-CONTRACT-FROZEN-HOST-ONLY; ZERO-SOURCES-ACQUIRED-OR-IMPORTED; OTCBR0-READINESS-BLOCKED. It distinguishes acquisition receipt, immutable source tree, project dependency lock, API/config eligibility, candidate import, and benchmark execution; admission is defined for the first five while benchmark-execution admission remains undefined and blocked. Candidate-specific source, API/config, and import registries are empty, so zero source locks are accepted and zero sources were acquired or imported. The installed ESP-IDF mbedTLS/PSA observation is not a project lock or proof of required API, Ed25519, or final-configuration eligibility. All six OTCBR0/v0 blockers remain open, OTCB0/v0 remains draft_blocked, and readiness advancement, execution authority, and score credit remain false. No OT-005 candidate or benchmark build/execution, selection, support, implementation, device/radio/key action, or physical evidence was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Host-only OT-005 candidate-readiness contract frozen; execution blocked.

OT-094 accepts strict OTCBR0/v0 at readiness_blocked, with result CANDIDATE-READINESS-CONTRACT-FROZEN-HOST-ONLY; OTCB0-EXECUTION-BLOCKED, canonical SHA-256 705b30693196e2f46d8bda7c17acb1e04d7b9092c4a3817286c14d189001b9d3. It binds the unchanged historical OTCB0/v0 plan and accepted OTCBL0/v0 baseline while preserving six blocked requirements: exact received target profile, final candidate build configuration, Espressif libsodium source lock, ESP-IDF mbedTLS/PSA dependency lock and API/config eligibility, Monocypher source lock, and direct-radio MTU/PHY/region. A legacy plan that merely declares itself ready is structural input only; with accepted_for_legacy_v0=false and an empty accepted-ready trust-anchor set, it cannot create a result template or yield a passing evaluation. OTCB0/v0 remains draft_blocked and unexecuted. No dependency acquisition, source or candidate import, result-template creation, benchmark build or execution, suite/wire selection, target support, implementation, device/radio/key action, physical evidence, or score credit was added. Next, close all six requirements, accept a new immutable executable benchmark plan, separately authorize and run the exact comparison, and make a later explicit suite/wire decision. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 20, 2026

Deterministic pre-crypto build baseline frozen; OT-005 execution blocked.

OT-093 accepts OTCBL0/v0 after two independent, initially absent, cache-disabled Heltec V4 bench builds exited zero with zero warnings and produced identical ordered seven-artifact tuples under exact source, raw-byte, configuration, stable-project-version, ESP-IDF, toolchain, and isolated-Python locks. Individual receipts remained reconciliation-pending; only the validated aggregate may report BUILD-BASELINE-FROZEN; OTCB0-EXECUTION-BLOCKED. No OT-005 candidate or secure-LoRa adapter was imported or executed, no crypto-free image claim is made because framework cryptographic objects already exist, and no suite/library, handshake/KDF, packet-v1 wire, supported target, device action, implementation, physical acceptance, or score credit was added. The OT-005 plan remains draft_blocked. Next, reconcile final-candidate target/toolchain/sdkconfig applicability, candidate dependency locks, and direct-radio MTU/PHY; then run the exact benchmark and make an explicit suite/wire decision. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, the historical baseline remains exact 31.75% and displays as 32%, and V1.5 and V2 remain unmeasured.

August 19, 2026

Post-V2 public lane and Public Assistance direction recorded.

OT-092 establishes a durable future-concepts register and accepts a provisioning-independent public/default regional lane plus a separately configurable Public Assistance Broadcast as a direction deferred until after V2 is fully functional and accepted. It promises no version, schedule, delivery date, implementation, availability, support, or progress credit. Safety, privacy, radio, abuse-prevention, regulatory, UI, packet, security, and physical-acceptance designs remain future work. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, and V1.5 and V2 remain unmeasured. The active V1 checkpoint remains the exact OT-005 target benchmark and explicit suite/wire selection.

August 19, 2026

Secure-LoRa key and direct-transport contract frozen host-only.

OT-091 freezes and host-tests the algorithm-neutral OTSL0/v0 lifecycle/admission semantics for exactly two current Heltec members using pairwise direct unicast, with no V1 relay, group broadcast, server, internet, or V1.5 authority. It binds a secret-free single-use authenticated invitation, mutual device authentication and matching local human confirmation, exact durable commit/readback and peer activation, epoch-plus-one replacement with no old-epoch fallback, full identities plus direction/purpose/domain/counter separation, durable replay and inbox admission before plaintext or a positive protected acknowledgement, exact-sealed-byte finite retry, and restart reconciliation with no automatic retry. The focused 40-group model, independent adversarial audit, and complete host gate passed. The result is CONTRACT-FROZEN-HOST-ONLY, implementation remains NOT-IMPLEMENTED, and physical acceptance remains NOT-EVALUATED. No hardware or phone was accessed, no key, secret, private identifier, packet, or content was published, and no target, storage, crypto, radio, BLE, execution authority, or score credit was added. Android remains 60%, V1 Companion remains exact 43.75% and displays as 44%, and V1.5 remains unmeasured. Decision 0003 still requires the exact OT-005 target benchmark and accepted suite/wire selection before implementation.

August 19, 2026

Practical BLE pairing and replacement contract frozen host-only.

OT-090 freezes and host-tests a normally closed 30-second authorization window opened by a local hold of at least three seconds and release, a fresh six-digit PIN displayed only on the Heltec and entered through Android system pairing UI, Secure-Connections-only MITM passkey bonding with an exact 128-bit key, one current controller, saved-bond reconnect, and a second local confirmation before replacement. The new owner is published only after exact commit and verified old-phone authorization and bond cleanup; deadline, restart, random-source, malformed-evidence, and ambiguous-cleanup paths fail closed. The result is CONTRACT-FROZEN-HOST-ONLY, implementation remains NOT-IMPLEMENTED, physical acceptance remains NOT-EVALUATED, and no device, phone, PIN, key, radio, signing, execution authority, or score credit was added. Android remained 60%, V1 remained exact 43.75% and displayed as 44%, V1.5 remained unmeasured, and the separate secure-LoRa contract was the next gate at that checkpoint.

August 19, 2026

Permanent V1 and V1.5 scope adopted; implementation remains open.

OT-089 permanently defines V1 as exactly two supported Heltec devices and two approved Android phones, one phone per device, with bidirectional BLE to direct LoRa to BLE acceptance. It adopts a practical fresh-six-digit-PIN BLE Secure Connections pairing/replacement boundary and discloses that factory reset or reflashing may reset or roll authorization back; a secure element or rollback-proof floor is not a V1 prerequisite. Secure LoRa remains a separate required gate. V1.5 is unmeasured and requires four supported nodes using any compatible mix; four phones are unnecessary and any relay claim needs three physical radios. This decision adds no implementation, physical, release, or score evidence: Android remains 60%, V1 remains exact 43.75% and displays as 44%, and both V1/V1.5 acceptance gates remain NOT-EVALUATED.

August 19, 2026

Private-pilot operational policies frozen; execution blocked.

OT-088 freezes one candidate-bound policy revision for offline/account-free/transient privacy and data safety, first-release removal with no downgrade, and best-effort/no-SLA support that starts only after a complete OTAR pass. Five of eight OTAR0/v0 prerequisites are satisfied; the three exact remaining blockers are physical matrix, release identity, and signer/custody. No phone, installation, removal, signing, account, upload, distribution, privacy execution, rollback execution, or support delivery occurred. The release gate remains NOT-EVALUATED; Android remains 60%, and V1 Companion remains exact 43.75% and displays as 44%.

August 19, 2026

Unsigned Android release-build foundation accepted; execution blocked.

OT-087 freezes version code 1 / version name 1.0.0 and verifies one explicit non-debuggable unsigned release build. Its packaged manifest, exact permission union, backup and transfer exclusions, DEX surface, and absence of OT-085 test helpers passed inspection. This satisfies two of eight OTAR0/v0 prerequisites; six remain. No signer, key, certificate, phone, install, upload, or distribution was used or authorized. The release gate remains NOT-EVALUATED; Android remains 60%, and V1 Companion remains exact 43.75% and displays as 44%.

August 19, 2026

Android operational-release plan accepted; execution blocked.

OT-086 accepts the plan-only OTAR0/v0 admission contract and private-sideload-v1-pilot as the only distribution scope. Eight named prerequisites remain open, no production candidate was built or run, and no phone was selected, approved, frozen, or supported by this planning result. Because this is the first supported release plan, in-place upgrade is not applicable and earns no credit; an accepted candidate must still prove uninstall/reinstall, promised data removal, and downgrade handling. Android remains 60%; V1 Companion remains exact 43.75% and displays as 44%. Execution, release acceptance, protected authorization, Ready, and the four-pair field proof remain open.

August 19, 2026

Automatic public BLE termination accepted.

On the exact verified OT-085 image, one authorized Android 13 / API 33 phone read the exact fixed 16-byte READ-only public value and made no disconnect request. The bound GATT disconnected inside the frozen timing window; the owner observed BLE CONNECTED followed by BLE ADVERTISING, and exactly one compatible service advertiser returned without a stable-identity claim. The sanitized result reported OT085B_PUBLIC_READ=PASS, OT085B_AUTOMATIC_TERMINATION=PASS, OT085B_COMPATIBLE_ADVERTISER_RETURNED=PASS, and OT085B_PHONE_ACCEPTANCE=PASS. Protected behavior and operational acceptance remain open.

August 19, 2026

Physical public BLE link and status accepted.

The exact OT-085 image was installed and verified on the selected experimental target. One authorized Android 13 / API 33 phone read the exact fixed 16-byte public value; the owner observed BLE CONNECTED followed by the phone-disconnect return to BLE ADVERTISING, and the selected endpoint was rediscovered. No device identity or raw trace was retained. The firmware's independent 15-second automatic termination was not physically exercised, and all protected behavior remains closed.

August 18, 2026

Public BLE link and status accepted build-only.

One fixed privacy-safe READ-only value and a bounded 15-second connection/display lifecycle pass the complete host gate and two reproducible target builds. The image was not flashed, no phone read or BLE CONNECTED hardware transition was observed, and protected authorization is deferred beyond current Heltec V1.

August 18, 2026

SECURE_VERSION rejected as the authorization floor.

Pinned ESP-IDF evidence proved the 16-step field is coupled to application-firmware anti-rollback and an OTA-only native model that conflicts with the accepted factory recovery route. No external part is selected or present on the current target; no hardware, eFuse, target build input, runtime, or physical authority changed.

August 18, 2026

Incompatible rollback-floor candidate rejected.

Pinned ESP-IDF evidence proved the proposed custom USER_DATA eFuse counter cannot support repeated independent advances. That candidate is now rejected, no replacement floor provider is selected, and no device, eFuse, target firmware, runtime, or physical authority changed.

August 18, 2026

Build-only NVS and security-state source accepted.

A one-use target-side leaf now compiles and passes synthetic, static, and reproducible target-build checks for default NVS build configuration and four decoded security-state values. It has no runtime call path, was not device-executed, and adds no complete inventory, provider, read, provisioning, or write authority.

August 18, 2026

Six-slot protected-root key roster accepted build-only.

A target-side one-use adapter now compiles against pinned ESP-IDF and passes strict synthetic and static checks across all six logical key slots. It exposes only coarse purpose, proven-unused, and protection states; no complete inventory reader/orchestrator, device read, allocation, provisioning, runtime activation, or write authority was added.

August 18, 2026

Unsafe host-side protected-root inventory route rejected.

Review found that the convenient host Python path would materialize raw key blocks in memory, so it is explicitly rejected. OT-080 accepted a target-side decoded-metadata contract permitting only five bounded ESP-IDF metadata calls; at that checkpoint no adapter or device-read authority existed.

August 18, 2026

Protected-root inventory admission accepted offline.

A pure supplied-evidence verifier and denied hardware-read plan define the complete private inventory required before physical key-block or rollback-floor selection. At that OT-079 checkpoint no complete inventory reader/orchestrator, device access, physical inventory, allocation, provisioning, runtime activation, or write authority existed.

August 18, 2026

Protected-root provider types reviewed offline.

Distinct ESP32-S3 HMAC_UP roles were accepted by type at OT-078. Its conditional custom user-eFuse floor candidate was later rejected by OT-083; no physical key block, rollback-floor provider, provisioning, device access, runtime activation, or write authority exists.

August 18, 2026

Exact recovery route accepted offline.

One fail-closed ESP32-S3 ROM source-restore contract now binds the exact application, source partition table, security-state checks, independent readback, and recovery-uncertain handling. No device was accessed and no recovery, partition transition, key, eFuse, or write was performed or authorized.

August 17, 2026

Exact installed application retained for recovery.

One bounded read captured and independently verified the application currently installed on the experimental Heltec target. The artifact is retained privately and the device returned to its Trail logo and BLE-advertising status. This improves recovery preparation only; no restore, partition transition, protected runtime, or additional write was performed or authorized.

August 17, 2026

Protected-storage source proof accepted.

One bounded physical read matched the exact installed partition table and verified the complete protected-storage source region was blank. The device then returned to the Trail logo and BLE-advertising status. This satisfies only the source prerequisite; partition transition, protected runtime, GATT authorization, and Ready remain open.

August 17, 2026

V1 Companion receives its first canonical measurement.

Six approved evidence-weighted milestones now measure the phone-assisted release separately from the historical standalone baseline. Physical GATT, protected authorization and Ready, operational release acceptance, and four-person field proof remain open.

August 17, 2026

Read-only storage-transition evidence tooling accepted.

A streaming offline verifier and denied acquisition plan now define the exact source proof needed before protected-storage work can advance. No executable hardware reader was published, no device was accessed, and the shared evidence baseline is unchanged.

August 17, 2026

Physical Trail startup and OLED status accepted.

One experimental Heltec target displayed the Trail logo and BLE-advertising status, passed exact write-region verification, self-check, four heartbeats, and one filtered Android scan. This advanced the shared evidence baseline; V1 Companion and V2 Integrated remain unmeasured.

August 16, 2026

Read-only protected-storage admission probe accepted.

Six focused host groups, a deterministic target self-check, five target-admission checks, and two reproducible ESP-IDF builds passed. The configuration stopped before target storage or key reads, the build was not flashed, and secure GATT remained denied. At that checkpoint the historical canonical baseline was unchanged; V1 Companion and V2 Integrated remained separately unmeasured.

August 16, 2026

First physical OpenTrail target and BLE advertisement accepted.

OT-DEV-001 passed one authorized exact-profile erase/write, post-write verification, boot self-check, and bounded USB heartbeat. The exact Android APK on a physical API 33 phone found one compatible service advertisement without selection, connection, pairing, or retained identifier. This advanced the historical canonical baseline; V1 Companion and V2 Integrated remained separately unmeasured.

August 16, 2026

Physical Android debug install and foreground screen retention accepted.

One exact APK was installed and launched on an owner-authorized physical Android 16 / API 36 handset. It stayed awake at normal active brightness through an untouched 40-second interval with a 30-second timeout active. At that checkpoint no target runtime or BLE evidence existed, so the historical canonical baseline was unchanged.

August 15, 2026

Exact Heltec memory profile and partition build accepted.

Two pinned builds matched for a 16 MiB flash and configured 2 MiB quad-PSRAM profile. Nothing was flashed or run, so the prior phone-independent baseline was unchanged; V1 Companion and V2 Integrated were not yet measured.

August 14, 2026

First pinned native ESP32-S3 build candidate accepted.

Exact configuration, artifact, and incremental-build evidence advanced the Heltec milestone and the shared evidence baseline.

August 13, 2026

Inspection, bundle, and cross-tool evidence expanded.

The loader remained inspection-only with no production trust or firmware writing authority.

Documentation

Read the contracts and the evidence.

Project documentation keeps architecture, platform boundaries, recovery, privacy, testing, and open gates visible.

ArchitectureSystem boundaries, ownership, safety, and composition.Platform contractsBLE, Android, authorization, and target-facing definitions.Secure-LoRa contractHost-frozen key lifecycle, direct transport, replay, acknowledgement, retry, and restart semantics.Secure-LoRa contract evidenceHistorical OT-091 host-only acceptance preserved without implementation or physical claims.Pre-crypto build baselineExact two-build OTCBL0 evidence with the candidate benchmark and selection still blocked.Candidate-readiness contractHost-only OTCBR0 evidence with all six requirements and OT-005 execution still blocked.Source-lock admission decisionHost-only OTCSL0 rules with zero accepted locks, zero acquired or imported sources, and readiness still blocked.Source-lock admission evidenceExact contract digest, empty trust anchors, six open readiness blockers, and no authority or score claim.Future conceptsAccepted post-V2 directions kept separate from schedules, implementation evidence, and progress credit.Permanent V1 and V1.5 scopeAccepted two-pair V1 and separate unmeasured four-node V1.5 boundary.V1 and V1.5 scopePermanent topology, security, acceptance, and supersession boundaries.mbedTLS/PSA static eligibility decisionPinned provenance, bounded 5/8 source-path result, unresolved final configuration, and no source-lock or readiness claim.OT-096 static assessment evidenceExact digest, absent Ed25519 and Noise XK paths, six open blockers, and no authority or score claim.License-aware source-lock admission decisionOTCSL0/v1 separates upstream expressions, project choices, complete license inventories, and inventory digests without claiming legal clearance.OT-097 license-aware admission evidenceExact v1 digest, incomplete inventories, zero accepted locks, six open blockers, and no authority or score claim.External candidate acquisition decisionRead-only source acquisition and static-inspection boundaries without import or lock acceptance.OT-098 acquisition evidenceExact source identities, 7/8 and 5/8 observations, unresolved limits, six blockers, and no score claim.Libsodium managed-import evidence decisionEvidence-complete managed import and isolated computer-build boundary with admission still pending.OT-099 managed-import evidenceExact digest, build/link observations, six open blockers, and no execution or score claim.Libsodium source-lock acceptance decisionExact accepted source anchor, historical six/current five accounting, and blocked readiness.OT-100 source-lock admission evidenceExact digest, empty API/import anchors, prior five-requirement state, and no authority or score claim.Monocypher source-lock acceptance decisionExact source evidence, owner-selected BSD-2-Clause branch, historical six/prior five/current four accounting, and blocked readiness.OT-102 source-lock admission evidenceExact digests, two accepted source anchors, empty API/configuration and candidate-import anchors, four current requirements, and no authority or score claim.Exact received target-profile decisionBounded OT-DEV-001 identity, historical six/prior four/current three accounting, and blocked readiness without support or regulatory claims.OT-103 received target-profile evidenceExact artifact digests, privacy-safe board/profile facts, three requirements at that checkpoint, and no radio, benchmark, selection, or score claim.mbedTLS/PSA source dependency-lock decisionExact installed pinned source metadata, three accepted source anchors, the same three requirements at that checkpoint, and blocked readiness.OT-105 source dependency-lock evidenceExact evidence, admission and lock digests, complete source/glue metadata, 3/0/0 counts, unchanged blockers, and no execution or score claim.Final per-candidate configuration decisionOwner-approved per-candidate sdkconfig digests, the historical OT-107 two-blocker checkpoint, and blocked readiness.OT-107 final configuration evidenceExact proposal, generation-evidence, admission, and candidate sdkconfig digests with no execution or score claim.OT-106 compact-footer build evidenceExact target linkage, two identical computer builds, placeholder telemetry boundaries, and no device, radio, support, readiness, or score claim.OT-117 libsodium API/configuration admission evidenceComplete 8/8 host-only operation evidence, counts 3/2/0, and explicit no-execution, no-selection, and no-score boundaries.OT-133 controlled abort and exact restoration evidenceNine complete pre-READY records in 512 bytes exceeded the frozen eight-record cap before any result frame; Node A restored exactly, Node B remained on Trail, both logos were confirmed, authority was consumed, and no result or score was added.OT-132 host-only opaque-preamble correction evidenceBounded complete opaque boot records, unchanged exact READY and frame strictness, fourteen adversarial tests, no device access, and no result or score change.OT-131 controlled abort and exact restoration evidenceControlled capture failure, consumed one-attempt authority, exact Node A restoration, untouched Node B Trail state, and no Monocypher result, frame, radio, selection, Phase 2 completion, or score.OT-129 host-only capture-protocol correction evidenceRetrying exact START/READY, streaming accumulation, endpoint-lifecycle proof, privacy-safe diagnostics, the real unchanged parser, and pinned ESP-IDF compile-only validation; no device, flash, benchmark, radio, result, score, or authority.OT-128 restored corrective-retry abort evidenceNo Monocypher result was admitted; all touched nodes restored exactly to Trail, both endpoints returned, and the owner later confirmed both displays on. It remains the historical abort and restoration record.OT-122 Noise XK and runtime-resource evidenceBoth anonymous nodes passed all eight libsodium operations, measured heap, stack, and watchdog outcomes, and restored exactly to Trail; Phase 2 remains incomplete and no radio was used.OT-121 bounded local-primitives evidenceBoth anonymous nodes passed all seven libsodium local primitives and restored exactly to Trail; Phase 2 remains incomplete and no radio was used.OT-120 retained candidate import/build admission evidenceSix clean reproducible builds across three retained candidate admissions, counts 3/3/3, Phase 1 complete, and fresh execution authority as the only remaining pre-measurement blocker.OT-119 second-node exact-profile admission evidenceBoth exact received node profiles admitted, Phase 0 complete, and no support or execution authority added.OT-118 Monocypher API/configuration admission evidenceStrict 5/8 comparison-only operation evidence, counts 3/3/0, and explicit no-execution, no-selection, and no-score boundaries.OT-116 successor readiness and execution-plan evidenceAll six historical readiness requirements closed, exact phased procedure frozen, and measurement blocked pending candidate admissions and fresh authority.OT-138 host-only transport-classification evidenceFabricated exact-counter reproduction, pinned public lineage, unconfirmed physical-byte boundary, and the console-isolated quiet-target next gate with no authority or score change.OT-138 boot/control transport decisionAccepted host-only classification, preserved 512-byte/time and exact protocol/privacy boundaries, and no hardware attempt.Canonical V1 progressWeighted milestones, evidence references, and next gates.Public backlogAccepted increments, open work, and explicit exclusions.

GitHub repository

The public source and history.

Review implementation, tests, evidence records, and documentation directly.

Limited Underground Trail on GitHub

Free software collaboration is welcome, with claims kept bounded to evidence and hardware work requiring explicit authorization.

Open repository

Contribute

Help where evidence can improve.

Useful contributions include contract review, documentation, host testing, compatible-hardware research, accessibility review, and authorized field evidence at the right project gate.

Software

Review bounded components and tests.

Protocol, firmware, Android, loader, and validation improvements should preserve fail-closed boundaries.

Hardware

Document exact, tested compatibility.

Board families are not enough; useful evidence identifies the exact target and test boundary without exposing device identifiers.

Field knowledge

Improve the acceptance plan.

Recovery, usability, range, endurance, and degraded-operation experience can sharpen the eventual pilot.