Bernal Books
Retail · M019 · onboarding 0/5
1 · Triage & diagnosis
How stuck this merchant is, and exactly what's blocking them — by an auditable rule, not a model guess.
- Risk score
- 73 (Medium)
- Blocker
- business_verification_needed
- Next best action
- verify_business
- Days since signup
- 7
- Last login (days ago)
- 3
- Reason codes
- low_completion
risk = 2×7 + 3×3 + 10×(5−0) = 73 # 5 steps remaining
Engaged but blocked at business / identity verification; the precise cause needs the verification_status / business_info_match_flag (IRS/Stripe mismatch vs not-yet-submitted) signal.
Send the 'match your business name + tax ID to your IRS records' fix with the exact field to correct.
Recently active but blocked at this step — a precise, step-matched self-serve nudge is the highest-yield, lowest-cost play.
Engagement state is a snapshot inference (last_login × steps × tenure), not a measured event. Pinning the exact root cause needs instrumentation: verification_status / business_info_match_flag (IRS/Stripe mismatch vs not-yet-submitted).
2 · Drafted outreach
A bounded, schema-constrained draft. Here it's the deterministic stub (REPLAY); a recorded real-Gemini run is on the Eval page — the safety machinery around it is identical either way.
Claims (each declared claim, verified against the merchant's data):
steps_completed = 0→ merchant.steps_completed = 0total_steps = 5→ merchant.total_steps = 5current_blocker_code = business_verification_needed→ merchant.current_blocker_code = business_verification_needednext_best_action = verify_business→ merchant.next_best_action = verify_business
3 · Claims-gatekeeper
A deterministic firewall: the draft cannot reach a human unless every declared claim checks out against the merchant's data and no forbidden-claim pattern is present.
4 · Faithfulness check (semantic judge)
A second, independent check: an LLM from a DIFFERENT model family reads the finished message and verifies each factual sentence against the merchant's data row — catching an invented number, capability, or timeline the deterministic gatekeeper structurally can't see. Here it's the deterministic stub verdict (REPLAY, $0); the live cross-family judge (Groq gpt-oss-120b) is key-gated.
- Your next onboarding step with Curbside Commons. →
steps_completed - Hi Bernal Books, thanks for getting started on your Curbside Commons onboarding. →
merchant_name - Your next step is to verify your business information. →
steps_completed
5 · Domain quality check (domain judge)
A third, independent check — on a different question than faithfulness. Not 'is every fact true?' but 'is this a GOOD activation message?' — scored against a cited rubric: matched to the merchant's real blocker · the right play for their engagement state · no over-promising. It's advisory and recall-favoring: the verdict is surfaced for the reviewer and recorded in the audit trail, but it never changes the send — eligibility and the human approval gate stay deterministic (a low-risk draft can still be simulated-sent even when flagged). Here BOTH the draft and this verdict are deterministic $0 stubs (REPLAY) — a minimal stub nudge often trips the engagement-fit check, which is the tertiary control doing its job, not the product grading its real output down; the live cross-family judge (Groq gpt-oss-120b) and the real drafter are separate and key-gated.
- Matched to the merchant's actual blocker — Addresses the 'Business / identity verification' blocker the merchant is stuck on.
- Right play for the engagement state — Fits the 'actively_stuck' engagement state.
- No over-promising (incl. implied / typicality claims) — No unsubstantiated outcome / implied-typicality language detected.
6 · Eval / quality
An independent measurement of draft quality across four dimensions — the deep-AI showcase, in human terms.
7 · Human-in-the-loop gate
A person decides — hold, reject, or send. Low-risk, clean drafts are eligible to send (simulated); high-risk ones are held for approval.
Eligible by the deterministic core → simulated send recorded.
8 · Audit trail
Every step of the decision, recorded.
- systemTRIAGErisk=73 (Medium); blocker=business_verification_needed; engagement=actively_stuck; play=self_serve_nudge
- draftDETERMINISTIC_RULESOutreach drafted by the deterministic stub (REPLAY; a recorded real-Gemini run is on the Eval page).
- gatekeeperPASS0 failure(s), 0 warning(s).
- judgeDETERMINISTIC_JUDGE3/3 prose assertions supported by merchant data; all supported.
- domainDETERMINISTIC_JUDGE3/3 domain-quality dimensions passed → good activation practice.
- evalPASS4/4 quality dimensions passed.
- systemSIMULATED_SENTEligible and not held — simulated send recorded (idempotent).
The merchant names shown are FICTIONAL (no real businesses — so synthetic risk states are never attached to real people). The product's adapter ingests real DataSF public-record names (PDDL 1.0, public domain — name + category only, PII-scrubbed; see lib/ingest/sf-adapter.ts). Activation state is synthetic and illustrative. No real merchant relationship or account.