Schema and Routing

Documentation schema, intent taxonomy, record format, and retrieval chunking rules.

Required 20-field documentation schema

Maintain each Lexul feature record using these fields so the chatbot can retrieve and answer consistently.

#	Documentation detail	How chatbot uses it
1	Feature name and aliases	Official Lexul name plus phrases customers may use.
2	Plain-English description	Short explanation the chatbot can reuse.
3	Problem it solves	Customer pain point or operational issue.
4	Primary use cases	Common business workflows and industries.
5	When to configure	Conditions where the feature should be set up.
6	When not to configure	Scenarios where another workflow is better.
7	Required setup information	Customer information or data needed first.
8	Dependencies and related features	Records/modules that must exist before setup.
9	Step-by-step setup instructions	Where to go, what to set, and how to test.
10	Role-based workflow	Admin, dispatcher, technician, foreman, accounting behavior.
11	Configuration scenarios	If customer does X, configure Y guidance.
12	Customer questions AI should ask	Discovery questions before exact instructions.
13	Common questions and approved answers	Reusable customer-facing responses.
14	Known limitations	Feature boundaries and non-promises.
15	Troubleshooting guidance	Symptoms, likely causes, and first checks.
16	Permissions and visibility	Who can view, create, edit, approve, sync, or export.
17	Data fields and examples	Fields, example values, statuses, types, and records.
18	Integration behavior	QuickBooks or external integration behavior and source-of-truth.
19	Example business scenarios	Realistic vertical examples.
20	Escalation rules	When to hand off to Lexul support or an admin.

Use these intent labels in retrieval metadata and evaluation sets.

Intent	Trigger pattern	Bot response objective
how_to_setup	User asks how to configure a feature.	Return setup prerequisites, steps, and test action.
when_to_use	User asks whether a feature fits their workflow.	Explain use cases, when not to use, and recommended configuration.
workflow_design	User describes a business scenario.	Map scenario to Lexul features and ask targeted discovery questions.
troubleshooting	User reports something missing, not visible, not syncing, or not working.	Confirm role, status, sync/version, record state, permissions, then escalate if unresolved.
quickbooks_sync	User asks about QuickBooks Online/Desktop data flow.	Clarify QBO vs QBD, source-of-truth, what syncs, and what to avoid.
permissions_visibility	User asks why someone can or cannot see/edit something.	Check role, status, assignment, inherited documents, and module permissions.
field_user_how_to	Technician/foreman asks what to do in the field.	Give role-specific mobile workflow steps and avoid admin-only setup instructions.
billing_invoice	User asks how to quote, invoice, hold, summarize, export, or sync.	Clarify invoice stage, customer/asset, QuickBooks connection, and whether it has already been sent/synced.
export_report	User asks to download XLSX/PDF or view reports.	Explain available export/report workflows and role limitations.
escalation_needed	User asks beyond documented behavior or reports a data issue.	Give safe next checks and hand off to support/admin.

Each sub-feature record below follows this format. Preserve field names during ingestion.

Field	Purpose
record_id	Stable ID for retrieval and troubleshooting.
feature / sub_feature	The topic the user is asking about.
primary_intents	Intent labels this record should match.
sample_user_utterances	Example customer wording for model training.
entities_to_extract	Variables the bot should identify before answering.
approved_answer_basis	Short response foundation the bot can reuse.
configure_when	When the bot should recommend this feature.
ask_before_answering	Clarifying question or context to collect.
dependencies	Related setup that must exist first.
role_workflow	How different customer roles use the feature.
permissions_visibility	Role and access-control considerations.
known_limits_guardrails	Boundaries that prevent overpromising.
escalation_rule	When to route to support/admin.
source_urls	Source articles/pages to cite or retrieve from.

Chunk one ### Knowledge Record: section per vector record or retrieval unit.
Keep the preceding feature group heading as metadata, not as the primary chunk.
Store record_id as the stable retrieval key.
Store primary_intents and entities_to_extract as filterable metadata if your retrieval layer supports it.
Store source_urls as source metadata and expose them to the agent for citation or support handoff.
Do not split a single knowledge record across multiple chunks unless your chunker preserves parent/child relationships.