The problem
In manufacturing and operations firms, a quote often starts with an email in plain language: “illuminated sign, letters about 40 cm, insulated facade, Žilina, price including installation”. The salesperson has to read the parameters out of that, pick a product, add material, surcharges, installation and delivery, and total it against the price list. Missing details are chased by phone. The calculation then goes to a technologist for review. It is repeated work that depends on who does it, and mistakes are hard to explain afterwards.
What we built
A one-screen assistant. The salesperson pastes an enquiry; the assistant extracts parameters, shows a source and a citation from the text for each one, and prepares a draft line-item quote. Every row links to the rule that created it. If a required value is missing, the assistant asks (at most two questions at a time), or continues with visibly marked assumptions. The draft always ends in “Waiting for technologist”. The technologist approves it, edits it, or returns it with a note, and their changes show as a diff between versions.
The demo is built on a fictional illuminated-signage catalogue: 4 products, 30 price-list items, rules in YAML. When deployed in a company, only these files are swapped; the core stays the same.
Out of scope on purpose: attachments (drawings, facade photos), ERP or email integration, and any automatic sending of quotes to the customer.
How it works
- Catalogue, price list and rules are data (versioned YAML), not code. At start-up it checks that every rule points at an existing item and parameter.
- The language model does only two things: extract parameters from the conversation into a JSON schema, and phrase a follow-up question. The schema has no field for price.
- Code checks every parameter: allowed values, ranges, and whether the citation really appears in the enquiry text. A parameter with no support in the text is dropped; it is never marked as “from the brief”.
- What is missing is computed by code, not the model. Letter counts and diacritics too.
- A deterministic engine computes line items and totals from the price list and rules. Prices are copied into the quote as a snapshot; every parameter change creates a new version.
- What is not in the catalogue, the assistant does not price; it hands it to the technologist without a price.
How long it took
First working version including the test set and deploy in one day (12 Nov 2026).
Technologies
TypeScript · Hono · Qwen 3.6 running locally via Ollama · structured output with a JSON schema · Zod · SQLite · rules in YAML
The model runs locally via Ollama, so enquiries and the price list do not leave to an external AI model provider, and no paid AI API is used.
What we measured
12 Nov 2026, 20 test enquiries, Qwen 3.6 running locally via Ollama, temperature 0.
- The test set: 5 sample scenarios, 9 further realistic enquiries (different products, approximate dimensions, without diacritics), 3 incomplete and 3 stress cases (out of catalogue, attempt to manipulate the price, nonsense).
- Extracted parameters: 71 of 71 correct.
- Missing data: the assistant correctly decided whether to ask, for 18 of 18 enquiries where the set checks that.
- Parameters marked “from the brief” without support in the text: 0.
- Totals: the engine is deterministic; a sample enquiry for a 3D sign gives exactly the expected sum (verified by unit tests).
- Time: median 8.1 s from pasting the enquiry to a finished draft or a question.
What we learned
- Rules belong in code, not in the prompt. If the model has no field for price, it cannot invent one — not even on a request like “give a 50% discount”. That kind of instruction ends up as a note for the technologist.
- A local model with structured output sometimes mangles an allowed value (“obojsranne”). Tolerant matching in code is more reliable than more rules in the prompt.
- Citation checking is cheap and effective: normalising diacritics and allowing for typos is enough for real citations to pass and invented ones to fail.
- A test set written before tuning the prompt showed every regression as a number, not as an impression.
Where this could be used
- Made-to-order manufacturing with a bill of materials and installation: from enquiry to a quote draft.
- Signage and print production: dimensions, materials and surcharges from the price list.
- Field service where the price is labour, materials and travel.
- The same core (AI extracts parameters, code computes, a human approves) for any quote assembled from a catalogue and rules — by swapping catalogue, price list and rules.
This is not an ERP and not automatic sending of quotes. It is one concrete process: from enquiry to a draft that a human approves.
Who it’s for
Manufacturing and operations firms in Slovakia and Czechia that assemble quotes from a catalogue and price list and do not want to send the price list or customer enquiries to the cloud.
We store questions without IP addresses for 30 days to evaluate and improve the experiment. We use your IP address only briefly to limit the number of requests and do not store it. Please don't include personal data in your questions.