← Choice Health 2026-07-11-first-dollar-prioritization.md raw .md

RIFF First-Dollar Prioritization

Date: 2026-07-11
Decision surface: /riff-priority.html
Objective: reach one paid, reliable plumbing appointment-booking pilot while building the system that makes every later flow cheaper and safer to produce.

Executive Decision

RIFF should not operate ten product initiatives in parallel. The immediate offer is:

A plumbing phone line that answers, qualifies the service request, offers real calendar availability, and books the caller's selected appointment.

The compounding platform investment is one measured release loop:

call -> outcome and cost -> synchronized replay -> marked defect
     -> regression fixture -> M3 candidate proof -> M1 promotion

Everything in the near-term portfolio must either sell that offer or strengthen that loop.

Priority Order

The workbench treats prioritization as a fixed 100-point allocation with a protected 0.1-point floor for every criterion. Increasing one criterion proportionally reduces the discretionary points on the other four; decreasing it returns those points in the same proportions. With five criteria the effective range is 0.1 to 99.6: moving one fully right produces [0.1, 99.6, 0.1, 0.1, 0.1], and reducing it to 80 produces [5, 80, 5, 5, 5]. The floor makes a criterion negligible without creating the undefined-ratio behavior of absolute zero.

Editable principle prompts

Each principle name in /riff-priority.html opens the exact prompt used to score the work queue. Saving a changed prompt marks that principle's existing scores stale. Save & re-score queue sends the edited prompt and all current initiative evidence through one bounded structured-output model call; the browser replaces that principle's score column only when every initiative ID appears exactly once with an integer score from 1 to 5.

Re-scoring is disabled by default. To enable it on the local RIFF server:

RIFF_PRIORITY_RESCORE_ENABLED=1 python -m riff.web_server

The default evaluator is gemini-3.1-flash-lite; override it with RIFF_PRIORITY_MODEL. Identical prompt-and-queue requests are cached by model. The endpoint allows six uncached runs per minute, reserves at most 1,600 output tokens per call, and defaults to 24 runs or 100,000 reserved tokens per UTC day. Those limits can be lowered with RIFF_PRIORITY_MAX_RUNS_PER_MINUTE, RIFF_PRIORITY_MAX_RUNS_PER_DAY, and RIFF_PRIORITY_MAX_TOKENS_PER_DAY.

The row reports the resolved model, token count, and cache status. Dollar cost remains unknown, not zero, until RIFF has a current provider-pricing ledger. The model supplies candidate scores and reasons; weighted totals, ordering, validation, and the decision to act remain deterministic and operator-owned.

1. Cost ledger and unit economics

Cost truth is a prerequisite for pricing, margin, model selection, and daily risk control. Persist normalized usage for model input/output, realtime audio, transcription, telephony, storage, and non-call development jobs. A missing price or provider measurement must render as unknown, never $0.

The first useful surface is small:

The current repository has cost estimators and local counters, but they are not yet one authoritative cross-provider ledger. T-M3-COST-WIRING-012 in the hardening backlog already identifies this as P0.

2. Replay-to-regression reliability loop

The remaining caller-visible flow bugs block charging more directly than missing product breadth. Continue improving capture and the State Program Debugger, but define completion as a closed defect loop rather than a better visualization:

  1. mark the exact audible problem;
  2. preserve aligned audio, transcript, state, tool, and variable evidence;
  3. reproduce it with a deterministic fixture;
  4. fix the generator or runtime ownership boundary;
  5. prove the fixture fails before and passes after;
  6. verify on M3 before promotion.

This is the highest-leverage AI surface. Codex and Claude can navigate the same artifact, compare repeated visits, generate adversarial pattern families, and propose regression tests without re-reading entire call logs.

3. Calendar booking contract

Booking is the outcome that makes the initial plumbing product valuable. The deterministic contract must own offered slots, selected slot ID, timezone, duration, corrections, provider idempotency, final event ID, and confirmation evidence. AI may interpret a phrase such as "tomorrow afternoon," but it must not invent availability or own the final calendar write.

Before a paid pilot, prove:

4. Sellable plumbing pilot

Publish one literal plumbing offer and provision one line. The landing page should show the product, the phone number, the booking outcome, a narrow pilot promise, and one conversion action. It should not advertise a general AI platform or several unfinished verticals.

Use manual operations deliberately:

Manual billing is enough to collect the first dollar. Automated billing is not a launch prerequisite.

5. M3/M1 promotion and failover

M3 is the candidate lane and M1 is the stable lane. Before paid traffic, finish the minimum safe release contract: exact clean SHA, node identity, health, drain state, targetable test call, active-call ownership, promotion evidence, and rollback. Elaborate active-active failover should not displace the plumbing happy path, but a known stable fallback is required once a customer depends on the line.

6. Billing and automated provisioning

After one customer accepts the offer and price, automate the repeated parts: account, plan, line provisioning, entitlement, usage statement, invoice, suspension, and teardown. Money movement and plan enforcement remain deterministic. AI can draft explanations or flag anomalies, but it cannot be the billing ledger.

7. Prerecorded DTMF Starter tier

This is the strongest adjacent product idea. AI can author and test the menu offline while production uses prerecorded prompts and deterministic keypad routing. That produces low variable cost, a degraded-mode fallback, and an entry plan for customers who do not yet need natural booking.

It must reuse RIFF's compiler, asset validation, telemetry, and account model. Do not build it as a second platform.

8. Intentional voice work inbox

The internal workflow opportunity is real, but begin with explicit recording sessions rather than ambient forever-recording. Each session should produce retained audio, timestamped transcription, editable decisions, proposed tasks, and links from every summary item back to the exact audio span. Human review occurs before tasks are dispatched.

This is a leverage experiment, not part of the first paid plumbing offer.

9. Domain RAG

RAG begins only when a real customer supplies an owned corpus and repeated questions. The contract requires corpus scope, authorization, freshness, citations, evaluation questions, and a deterministic escape to booking or a person. It must never block the core appointment workflow.

10. Live bulletization and additional vertical pages

Live transcription-to-bullets is a separate product hypothesis with a different user and quality bar. Prototype it from recorded voice-inbox sessions before building realtime infrastructure.

Electrical and law landing pages are inexpensive to generate but costly in focus. Clone the plumbing acquisition and onboarding pattern only after its conversion path is measured.

Product Ladder

Tier Runtime Customer outcome Timing
Starter Prerecorded audio and DTMF Route calls and capture a structured message After core cost model
Core Natural voice plus deterministic tools Qualify and book a plumbing appointment First paid pilot
Knowledge Core plus source-backed RAG Answer approved domain questions without blocking booking After customer corpus exists

Cost Guardrails

The interactive workbench contains a planning calculator. Its values are assumptions, not billing truth. The production cost ledger must support:

call_variable_cost = model + realtime_audio + transcription + telephony + storage
monthly_operating_cost = sum(call_variable_cost) + attributable_fixed_cost
price_floor_per_account = monthly_operating_cost / accounts / (1 - target_margin)

Daily controls should include a warning threshold, a reviewed hard ceiling, and explicit behavior when the ceiling is reached. A ceiling must not terminate an active emergency call or corrupt an in-progress calendar write.

AI Allocation

Use lower-cost models for bounded, verifiable expansion:

Use stronger models selectively for:

Keep these deterministic:

Thirty-Day Gates

Gate 1: Cost truth

Gate 2: Sellable path

Gate 3: First customer

Gate 4: Safe operation

Stop Rules