How the Sensai concierge works

Classification is hybrid: deterministic first, AI second

Every turn runs through a keyword and pattern table first, with no AI involved. Near-unambiguous phrases (for example, describing being served with a lawsuit) short-circuit at high confidence. Only when the deterministic pass is not confident enough does a model classify the conversation, and its output is validated against a strict schema before it is used.

Recommendations come from a fixed registry, not from the model

The AI model never picks products and never writes product links. Cards are built from a typed product registry checked into the codebase: one record per product with its name, a one-sentence factual value statement, and its entry link. If a product is not in the registry, Sensai cannot recommend it.

Ordering is relevance plus continuity. Nothing else

At most two cards render per turn. Candidates must clear a classification confidence threshold of 0.6 and are ranked by confidence alone. The single exception: if you are signed in and already have an open matter in the recommended product, a continue-where-you-left-off card renders above any new recommendation.

No product pays for placement

There is no payment, bid, or sponsorship input anywhere in the ranking. Every product in the registry is a LawSens.ai tool, the registry is code reviewed like any other code, and the only signals that order cards are how confidently your conversation matched a product and whether you already started there.

Why-lines are grounded, and products can veto their own card

The one-line reason on a card is composed from facts you actually mentioned. For the family, civil defense, and criminal defense pathways, the destination product's own triage logic is dry-run first to ground the line, and the family triage can suppress the card entirely when its safety rules say a handoff is not appropriate.

Hypothesis-bearing copy variants, picked by Thompson sampling

The button text on a recommendation card is drawn from a small set of pre-written variants. Each variant is seeded with a written hypothesis about why it might serve visitors better (for example, that naming the exact task lowers anxiety for someone responding to a lawsuit). A Thompson-sampling bandit picks among them, which means better-performing wording is shown more often while weaker wording is still occasionally tried.

The reward is a real outcome, not a click

A variant only earns full credit when the visitor who saw it actually completed the handoff into the product within 24 hours. A click that goes nowhere earns a quarter of the credit, and a card that was shown but never clicked earns nothing. This stops the system from learning clickbait: copy that attracts clicks but does not help anyone scores poorly.

Copy rules are enforced by automated tests

• No outcome promises. Words like win, beat, guaranteed, or erase are barred from button copy.
• No fabricated urgency. Urgency framing appears only when a deterministic detector finds a real deadline in what you wrote.
• Family law copy must be supportive and pressure-free.
• Every button must describe an action the destination page actually performs.

Every seeded variant is checked against these rules in the test suite before it can ship.

Only the wording is tested. Never the ranking

The experiment changes which words appear on the button. It never changes which product is recommended, the order of cards, or whether a card appears at all. If the experiment system fails for any reason, the card simply falls back to its plain default wording.

No conversation is saved

Anonymous turns are never written to conversation tables. There is no transcript to recover later because none is stored.

A daily turn budget applies

Anonymous use is capped at 6 turns per day, counted per device session and per network address, whichever runs out first. The budget exists to bound cost, not to track you. If no budget store is configured at all, anonymous turns are denied rather than left unmetered.

The session cookie is a random id

Anonymous sessions are identified by a random identifier in a cookie, used only for the turn budget and aggregate telemetry. It is never linked to any account.

Telemetry references are hashed

The attribution reference that connects a shown card to a later signup can embed a conversation id, so analytics and learning systems only ever see a one-way hash of it, never the raw value.

Learning is aggregate-only

The learning signals that improve recommendations carry the pathway, the surface, the conversation length, and the outcome. Never a user id, network address, session id, or any conversation text.

Conversations live in your account and you can delete them

Signed-in conversations are saved to your account's conversation history so you can pick up where you left off. Deleting a conversation removes it; the delete only works against your own rows.

Pre-intake briefs exist only for signed-in users

When you click through to a product, a short brief of the facts you shared (state, role, claim type, key date, amount range) can pre-fill that product's intake so you do not retype them. Briefs are written only for signed-in conversations, the table is locked to server-side access, and you review and can edit everything before submitting.

Chat uploads, when enabled, are processed in memory

Document upload in the chat ships behind a flag that is off by default. When it is enabled, the document is parsed entirely in memory and discarded: no file storage write, no database row, and no document text in any log. Saving a document is the destination product's job, with your consent, not the chat's.