Flutterfrog

Method

A result you can check, not one that sounds right.

The reason most AI work fails in a business is not that the model is weak. It is that nobody decided in advance what a correct answer looks like — so there is nothing to check the output against, and a confident wrong answer sails straight through.

Everything below is how we prevent that. In diagrams, because the shape is the point.

The pattern

Every system we build has the same five blocks. The one in the middle is what makes the result predictable — it is a rule, not a judgement, so it gives the same verdict every time and cannot be persuaded.

The shape of every flow we build

The model proposes. Something that cannot be talked round decides. A person confirms before anything leaves the building.

InYour existing recordsAs they are. No clean-up first.
AIProposes a resultWith its confidence, field by field.
GateDeterministic checkRules, not judgement. Passes or stops.
PersonConfirmsAgainst the evidence, not the claim.
OutResult you can auditEvery field traceable to its source.

Stops when: any required field is missing, malformed, or below the confidence bar

Measured
The gate is the difference between automation and a fast way to be wrong.

Four of them, running

These are ours, on our own business, with counts that can be checked. The numbers on the right are measured, not projected.

Catalogue enrichment

Billing-software shorthand into a listing a customer can actually buy from.

InTally exporte.g. “SOFT 100ML”
AIReads and proposesName, description, quantity, brand
GateRequired fields presentUnsure ⇒ left blank, never guessed
PersonVerifiesAgainst the pack photo
OutLive listing

Stops when: the model cannot name the product with confidence — the field stays empty rather than wrong

Measured
703 listings in one pass · 656 names cleaned · 870 Tamil corrections · 2 left deliberately blank

Personalised outreach

A member list into messages that reference what each business actually does.

InVerified list171 members
AIResearches, then draftsMatched to the closest prototype
GateLength and content rulesAdded after one message failed
PersonSendsNothing transmits itself
OutDelivered

Stops when: a draft is too short or missing its required references — one slipped through before this rule existed

Measured
171 researched · 513 drafts across 3 channels · 87 emails sent · 0 sent automatically on WhatsApp

Proposal and deck production

A brief into a client-ready document, the same way every time.

InBrief + brandEvent, client, numbers
AIWrites the contentInto a fixed template
GateBuild fails on any gapOne unfilled placeholder halts it
OutPDF, slides, QROne command

Stops when: a single placeholder is still unresolved — the build refuses rather than shipping a document with a hole in it

Measured
5 events through the same factory · 87 slide images · 114 documents, 1,048 pages since April

One source, four formats

Write it once. Decide the format late, and change your mind without redoing the content.

InOne source fileText plus a brand stylesheet
AIContent and layout
OutPDF · 4 image sizes · video · shareable pageFrom the same file

Stops when: nothing to stop — but change the headline once and all four outputs are correct together

Measured
Print, square, story and link-preview canvases render from a single poster source

When one pass is not enough

A gate answers yes or no. Some work needs a grade — is this document good enough to send? For that we run a loop: generate, render, score against the standard written beforehand, and go round again if it falls short.

What makes the score trustworthy is not the scoring. It is that the standard was fixed first and the thing being graded is the finished artefact, exactly as you would receive it.

Where this stands

The gates above run in production every day. The scoring loop has been run as a head-to-head on a live client proposal and won on the rendered pages — it is being built into the pipeline now, and we would rather say that than imply it is already automatic everywhere.

  1. Write the rubric

    What correct looks like, decided before anything is generated.

  2. Generate a variant

    The model produces one candidate from the spec.

  3. Render it

    To the real artefact — the actual PDF, page, or image.

  4. Score the artefact

    Against the frozen rubric. The output is judged, never the source that made it.

    Passes — below the bar, it goes back up
  5. Person confirms, then it ships

    Nothing reaches a customer on a score alone.

The five rules underneath it

None of these are about the model. They are about who decides what correct means, and when.

01

Correct is defined before anything is generated

The rubric is written first, from your requirements. A standard invented after the fact is not a standard.

02

The output is judged, not the thing that made it

We score the rendered page as an image, the way you will see it. Source that looks right and renders wrong is the common failure.

03

The generator never edits the rubric

The most reliable way to pass a test is to change it. If the same process writes the standard and meets it, the score means nothing.

04

The loop is bounded

A fixed number of attempts. Then it stops and asks a person, rather than burning budget converging on nothing.

05

Nothing mechanical is judged by a model

Totals, dates, references and formats are checked by rules. A model is only asked things a rule genuinely cannot settle.

The honest limit

Nothing is correct every time, and anyone who tells you otherwise is selling. What this method gives you is different and more useful: when it is wrong, it stops instead of shipping — and when it does ship something wrong, you can trace exactly which check should have caught it and add that check.

That is what predictable means in practice. Not never failing. Failing in a way you can see, in the same place, for a reason you can fix.