How to Turn a Decision Log Entry into a Prompt for a Review Model

Rewrite the entry into exactly four blocks. Keep each one short. The labels do the work; prose between them does not.

The evidence block is where most of the value sits, and where most entries fail on the first attempt. Compare a typical log line with a converted one:

• Log: "Enterprise demand is picking up, so we should add a team tier."
• Converted: "Three of the last five signed contracts asked for SSO before signature (deck s9; calls sheet rows 14, 19, 22)."

The second version is longer, but every clause can be checked against something the model can open. The first version forces the model to guess, and guessing is where fabricated support enters the review. The discipline mirrors what investors expect in a deck: J.P. Morgan's startup banking guidance stresses data-backed problem statements and traction evidence over assertion, and a reviewer model can only apply that standard if the evidence is addressable (J.P. Morgan on pitch decks).

A practical rule: if you cannot name the slide, the cell, or the paragraph behind a line, move it to ASSUMPTIONS. That keeps the claim alive in the review but marks it as unproven, which is exactly the verdict you want the model to return.

Source pointers need a grammar, or the model will invent addresses. Pick one convention and state it in the instruction header. Three formats cover most decks and models:

1. Deck: (deck sN) where N is the slide number, counted from the title slide as 1.
2. Spreadsheet: (metrics!<cell>, <as-of date>), for example (metrics!C4, 2024-03-31).
3. Document: (memo pN, para M) for written memos and research notes.

The as-of date matters because reviewers check freshness as much as presence. A margin claim sourced to a cell from two quarters back is found but stale, and you want the model to say so rather than pass it. Financial projection slides fail precisely because the numbers on them are not anchored to current pipeline; Waveup's review of hundreds of decks argues year-one figures must be backed by signed pipeline rather than modeled growth, which is a claim a model can verify only if you point it at the pipeline source (Waveup on financial projections).

Send the source files with the entry in one message. Extract the deck to text with slide markers, export the metrics sheet as CSV, and paste both beneath the entry inside clear delimiters. The Patterns review of prompt engineering techniques notes that delimiters separating instructions from content are a basic and reliable way to keep a model from confusing the two (Chen et al., Patterns).

The header is five to eight lines and never varies between entries. It does four jobs: names the task as a check, lists the allowed verdicts, forbids rewriting, and fixes the output shape.

TASK: Check the DECISION ENTRY below against the attached sources.
You are not writing or improving the entry.

VERDICTS (use only these):
  SUPPORTED      the source says what the claim says
  PARTIAL        the source says something weaker or narrower
  NOT FOUND      no source in the attachment contains it
  CONTRADICTED   a source says the opposite

RULES:
1. Quote the exact line from the source. Never paraphrase a quote.
2. If the pointer is wrong but the claim is findable elsewhere, quote
   the real location.
3. Do not propose new reasoning, new numbers or new recommendations.
4. If you cannot quote it, the verdict is NOT FOUND.

OUTPUT: one markdown table, columns: Claim | Source found | Verdict | Quoted line.
Then one final row per ASSUMPTION, verdict UNPROVEN unless a source proves it.

The verdict on assumptions is the subtle part. A model asked to "check assumptions" will happily argue for or against them, which reintroduces composition. Forcing UNPROVEN keeps the model in check mode and leaves judgment with you. That split, deterministic checking by the model and judgment by the human, is the distinction the broader prompt engineering literature draws between instruction design and evaluation design (Maxim's practitioner guide).

If your team runs several review passes, keep the header in version control and change it deliberately, treating edits as a hypothesis to test against a fixed set of entries, as the local-first prompting guide recommends for repeatable review work (LocalChat best practices).

Here is a raw entry as it might appear in a founder tracker, written in the usual shorthand:

Raised prices on the Team plan from $20 to $29 per seat. Growth is strong and competitors are more expensive, so churn should hold. We can push the annual discount later if needed.

Converted into four blocks:

DECISION
On 2024-04-02 the pricing committee raised Team from $20 to $29 per
seat, effective 2024-05-01. Owner: Head of Revenue.

OPTIONS
A. Keep $20 and add a usage fee.
B. Raise to $29 flat, keep annual discount at 20%.
C. Raise to $35 and drop the annual discount.
D. Do nothing until the next quarter.

EVIDENCE
E1. Team-plan churn averaged 1.9% monthly in the six months to
    2024-03-31 (metrics!B7, 2024-03-31).
E2. Two competitors list entry seats above $25 (deck s14).
E3. 11 of 14 renewal calls raised price before value (calls sheet
    rows 3 to 16).
E4. Gross margin on Team was 71% in Q1 (metrics!D2, 2024-03-31).

ASSUMPTIONS
A1. Churn stays under 2.5% monthly for two quarters after the raise.
A2. The annual discount remains a strong enough incentive at $29.
A3. Sales cycle length does not change materially.

Now the model's job is narrow. For E2 it opens deck slide 14 and quotes the competitor lines, or returns NOT FOUND. For E1 it finds cell B7, quotes the churn figure, and notes whether the pointer is right. For E4 it may find that D2 holds a different quarter or a blended margin, giving PARTIAL or CONTRADICTED. The three assumptions return UNPROVEN, which is the honest answer and the one that tells you what to watch after the change.

A typical output looks like this:

Read the verdicts as a punch list: one claim needs a better source (E3), one is weaker than stated (E2), one is wrong (E4), and one slipped past everyone (E1). That is a fifteen-minute pass that would otherwise cost a meeting. The same check applies to investor-facing versions, where deck claims about market size and traction are the ones reviewers press on, as the deck examples collected by Slidebean and Figma show in their traction and market slides.

Even with the header in place, five failures recur. Each has a specific countermeasure.

The assumption-advocacy failure is the most tempting to allow, because a model that argues is more interesting to read. Resist it. The moment the model builds an argument, you are reading a composition and cannot tell which parts came from your files. The investor-deck literature is full of warnings about projections that sound confident and fail on first contact, and forward-looking statements in regulated documents carry explicit disclaimers for the same reason: they are estimates, not facts (J. Crew's FY20 forecast materials on SEC.gov show the standard forward-looking disclaimer that accompanies projection tables). A model that marks those projections UNPROVEN is behaving like a careful reviewer.

One more safeguard: run the review twice with the same inputs and compare tables. Disagreement between runs on a SUPPORTED verdict is a sign the claim is ambiguous, not that the model is unstable. Rewrite the claim until both runs agree.

The conversion should not be a one-off. Two habits keep it cheap. First, store the four blocks in the same record as the decision, so the reviewed version is the version of record. Second, add a review date to the entry, which standard decision log templates already recommend, so each decision gets rechecked against updated metrics rather than being trusted forever (Craft's decision log template and Miro's decision log template both treat status and review as core fields).

For teams logging many decisions, a light pipeline works well: export entries to Markdown, batch them by quarter, and run the same header across the batch. If you would rather not wire a pipeline yourself, Quanta Inference exposes text models through one OpenAI-compatible API key, which is enough to send the header plus entry plus sources and collect the table without managing model providers.

Finally, write the review result back into the entry as a short line: verdict count, date, reviewer. A decision that was checked and one that was not are different artifacts, and the difference is what makes the log worth keeping.