Accordion Sentry Model

ESH10000688 · Rev R0

in_progresselectronics

Concept

The Accordion Sentry Model (ESH10000688) is a sensor-focused add-on module designed to attach to the Accordion Beacon Module. Power and bus communication are sourced entirely from the Beacon Module — the Sentry carries no independent power management or primary MCU.

Sensor Suite

Domain	Target Component
Audio	MEMS microphone
Environmental	BME280 or BME680 (temperature, humidity, pressure)
Location	GPS module
Air quality	CO2 sensor
Motion & orientation	IMU (accelerometer / gyroscope)

Design Goals

Ultra low power — optimised for battery-backed operation via the Beacon Module supply rail.
Sensor-centric — all board resources dedicated to optimal sensor performance and signal integrity.
Headless — compute offloaded entirely to the MCU on the Beacon Module; no local application processor.

Reports Audit Log

Everything here lives inside a Project (a code + revision, e.g. ESH10000540 R3). The backbone is the V-model, read top-to-bottom: define what the product must do, plan how to prove it, execute the proof on real units, then learn from the field — and the Loop closes back up to the top.
This map is live: a block is green with a count when this project actually has that entity, and dashed/dim when it’s empty. Click any block to open its tab; hover for details. Arrows are the meaningful links; the implicit “belongs to this Project” edge is left out for legibility.

What each thing means

Requirement: One thing the product must do or satisfy — the “what”.
Test Case: A defined check that proves one or more requirements — the “how we prove it”. A verified_by trace link ties a test case to the requirement(s) it covers; that link is exactly what Coverage % counts. (So: a test case refers to the requirements it verifies.)
Verification Plan: A named grouping of test cases, approved before a test campaign and optionally gated by a milestone.
Verification Record: The result of running one test case against one unit: pass / fail / error / na. This is the evidence a requirement is actually met.
DUT: Device Under Test — an individual physical unit (by serial number) that records and test data attach to.
Deviation: A documented waiver against a verification record (e.g. accept a known non-conformance, with justification).
Entry: A knowledge note: a decision (settled choice), notice (assumption / risk / open question), issue (tracked problem), or concept (idea under exploration). It can attach to any other entity.
Design Rule: A reusable, checkable engineering constraint. Running the checks turns each violation into a Conflict.
Conflict: An open flag raised by a failed design-rule check (or an end-of-life / component-library issue) that needs resolving.
Milestone: A dated gate; verification plans can be tied to it.
Field Issue (RMA): A failure reported from the field on a returned unit; Root-Cause Analysis explains why it happened.
The Loop (S-16): loop_trace reconciles a field issue against that unit’s own verification record (did it pass at the edge of the band?). closes_loop records the corrective decision or design rule so the lesson is captured — and clears the project’s open-loop count.
Interface / Port: A contract between projects; each port can be driven by a requirement (and cascade one into the connected project).
BOM Component: A part on this project’s bill of materials, optionally linked to the shared Component Library.
GRR Study: A Gauge R&R study measuring how repeatable a test case’s measurement is.
Test Data: Production / Maestro run results recorded against DUTs — the population behind a single verification record.

0% Coverage

0% Done

0 Requirements

6 Open Entries

Timeline

Color = derived gate state · hover a tile for its note.

not started

🏁 Release

· 3/6

Status & gates

Chronological — Release is the final gate. Derived & read-only; edit via trace_milestone_* tools.

Release / Readiness not started 3/6 met

pending Requirements approved

No requirements in scope

pending Coverage ≥ 100%

No requirements in scope

pending All test cases pass

No test cases in scope

met No blocking issues open

met Deviations resolved

met Interfaces frozen

Coverage — 0.0% · Done — 0.0%

0 Done 0 Partial 0 Not Started 0 Missing 0 Obsolete

Code	Title	Category	Coverage	Status