The launch gate: one real verified completion
The goal is a real booking completed through the full path, supported by evidence and explicit customer authorization. A sample record, synthetic cancellation cycle, or published website does not count as that completion.
Remove friction at each handoff
| Handoff | Intended acceptance criterion | Preview status |
|---|---|---|
| Spec reader → record | A complete template and local checks let a developer publish in under an hour. | Starter JSON and browser preflight available. Time target not yet measured. |
| Record → L2 | Safe, consented probes and validation run automatically, with no manual application handoff. | Planned; not a claim of instant verification. |
| L2 → L3 | Reusable vertical policies and authority integrations establish required credentials and synthetic success. | Planned. |
| L2 → indexed listing | Admission is event-driven after eligibility, with no duplicate form. | Planned. |
| Agent query → booking | One real agent integration finds a qualified endpoint and completes an authorized booking. | Planned. |
| Booking → completion | Independently reconcile service fulfillment and disputes. | Planned. |
| Outcomes → adoption | Publish verified results and use them to resolve the slowest transition. | No operational metrics yet. |
Four phases
Phase 1 — First reference and tools. Publish the draft and preflight. Evaluate StainMyDeck, LegalBarry, and MakeupHeat as reference candidates; validate home, legal, and beauty requirements before claiming L3. Complete the first real verified booking.
Phase 2 — One dense pocket. Concentrate supply in Spokane and connect one real agent framework or MCP integration. Prove useful local coverage before broad geographic expansion.
Phase 3 — Public operations. Open verification and the index only after admission, evidence expiry, suspension, safe retries, appeals, and outcome reconciliation work with real inventory.
Phase 4 — Evidence-based data products. Consider aggregate demand and pricing reports only once permissioned, sufficiently representative operational data exists. Protect confidentiality and disclose sampling limits.
Measure the constraint
The primary outcome is verified booking completion rate: independently confirmed completions divided by eligible accepted bookings in a declared observation window. Define pending jobs, cancellations, refunds, disputes, and exclusions before reporting a number.
The second metric is time from discovering the specification to the first verified completed booking. Track conversion, elapsed time, failure reasons, human effort, and marginal cost at every handoff. The slowest material handoff should determine the next work, not the most attractive feature.
No conversion analytics or live outcome collection is installed in this preview. Measurement must be implemented with an explicit event contract and appropriate consent before operational collection begins.
Make each turn cheaper
Reuse jurisdiction integrations and vertical check templates. Separate one-time integration effort from recurring per-endpoint cost. Automate safe checks and renewal handling. Keep L1 free and L2 accessible; price higher tiers against demonstrated benefit. Consider booking fees only after the value is proven.
Protect earned trust
Reconcile outcomes independently, deduplicate bookings, bind evidence to the endpoint and transaction, and keep an auditable correction trail. Self-reported success must not improve ranking. Paid placement cannot outrank earned standing. Suspension and stale-evidence removal must propagate to lookup, badges, attestations, and index eligibility.
Keep the specification open and implementable by competitors. Use lightweight extension RFCs with reference implementations and public tests. Favor additive changes and document any migration explicitly.
These are rollout requirements, not assertions that the operational loop already exists.