# ADR: Unified BLE 4.0 open-source governance, evidence, and support claims **Status:** Accepted design baseline **Date:** 2026-07-25 ## Decision 4.0 is an independently consumable open-source foundation. Support claims, backend certification, release artifacts, security disclosures, and deprecation are governed by machine-readable evidence and published policy, never by a consumer-specific exception, mock, host name, or successful compile alone. The package provides an open backend SDK/TCK path. An external author declares identity, version ranges, capabilities, limits, ownership/cancellation/stream semantics, schema validation, evidence, and TCK profile through the backend and capability contracts. Passing a TCK proves only the recorded contract profile; it does not automatically grant a first-party, live-radio, reliability, or certification label. The production public/backend shapes are [`src/index.ts`](../../src/index.ts) and [`backend-sdk.ts`](../../src/backend-sdk.ts). They encode attachment/generation ownership, bounded streams, `AbortSignal` and deadline behavior, and stable errors. ## Evidence and support taxonomy Every claim binds backend/platform/build/runtime/ABI identity, source and artifact provenance, capability descriptor, named scenario, peripheral or test controller conditions, observed outcome, limitations, timestamp, and revalidation policy. Evidence labels are explicit and scoped; missing evidence is `blocked` or lowers the affected feature to `unavailable`/`limited`, never a fake success or silent fallback. Deterministic backend/TCK results prove state-machine, byte, cancellation, generation, stream, error, cleanup, and contract behavior. They do not prove radio, permissions, restoration, native timing, browser chooser, or controller behavior. Live and reliability claims require the relevant physical evidence. Hardware unavailability blocks only its evidence label, not the portable contract, deterministic backend, TCK, packaging, or unrelated host work. Meta Quest is explicitly deferred to 4.1. It is absent from 4.0 work packages, evidence requirements, support labels, and release gates; its future shared Android-backend profile and evidence target require a separate 4.1 decision. ## Security, privacy, and ecosystem rules Third-party backends, evidence manifests, diagnostics, package artifacts, native loaders, and release workflows are untrusted inputs until validated. Certification validates schema, receipt/source/artifact binding, regular-file containment, allowed command profile, runtime ABI, and feature-scenario linkage. It never executes arbitrary shell interpolation or treats an exit code as proof. Security policy provides a private reporting route, coordinated disclosure, severity handling, and supported-version response commitment. Release processes use integrity-pinned dependencies, artifact inventory, trusted publishing, minimal CI permissions, and provenance. Diagnostics are local, bounded, redacted, no-network by default, and require explicit export action. No BLE identifier authenticates a peripheral or authorizes a product action. ## Versioning, deprecation, and compatibility Package semver governs published API changes. Backend-contract, capability, event, trace, native, and IPC protocol axes negotiate independently and reject non-overlap/unknown-required data with `protocol.incompatible`. Additive fields are accepted only by the relevant negotiated rule; silent downgrade is banned. 4.0 begins a new package contract, so it does not ship a 3.x compatibility surface, legacy fallback, dual protocol, deprecated byte path, or migration shim. Post-GA removal follows published semver/deprecation policy; before GA raising a platform floor is preferable to carrying a compatibility lane. ## Rejected alternatives - Calling a mock, simulator, fixture, benchmark, package build, or old receipt a supported/live backend: rejected because its proof scope is narrower. - A private consumer's policy, device list, reconnect behavior, telemetry, or support exception in the generic governance contract: rejected because it breaks clean-room adoption. - A permanent warning allowlist, skipped required test, or unsupported capability represented as a nominal result: rejected because release truth is fail-closed. ## Consequences and gates The project publishes architecture, ownership, API, backend authoring, TCK, capability/limitation, evidence, host setup, permission/restoration, Electron security, error, byte-ownership, diagnostics, security, contribution, governance, and release documentation. Independent consumers install packed artifacts and complete the declared host/TCK path without repository-only imports or product vocabulary. Release requires validated evidence, package/provenance/ABI gates, zero diagnostics, no unresolved actionable findings, correct support labels, and security/release policy checks. The Phase 0 draft and spikes are deleted or superseded before production authority; they are never published evidence or runtime dependencies. ## Related decisions - [Backend contract ADR](2026-07-4.0-backend-contract.md) - [Capability registry ADR](2026-07-4.0-capability-registry.md) - [Boundary ADR](2026-07-4.0-boundary.md) - [Packaging ADR](2026-07-4.0-packaging.md)