Engineering · 27 September 2026 · 4 min

Parsing a meeting line without a model

The Meeting tab sorts every line into a decision, an action for someone, a note or a question - with a page of rules, no AI and no network. The interesting part is what those rules refuse to guess.

Every line typed into Jot’s Meeting tab goes through one function, parseMeetingLine, before it is saved. It returns a type (note, action, decision, question or topic), an owner for actions, a due date for actions, and any #tags. It runs on every keystroke for the live chip under the input and again on Enter, and both must agree instantly and offline.

So it is not a model. It is about two hundred lines of rules, and most of the thinking went into where the rules should stop.

The asymmetry that decides everything

A parser like this can be wrong in two directions, and they do not cost the same.

If a real action is read as a note, the fix is one click on its chip, and nobody but the note-taker ever saw the mistake.

If an ordinary sentence is read as an action for someone, the minutes go out saying John agreed to something he did not agree to. That mistake is sent to the whole room.

So every rule leans towards “note”. The parser is allowed to miss; it is not allowed to invent.

Explicit forms first

The unambiguous forms are read anywhere they appear:

Short prefixes only count at the start of a line. Otherwise “a to-do list” would be an action for a person called “do” - and there is a small list of words that can never be an owner after a to for exactly that sentence.

The rule that needed a gate

The most natural way people write an action is also the most dangerous:

John will send the deck

“X will …” reads as a commitment. So does “It will rain”, “Nobody will own this” and “will send the deck” (which is not about a person called Will). The parser only reads <name> will / to / is going to / needs to … as an action when the name is already known - typed into the meeting’s attendee field, used with @ earlier, or used in a past meeting.

The first time someone is mentioned, you get a note, and the chip fixes it. Every time after that, it just works. That trade is the whole design in miniature.

Typos, but only when they are safe

Names are matched case-insensitively and forgive one typo - one insertion, deletion, substitution or swap of two adjacent letters, so Mratin finds Martin. Two guards keep that honest:

Dates only on actions

The date pass is the same one the rest of Jot uses. It runs on actions only: @John send the deck by friday becomes the action “send the deck”, due Friday, with the dangling “by” removed. A decision like “we launch on friday” keeps the date in its text, because turning a decision into a reminder is not what anyone asked for.

The test list is the specification

Every form in the design document has a row in a table-driven test, and so does every sentence that must stay a note:

a to do list for the offsite
action to take is unclear
It will rain tomorrow
Nobody will own this
Priya will send the deck        (Priya not known yet)
email nick@example.com about it
John: we are over budget        (attribution, not a commitment)

The second list is the more important one. It is also the list that grows every time someone finds a sentence the parser misread, which is the right direction for it to grow.

Why not ask a model

Jot already supports bring-your-own-key AI, and it would be easy to send each line to it. It would also be slower than a keystroke, fail without a network, send your meeting to a third party a line at a time, and be confidently wrong in ways that are hard to predict. A page of rules that errs towards “note” is less clever and much easier to trust.

The Meeting tab ships in the next release. The parser has 60-odd unit tests; what it has not had yet is a month of real meetings, and that is the test that will rewrite the second list.

Jot is a quick-capture app for Windows: one hotkey, one line, back to what you were doing. What it is, or what is still unproven.