Why This Matters
Grounding the support assistant on a published, managed knowledge set prevents stale, duplicated prompts and reduces accidental drift from operational reality. Static knowledge should explain stable policy and product context, while operational facts continue to come from live services.Static Knowledge Source of Truth
The source of truth for support-agent static content is:- dashboard-authored and dashboard-published documents in Hono
- served through
GET /api/ai/customer-support/knowledge
compiledPrompt string into the runtime prompt context and use it for stable business context only.
In production, apps/mastra reads this endpoint through the generated @hol/client package using the HOL_HONO Cloudflare service binding as the client fetch transport. Hono still owns the endpoint contract and public-read policy.
The endpoint is public because it only returns guest-facing published content. It must never expose draft content, revision history, internal notes, reservation IDs, payment details, or email delivery states.
Runtime Dynamic Boundary
These domains are operational and must be answered through tools, not static prompt memory:- show schedules
- prices and package offers
- live availability
- menus
- reservations
- payments
- refunds
- email delivery status
Endpoint Surface
| Route | Method | Access | Purpose |
|---|---|---|---|
/api/ai/customer-support/knowledge | GET | Public | Returns only published documents and a deterministic compiledPrompt used by static agent grounding. |
Governance and RBAC
/api/ai/knowledge/*write operations (create/update/publish/archive) areadmin/superuser.staffis read-only for knowledge management and has no write path.- Read access to published knowledge is public.