Conversational analytics: Requirements and policy

Defines intended behavior, human controls, prohibited authority, clarification, fallback, and evidence requirements for conversational analytics, so adopters can turn a business question into a bounded analytics dialogue and a structured dashboard without e...

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

For Conversational analytics, define the assistant behavior and authority boundary so adopters can turn a business question into a bounded analytics dialogue and a structured dashboard without exposing raw data-access primitives to the model. The assistant may discover, describe, query, compare, and present approved metrics; it cannot execute SQL, change data, or invent metric semantics. This is a reference contract: database products, numeric budgets, jurisdictions, retention, organizational defaults, and accountable owners remain explicit adoption choices.

Scope

• The Conversational analytics actors, inputs, outputs, states, versions, and externally visible outcomes needed to turn a business question into a bounded analytics dialogue and a structured dashboard without exposing raw data-access primitives to the model.
• The role-specific focus of this block: define the assistant behavior and authority boundary, including primary, cached, asynchronous, export, support, and recovery paths where applicable.
• Adoption-specific configuration, ownership, rollout, evidence retention, and review responsibilities needed to use the contract safely.

Outside this block

• The assistant may discover, describe, query, compare, and present approved metrics; it cannot execute SQL, change data, or invent metric semantics.
• Choosing a universal database, model, renderer, vendor, numeric threshold, retention period, timezone, jurisdiction, or service-level objective.
• Claiming that packaged scenarios ran against a downstream implementation or that this reference grants security, privacy, accessibility, analytical, or legal approval.

Contract

• The declared Conversational analytics contract requires this rule: The assistant resolves metric, subject, interval, comparison, grain, dimensions, and decision goal before requesting analytical values.
• The declared Conversational analytics contract requires this rule: It uses catalog discovery and typed analytical tools only; no prompt, memory item, retrieved text, or user request can enable an unrestricted SQL tool.
• The declared Conversational analytics contract requires this rule: Caller identity and authorization scope come from the trusted host context and are rechecked by every tool rather than supplied as authoritative model arguments.
• The declared Conversational analytics contract requires this rule: Material ambiguity produces one focused clarification with visible assumptions; low-impact display choices may use documented organizational defaults.
• The declared Conversational analytics contract requires this rule: The answer includes plain metric descriptions, exact periods, values, deltas, charts or tables, freshness, caveats, and an evidence-backed summary.
• The declared Conversational analytics contract requires this rule: Observed change, arithmetic contribution, association, experiment result, forecast, and causal conclusion are distinct claim classes with different evidence gates.
• The declared Conversational analytics contract requires this rule: The conversation stores normalized analytical handles and result IDs, not raw restricted rows or credentials, and revalidates scope when a handle is reused.
• The declared Conversational analytics contract requires this rule: When tools fail or evidence is insufficient, the assistant returns a bounded partial answer or abstention and suggests a safe next analytical action.

Implementation guidance

• Write representative user questions, ambiguous variants, adversarial requests, and expected abstentions before selecting a model or prompt.
• Separate product defaults from facts the assistant must resolve through trusted tools and name who approves each default.
• Define a non-AI baseline and a safe degraded response for unavailable models, tools, or verification.
• Review outputs with business, data, security, and affected user representatives before broad rollout.

Failure handling and safeguards

• For Conversational analytics, Prompt injection requesting SQL, broader tenants, hidden dimensions, credentials, or write operations is denied and recorded without revealing protected metadata.
• For Conversational analytics, An ambiguous organization name or metric alias remains unresolved until the tool returns one authorized match or the user selects among safe candidates.
• For Conversational analytics, If chart generation fails, the assistant preserves the validated result as text and a data table instead of fabricating a visual conclusion.

Verification and operations

• For the requirements evidence of Conversational analytics, evaluate representative executive, internal, customer, and account-manager questions against expected metric, scope, period, and output plans.
• For the requirements evidence of Conversational analytics, run injection, cross-tenant, stale-handle, unsupported-metric, zero-baseline, partial-data, and tool-timeout adversarial cases.
• For the requirements evidence of Conversational analytics, score factual consistency by recalculating every statement and plotted value from structured tool results rather than comparing prose alone.

Adoption assumptions

• The adopting product has authenticated identity, a versioned authorization policy, owned metric definitions, bounded telemetry, and a controlled path for change.
• Names and values in the example are fictional adoption fixtures, not universal defaults, production credentials, performance promises, or business targets.
• Referenced specifications constrain protocol, security, accessibility, or vendor behavior; the adopting team must confirm current applicability before promotion.

The executable-looking examples in this package are fixtures and acceptance contracts. Run the collection validator to check structure and metadata, then translate and execute the scenarios in the target repository before recording implementation evidence.

References

• NIST AI 600-1, Generative AI Profile (applies as of 2026-09-12)
• Model Context Protocol 2026-07-28, Tools (applies as of 2026-09-12)