Prefer flagging over guessing
There is a rule written at the top of the prompt that turns meeting transcripts into tasks, and it governs everything below it:
Prefer flagging over guessing.
It sounds like a hedge — the sort of caution you add because the model is not good enough yet. It is not. It is a deliberate product decision, and it makes the output measurably less impressive to look at and considerably more useful to work with.
The asymmetry that drives it
Take a single field: who owns this task.
A task that arrives with no owner costs the reviewer about five seconds. They read the row, they know who was in the room, they pick the name, they move on.
A task that arrives with the wrong owner costs something else entirely. Best case, the reviewer notices and fixes it — the same five seconds, plus a moment of doubt. Worst case they do not notice, and work is now assigned to someone who never agreed to it and may not look at it for a week.
The real cost is not in that one row, though. It is that once a reviewer catches one confidently wrong assignment, they stop trusting every other row on the page. A list you have to check line by line is not faster than writing it yourself. The tool has to be right often enough that skimming is rational, and a single visible fabrication resets that.
So the two errors are not symmetric, and a system that treats them as symmetric — that optimises for "how many fields did we manage to fill?" — is optimising the wrong number.
Filling the gap is the easy part
The uncomfortable thing about this rule is that guessing is genuinely easy and usually right.
Given a transcript where someone asks "can someone pull the Q3 numbers?" and Maria happens to be the analyst in the room, assigning it to Maria is a good bet. It would be right most of the time. A model asked to produce a complete, tidy list will make that inference without being asked, because a complete list looks like a better answer than one with holes in it.
The trouble is that "usually right" is the wrong standard here. Nobody said Maria's name. The row would carry an owner that no sentence in the meeting supports, and it would look exactly like the rows that are supported. There is no visual difference between a fact and a good guess once both are sitting in the same column.
That is what the rule defends against. Not model error — inference presented with the confidence of observation.
What honesty looks like in the schema
Saying "prefer flagging" only works if the output has somewhere to put the uncertainty. Four places carry it:
- A null owner. Both the name and the email go empty when nobody clearly took the work on. The task still exists.
- A flag. Exactly one of Needs an owner or Soft commitment — or null, when it is a firm promise with a clear owner.
- A confidence score. Zero to one, scoring whether a commitment was really made, not whether we know who made it.
- A verbatim quote. The transcript line the task came from, reproduced exactly.
The last two are worth separating, because they answer different questions and conflating them makes both worse.
Confidence scores the commitment, not the ownership. An unmistakable promise that nobody put their name to — "we'll definitely get that over to you" — is a high-confidence task with no owner. Not a low-confidence one. The doubt about who owns it is already carried by the null and the flag, and discounting confidence for the same uncertainty would count it twice, pushing a real firm commitment down the page where it is more likely to be waved through.
The rule applies to dates too
Ask a model for a due date and it will happily give you one. The meeting was on a Wednesday, someone said "Thursday", the model knows the meeting date, so it returns a calendar date. Helpful.
The extractor is explicitly forbidden from doing this. Due dates come back in natural language, exactly as loose as the speaker was: "Thursday", "end of the month", "before the board meeting".
The reason is that the conversion is not free. "Thursday" resolves differently depending on what you anchor it to, and the obvious anchor — today — is the wrong one, because reviews happen days after the call. There is also a whole class of phrase with no calendar answer at all. "Before launch" is a real deadline that everyone in the room understood, and there is no date that captures it without inventing a fact nobody stated.
So the conversion happens later, in one place, and it is a proposal rather than a decision. The resolver that does it is anchored deliberately:
Everything resolves against the date the meeting was recorded, not today. "Thursday", said on a Wednesday in August, means the next day — not the Thursday after whenever someone gets round to reviewing it.
It pre-highlights a day in the date picker. It never writes one. And when a phrase carries no resolvable date it returns nothing at all, so the picker opens on the meeting's month with no day highlighted — which is the common outcome, and the correct one.
Both destination trackers require a real date and quietly ignore anything else, so this is the point where a spoken phrase becomes a deadline or fails to. Putting a human click exactly there is the entire design.
Where the rule stops
Taken too far, "never guess" would make the output worse, so there is a line — and it sits somewhere slightly surprising.
Transcripts come from speech recognition and they contain errors. "Webhook" comes out as workbook. "Team" comes out as Steam. When the surrounding conversation makes the intended word unambiguous, the extractor is told to silently correct it in the task title. That is not guessing; it is reading the sentence the speaker actually said.
Inside the quote, nothing is corrected. Not even the same word that was just fixed in the title.
That looks like an inconsistency, so it is worth being precise about why. The quote exists to be checked against the recording. A quote that reads better than the transcript makes that check impossible — the reviewer searches for the tidied sentence, does not find it, and ends up doubting the tool rather than the transcription. A title and its quote disagreeing on a word is expected, and correct.
The general form: correcting an observation is allowed, inventing one is not.
What you get for it
A list with holes in it, honestly.
Some rows have no owner. Some carry a Soft commitment flag saying this was hedged and may not really have been agreed to. Some sit low on confidence with a note that the transcript does not clearly support them — and they are still shown, because an item that gets silently dropped is one the reviewer never gets the chance to judge.
That list photographs badly. Eight tidy rows with every field populated make a better screenshot than eight rows where three of them say Needs an owner.
But the second list is the one you can act on without re-reading the transcript, because every gap in it is a gap that was really there in the meeting. Rooms are ambiguous. People leave with different beliefs about who agreed to what. A tool that renders that ambiguity as clean data has not resolved it — it has hidden it, and moved the moment of discovery to three weeks later, when the work has not happened and nobody can say why.
The version that shows you the holes lets you close them in five seconds each, while you still remember the room.
This is how promisedby reads the meetings you already record: every extracted commitment carries the quote it came from, and nothing reaches your tracker without your approval. There are setup guides for Notion and Linear, and a longer piece on the workflow gap this all exists to close.