Audiences AIInterpret · STATE-type decision system · built first for Retail & D2C
Your stack knows what customers did. It never asks why.
Interpret sits between customer signals and customer actions: it reads what a behavior most likely means, then decides which treatment follows.
Available for pilot. The rules are validated synthetically before they touch a single live customer.
Three customers leave the same trail
The stack records an abandoned cart three times, and the usual answer is the same discount three times. It converts the first customer, unsettles the second, and teaches the third they were right to wait. Nothing in the stack was ever asked what the behavior meant.
An illustrative retail pattern, framed to show the problem. Not a claim about your customers.
The output is a card, and nothing runs until you accept it
Interpret is a short stack of cards, each a single decision you accept or reject. Every card states what to do, why this and nothing else, the evidence behind it, what it is worth against your own baseline, and a confidence band.
Why a band? It reflects how many independent signals agree and how cleanly they separate the competing reads. A decimal would imply precision the rules do not claim.
When a trail reads two ways, the card says so: the dominant read carries the recommendation, and the competing read is named beside it. A clean-sounding label never hides a contested one.
Deliberate waiting
confidence: high- recommendation
- Hold the discount for this segment. Serve proof and availability instead of price.
- why this
- The trail reads as a customer who has learned that waiting brings the price down. A discount now confirms the lesson and trains the next wait.
- evidence
- Repeated returns to the same item across days; prior purchases in this segment clustering after markdowns.
- worth
- The margin on the discount you did not send, measured against a holdout slice of the segment on your own numbers.
Illustrative card. Enough to show the reasoning, deliberately partial so the rule cannot be reconstructed from it.
Same trail, different context, different decision
The same abandoned cart, read against three purchase histories. Pick one.
read
Distraction. Ready to buy, pulled away mid-purchase.
decision
A well-timed reminder. No discount needed: it would spend margin on a sale you already had.
read
Distrust. Wants the product, doubts the seller. They are in your reviews, and nowhere near your checkout.
decision
Send proof: ratings, guarantees, easy returns. Money thrown at doubt reads as desperation.
read
Deliberate waiting. The discount has always come to those who wait, so waiting became a strategy.
decision
Hold the line this cycle. Consistency now protects margin later.
Interpretation is computed from the pattern, never read off one event, and it re-reads every session.
When the signal is weak
Most sessions resolve to a treatment. Two states exist for the ones that should not.
enough unambiguous signal?no → weak signal · held
Low confidence is said out loud. The recommendation is exploratory content only, with no conversion push until the signal clears. Held is a designed state with its own logging.
should this customer be sold to right now?no → suppressed · not sold to
Repeated returns, a dispute, a cancellation in the same window: observable signs of a bad moment to sell. No urgency, no countdown, and the restraint is logged and audited. Suppression is mandatory behavior, never a configurable preference.
And when you reject a card, nothing runs. The rejection is logged and teaches the next run.
What it will not do
You approve every card. Your team renders the treatment in your own channels.
It runs inside your environment. No PII, no IDs, no behavioral logs leave. Abstracted signal labels only.
No ML in the scoring. Rules only, so every recommendation carries reasoning you can interrogate.
Where the observable signals say do not upsell, restraint is built in. It is a behavior, and no setting turns it off.
Low confidence is stated, and the recommendation is to hold.
It is validated synthetically before it touches a single live one.
Five decision families
Interpretations route into five families. Four recommend. One protects.
| Convert | The ready, interrupted customer. A plain reminder converts them; a discount pays for a conversion that was already coming. | rules |
|---|---|---|
| Reassure | The customer who doubts the seller. Proof over price: the review score, the service promise, the returns policy. | rules |
| Hold | The customer gaming the discount. Hold the discount this cycle and waiting stops paying. | rules |
| Retain | The account that is drifting. The reason decides the treatment: a lapsed habit and a bad experience need opposite answers. | rules |
| Suppress | The customer who should be left alone. Repeated returns, a dispute, a cancellation in one window. No urgency, no countdown. Logged and audited. | guardrail |
How a pilot runs
-
Integration is framed at one sprint against the analytics, commerce and CRM systems you already run. A translation layer inside your environment turns raw events into abstracted signals. Nothing leaves.
-
The rules run against synthetic customers first, never yours. That proves the logic executes and the reasoning is legible. Your team interrogates the cards before anything goes near live traffic.
-
Live, each accepted card is tracked against the KPI it named, on your own baseline. Outcomes re-fit the interpretations. What does not move a KPI does not survive.