Skip to main content
Activation queue

Pacific Heights Provisions

Retail · M016 · onboarding 3/5

Low risk · 37

1 · Triage & diagnosis

How stuck this merchant is, and exactly what's blocking them — by an auditable rule, not a model guess.

Risk score
37 (Low)
Blocker
business_hours_needed
Next best action
set_business_hours
Days since signup
7
Last login (days ago)
1
Reason codes
—

risk = 2×7 + 3×1 + 10×(5−3) = 37 # 2 steps remaining

Why they're stuckactively stuckmerchant side

Engaged but blocked at hours & availability; the precise cause needs the hours_populated_flag signal.

Recommended play · self serve nudge

One-click 'set your store hours to go live' checklist nudge.

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: hours_populated_flag.

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.

Your next onboarding step with Curbside Commons
Hi Pacific Heights Provisions, thanks for getting started on your Curbside Commons onboarding. Your next step is to set your business hours. Reply to this message if you would like a hand.

Claims (each declared claim, verified against the merchant's data):

  • steps_completed = 3→ merchant.steps_completed = 3
  • total_steps = 5→ merchant.total_steps = 5
  • current_blocker_code = business_hours_needed→ merchant.current_blocker_code = business_hours_needed
  • next_best_action = set_business_hours→ merchant.next_best_action = set_business_hours

mode: DETERMINISTIC_RULES · cost: $0.00 · model: stub-deterministic.v1

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.

PASSApproved for the human gate
Guardrail flags: none — clean
Failures: none
Warnings: none

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.

ALL SUPPORTED3/3 prose assertions backed by the data row
  • Your next onboarding step with Curbside Commons. → steps_completed
  • Hi Pacific Heights Provisions, thanks for getting started on your Curbside Commons onboarding. → merchant_name
  • Your next step is to set your business hours. → steps_completed

mode: DETERMINISTIC_JUDGE · model: deterministic-judge · cost: $0.00

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.

GOOD PRACTICE3/3 domain-quality dimensions passed
  • Matched to the merchant's actual blocker — Addresses the 'Hours & availability' 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.

mode: DETERMINISTIC_JUDGE · model: deterministic-domain-judge · cost: $0.00 · advisory — does not change the send decision

6 · Eval / quality

An independent measurement of draft quality across four dimensions — the deep-AI showcase, in human terms.

structurePASS
state-consistencyPASS
policyPASS
no-leakagePASS

4/4 dimensions passing.

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.

idempotency_key: M016:business_hours_needed:blocker_nudge.v1:2026-06-01

8 · Audit trail

Every step of the decision, recorded.

  1. systemTRIAGErisk=37 (Low); blocker=business_hours_needed; engagement=actively_stuck; play=self_serve_nudge
  2. draftDETERMINISTIC_RULESOutreach drafted by the deterministic stub (REPLAY; a recorded real-Gemini run is on the Eval page).
  3. gatekeeperPASS0 failure(s), 0 warning(s).
  4. judgeDETERMINISTIC_JUDGE3/3 prose assertions supported by merchant data; all supported.
  5. domainDETERMINISTIC_JUDGE3/3 domain-quality dimensions passed → good activation practice.
  6. evalPASS4/4 quality dimensions passed.
  7. 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.