RoomState
A stateful intake runtime for service businesses: messy customer communication becomes a persistent Room — structured facts with provenance, a checklist of what's still missing, targeted follow-up, and a complete handoff packet.
The demo runs the product's actual runtime — intake runner, acceptance gate, checklist, guardrails, state machine, export packet — vendored at a pinned commit, against an isolated per-run workspace. No account, no email, no signup.
The problem
Service businesses lose work before the work starts: a customer sends a vague request, staff chase the basics, attachments go missing, the lead sits in an inbox and quietly dies. Forms are too rigid for how people actually communicate; email preserves the messages but not the state of the work. Nobody can answer "what do we have, and what's still missing?" without re-reading a thread.
What the system does
RoomState makes the Room — not the conversation — the system of record. Every request becomes a persistent Room holding messages, participants, files, extracted facts with source spans, a requirements checklist derived from a domain pack, explicit workflow state, and an append-only audit trail. AI extracts and drafts inside hard boundaries: a confidence-banded gate decides what may become truth, guardrails decide what may be said, and everything else is deterministic code. When the checklist completes, the business receives a structured intake packet.
The Room is the source of truth
Channels are adapters. A conversation — whatever it arrives through — is a stream of events into one persistent operational object. Not a chatbot with memory: a state machine for business interaction.
WEB FORM ──┐
EMAIL ─────┼──▶ ROOM
PORTAL ────┤ ├─ Facts (with source spans)
SMS/VOICE ─┘ ├─ Checklist (what's still missing)
├─ Files
├─ Participants
├─ Actions (proposed → approved)
├─ Workflow (explicit, named states)
└─ Audit trail (append-only)What exists today
Every claim here is graded from a source-level inspection of the product repository. The categories do not blur: a thing is implemented, demonstrated live, in development, or planned — a stubbed integration is not a production-proven one, and this page becomes more credible as more of the implementation is exposed, not more promotional.
Implemented
The Room runtime: append-only messages, facts with source spans and a proposed → accepted → superseded lifecycle, a checklist derived from a validated Contractor/Roofing domain pack, actions with approval, an 11-state lifecycle enforced by database triggers, an append-only audit trail, web intake and per-Room customer portal surfaces, operator review UI, and a deterministic export packet. ~3,600 tests in the product repository, end-to-end with zero external credentials.
Demonstrated
Everything the working demo shows: the real intake runner extracting facts with provenance, the confidence-banded acceptance gate (including facts it refuses to auto-accept), targeted follow-up that asks only for what's missing, the roofing guardrail refusal, operator review, completion, and the real export packet — with live model calls through this site's shared AI budget, labeled live or mock per call.
In development
Launch itself. The product is feature-complete against stubbed integrations and deliberately paused awaiting operator credential provisioning: Stripe billing, Postmark email (both directions), and Twilio voice with speech pipelines are implemented to the stub seam and one credential flip from live — but none is production-proven with real customers yet, and this page does not count them as such.
Planned
The embeddable website widget (spec only today — the hosted intake page is the built path), additional vertical domain packs beyond roofing and generic lead intake, retention enforcement (the policy is written; the runtime is not), CSV and downstream-system exporters beyond the signed webhook, and a workflow runtime on top of Rooms.
How a request becomes a packet
MESSY MESSAGE → ROOM → FACTS + CHECKLIST → TARGETED FOLLOW-UP → COMPLETE INTAKE → HANDOFF PACKET
What the model owns
Reading prose: proposing facts (with the exact words they came from), scoring whether a conversation is still on topic, and drafting the follow-up question — inside output contracts that are parsed, span-verified, and refused when they overreach. The prompt's confidence rubric is anchored to the acceptance gate's real cutoffs and pinned by a test.
What deterministic code owns
Everything that is allowed to be true: which facts satisfy requirements (only accepted ones), checklist derivation, completion, routing, the state machine, guardrail checks on outbound language, idempotency, the audit trail, and packet generation. No model call decides whether a conversation closes, and no model output mutates state without passing the gate.
Current capabilities
- Messages from any channel are events attached to one persistent Room — web form, portal chat and email are adapters, not the state
- AI-extracted facts carry the exact source words and character spans they came from, verified against the message before they can persist
- A confidence-banded gate governs acceptance: high-confidence statements auto-accept, mid-band values are echoed back for confirmation, uncertain inferences wait for a human — with identity and field-meaning checks on top
- The intake checklist derives from a validated domain pack (Contractor/Roofing today), so follow-ups ask only for what is genuinely missing
- Outbound drafts pass pack guardrails before they can become actions — no coverage claims, no damage diagnoses, no promises the business didn't make
- Every state transition is enforced by the database's own lifecycle machine and recorded in an append-only audit trail; completed Rooms export a deterministic, leak-proof handoff packet
Limitations, stated plainly
- Not yet launched: no production customers, no self-serve service. The product's own focus document says the next milestone is operator action, not code.
- External integrations (Stripe, Postmark, Twilio voice, Supabase storage) are implemented against stub seams and are not production-proven; the product refuses to boot in production with mocks unless explicitly overridden.
- Two domain packs exist — Contractor/Roofing (validated) and generic lead intake. No other vertical is claimed.
- The product's live-model path is implemented for OpenAI; the AiAdapter interface is provider-agnostic, and this site's demo supplies its own gateway adapter behind that interface — the demo is the first Anthropic-backed run, and it is labeled as the demo's adapter, not the product's.
- Retention is a written policy, not yet a runtime. The public demo enforces its own 24-hour expiry with a purge sweep.
Technical shape
A TypeScript monorepo: a zero-dependency core (types, branded ids, the intake state machine), domain packs as pure configuration, a raw-SQL Postgres layer whose triggers enforce append-only history and legal status transitions at the database itself, an AI package with no provider SDK imports (lint-enforced) driven through an injected adapter interface, and dual PGlite/Postgres support that runs the full test suite with zero infrastructure. The public demo vendors those packages at a pinned, hash-manifested commit with a CI tamper check; each demo run is a fresh workspace in a dedicated database, isolated by the product's own tenancy fence under this site's run-token model, spending from the site-wide daily AI budget.
This product is in active development — feature-complete against stubbed integrations and deliberately paused ahead of launch. The demonstration is real: it executes the product's actual runtime. The service is not yet shipped, and this page does not pretend otherwise.