build.allanninal.dev

Part 4 of 7 · Proposal generator series ~5 min read

How a proposal stays on brand

The generator wrote a draft. Before it reaches you — let alone a client — it passes through four checks. Each one catches a different way a draft can embarrass you: the wrong tone, a promise you’d never make, a price or date that drifted from the real number, a missing piece. Get any of these wrong and a confident-looking proposal does real damage. Four small gates sit between a fresh draft and your sign-off.

Key takeaways

  • Gate 1 checks the draft against your voice rules: tone, length, the phrases you do and don’t use.
  • Gate 2 scans for banned claims — guarantees, superlatives, anything your templates don’t support.
  • Gate 3 re-reads every price and date and compares them to the computed numbers; any mismatch holds the draft.
  • Gate 4 assembles the proposal, attaches the brief, and renders a preview for you.
  • Every gate is a check, not a sender. The draft always stops at you for sign-off.

Four gates before sign-off

Four gates between a fresh draft and your sign-off A horizontal flow diagram. On the far left, a "Fresh draft" box: the generator returned five sections — cover, understanding, approach, timeline, and price summary. Four guardrail gates sit in a row to the right, each drawn as a vertical bar. Gate 1: Voice check — compares the draft against the tone rules in the voice doc (sentence length, reading level, the phrases you always use and the ones you avoid); if the tone strays, a short Haiku pass rewrites to match before moving on. Gate 2: Banned claims — scans for guarantees, superlatives like best or guaranteed, and any promise the section templates don't support; a flagged claim is softened or removed. Gate 3: Price and date guard — re-reads every number and date in the prose and compares them to the computed price summary and the timeline dates; any number that doesn't match a computed value holds the draft for a human rather than shipping a wrong figure. Gate 4: Final assemble — stitches the five sections into the proposal layout, attaches the brief and the computed price table, links a Google Doc copy for editing, and renders a preview. After all four gates pass, the draft is shown to the owner — in Slack with Approve, Edit, and Discard buttons, or in the linked doc. A note at the bottom: every gate is a deterministic check or a small grounded pass — none of them sends anything; the owner always signs off. Fresh draft five sections, cover to price Gate 1 Voice check tone + length vs voice doc phrases you use stray → Haiku rewrites to match Gate 2 Banned claims guarantees, superlatives? if found, soften or remove Gate 3 Price + date guard numbers match computed? mismatch → hold for a human Gate 4 Assemble + preview stitch layout, attach brief + price table, link doc, render preview Shown to you — Slack card (preferred) or linked Google Doc (to edit) buttons: Approve · Edit · Discard every draft logged to DDB pg-drafts — nothing sends without sign-off Every gate is a check, not a sender — the draft always stops at you for sign-off.
Fig 4. Four gates between the fresh draft and your sign-off. Check the voice. Strip banned claims. Guard every price and date. Assemble and preview. Then show it to you — never to the client — with Approve, Edit, and Discard.

Gate 1: the voice check

A proposal that’s correct but sounds like a stranger still loses. Gate 1 compares the draft against the voice notes in your rules doc: how long your sentences run, how formal you are, the phrases you reach for (“here’s how we’d approach it”) and the ones you avoid (“synergize,” “cutting-edge”). Most of this check is plain pattern-matching in code — a banned-phrase list, a sentence-length range, a reading-level target.

If the tone strays far enough, a short Haiku 4.5 pass rewrites the offending section to match your voice, then the check runs again. Haiku is the cheap model, and rewriting a paragraph to a known style is exactly the kind of small, well-defined job it’s good at. The expensive Sonnet call already happened; this is a light touch-up, not a re-draft.

Gate 2: banned claims

The fastest way to get a proposal into legal trouble — or just to sound like everyone else — is an unearned promise. “Guaranteed results.” “The best in the industry.” “100% uptime.” Gate 2 scans the draft for a configurable list of banned claims: guarantees, superlatives, absolute numbers you can’t back, and any promise the section templates don’t explicitly support. A flagged claim is softened (“guaranteed” becomes “we aim for”) or removed.

The banned list lives in the rules doc, so you can tune it without a deploy. A consultancy and a builder will draw the line in different places; the system enforces wherever you draw it. This gate is the difference between a draft that’s confident and one that’s reckless.

Gate 3: the price-and-date guard

This is the gate that matters most, and it’s pure code. Part 3 computed the price summary and the timeline dates in plain Python. Gate 3 re-reads the finished prose, pulls out every number and every date the model wrote, and compares each one against the computed values. The total in the cover has to match the total in the price table. The “four weeks” in the approach has to match the dates in the timeline. A figure in the prose that doesn’t match a computed value is a red flag — the model either restated a number wrong or invented one.

Any mismatch holds the draft. It doesn’t quietly fix the number (a quiet fix could mask a real bug), and it never ships the wrong figure to you hoping you’ll catch it. It stops, flags exactly which number disagreed with which computed value, and routes the draft to a human. In steady state this gate almost never fires — the model is told to use the numbers verbatim — but it’s the backstop that lets you trust the price on every draft you do see.

Gate 4: assemble and preview

The last gate isn’t a filter; it’s the packaging. It stitches the five approved sections into your proposal layout, attaches the original brief and the computed price table, creates a Google Doc copy you can edit directly, and renders a preview. Then it shows you the result — as a Slack card with Approve, Edit, and Discard buttons, or as the linked doc.

Note what Gate 4 does not do: send anything. It assembles and previews. The proposal sits in a “ready for review” state, logged to the pg-drafts table, until you act on it. The next post is about what those three buttons actually do.

Why the guardrails exist

None of these gates are exotic. They’re the care a careful person takes before sending a proposal under their own name: does this sound like us, did we promise anything we shouldn’t, are the numbers right, is it actually finished. Putting them in code as four sequential gates makes that care automatic instead of something you’re trusting yourself to remember at 6pm on a Friday. The model is fast and fluent; the gates are what make it safe to be fast.

Next post: how a proposal gets sent — the three actions on the Approve button, and how the registry of sent proposals stays in sync with the audit trail.

All posts