01
What it is
A restaurant owner opens the POS and sees revenue, receipts, top sellers. What they do not see is what to do about it. Poster answers “how much” but not the three questions the owner is actually asking: am I making money or losing it, where exactly am I losing it, and what should I do this week.
Sol pulls the data through a single read-only token and answers all three.
Every finding is priced in hryvnia and carries the query that reproduces the number. An advice item without money and without evidence is never published — that is a release-blocking rule. From there the advice has a life of its own: seen, accepted, done, measured — and the system shows what it actually returned.
02
capabilities
What it does
01
Every recommendation priced
An impact estimate in ₴ per month plus SQL evidence. No number or no evidence means no recommendation.
02
Finding losses in menu and purchasing
Price history per SKU and supplier, recipe cards resolved recursively through prep items, dead menu positions, and write-offs that separate staff meals from genuine spoilage.
03
Advice lifecycle
New → seen → accepted → done → measured. A rejected item mutes that detector for that entity for N days so it stops nagging.
04
Contradiction check
The engine will not simultaneously advise “raise the price of this item” and “drop this item from the menu”. One survives, by priority.
05
Live pulse of the day
Revenue, receipts, average check and hourly pace against the median for this weekday. By 11:00 you already know the day is sagging.
06
A written morning briefing
The LLM receives finished findings as JSON, never the raw database, and writes the human text. Code computes the numbers; the model writes the words.
03
architecture
How it works
01
Nightly sync from Poster
02
Metrics and detectors
03
Findings priced in ₴
04
Advice with a lifecycle
05
Measurement of real effect
Under the hood
- Every data trap is encoded in a single rules module: cents versus hryvnia, row totals versus quantity, overlapping identifier spaces.
- We never write to the POS database — everything derived lives in a separate database alongside it.
- The nightly pipeline is idempotent: rerunning the same date never duplicates findings.
- Every detector carries a confidence threshold and refuses to publish on too small a sample.
- Trends are computed weekday-adjusted: Monday is compared against Monday.
- Drill-down to the source document — receipt, invoice, write-off act — in at most two clicks.
04
scale
Numbers
₴
attached to every advice
36K+
receipts analysed
72
findings in the first audit
2
clicks to the source document