Intelligence engine

Run governed natural-language analytics using facts-grounded responses.

Last updated:

The Intelligence Engine follows one strict split:

  • Facts = truth (deterministic operational data)
  • Model = interpretation (summaries, prioritisation, next-step guidance)

For the full end-user capability list in Eden, see Eden capabilities.

User-facing access

All Intelligence access requires a signed-in ChannelWeave account.

Naming

Eden names the user-facing assistant and help experience. App copy uses the same name users see in buttons and page-help entry points; the full-page Eden view lives at /chat.

Request lifecycle (high level)

  1. Validate request shape and bounds.
  2. Resolve the signed-in workspace.
  3. Resolve typed contextual help against the exact current public guide when a page-help entry point supplied one. Known page help goes directly to a guide-grounded answer and does not use intent classification.
  4. Otherwise, try deterministic intent routing.
  5. If the deterministic router misses, run one local structured intent classifier pass. The classifier chooses only an allowlisted intent and slots; it does not generate facts or answer text. Relative calendar follow-ups and requests to prioritise operational work have explicit typed intents.
  6. Gather deterministic facts for the recognised question.
  7. Return either:
    • A direct fact answer (for explicit factual prompts), or
    • A model-composed answer grounded in those facts.
  8. Persist audit metadata for traceability.

Response behaviour

  • If required facts are unavailable, Eden returns an explicit uncertainty note.
  • If model generation fails, Eden returns a safe deterministic fallback where possible.
  • Eden links to in-app pages are rendered as safe clickable links.
  • User-facing wording is normalised to British English.
  • Today, yesterday, and tomorrow date questions are answered deterministically from the Intelligence Engine clock in the browser's validated IANA time zone. They bypass page-help grounding, operational intent classification, and answer generation when the wording contains a clear calendar cue. Bounded conversation follow-ups may use the classifier only to resolve the relative date; the answer still comes from the clock.
  • High-confidence operational planning prompts route directly, including from page help; broader natural wording is classified separately from status recaps. Eden loads the tenant-scoped daily fact pack, applies a fixed operational priority order, and returns at most three read-only steps. The model does not invent the plan and Eden does not change any records.
  • Inbox reply assistance uses governed draft generation. Buyer and seller conversation bodies are treated as untrusted context; Eden uses them only to draft the reply and must not follow instructions embedded inside those bodies.
  • Custom insight rule questions use saved rule state, finding history, and template-specific evidence.
  • Custom insight facts are read-only from Eden’s point of view.
  • Daily operations brief prompts such as How did it go today? are handled deterministically from approved account data covering sales, fulfilment, stock, channel/sync health, Inbox, warehouse movement, and custom insight state.
  • Natural operational phrasing that misses the deterministic router can be classified locally into an allowlisted intent. The classifier output is validated before use, and any invalid or unsupported classification falls back to the governed model-assisted path. A how-to classification without a valid allowlisted guide key is rejected; Eden never substitutes a default guide.
  • Page-help answers use the exact server-resolved guide selected by the current app page. The browser cannot supply arbitrary files or external URLs, and Eden removes unrelated generated links before returning the canonical guide link.
  • Follow-up answers receive at most the six most recent user/assistant messages. Saved history is loaded server-side for the signed-in user and workspace; unsaved modal history is validated and bounded before it is forwarded.
  • Approved Eden knowledge is retrieved from customer-specific approved guidance. Unrelated recent guidance is not injected just because it is fresh.
  • Common paraphrases such as “running low”, “need reordering”, “what broke on Shopify sync”, and “which stock groups make the most money” route to the same deterministic answers, as do seller-style questions such as “what’s waiting to be posted?” and “any customers waiting on me?”.

Local-first model handling

Eden is local-first. Model-assisted interpretation runs in the ChannelWeave operating environment rather than requiring a hosted model API for the current operating plan.

Model-assisted answers follow Eden’s warm precision tone standard: corporate-grade, calm, human, concise, British English, and free of novelty-chatbot phrasing.

The local Eden wrapper uses an 8,192-token active context so bounded conversation history, system instructions, and approved fact packets fit without relaxing the application-level history limits.

Data safety

  • Responses use only facts from the signed-in workspace.
  • Browser users do not choose or override account identity.
  • The daily operations brief uses only reported facts. Eden can prioritise the next focus from those facts, but it must not infer performance where the fact pack has no activity.
  • Operational plans contain at most three steps, use the same reported daily facts, remain read-only, and cannot authorise or execute mutations.
  • Knowledge retrieval is customer-specific and approved-only.
  • Saved conversation context is scoped by both customer_id and the signed-in user; browser-supplied conversation IDs cannot cross that boundary.
  • Reported operational facts remain authoritative. Retrieved knowledge can guide safe wording and policy context, but it must not override reported metrics.
  • The assistant does not execute arbitrary user-authored data queries.