Skip to content
Back to home

Lab · working demonstration

The parser reads. The code decides.

Write a customer message the way someone actually would, and watch what the system does with it. Feel free to try breaking it: demand an impossible discount, feed it absurd numbers, tell it to ignore its instructions. The amount will not move, because whoever computes the price is not whoever reads the text.

Incoming message

0 / 4000 characters

Or start from one of these

  1. Message
  2. Extraction
  3. Validation
  4. Decision

Write a message or pick an example to watch the flow run.

Lab · working demonstration

Why it is built this way

The parser never touches a price

It only identifies what is being asked for and how much of it. The amount is computed afterwards by deterministic code against the rate card. That is why a malicious message cannot move an invoice: reading and charging are separate parts.

Stopping is a feature, not a failure

If a measurement is missing, a figure is incoherent, or the work needs a site visit, the flow halts and returns concrete questions. There is no path through the code that produces an amount without passing validation.

It measures walls as walls

When someone says "the bathroom is 6 m²" they mean the floor, but tiling is measured on the wall. The system derives the wall area and flags that figure with lower confidence, precisely because it is inferred.

The AI is swappable

The extractor satisfies a contract a language model could satisfy too. Today rules implement it; swapping in AI means replacing one file. Your business should not depend on whichever provider is in fashion.

Lab · working demonstration

What is real and what is simulated

Genuinely works

  • Reading the message and extracting the data
  • Validation against the rate card and its ranges
  • Computing the amounts, taxes included
  • Generating the PDF you can download
  • The execution trace with measured timings

Simulated

  • The inbox: you type here, no email arrives
  • Sending the quote to the customer
  • Writing to the CRM: the payload is shown, not sent
Lab · working demonstration

How well it actually reads

These figures come from running an evaluation set, not from an estimate. The set lives in the repository and runs with one command. If the number drops, a lower number gets published.

79%Cases never seen11 of 14 cases written after the parser was finished, with no tuning to make them pass. This is the figure that measures generalisation.
86%Correct decision12 of 14: it got right whether to quote or escalate, and for which reason.
90%Full set36 of 40 cases across the development and held-out sets.
100%PrecisionOf everything it detected, nothing was spurious. Quoting work nobody asked for is a worse error than missing it.

What it still does poorly

  • It does not correct spelling: "alikatado" goes unrecognised.
  • It does not resolve pronouns: in "change the floor and paint it", the painting is lost.
  • We wrote all 40 cases ourselves. They measure that the flow does what we claim, not that it handles any real-world message.
  • The rate card is a demonstration one, with indicative market prices.