ACT — Actober AI
Teaching software what experienced technicians notice.
Capture a senior technician's reasoning from a real job, turn it into one reviewed lesson, and measure whether it changed anything.
- Builder and product owner
- In active development
- 2026 — present
- Solo build
- iOS/Android client · web admin · HTTP API
- In active development. Deployed backend and working end-to-end loop; no field capture and no paying customers yet.
Most of the workforce does not sit at a desk, and almost none of what those people know is written down. In HVAC the cost of that shows up in numbers a service manager already tracks: callbacks, first-time-fix rate, and how long a new hire takes to become billable.
ACT starts from a narrower version of the problem. A company's best technician is retiring in a year. The shortcuts they use on that company's own install base — the accounts they have serviced for a decade, the failure modes they recognise by sound — are not in any training catalogue and never will be. ACT captures those from real jobs, compiles them into reviewed lessons, and tracks whether they move callbacks and ramp.
The loop
Capture
One button, gloves on, consent set
Detect
Frames, transcript, ranked moments
Ask
Expert answers after the job
Structure
Card with cue, trap, safety, quiz
Review
Lead tech approves or rejects
Teach
Apprentice library, cited
Measure
Callback and ramp signals
Measurement feeds the next capture: which jobs to record, which moments were worth keeping.
Seven stages. Two of them are human gates — the expert answers, and a lead technician approves — and the system cannot skip either.
The problem
Senior technicians are rarely willing to write documentation after a full day of calls, and the thing worth documenting is usually invisible to them — it is the part they stopped noticing they knew. Ask them to write it down and you get a procedure. Ask them the right question, ten minutes after the job, about a specific moment you can point at, and you get the reasoning.
So the hard problem is not summarisation. It is knowing which twenty seconds of a two-hour recording carried judgment, and asking about that specific moment while it is still fresh.
Users
Four roles, three of them with completely different tolerance for friction.
Senior technician
Captures the job and answers debrief questions. Will abandon anything that costs more than a few seconds mid-job or more than a couple of minutes after.
Lead technician
Reviews and approves. Their signature is what makes a lesson trustworthy inside the company.
Apprentice
Learns from approved cards. Needs company-specific judgment, not textbook theory.
Operator
Buys it. Cares about callbacks, first-time-fix, and time to billable.
Constraints
These shaped nearly every technical decision in the product.
- Gloves and one hand. Capture is a single large button, and marking a moment is one tap with no dialog.
- Bad connectivity. Uploads retry and resume; recording never blocks on the network.
- Not surveillance. Consent state is selected before recording, and a do-not-share setting blocks capture entirely.
- Customer footage. Redaction and purge paths are product requirements, not a compliance afterthought.
- No live diagnosis. The system answers only from published, approved cards and refuses live-diagnosis-shaped questions by design.
Product decisions
Ask after the job, not during it
An interruption mid-diagnosis is both dangerous and useless — the technician is concentrating. The debrief happens afterwards, anchored to a timestamp the technician themselves marked.
Nothing publishes itself
Automation runs between approval gates, never around them. Compilation is automatic; publication is not.
Footage is the proof
Every card stays grounded in the clip it came from, so a disagreement can be settled by watching rather than arguing.
Keep the moments that carry judgment
Not everything is worth storing. The targets are sensory cues, counterfactuals, thresholds, safety boundaries, and verification steps — the things a novice would not know to notice.
Architecture
Capture, debrief, review, learn, outcomes
Review queue and publish gate
Jobs, recordings, moments, knowledge, library
Postgres SKIP LOCKED, heartbeat reclaim, backoff — worked in-process
Enforced per object, not per query
Async SQLAlchemy, 26 migrations
Video and extracted frames
Transcript segments at marks
Moment ranking and card compilation
The mobile client never talks to storage or the model directly. Processing is a durable queue in Postgres — no Redis, no separate worker fleet to operate.
Interface surfaces
Five screens carry the product. Screenshots to be added — see CONTENT_REVIEW.md.
Record, select consent state, drop moment marks one-handed, queue uploads with retry and resume.
Pending questions with a waiting badge; the expert answers by voice or text and can correct the transcript inline.
Lead technician approves, edits, or rejects each proposed moment before anything compiles.
Apprentice library of published cards with quiz events and an honest empty state.
First-time-fix, callback, and time-to-diagnosis capture, logged against the real job.
Trust boundaries
Consent state is chosen before recording starts. A do-not-share setting blocks capture outright.
Identifiers belonging to another account return 404 across the whole API. List routes cannot enumerate another tenant's IDs.
A lead technician approves, edits, or rejects. Compilation is automatic; publication never is.
Questions are answered only from published, approved cards with citations. Live-diagnosis requests are refused by design.
Three enforcement points sit below the product surface: consent at capture, account scoping at every read, and a human approval gate before publication.
Trust and safety
Per-account scoping is enforced per object, not per list query. A recording, moment, job, question, answer, or card identifier belonging to another account returns 404 across the entire API, and list routes cannot enumerate another tenant's identifiers. Tests assert this rather than assuming it.
Authentication is invite-only Supabase with server-side token verification — JWKS with ES256 and RS256, plus legacy HS256 — and the backend maps the token's email onto its own user row rather than trusting any client-supplied actor identifier. Sessions persist encrypted, with the key in the OS keychain, and a session lost mid-recording overlays the login screen on top of the still-mounted capture stack so an in-progress capture is never destroyed.
The knowledge surface refuses live diagnosis. Answers come only from published, approved cards, with citations back to the footage.
Testing and evaluation
The backend carries 444 tests across 47 modules, covering the capture pipeline, the job queue under concurrency, account scoping, consent, redaction, grounding, card provenance, and evidence eligibility. Schema changes go through 26 Alembic migrations.
Evaluation is separate from testing and matters more. The first experiment asked whether the captured corpus carried any evidentiary value at all — and the answer was no. That result is below.
Results
The full loop runs end to end against the deployed backend: record on a phone, mark a moment, upload with retry, extract frames and transcript, propose moments, generate debrief questions, answer by voice, compile a card, approve it in the admin, read it in the apprentice library, and log the job outcome.
That is a working system. It is not evidence that the system works — those are different claims, and the section below is the one I would want a hiring manager to read.
What I built
Solo build across four surfaces. Concretely:
Designed the capture workflow and implemented the React Native recording experience — consent gating, one-tap moment marking sized for gloves, and upload queueing with retry and resume.
Built typed API clients for the mobile app and wired token attachment across every call, including the audio-answer upload, while deliberately leaving the presigned object-storage PUT headerless.
Designed the backend data model — jobs, recordings, marks, moments, frames, transcript segments, elicitation questions, expert answers, knowledge objects, training events, and job outcomes.
Implemented the FastAPI service and its Postgres-backed durable job queue using SKIP LOCKED with heartbeat reclaim and backoff, worked in-process rather than adding Redis and a worker fleet.
Connected the media pipeline: object storage for video and frames, speech-to-text transcription, frame extraction around marks, and model-ranked moment detection.
Implemented per-object account scoping across the whole API and the invite-only authentication path, including server-side token verification and encrypted session persistence.
Built the Next.js admin: review queue, debrief answers, inline transcript correction, in-browser voice recorder, and the publish gate.
Deployed the backend, then ran the audit that invalidated my own numbers.
What remains unproven
- No real field capture. A July 2026 audit of the production corpus found that the 22 recordings were app tests rather than field jobs — 11 failed at upload, 3 failed processing, and most of the rest had no usable speech. Total usable footage was about five minutes.
- The five published lesson cards were fabricated by the compile pipeline from a bare mark timestamp with no transcript and no genuine expert answer. They were permanently deleted; the production corpus is now zero. This was the exact failure mode the product exists to prevent, and finding it in my own system is the reason I no longer trust a dashboard I have not audited.
- No paying customers, no signed pilot, and no measured effect on callbacks or ramp. Every outcome claim in the product is currently a hypothesis with instrumentation attached.
What I took from it
A dashboard will happily count your own testing
The usage numbers were real numbers. They were also entirely me. Instrumentation without a definition of what counts as a genuine episode measures activity, not value.
A compile step that cannot fail will invent
Given a timestamp and nothing else, the pipeline produced plausible HVAC guidance. The fix is not a better prompt — it is an eligibility gate that refuses to compile when the evidence is not there.
Durable queues in Postgres are usually enough
SKIP LOCKED with heartbeat reclaim and backoff handled everything a one-person product needed, and removed an entire piece of infrastructure from the operational surface.
Stack
- Product strategy and the capture-to-lesson loop
- React Native capture, debrief, learn, and outcome screens
- FastAPI backend, data model, and durable processing queue
- Media pipeline: upload, frame extraction, transcription, moment detection
- Next.js admin review and publishing gate
- Auth, per-tenant isolation, consent and redaction paths
- Deployment and evaluation of whether any of it works