work / instrument 05 · rev 1
in development
2026 python · claude · faster-whisper · sqlite brilliant labs halo, ordered phase 2

Repository · Roadmap · Decision log · graph.json

01 · problem

Problem

The thesis sentence in the repo reads: understand my world better, don’t miss things, get insight from the wealth of knowledge plus me. The last two words carry the design. The model holds breadth. The person holds the problem and the check.

Most smart-glasses products get this backwards. They listen all day, speak uninvited, and spend a week’s worth of attention in an afternoon. compass is built on the opposite premise: it speaks when invoked, it remembers across sessions, it never records continuously, and it never surveils anyone but the wearer’s own working memory.

The harder problem underneath is the one this page exists for. Building the pipeline is cheap now. Knowing whether a given piece of it is right is the work, and it has to be done in domains where the usual geometry instruments don’t apply: speech recognition, vision model answers, a HUD a person has to read in a glance.

02 · signal

Signal

Retro mode came up on the laptop in June. Press a key, the last five minutes of the mic buffer go through a local Whisper model, the transcript goes to the coach, a directive lands on the simulated HUD. It worked on the first try, which is the moment this project is about.

The STT model was base.en, chosen because it was fast. Said aloud at one desk, “facade panels” came back as “sign tables.” That was caught by ear, on one machine, in one session. The fix was a bigger model, small.en, and the fix was right. But the check that found the error was a person listening once, and that check does not run again. The next model swap, or the next shop vocabulary, gets no verdict unless somebody happens to be listening.

That is the skip in the figure below. The pipeline went from candidate to “looks right” with no reference in between. The reference is a phrase set: the vocabulary the coach has to hear correctly, recorded once, scored against every model. It is on the instruments list and not yet built.

03 · calibration

Calibration: what an instrument is here

instrument candidate reference knowledge supplies compare residual 0 1.0 threshold 0.50 mm 0.62 mm verdict pass no ill-posed blocked the skip: "looks right", no reference, no residual returns, reusable
fig 01 · an instrument: a candidate against a reference the author did not make, a residual against a threshold set beforehand, a verdict that can be no

Every instrument on this project has the same shape, whatever the domain. A candidate (a transcript, a vision answer, a driver) goes against a reference that neither the author nor the model produced. A comparator turns the pair into a residual, a number rather than an impression. A threshold, set before the run, turns the residual into a verdict. The verdict can be no.

The dashed edge is the alternative: candidate straight to verdict on the strength of looking right. It is the fast path and the one that costs understanding, because nothing from it comes back. The solid return edge is why instruments are worth building: an instrument outlives the candidate it was built for, and running it again is free.

The structure in the figure is also published as data at graph.json, with notes the drawing leaves out. The SVG is rendered from that file. Change the file and both faces change.

04 · constraints

Constraints

compass · constraints
trigger pull-default: tap, voice, or button. Never ambient
recording rolling buffer in RAM only, never persisted. Transcripts persist; audio does not
hardware abstracted behind a Glasses protocol. Mock first; a real device is one more driver
host windows laptop, per-user venv, no admin, no docker
latency a glance. Visual and verbal in seconds; retro in the time it takes to transcribe five minutes locally

The hardware constraint is the one that shaped the build order. The Halo was ordered in May and has not arrived. Rather than wait, the three modes were built against a laptop mock (webcam, mic, a window standing in for the HUD) and the roadmap was restructured in June to match: software modes complete on the laptop first, the hardware wire-in last. Two of three modes run today on no glasses at all.

05 · action

Action: three modes, one backend

mode · visual runs on mock
trigger tap
input one camera frame
ask "what is this?" or "does this match the drawing?"
output a directive on the HUD
mode · verbal runs on mock
trigger key, then speak
input a fixed capture window, plus the preceding two minutes of buffer as context
output a directive on the HUD
mode · retro runs on mock
trigger key
input the last five minutes of the rolling buffer, transcribed locally
ask "what did they just ask?", "what did we decide?"
output a directive on the HUD

All three feed a layered memory store: rolling buffer, session transcript, session summary, daily digest, project memory. The same question can be asked about five minutes ago or five months ago. The rollup layers past the transcript are scaffolded, not finished.

06 · verification

Instruments

This is the list the page exists to keep. Each entry says what the instrument can say no to. Entries get added as they are built; none get removed.

instrument · smoke suite running
reference the protocols each provider must satisfy, mock inputs with known outputs
says no to a wire-up change that breaks a mode without anyone running it
reading 23 passed, 1 skipped (no audio device on the test host), pre-hardware baseline
instrument · protocol check running
reference typing.Protocol contracts for glasses, vision, coach, audio, marked runtime_checkable
says no to a new hardware driver that claims the interface and does not implement it
instrument · stt phrase set not built
reference a recorded set of shop and site phrases ("facade panels", part names, tolerances) with known transcripts
residual word error rate on the set, per model
says no to a faster STT model that cannot hear the vocabulary. The check that was done by ear, made repeatable
instrument · halo wire-in measurements waiting on hardware
reference the firmware protocol as inspected, pinned to a commit
residual capture-to-host latency for a 640 px JPEG over BLE; tap reliability while worn; characters per HUD line at each font size
says no to a driver that works in the SDK example and fails in the glance budget. Nothing here is measured yet; the playbook lists what to measure first
07 · artifacts

Artifacts

Repository → Halo wire-in playbook → Hardware landscape → graph.json →

Hardware: Brilliant Labs Halo, with the SDK and firmware at docs.brilliant.xyz and github.com/brilliantlabsAR/halo-firmware. What the repo’s own inspection of that firmware established: a single-eye color microOLED, a camera that returns complete JPEG bytes at 640 px to a Lua app on the device, which relays them to the host over Bluetooth. A photograph of the device on this page will be one I took, once it is on the desk.

Where it sits

compass is the glance-paced member of the same family as Directive Engine. Same pattern, capture to reconcile to directive to log, at a different rhythm of attention: seconds to minutes during an install, milliseconds to seconds in a glance. It is also the first instrument here pointed at the person rather than the panel.