Skip to content

How the Context System Works

The user-facing guide for context lives at The Context System. This page covers what happens under the hood—how Aliveo composes Global, Org, and Account context into the effective prose an agent reads, and why the resolution stays fast even as your context tree grows.

Three Stores, One Tree

Context is persisted in three independent stores:

  • Global Context — a single record per organization.
  • Org Context — one record per line of business.
  • Account Context — one record per integration (or group of integrations) within a business.

Each record stores its own natural-language prose, an inheritance flag (whether to compose with the parent), and provenance metadata (who saved it, when). The three layers form a tree: account points to its business, business points to global.

Effective Prose Composition

When Aliveo needs the effective context for a workflow (chat, automation agent, dashboard), it walks the tree from the most specific scope up to the most general:

  1. Read the Account Context record(s) for the in-scope accounts.
  2. If the account record has inheritance on, read the Org Context record for its business.
  3. If the org record has inheritance on, read the Global Context record for the organization.
  4. Compose the three blocks in order: global → org → account.
  5. The resulting effective prose is what downstream agents read.

The composition is order-sensitive: more specific context is appended after broader context, so when an LLM weighs conflicting rules it weighs the more specific one more heavily. Account-level instructions can also explicitly disable inheritance, in which case higher layers are dropped entirely for that account.

Metric-Aware Context Resolution

Effective prose can grow large, especially when global glossaries and per-account exclusions accumulate. Pushing all of it into every LLM prompt would be wasteful—and slow.

Aliveo solves this with metric-aware resolution:

  1. The user’s question is parsed for metric mentions (KPI names, derived measures, business concepts).
  2. A lightweight resolver walks the Data Knowledge Graph and the context tree to identify which fragments are relevant to those metrics—definitions, formulas, exclusions, related tags.
  3. Only the relevant fragments are surfaced into the planning and code-generation prompts.

The same mechanism extends to accounts: when the question implicates only a subset of in-scope accounts, only those accounts’ contexts contribute. This keeps prompts focused and lets you keep growing your context library without hitting token ceilings.

Metric hints

Custom-data columns can carry metric hints—small tags such as revenue, cost, dimension, or date. The resolver uses these hints to bridge raw warehouse columns to the semantic roles your context refers to. For example, a hint of revenue on a column named gross_take lets the resolver answer “revenue” questions even though the column doesn’t literally use that word.

Conflict Detection

When you save context that materially contradicts its parent (e.g. global says “ROAS uses revenue,” your org context redefines it as “gross profit”), the UI raises a context conflict prompt:

  • It shows both blocks side-by-side.
  • It asks you to confirm the override is intentional.
  • The acknowledgment is saved with the record’s provenance so future readers know the conflict was deliberate, not accidental.

This stops accidental redefinitions from silently changing answers.

Cascading Saves

Some changes need to be propagated rather than overridden. For these, the UI provides explicit cascade actions:

  • Cascade global to org — applies a new global statement to specific org-level records that should inherit it as if it were always there.
  • Cascade global / org to account — same idea, applied downward.

Cascading is opt-in—you pick which child records to update—rather than a forced top-down rewrite. The provenance ledger records who triggered the cascade.

Provenance and Audit

Every save records:

  • The user who saved it.
  • The timestamp.
  • A short delta summary (which blocks were added, removed, or changed).

This is what powers the “Last saved by … on …” line you see on each context page and gives compliance teams a trail when context that affects KPIs changes.

Coverage Indicators

Each Account Context page shows a coverage indicator (the “pie”) that estimates how many of the account’s feasible questions, KPIs, and tags are explained by the current effective prose. The indicator is computed by:

  1. Enumerating common question patterns + KPIs registered for the account.
  2. Checking which ones have an associated definition or exclusion in the effective prose.
  3. Returning the ratio.

It is intentionally an estimate—a quick health check, not a guarantee. A higher slice means the AI is less likely to ask clarifying questions when this account is in scope.

How Context Plumbs Into Workflows

When a chat or automation agent session starts:

  1. The scope of the session (active org, selected accounts, selected documents) is resolved.
  2. The Context Resolver produces the effective prose for that scope.
  3. Integration documents (Global, Business, Account) attached to that scope are pulled into the document store.
  4. The Plan Generator receives the resolved context as part of its prompt. From there it flows into code generation, validation, and summarization (see Multi-Agent Orchestration).

If you’ve ever wondered why a chat at the org level returns slightly different framing than the same question scoped to a single account—now you know. Different scope, different effective prose.

Putting It Together

The context system is intentionally layered to mirror how real organizations work: shared vocabulary lives once at the top; teams add their playbooks; individual accounts attach the truly bespoke exceptions. Combined with metric-aware resolution and metric hints on custom data, it lets Aliveo scale context arbitrarily without slowing down or losing precision.