Every answer traces to retrieved evidence in the assistant's memory and is cited back to its source. When the assistant can't find grounded evidence, it says so instead of guessing, and files the gap for the content team to resolve.
GreenHaven Assistant
Product advisor
Real suite from the repo: node --test across chat-core, statewave-core, and server, green on every Node version in CI.
Why Statewave
Grounding is enforced by the memory runtime, not the prompt. Either an answer survives citation validation, or the question becomes a coverage gap the Ops Assistant can resolve.
The model answers from retrieved evidence, and at least one citation ID survives validation.
No evidence, or no citation survives. The assistant says it doesn't know, and the route files a gap.
The model answers strictly from retrieved evidence, and is told to say it doesn't know rather than fill the gap with a guess.
Are your terracotta pots frost-proof?
I don't have grounded information on frost tolerance for that item.
Citation IDs from the model are validated against the evidence actually retrieved. Unknown IDs are dropped and flagged as a warning.
An ungrounded question writes a Coverage gap Episode. The Ops Assistant reads gaps beside the catalog and FAQs, so the content team fixes them from the same UI.
"Which planters suit a rooftop weight limit?"
Nothing is mutated in place. Updating a product or resolving a gap appends a new Episode with the same sourceId, so facts supersede instead of editing history.
How It Works
Source content flows through ingestion into an append-only episode store, compiles into Subjects — the durable memory both assistants read — and is served over the same completion path.
Source content
catalog.json
Product data
service-content.json
FAQs and care guides
Ingestion
ingest job
Dedups by content hash, appends Episodes
StatewaveStore
Episodes → compileSubject
Newest Episode per sourceId, persisted to db.json
Subjects → Assistants
Shopper Assistant
POST /api/chat
Ops Assistant
POST /api/ops/chat
completionFn
LiteLLM · OpenRouter · offline
The closed loop. A question the shopper assistant can't ground becomes an ops:coverage-gaps Episode the Ops Assistant reads as evidence. Resolving it appends another Episode with the same sourceId, superseding the gap instead of editing history.
Ops Console
Every ungrounded question shows up in the Ops console as an open coverage gap, with the shopper's exact wording. Resolving one appends an Episode under the same sourceId, so the next shopper gets a grounded answer.
"Which planters are safe for a rooftop with a weight limit?"
"Do you ship bare-root roses in winter?"
"What's your return window on live plants?"
Data Model
The compiled memory both assistants query. Each is written by exactly one path and read where it makes sense.
| Subject | Written by | Read by |
|---|---|---|
| shop:products | ingestion job (catalog.json) | shopper + ops assistants |
| faq:service | ingestion job (service-content.json) | shopper + ops assistants |
| content:guides | ingestion job (service-content.json, guide docs) | shopper assistant |
| ops:coverage-gaps | shopper route, on an ungrounded answer | ops assistant, /api/ops/gaps |
| shop:conversations | shopper route, every turn | audit trail |
| ops:conversations | ops route, every turn | audit trail |
Developer API
{
"sessionId": "optional, generated if omitted",
"message": "Do you have anything for full shade?",
"readSubjects": ["optional override of the default subjects"],
"retrievalConfig": { "globalMaxTokens": 2000 }
}{
"answer": "...",
"grounded": true,
"citations": [
{ "evidenceId": "S1", "subject": "shop:products",
"sourceId": "PLT-001", "label": "Hosta 'Blue Mouse Ears'" }
],
"warnings": [],
"evidenceCount": 4
}grounded is only true when the model both claims groundedness and at least one citation survives validation against the retrieved evidence.
/api/chat
Shopper-facing grounded chat turn
/api/ops/chat
Ops chat turn, reads coverage gaps too
/api/ops/gaps
Open and resolved coverage gaps
/api/ops/gaps/:sourceId/resolve
Marks a coverage gap resolved
/healthz
Liveness; reports the active completion mode
Boots with a deterministic offline responder, so grounding, citations, and the coverage-gap loop all work with zero setup. Point it at any OpenAI-compatible gateway for real generated answers.
FAQ
Grounding is enforced by the memory runtime rather than by prompt wording. The model answers strictly from evidence retrieved out of compiled Subjects, and the citation IDs it returns are validated against the evidence actually retrieved — unknown IDs are dropped and flagged as a warning. An answer ships only if at least one citation survives validation, so "sounds plausible" is not a passing grade.
It says it does not know, and the route writes the question to an ops:coverage-gaps Episode carrying the shopper’s exact wording. The Ops Assistant reads those gaps beside the catalog and the FAQs, so the content team resolves them from the same console. An unanswerable question becomes a tracked object with an owner, instead of a guess that reaches a customer.
Nothing is mutated in place. Updating a product or resolving a gap appends a new Episode under the same sourceId, and the newest episode per sourceId supersedes the older one at compile time — so facts change while the record of what was true when stays intact. Ingestion deduplicates by content hash, so re-running the job over an unchanged catalog writes nothing.
The same open-source memory runtime this site documents: append-only episodes, compileSubject, and Subjects persisted through StatewaveStore, served over one completion path shared by the shopper and ops assistants. Completions route through LiteLLM or OpenRouter, and an offline mode runs the flow with no provider at all. Its test suite is node --test across chat-core, statewave-core, and server, green on every Node version in CI.
Answers last checked against the Statewave docs and repositories on .
Every answer traced to evidence, every gap filed automatically. Clone the repo and see the whole loop run offline in minutes.