Architecture

`draftAnswer` runs retrieve → ground → answer → guard. Retrieval scores articles by term overlap; grounding takes the top ≤2; the answer is composed from the grounded article bodies (optionally led by the pinned property); the guard decides grounded-vs-escalate by whether any evidence was found. `askConcierge` wraps this to append the guest/assistant turn pair to the persisted conversation.

The app owns `demo_eco_concierge_conversation`, `demo_eco_concierge_message`, and `demo_eco_concierge_ticket`, written through the one typed C1 adapter. It reads shared-core `property` and `booking` and the knowledge corpus (a synthetic mock-read until the C3·25 Knowledge Base CMS ships the real source). It emits `concierge.answered` and `ticket.created`; the latter is the live connection the C2 support inbox consumes. The data invariant holds: owner writes are canonical (`credential_id` NULL); a viewer's turns are credential-scoped, ephemeral, and reset-clearing, and can never clobber a canonical row (setWhere-guarded).

The one metered stage is `draft-answer`. It runs dual-mode: Cloud `claude-haiku-4-5`, cost-capped and fail-closed; OSS recorded as `qwen3:8b (recorded · M4)` at $0 (the recorded-replay set — we never fabricate an un-recorded OSS row). Each metered run writes a `cost_ledger` row plus a `demo_cache` replay marker keyed on (slug · stage · prompt version · mode). Retrieval, grounding and the guard are deterministic ($0). All cost/mode/trace lives only in the dark inspector.

The escalation confirmation is a simulated message in the in-app sent viewer (no real SMTP). The knowledge base is a small synthetic corpus with deterministic retrieval (no production vector store, no proprietary content). No real imagery, no PII, no production prompts appear anywhere.