DataFab Dialog

Version: 2.3 Last Updated: May 2026

Component Overview

Dialog is the platform’s conversational layer — the analyst-facing surface that turns the rest of DataFab into something a person can talk to. Conversations are not free-form: every dialog session is governed by a playbook that declares the intents the dialog can serve, the tools each intent may invoke, the turn structure, and the data the dialog is allowed to introspect. The Dialog is context-aware (it understands the user, tenant, current case / alert / client, active operational mode, and the conversation so far) and widget-capable (it can render structured Studio Widgets in-line as part of its response, not just text).

Dialog is a peer to Studio, Knowledge Fabric, Graph Operations, and the AI/LLM Layer — not a sub-feature of any single one. Dialog uses Studio (Tools, Widgets, Tool Authorization), the Knowledge Fabric (Search Sessions, Session Graph), Graph Operations (chain traces, rule registries), the LLM Gateway (model invocations and provenance), and Schema Management (slot validation, schema introspection); but it owns the conversational contract on top of all of them.

Core Capabilities:

Capability	Description
Playbook-Based Communication	Tenant-scoped, version-controlled playbooks declaring intents, slots, tool plans, persona, and guardrails
Context-Awareness	Per-turn awareness of user, tenant, role, active operational mode, current entity / case / alert / client, and conversation history
Tool Plan Execution	Bound tool catalog (DDAs, MCP, External APIs, Scripts, Text-to-Cypher, Search) executed under Tool Authorization
Widget Rendering	Inline rendering of Studio Widget Types (SYSTEM and OUTPUT) in dialog and canvas views
System Self-Awareness	Introspection of platform components, rules, traces, configuration, schemas, and service health from inside the conversation
Memory Policy	Governed retention of turn / session / cross-session context, with explicit tenant isolation
Operational Mode Binding	Dialog behaviour gated by Studio operational modes (0–4)
Audit & Provenance	Per-turn auditable record with intent, slots, tool calls, response category, and LLM provenance

Architecture Overview

┌─────────────────────────────────────────────────────────────────────┐
│                       DIALOG ARCHITECTURE                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  CONVERSATION SURFACE                         │  │
│  │  Dialog View │ Canvas View │ Widget Streams                   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  PLAYBOOK ENGINE                              │  │
│  │  Intent Match │ Slot Filling │ Memory Policy │ Persona        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  CONTEXT FABRIC                               │  │
│  │  User & Role │ Tenant │ Operational Mode │ Active Entity      │  │
│  │  Conversation History │ Search Session │ Session Graph        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  TOOL PLAN RUNNER                             │  │
│  │  Tool Authorization Gate │ Mode Gate │ Schema Bounding        │  │
│  │  Sequential / Parallel Tool Invocations                       │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                              │                                      │
│         ┌────────────────────┼────────────────────┐                 │
│         ▼                    ▼                    ▼                 │
│  ┌──────────────┐  ┌──────────────────┐  ┌─────────────────────┐    │
│  │ Studio       │  │ Self-Awareness   │  │ Knowledge / Graph   │    │
│  │ Tools +      │  │ Introspection    │  │ DDA, MCP, Search,   │    │
│  │ Widgets      │  │ Tools            │  │ Text-to-Cypher,     │    │
│  │              │  │                  │  │ Chain Trace         │    │
│  └──────────────┘  └──────────────────┘  └─────────────────────┘    │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  RESPONSE RENDERER                            │  │
│  │  Text │ Tables │ Cards │ Widgets │ Trace Walkthroughs         │  │
│  │  Persona Enforcement │ Guardrail Check                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                  AUDIT WRITER                                 │  │
│  │  Per-turn audit record │ LLM provenance │ Tool-call audit     │  │
│  └───────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘

The Dialog component coordinates four sub-systems: the Playbook Engine (matches intents and fills slots), the Context Fabric (assembles per-turn context), the Tool Plan Runner (executes the bound tool plan under authorization and mode gates), and the Response Renderer (assembles the assistant message, including any widgets to render). All four sub-systems are bound by the Audit Writer.

Playbook-Based Communication

A playbook is a reusable, version-controlled asset that defines a coherent conversation surface (e.g., “Transaction Monitoring Analyst”, “Car Finance Underwriter”, “Compliance Officer”). Playbooks are domain-bound and tenant-scoped.

Playbook Concepts

Concept	Description
Playbook	Top-level dialog asset that defines a coherent conversation surface
Intent	A named handler for a class of analyst questions (e.g., “explain a rule”, “show alerts for entity”, “summarise a chain run”)
Turn Template	The structured prompt + tool-binding configuration that runs when an intent is matched
Tool Binding	The set of Studio Tools (DDAs, MCP Integrations, External APIs, Scripts) and Self-Awareness tools the playbook may invoke
Slot	A typed parameter the dialog elicits or extracts (e.g., entity ID, rule key, date range)
Guardrail	Constraints on what the dialog may say or do (refuse-list, escalation triggers, off-topic redirects)
Persona	Tone, format preferences, and language settings for responses
Memory Policy	Rules governing what the dialog remembers across turns and across sessions
Widget Binding	The Studio Widget Types the playbook is permitted to render

Playbook Structure

Field	Description
Name	Stable playbook identifier
Description	Purpose and intended audience
Domain	Bound business domain (controls schemas, datasets, and DDAs the playbook may reference)
Intents	Ordered list of intent definitions with patterns, slots, and tool bindings
Tools	Allowed tool catalog for this playbook (subject to Tool Authorization)
Widgets	Allowed Studio Widget Types renderable by this playbook
Persona	Voice, tone, length defaults
Guardrails	Refuse-list, escalation triggers, content filters
Operational Mode Binding	Which operational modes (0–4) the playbook is permitted in
Stage	Lifecycle stage (DRAFT or PUBLISHED)
State	Operational state (ACTIVE or INACTIVE)

Intent Definition

Field	Description
Intent Key	Stable identifier (e.g., `explain_rule`, `list_alerts`, `summarise_alert`)
Trigger Hints	Natural-language patterns or examples that orient the agent toward this intent
Required Slots	Slots the agent must fill before invoking tools (with type and validation)
Optional Slots	Slots that refine the response if available
Tool Plan	Ordered tool invocations (DDAs, MCP, APIs, Text-to-Cypher, Search, Self-Awareness tools)
Response Template	Structured response shape (text, table, card, widget, trace walkthrough, mixed)
Widget Renderings	Optional Widget Types this intent may surface
Risk Class	Low / Medium / High — drives whether the intent requires a Human-in-the-Loop gate
Audit Class	What is logged for this intent (input, slots, tool calls, output)

Turn Lifecycle

┌─────────────────────────────────────────────────────────────────┐
│                    DIALOG TURN LIFECYCLE                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  User Message                                                   │
│        │                                                        │
│        ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ Context Assemble │  User, tenant, role, mode, active entity, │
│  │                  │  conversation history, session graph      │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Intent Match    │  Pattern + LLM-assisted classification    │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Slot Filling    │  Required slots elicited or extracted     │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Authorization   │  Tool Authorization, Operational Mode     │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Tool Plan Run   │  Sequential or parallel tool invocations  │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Response Render │  Text + tables + widgets; persona applied │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Guardrail Check │  Refuse-list, escalation triggers         │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │  Audit Write     │  Per-intent audit class                   │
│  └────────┬─────────┘                                           │
│           ▼                                                     │
│  Assistant Message (Text + Widgets)                             │
└─────────────────────────────────────────────────────────────────┘

Playbook Communication Patterns

Pattern	Description	Example
Lookup	Single tool call returning structured data	“Show me alerts for entity X”
Explain	Tool call returning metadata followed by structured rendering	“How does TM_TRX_007 work?”
Walkthrough	Multi-tool plan that reconstructs a decision narrative	“Why did this alert score 74?”
Drill-down	Stepwise narrowing of a result set across turns (uses Context-Awareness)	“Show high-risk alerts → only Q1 → only those with sanctions hits”
What-if	Sandboxed re-evaluation under user-supplied parameter overrides (Mode 1+)	“What would TM_RSK_001 produce if domain weights were equal?”
Widget Surface	Render a Studio Widget inline as part of the response	“Show me the case dashboard for client X”
Escalate	Hand-off to a human reviewer or to a Chain of Agents step	“Open a case for this entity”

Tool Plan Execution

Aspect	Behavior
Tool Catalog	Restricted to the playbook’s bound tools; ad-hoc tool calls are rejected
Authorization	Each tool call checked against Tool Authorization (per-user, per-tenant)
Parameter Binding	Slot values bound to tool parameters; unbound parameters default or fail-closed
Result Caching	Tool results cached within the turn; deduplication across an intent’s plan
Timeout	Per-tool-call timeout enforced; partial results surfaced when permitted
Failure Handling	Tool failure produces a graceful response with reason; no silent fall-through

Memory Policy

Scope	Description	Default
Turn	Slots and tool results available within a single turn	Always retained
Session	Conversation history within a single session	Retained subject to TTL
Session Graph	Accumulated entities and relationships explored in this session (see 13-Graph-RAG)	Retained subject to session security
Cross-Session	Information persisted across sessions for the same user	Off by default; explicit opt-in per playbook
Cross-User	Information shared across users	Forbidden — never permitted

Playbook Lifecycle

Operation	Description
Create	Define playbook with domain, intents, tool bindings, widget bindings, persona, guardrails
Draft	Save as draft for editing and testing
Test	Run scripted conversation suites in sandbox (Studio Testing & Debugging Framework)
Apply Draft	Promote draft to active definition
Publish	Move stage from DRAFT to PUBLISHED; make available to users
Configure	Per-tenant overrides for slots, persona, guardrails
Deactivate	Set state to INACTIVE; existing sessions complete; new sessions blocked
Version	Immutable published versions; rollback supported

Playbook Security Controls

Control	Implementation
Tool Authorization	Every intent’s tool plan is validated against the user’s Tool Authorization policy
Operational Mode Gating	Intents may declare a minimum operational mode; out-of-mode invocation is rejected
Schema Bounding	Slot validation and tool parameters are bound by the registered schema for the domain
Refuse-List Enforcement	Configurable refuse-list applied at intent-match and at response-render
Escalation Triggers	High-risk intents auto-escalate to Human-in-the-Loop gates
Prompt Injection Defense	User text is escaped and bracketed in prompts; system prompts are immutable per turn
Tenant Isolation	Playbooks, slots, and memory are tenant-scoped; cross-tenant references rejected
Audit Logging	Every turn produces an auditable record per the intent’s audit class

Playbook Audit Trail

Event	Logged Data	Retention
Playbook Created	Definition, author, timestamp	2 years
Playbook Modified	Diff, modifier, justification	2 years
Playbook Published	Version, approver, effective date	2 years
Intent Matched	Intent key, slots filled, user, session, timestamp	1 year
Tool Plan Executed	Tools invoked, parameters, durations	1 year
Widget Rendered	Widget Type, parameters, recipient	1 year
Refusal	Trigger reason, intent, user, session	1 year
Escalation	Escalation reason, intent, target reviewer	2 years

Context-Awareness

The Dialog is context-aware: every turn is interpreted against an assembled per-turn context. The dialog is not a stateless prompt-in / response-out function; it knows who the user is, what tenant they are working in, what they were just looking at, what mode the platform is operating in, and what the conversation has already established.

Context Layers

Layer	Source	Examples
Identity Context	Authentication & RBAC	User ID, role, tenant, organisation, permissions
Operational Context	Studio Operational Modes	Current mode (0–4), HITL gates currently in force
Application Context	Active surface in the UI	Current case / alert / client / application / decision under review
Conversation Context	Session memory + playbook memory policy	Previous turns, slots already filled, decisions narrated
Knowledge Context	Search Sessions + Session Graph (see Graph RAG)	Entities and relationships accumulated across the session
Run Context	Chain trace + DDA execution log (08, 04)	Persisted analyses the user is currently exploring
Schema Context	Schema Registry (09)	Active schemas for the user’s domain
Service Context	Health Registry	Availability of upstream services (graph DB, screening, OSINT)

Context Assembly

Context is assembled at the start of every turn, before intent match, so that intent classification and slot extraction can use the active surface as a default. This is what allows:

Pattern	How Context-Awareness Helps
Pronoun resolution	“Why was this alert escalated?” → resolves `alert_id` from the application surface
Drill-down	“Now show me only those with sanctions hits” → uses the previous result set, not a fresh search
Implicit defaults	“Show me high-risk cases” → defaults `tenant`, `domain`, `time-range`, `cohort` from the active surface and prior turns
Reactive guardrails	If the user’s role drops mid-session (e.g., privileges revoked), the next turn re-evaluates authorization with the new role
Mode-sensitive replies	Same intent answers differently in Mode 1 (suggest only) versus Mode 3 (autonomous with escalation)

Context Security Controls

Control	Implementation
Identity Re-Resolution	Identity context resolved per-turn; revoked permissions take effect immediately
Tenant Confinement	Application, conversation, knowledge, and run context are all tenant-scoped; cross-tenant context cannot leak
Sensitive-Field Masking	Application context fields are filtered by Field-Level Masking (see Knowledge Fabric › Data Protection)
Stale-Context Detection	Context older than configured TTL is invalidated and re-assembled
Memory Opt-In	Cross-session memory is off by default and gated by an explicit playbook opt-in
Audit	The context summary used for each turn is logged for replay in audit

System Self-Awareness

System Self-Awareness is the Dialog’s ability to communicate about its own components, configuration, and runtime state. It enables analysts to ask the conversation directly about the rules that ran, the chain trace of a decision, the tools available to them, the schemas in scope, the playbook governing the current dialog, and the state of upstream services — without leaving the conversation.

Self-Awareness is implemented as a curated set of introspection tools registered with the dialog playbook. Tools are subject to the same Tool Authorization model as any other tool; analysts only see what their role permits.

Self-Awareness Capabilities

Capability	Description
Component Introspection	Describe the platform components currently active in the user’s tenant (Knowledge Fabric sources, Studio assets, Utilities, Graph Operations chains)
Asset Catalog Lookup	Enumerate DDAs, Widgets, Datasets, Utilities, Chains, Playbooks visible to the user
Rule Catalog Lookup	List rules in a chain or rule engine with metadata, scoring weights, and enabled status
Rule Deep Dive	Return full metadata, dependencies, and audit history for a single rule key
Configuration Introspection	Read effective scoring config, decision thresholds, domain weights for the user’s tenant
Chain Trace Explanation	Walk the chain trace of a specific analysis, explaining which rules fired and why
Schema Introspection	Describe the schemas bound to the current domain and their entity / relationship structure
Playbook Introspection	Describe the active playbook, available intents, and current tool authorization scope
Service Health	Report status of upstream services the dialog depends on (graph DB, OSINT, Text-to-Cypher, screening)
Capability Discovery	Answer “what can you do?” by enumerating intents the user is authorised for in this playbook

Introspection Tool Categories

Category	Example Tools	Typical Intents
Catalog	`list_assets`, `list_chains`, `list_playbooks`, `list_utilities`	“What utilities are available to me?”
Rule Awareness	`list_rules`, `rule_deep_dive`, `rule_dependencies`	“Show me all rules in the transaction monitoring chain”
Run Awareness	`get_chain_trace`, `explain_decision`, `show_evidence`	“Why was this alert escalated?”
Config Awareness	`get_scoring_config`, `get_thresholds`, `get_domain_weights`	“What does a score of 75 mean here?”
Schema Awareness	`describe_schema`, `list_entities`, `list_relationships`	“What entities exist in this domain?”
Tool Awareness	`list_my_tools`, `describe_tool`, `tool_authorization`	“What can I ask you to do?”
Service Awareness	`service_health`, `dependency_status`	“Is the graph database available?”

Self-Awareness Architecture

┌─────────────────────────────────────────────────────────────────┐
│              SYSTEM SELF-AWARENESS ARCHITECTURE                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌────────────────────────────────────────────────────────┐     │
│  │              DIALOG (Playbook-Driven)                  │     │
│  │  Intent: introspection_class                           │     │
│  └────────────────────────────────────────────────────────┘     │
│                          │                                      │
│  ┌────────────────────────────────────────────────────────┐     │
│  │              INTROSPECTION TOOLS                       │     │
│  │  Catalog │ Rule │ Run │ Config │ Schema │ Tool │ Svc   │     │
│  └────────────────────────────────────────────────────────┘     │
│                          │                                      │
│       [Tool Authorization · Operational Mode Gate]              │
│                          ▼                                      │
│  ┌────────────────────────────────────────────────────────┐     │
│  │              PLATFORM REGISTRIES                       │     │
│  │  Asset Registry │ Rule Registry │ Schema Registry      │     │
│  │  Chain Trace Store │ Health Registry │ Tool Registry   │     │
│  └────────────────────────────────────────────────────────┘     │
│                          │                                      │
│  ┌────────────────────────────────────────────────────────┐     │
│  │              RESPONSE RENDERER                         │     │
│  │  Tables, rule cards, trace walkthroughs, widgets       │     │
│  └────────────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────────────┘

Run Awareness Example: Decision Explanation

When an analyst asks “why was this alert escalated?”, the Dialog:

Step	Action
1	Match intent `explain_decision`; resolve `alert_id` from the active application surface (Context-Awareness) or elicit it
2	Load the chain trace from the analysis record (see Graph Operations › DAG Rules)
3	Identify rules with `matched=True` and severity contributing to the final score
4	Identify any `hard_override_triggered` reason
5	Render an ordered walkthrough: which rules fired, what they observed, the score impact, and the decision; optionally surface a chain-trace widget
6	Offer follow-up drill-downs (rule deep dive, evidence pack, similar alerts)

The Dialog never invents rule outcomes — it reads from the persisted chain trace and rule registry.

Self-Awareness Security Controls

Control	Implementation
Authorization Boundary	Self-Awareness exposes only what the user’s role and tenant permit; out-of-scope artefacts are filtered before rendering
Permission-Filtered Catalogs	Asset catalog responses are filtered through the user’s permission set; assets the user cannot see do not appear
Configuration Read-Only	Self-Awareness tools are read-only; no introspection tool may modify configuration
Chain Trace Integrity	Trace lookups read from append-only storage; no tool can mutate trace records
PII Awareness	Self-Awareness responses respect Field-Level Masking and Data Classification (see 03-Knowledge-Fabric)
Rate Limiting	Introspection calls are rate-limited per user to prevent enumeration attacks
Audit Logging	Every introspection call is logged with user, intent, slots, and result categories

Self-Awareness Audit Trail

Event	Logged Data	Retention
Introspection Invoked	User, intent, tool, slots, timestamp	1 year
Catalog Filtered	User, original size, filtered size	1 year
Authorization Denied	User, requested artefact, reason	1 year
Trace Read	User, alert ID, fields read	1 year

The Dialog can render Studio Widgets inline as part of its response. Widgets are owned by Studio (see 04-Studio: Widget Types), but the Dialog is one of their primary surfaces. The connection between Dialog and Studio is loose-by-design: Studio defines widget types, the Dialog uses them.

Surface	Description
Dialog View	Inline widget rendered as part of the assistant message
Canvas View	Widget rendered into a side canvas for richer interaction
Both	Widget supports either surface; the Dialog selects per intent

The Dialog does not invent widget types. It surfaces the Studio Widget Types the playbook is permitted to render (Widget Binding in the playbook structure). Two categories apply (see 04-Studio: Widget Types):

Widget Class	Role in Dialog
SYSTEM Widgets	Platform-managed renderings: chain-trace walkthroughs, rule cards, schema explorers, service-health panels
OUTPUT Widgets	Domain-specific renderings produced by DDAs or tools: dashboards, case cards, decision packs, payment status, screening hit lists

Step	Action
1	Intent matches; tool plan returns a structured payload
2	Response template specifies a Widget Type (one of the playbook’s bound widgets)
3	Widget Type selected; payload validated against the widget’s input schema
4	Widget rendered into the dialog or canvas surface
5	Per-widget audit record written

Control	Implementation
Widget Binding	Playbook declares which Widget Types it may render; ad-hoc widgets are rejected
Input Validation	Widget payload validated against the widget’s input schema
Tool Authorization	The tools that produce widget payloads are gated by Tool Authorization
Sensitive-Field Masking	Widget payloads respect Field-Level Masking (see Knowledge Fabric › Data Protection)
Tenant Isolation	Widget payloads are tenant-scoped; cross-tenant rendering is rejected
Audit	Widget renderings are logged with type, payload size, and recipient

Operational Modes

Dialog behaviour adapts to the platform’s Operational Modes. The same intent can produce different responses depending on the mode in force.

Mode	Dialog Behaviour
0 — Traditional Platform	Dialog disabled or restricted to Self-Awareness only
1 — AI-Assisted Manual	Dialog suggests, retrieves, explains; never decides; HITL on every actionable intent
2 — Routine Automation	Dialog can act on routine intents (e.g., close a clear case); HITL retained on high-risk intents
3 — Autonomous with Escalation	Dialog acts autonomously where authorised; escalates exceptions; HITL retained on hard overrides
4 — Fully Automated with Audit	Dialog acts autonomously across the surface; analysts audit a sampled subset

The mode is part of the per-turn context and is enforced at the Authorization step of the turn lifecycle.

Integration Points

Component	Role in Dialog
04-Studio — Tools	The Dialog’s tool plan invokes Studio Tools (DDAs, MCP, External APIs, Scripts)
04-Studio — Widget Types	The Dialog renders Studio Widgets as part of responses
04-Studio — Tool Authorization	Every tool call is authorised by Studio’s Tool Authorization model
04-Studio — Operational Modes	Dialog behaviour is bound by the active mode
03-Knowledge-Fabric — Search Sessions	Session graph and accumulated context are surfaced through Dialog
03-Knowledge-Fabric — Field-Level Masking	Widget and response rendering respect masking
05-AI-LLM — LightLLM Gateway	All LLM calls (intent classification, narration, slot extraction) flow through the gateway with provenance
08-Graph-Operations — Chain Trace	Run-awareness reads chain traces from Graph Operations
08-Graph-Operations — Rule Registry	Rule-awareness reads rule definitions from the Rule Registry
09-Schema-Management — Schema Registry	Schema introspection draws from the Schema Registry
13-Graph-RAG — Text-to-Cypher	Dialog tools may invoke Text-to-Cypher under playbook binding
13-Graph-RAG — Session-Based Retrieval	Conversational drill-down builds on the session graph

Audit Logging

Event	Logged Data	Retention
Session Started	User, tenant, playbook, mode	1 year
Context Assembled	Context layer summary (no raw PII)	1 year
Intent Matched	Intent key, slots, confidence	1 year
Tool Plan Executed	Tools, parameters, durations, results category	1 year
Widget Rendered	Widget type, payload size, recipient	1 year
LLM Invocation	Model ID, prompt hash, response category	1 year
Refusal	Trigger reason, intent, user, session	1 year
Escalation	Escalation reason, intent, target reviewer	2 years
Cross-Session Memory Opt-In	User, playbook, scope	2 years
Authorization Denied	User, intent, requested tool, reason	1 year

Cross-References

Studio — Tools, Widget Types, Tool Authorization, Operational Modes, Testing & Debugging Framework
Knowledge Fabric — Search Sessions, Session Graph, Field-Level Masking
AI/LLM — LightLLM Gateway, model provenance
Graph Operations — Chain Trace, Rule Registry, DAG Rules
Schema Management — Schema Registry
Graph RAG — Text-to-Cypher, Session-Based Retrieval
Transaction Monitoring — Reference dialog playbook
Car Finance — Reference dialog playbook
Compliance — Reference dialog playbook