Live minutes

How it works

The Jev original asked seven questions about every sentence of a product standup, one request per sentence: what kind of note it is, who owns it, whether it has a deadline, what kind of deadline, whether it reverses an earlier decision, whether the work is blocked, and how important it is. The transcript here is that experiment's seed data, unchanged: 180 labelled lines of a synthetic "checkout redesign" standup with four attendees. This page does not play a prefix of it. It plays 37 lines stitched from three non-contiguous excerpts — the open, the launch-date flip-flop, and the load test that is blocked on a vendor — with the timings re-based so playback is continuous.

decision-machine-1 has no state object, so the questions become six batched calls per window of lines. Lines pile up for 1.2 seconds (or until 12 are waiting), then the window leaves as one call per question, each carrying the whole window in texts:

• /classify note kind over six labels — action_item, decision, open_question, risk, progress_report, small_talk. Each label is described by the words people actually say ("the speaker says 'I'll do it', 'I can take that', 'can you do this'"). Under a winning probability of 0.6 the line stays in the transcript and never becomes a note.
• /classify owner over one label per attendee plus nobody, on the text Priya says: "…" Who does the work?. There is no dynamic "the speaker themself" option, so each label names its person: "the work lands on Priya: someone asks Priya to do it, Priya says 'I'll do it' or 'I can take that', or someone says Priya will do it". Below 0.6 the card shows the amber "Who owns this?" chip with each attendee's probability, and you can set the owner yourself.
• /classify deadline kind over specific_date, this_week, next_sprint, before_launch, end_of_quarter and none. Plain TypeScript then turns the label into a real date: "by tomorrow" against the meeting's own date, "next sprint" against the sprint end, "before launch" against the launch date.
• /yes-no "Someone leaves this meeting owing a piece of work because of this line." The sixth call, and the one that is not in the Jev original. action_item loses inside the six-way classify: "Yep, I'll have the write-up to finance by tomorrow" comes back progress_report at 0.99, and the classify on its own finds 15 of the transcript's 50 to-dos. This narrower question gets a second vote, but only on lines the classify filed as a progress report or a risk, and only when the owner call is confident above 0.6 — about an attendee, or about nobody, which is how "someone needs to file a ticket" reaches the list as an unassigned to-do wearing the amber chip. Asked everywhere and trusted alone it says yes on 70 of 180 lines, which is why it is fenced in on both sides. A to-do promoted this way is kept on its own 0.55 bar and is not re-checked against the 0.6 keep threshold, which belongs to the classify: the two gates used to fight, and the casualty was this page's own opening hand-off, "Marcus, can you write up the rounding discrepancy and send it to finance before end of day tomorrow?"
• /yes-no "The speaker says 'actually, scrap that' and changes a plan the team already agreed." with a when_true / when_false pair. Only decisions are asked, and only above 0.8 does the note strike through the decision it replaces. A decision that reverses is also exempt from the 0.6 keep threshold: without that exemption the decision being scrapped never rendered a card, so there was nothing left to strike through.
• /yes-no "The speaker says the work is blocked right now and cannot continue." when_true: waiting on another team, a vendor, an approval or a dependency, or a quota or rate limit that caps the run until it is raised. when_false: a deadline, a plan, a prerequisite nobody is waiting on yet, a risk, a request, or work simply in progress. This answer is bimodal — a real blocker comes back 0.97–1.00 and every near miss sits at 0.5–0.8 — so the tag needs 0.85, not the usual 0.5. A blocked progress report is filed as a risk.

The seventh Jev question, importance, is dropped: the original never rendered it, and it would cost another call per window. Packing the previous three lines into the text, as a state object would have carried them, made every question measurably worse, so each call sees one line and nothing else.

What is missing. The original had a live-microphone mode beside the replay. It is not here. Web Speech is Chrome-only, and an open mic cannot honour the rule that every loop on this site stops by itself inside 60 seconds. The keyboard map loses r and m with it; s, x, 1, 4 and a remain.

What the numbers say. src/demos/live-minutes/smoke.mjs replays all 180 lines against the transcript's ground truth in six windows of thirty. It keeps 79 notes, 71% of which land in the right list; it finds 49% of the notes a human took; the owner is right on 91% of the to-dos it shows and the due date on 82%; the reversal and blocked calls agree with ground truth on 98% and 99% of all lines. The honest gap is recall: the six-way kind judgment is right on 54% of lines, and even with the sixth call the page surfaces 22 of the 50 real to-dos. It is a good first draft of the minutes, not a complete set. Two known misses, both measured: a question that proposes a change ("should we move the rollout to Monday instead?") is read as a decision and strikes the earlier one, and a speaker asking for a volunteer mid-sentence ("I also need someone to double check the currency table") scores 0.19 on the to-do question and is dropped. The counter-example that fixes the first costs the flip-flop this page is built around — REVERSES.when_false in judge.ts carries the measurements. node smoke.mjs --demo replays the 37 lines this page plays and asserts the flip-flop really strikes an earlier decision. The strip above shows what your run actually cost: calls made, model time, round trip and input tokens, and whether the minutes came from the model or from the fallback. If the proxy fails mid-run the error is shown inline, the window falls back to the transcript's own labels so the page still fills, and the strip flips from live to mock so nothing on screen is passed off as a model answer.

About latency. The original promised a note on screen about 150 ms after the sentence ended, with one request per sentence. Here all traffic shares one demo key at two calls a second, so a six-call window takes about three seconds and the honest end-of-line-to-screen figure in the strip is seconds, not milliseconds. The model time beside it is the part that belongs to the model. A run stops by itself after 37 lines or 60 seconds — which is why 1× is labelled "opening only": in real time the cap lands mid-way through the first excerpt, before the flip-flop and the blocker.