One decision, start to finish.The measurement can say no.
A playbook follows one operating decision through marql: the signal, the arithmetic underneath, the actions available, and the control period that decides whether the effect counts. Real product screens, demo-tenant numbers.
What every playbook follows
Four stages, and two of them can end without a number.
The same four stages in every playbook, in this order. Two carry a gate — a point where the honest output is a gap rather than a figure, and where marql is built to show the gap.
Find it before the period closes
A daily run over the raw feeds, not a report someone remembers to open. Deviations are ranked by what they are worth in money, so the list starts where the money is rather than where the alert happened to fire.
Separate the cause from the symptom
Dead stock and a selling product with too much cover look identical in a stock report and need opposite actions. The diagnosis reads sell-through, the season, and availability in the other locations before it says which one this is.
No cost prices in the feed — the playbook counts the excess units and leaves the money column empty rather than estimating it
Put an action against a name and a date
More than one option, because the right move depends on things a model does not know: pause replenishment, move stock between locations, price it down, or change the threshold. Each carries an owner, a deadline and a review date.
Measure it against a baseline
The baseline period and the measurement window are fixed when the action is confirmed, not chosen afterwards. Nothing is counted as an effect before the window closes.
The window cannot separate the action from an outside factor — the ledger records «no effect» or «not enough data», and no saving is claimed
What a playbook has to state on the page
Six things, and the last two are the ones that are usually missing.
A vendor's own worked example is easy to write and easy to distrust. These six are what make one checkable, so every playbook in the library carries all six.
The question, in your words
The question an operator actually arrives with, before it has been translated into the product's vocabulary.
Printed at the top of the playbook, with the five or six follow-ups underneath in the order they get asked.
The minimum data set
Which feeds have to be connected for this decision to be possible at all, and which only improve the accuracy.
Three tiers, named: required, required before any money figure, and improves accuracy. No playbook implies it works on less than it needs.
How the number is computed
Whether the figure is a model's opinion or arithmetic you could repeat in a spreadsheet.
The quantities are deterministic — stock on hand, average daily demand, lead time, target buffer. The AI explains the reasoning; it does not produce the number.
More than one action
A single recommendation is a tell: it means the tool has not modelled the trade-off, only the symptom.
Every playbook ends on a set of options with their conditions, and the choice stays with the person who owns the consequence.
Where potential stops and proof starts
The one section most vendor case material leaves out, because the figure looks better without it.
A block of its own, in the same type size as the rest of the page: what the headline figure is, and what it is not. It is a potential on demo data, not a saving anyone has banked and not our ROI.
Real screens, labelled as demo data
Whether the interface in the images is the shipped product or a designer's illustration of it.
Real screens, and the frame around every one of them says which tenant and that the numbers are synthetic. No customer's data appears in any playbook.
Who wrote this
What the library does not do yet.
These are our own worked examples on our own demo data. Here is exactly what that is worth and where it stops.
- One playbook is published. There is no list of the ones being written, because a hub of links to pages that do not exist is a promise with no date on it.
- No customer results appear in any playbook. marql has no signed chain whose numbers it can publish, so every figure comes from the demo tenant and says so on the screen it appears in.
- No playbook guarantees a percentage. Two of the platforms in this category sell exactly that — a floor on what an audit will find — and it is a defensible offer with a book of engagements behind it. We do not have one, so we do not price the downside.
- Every figure is a potential, computed from the demo data. A potential becomes an effect only after an action, a baseline period and a control window, and the ledger is allowed to conclude that it did not.
- No playbook states how long any of this takes on your data. The product does not commit to a window, so nothing here implies one.
- The copy is published in English, Romanian and Bulgarian; the product screens inside it are in English in every market, because the demo tenant runs in English and re-recording five screens per language would prove nothing more.
Frequently asked questions
About the playbooks
No, and the difference matters. A case study is a customer's result, told with their permission and their numbers. A playbook is one decision worked end to end on our demo tenant: the same screens a customer would see, with figures we generated. There is no customer in any of them, which is why nothing on these pages is attributed to one.
The screens are the shipped product. The numbers in them come from the demo tenant and are labelled as synthetic in the frame around every image. What is real and checkable is the method — what raises the signal, which inputs the arithmetic needs, how the quantity is computed, and what the ledger does when the control window is inconclusive.
English, Romanian and Bulgarian — the three markets the site serves. The product screenshots are in English in all three: the demo tenant runs in English, and what the screens are there to prove is the sequence of the decision rather than the interface language. The product itself is used in the local language.
That is what the working session is: your sales and stock data, the same four stages, and the deviations that are actually in your chain rather than in the demo tenant. It needs no preparation on your side beyond read access to the systems that hold sales and cost.
Where the screens come from
Decision Inbox
Where the signal arrives, ranked by what it is worth rather than by when it fired.
Copilot
Where the cause is separated from the symptom, and the options are put side by side.
Impact Ledger
Where the effect is measured, and where it is recorded as unproven when it cannot be.
How marql fits together
The connection, the daily run and the brief, for a reader who arrived at a playbook first.
Talk to us
Tell us about your business. We'll call you.
Tell us a bit about your business and your data sources. We'll tailor the walkthrough, then you pick a time that works for you.