
Field technicians spend 30-60 minutes per job writing up the visit - often after hours, from memory. Notes get lost, reports get thin, nothing is auditable. Dictation alone cannot tell a report from a guess: "production" and "staging" servers, rack A3 and A8 all sound close enough to end up on an invoice. Of the submissions we audited (61 audited, 94 live), none published measured extraction accuracy. WHAT IT DOES: One visit, one loop: the technician starts a voice session (consent first, microphone second); every statement becomes a JSON-Schema tool call, so the incident card fills live, each field with its audit trail. Critical values - services, severity, timeline hours - are read back out loud and confirmed before they count. The session ends as evidence: CSV, print-ready PDF, JSON artifact. Audio is discarded by design. HOW WE BUILT IT: AssemblyAI Voice Agent API over a raw WebSocket (client written from the documented contract). JSON-Schema tools with catalog enums - the agent can only pick services that exist. Zero npm dependencies, Node 22, no build step. Vercel serverless issues single-use temp tokens (API key never reaches the browser). A deterministic mock channel drives CI; a metrics harness with a hand-computed oracle and a real-session driver measured 10 sessions against the live API. Born in Spanish; rewritten in English in the final 24 hours and re-measured (N=10). METRICS (N=10, failures published): turn completion 100%, severity exact 9/10, services precision/recall 100%/100%, timeline hours 80.0%, confirmation precision 71.0%, WER 0.685 word-level (a VAD segmentation artifact - the ASR hears everything) and 0.137 turn-level, both published. Evidence committed in docs/evidence/gate/. HONESTY: The demo roleplay is a deterministic replay of the mock channel, stated on screen; narration is synthetic TTS, disclosed. A pre-registered noise gate failed, so we pivoted to post-visit dictation. Privacy enforced in code: audio never stored.
30 Sep 2026

An incident gets fixed, the PR is merged, and then the postmortem often never gets written. It takes time, and after the immediate problem is solved, it is easy for the write-up to fall to the bottom of the list. The Incident Postmortem Generator starts with what is already in the repository. Given a repo, the issue related to a bug, and the SHA of the fix, it works backwards to identify likely introducing commits using SZZ-lite signals such as git blame, pickaxe searches, and issue links. It then builds a timeline, analyzes the root cause, and proposes prevention actions. A key part of the project is knowing when the repository does not contain enough information. Claims are linked to the evidence that supports them, sections have confidence levels, and things such as user impact, detection time, or telemetry are marked "No evidence" when they cannot be established from the available data. The evaluation harness checks this instead of relying on the model to simply follow a prompt. The target users are engineering teams and maintainers who need an incident record but do not want to spend an hour reconstructing one manually. The tool can be used from the CLI or through the offline UI and produces a Markdown postmortem with evidence links, confidence badges, and an evaluation report. The demo uses real cases rather than synthetic examples: curl CVE-2023-38545, log4j CVE-2021-44228, and the GitLab 2017 database outage. The GitLab case is useful because it has no fix commit, so it exercises the "No evidence" path rather than forcing the system to invent one. On the curl case, the deterministic baseline found the actual introducing commit as the top candidate, with timeline precision of 1.00. Adding Bob agent-mode analysis increased action-item overlap from 0.00 to 0.22 while claim linkage remained at 1.00. My approach was to stop asking an LLM to write a convincing postmortem and instead hand it repository evidence, then make the evidence part of the output.
27 Sep 2026