Database operations are an unusually difficult decision environment. Relevant evidence may span live performance behavior, workload and execution characteristics, resource use, configuration, change history, service objectives, business sensitivity, capacity, and cost. It is distributed across time as well as across systems. A single alert can correctly identify that a threshold has been crossed without identifying the workload, recent change, resource contention, or operating consequence that should determine the response.

This is not a criticism of monitoring. Monitoring and alerting are necessary capabilities. Site-reliability guidance makes the distinction directly: an operational dashboard can establish that a service is violating an objective, but may not provide enough information to explain why; investigation must move from the notifying signal to context that can explain the condition.^[3] The design error is assuming that a collection of individually useful surfaces automatically becomes a decision system.

A dashboard-first workflow assumes that an operator already knows where to begin: which engine, target, workload, interval, dimension, comparison, and diagnostic view matter. That assumption becomes brittle when the question is cross-system, forward-looking, cost-sensitive, or posed by someone who does not know the estate’s internal navigation grammar. The person does not need a more attractive starting dashboard. They need a way to declare the decision they are trying to make and to see how evidence supports the resulting answer.

The unit of work therefore changes. Instead of treating an alert, dashboard, chart, or query as the center of the interaction, the architecture treats an operating inquiry as the primary object. An inquiry has a decision purpose, authorized scope, time horizon, evidence requirements, and action boundary. It can produce a useful answer even when the answer is “insufficient evidence,” “no material condition within the stated scope,” or “specialist review is required.” Those are disciplined answers; an untraceable confident narrative is not.

The goal is not to remove visual analysis. Specialists still require charts, queries, plan views, and deep diagnostics. The goal is to let the architecture determine which of those surfaces are relevant to a stated inquiry, make their contribution inspectable, and return the operator to a coherent decision path.

This is a reference architecture rather than a vendor feature set. It assumes a heterogeneous enterprise estate—potentially multiple database engines, deployment models, accounts, data classes, and operating teams. It is suited to questions that require a bounded combination of performance, workload, availability, cost, capacity, configuration, or change evidence. It does not prescribe a telemetry product, query language, machine-learning model, data store, or user-interface framework.

The architecture also assumes that evidence is incomplete, late, inconsistent, or ambiguous at times. That is not an edge case; it is normal operating condition. A system that makes uncertainty visible is architecturally stronger than one that collapses missing context into an authoritative sounding response.

What this paper does and does not claim

• It defines properties of a reviewable operational answer; it does not assert that every question can be answered automatically.
• It supports forecasts as explicitly qualified estimates; it does not present a forecast as observed fact or promise a future outcome.
• It supports recommendations and governed work handoff; it does not authorize a generic conversation to change a production system.
• It allows language models, rules, statistical methods, and domain analyzers as components; it does not depend on one implementation technique.
• It complements dashboards and specialist tools; it does not argue that visual evidence or expert investigation should disappear.

Architecture descriptions are most useful when they make stakeholders, concerns, and viewpoints explicit rather than presenting one undifferentiated diagram. That is the purpose of the following sections, consistent with ISO/IEC/IEEE 42010 and view-centered architecture practice.^[1][2]

The reference architecture has four visible stages and a set of cross-cutting controls. The stages are intentionally separated. They prevent a free-form response from becoming both the interpreter of a request and the sole judge of whether its own answer is adequate. An implementation can use different technologies within each stage, but responsibilities should remain visible and independently testable.

Stage 1: decision dialogue

The interaction accepts a question in the language of the operating decision. Examples include: “What changed before this latency regression?”, “Which databases need capacity review this quarter?”, or “Show systems likely to experience material performance pressure within a stated planning horizon.” The question is not an executable command. It is a request to form an inquiry. The user must be able to refine it, see inferred scope, and understand which evidence can contribute.

Stage 2: inquiry contract

The inquiry contract is the first safeguard against convenient but weak answers. It converts an ambiguous request into explicit, inspectable constraints. The contract need not be a cumbersome form; a dialogue can gather or confirm it progressively. But the resolved fields must exist before analysis claims an answer.

Stage 3: evidence and interpretation

Once the contract is known, the architecture composes a bounded evidence route. This is broader than retrieval. It may coordinate direct telemetry, workload behavior, execution or plan context, configuration and change records, capacity and cost signals, service objectives, and prior decisions. Each source keeps its original time basis and identity. The system should not claim that separately collected values are comparable without making their windows, units, and join assumptions explicit.

Interpretation is performed by specialized components appropriate to the evidence and question. A robust design can include intent interpretation, orchestration, domain-specific analysis, and independent assurance. The principle is not that these must be branded as “agents”; it is that one component should not invent its own task, select arbitrary data without bounds, and certify its own conclusion.

Stage 4: reviewable answer and governed next step

The final stage produces an answer record, not merely prose. It includes a concise conclusion, evidence links or summaries, the answer category, caveats, and the next step that policy permits. In low-risk contexts that step may be another inspection view. In higher-risk contexts it may be a draft investigation or maintenance request awaiting an authorized owner. Any side effect belongs to a separate governed workflow with explicit authority, approval, execution record, and verification; it is not implied by a persuasive explanation.

One diagram cannot establish whether an operational architecture is understandable, safe, and useful. The following views isolate four concerns: the decision interaction, the evidence path, the reasoning-quality boundary, and the governance boundary. They can be reviewed independently by operators, architects, data owners, security teams, and control owners.

View A: interaction and decision

The central interaction principle is that dialogue must preserve operational precision. A user can ask a broad question, but the architecture must progressively resolve what “system,” “major,” “next two weeks,” or “performance issue” means in that organization. The user must be able to inspect and correct assumptions rather than discover them after an answer is produced. A dialogue-first experience therefore requires visible scope, time semantics, result type, and evidence status—not an invisible prompt transformed into an unverifiable result.

Visual interfaces remain vital. A useful answer can link directly to the relevant time series, workload comparison, configuration difference, cost attribution, or detailed diagnostic view. The architecture changes the starting point and preserves the reasoning route; it does not ask a language interface to replace specialist analysis surfaces.

View B: evidence and provenance

Provenance is information needed to assess the quality, reliability, and trustworthiness of a result. W3C’s PROV model describes provenance in terms of entities, activities, agents, derivations, and time; those ideas are directly applicable even if an implementation does not use that standard’s data model.^[5] For an operational answer, provenance must answer practical questions: Which sources were considered? When were they collected? Which intervals were joined? What transformations or aggregations were applied? Who or what produced the result? What was excluded, unavailable, or redacted?

Evidence should be typed before it is summarized. A direct metric reading, deterministic calculation, modelled estimate, forecast, and human-entered annotation do not have the same epistemic status. Blending them into one unlabelled “insight” loses information precisely when an operator needs to assess a recommendation or challenge a conclusion.

View C: reasoning and assurance

For complex questions, useful answers often require more than one analytical technique. Intent interpretation determines what is being asked. Orchestration determines which bounded analyses are relevant. Domain analysis evaluates workload, time-series, configuration, cost, or capacity evidence. Independent assurance checks whether the proposed answer satisfies the contract: it is within scope, cites appropriate evidence, distinguishes observation from forecast, and expresses uncertainty where required.

This separation is a safety and quality requirement, not merely an implementation preference. NIST’s AI Risk Management Framework identifies valid and reliable behavior, accountability, transparency, explainability, and resilience as important trustworthiness characteristics; it also treats governance as cross-cutting.^[6] In operations, those qualities appear as bounded access, explicit evidence, testable answer criteria, retained review history, and a visible abstention path.

View D: governance and action

The architecture must never let fluency become authority. A well-phrased recommendation can be helpful; it is not approval to alter configuration, run a risky command, or schedule production work. The action boundary should be explicit: read-only inquiry may be automated within access policy; a proposed change becomes a governed record; approval and execution are performed by authorized actors or approved automation; verification records what occurred and whether the intended effect was observed.

This boundary is especially important for maintenance. Dialogue can collect and structure evidence for a maintenance decision, draft scope, owner, validation criteria, and rollback expectations. It should not silently become a maintenance executor. Separating evidence, decision, authority, execution, and verification keeps the system useful without representing unreviewed change as an inevitable consequence of diagnosis.

An answer is not defined by its tone or by whether it is expressed in natural language. It is a structured claim made for a particular decision under stated conditions. The following record is a minimum conceptual contract. It can be displayed as a summary, detailed investigation, work item, or linked visual evidence, but the information should remain recoverable.

Evidence categories must remain visible

A recurring failure in operational AI is category collapse: a forecast is presented like a measurement, a correlation like a cause, or a recommendation like an approved action. The answer contract prevents this by giving material claims a type.

• Observed: a direct record from a named source and time interval, subject to normal collection and quality limitations.
• Derived: a deterministic transformation, aggregation, or comparison whose inputs and method can be inspected.
• Modelled: an estimate produced by an explicit model, assumptions, and input domain; neither raw telemetry nor a guaranteed outcome.
• Forecast: a modelled statement about a future window, presented with horizon, reference basis where appropriate, and uncertainty conditions.
• Recommendation: a proposed action or investigation, with rationale, required authority, validation criteria, and rollback or review conditions where relevant.

These categories enable better interface behavior. A forecast can be shown beside the observed trend that supports it. A recommendation can link to evidence and policy that make it eligible for review. An answer that lacks critical evidence can disclose that gap without being forced to mimic certainty.

Answer quality is more than accuracy

Accuracy matters, but it is insufficient. An answer can be locally accurate and still be unsuitable because it is stale, outside authorized scope, disconnected from evidence, too broad for the decision, or framed as causal when the evidence establishes only association. The architecture should evaluate at least six qualities: decision relevance, scope correctness, evidentiary traceability, temporal fitness, uncertainty calibration, and policy compliance. Organization-specific thresholds may vary; the need to state them does not.

A simple review test follows: Can a skeptical operator identify the decision, reconstruct the evidence path, see what the system does not know, and determine whether the next step is allowed? If not, the system has produced an assertion rather than a reviewable operational answer.

Consider the request: “Show me systems that would have major performance issues in the next two weeks, and explain why.” This is strategically useful because it combines operational risk, planning horizon, and explanation. It is also deliberately under-specified. “Systems,” “major,” “performance issues,” “next two weeks,” and “why” each need an explicit meaning before an answer can be defensible.

The reference architecture does not treat the phrase as a command to produce a list. It turns the phrase into an inquiry whose assumptions can be inspected. The sequence below illustrates required behavior; it does not claim that any particular forecast model, threshold, or result is universally valid.

1. Clarify the decision and materiality.

   The system identifies the likely decision: capacity review, risk review, or preventative investigation. It asks for or applies policy-defined materiality—such as a service objective, saturation boundary, business criticality, or planning threshold. If definition remains unresolved, the answer must say it is ranking candidates rather than predicting an incident.

2. Resolve scope and access.

   The inquiry records which production estates, environments, engines, services, and accounts are included; what the requester may inspect; and whether the horizon is rolling fourteen days or a named planning period. A result must not silently widen scope because more data would be convenient.

3. Assemble an evidence route.

   The system selects historical workload and resource behavior, current capacity posture, known changes, seasonality or calendar context where available, service objectives, and prior similar conditions. It retains the time basis and source status of each component. Absent or poor-quality sources are reported as gaps, not filled by narrative.

4. Interpret and qualify.

   Specialized analysis estimates which systems warrant review under the stated definition. It separates observed current pressure from forecasted pressure, distinguishes association from demonstrated cause, and tests whether evidence contradicts a candidate conclusion. An inconclusive result is valid when data do not support a stronger claim.

5. Return a reviewable answer.

   The response ranks eligible systems with the evidence route, time horizon, major assumptions, uncertainty, and investigation path. The next step might inspect a workload, compare a change, open a governed review, or ask an owner to validate a planning hypothesis. It is not “automatically change production.”

The same pattern scales down to incident and change questions. “What changed before this regression?” should expose a controlled comparison window and evidence routes. “Which workloads account for the capacity increase?” should identify the attribution basis. “Should this maintenance plan proceed?” should separate supporting evidence from approval and execution. Dialogue reduces navigation burden only if the answer preserves technical and governance context that navigation previously forced a specialist to collect manually.

A dialogue-first operating model is not a claim that every complex question becomes easy or safe. The architecture becomes more valuable when it makes limits explicit. The following risks must be designed for, observed, and tested rather than relegated to disclaimer text.

Where generative components are used, additional concerns include prompt injection, unreliable tool selection, ungrounded summaries, and exposure of data outside the inquiry’s authorization boundary. The response is not to hide those concerns behind a model prompt. Constrain accessible tools and data, preserve an evidence route, validate outputs against the contract, observe behavior in production context, and require human governance for material side effects. NIST’s Generative AI Profile provides a useful risk-management framing for this broader class of concerns.^[7]

Dashboards remain part of the solution. They are often the most efficient way to inspect a time series, compare a distribution, validate an anomaly, or perform specialist exploration. Dialogue should make those surfaces easier to reach and interpret in context. It should not replace high-resolution evidence with a verbal paraphrase.

The safest path is to begin with one high-value, bounded operating inquiry that currently requires a known manual route. The objective is not to maximize conversation volume. It is to prove that the architecture can produce a more reviewable decision record than the existing workflow, within a defined scope and without weakening technical or governance controls.

A phased adoption path

1. Select an operating inquiry. Choose a recurring question with a clear decision owner, known evidence sources, and an existing manual baseline. Avoid beginning with a broad “ask anything about the estate” promise.
2. Define inquiry and answer contracts. Specify scope, time semantics, evidence categories, materiality, permitted outputs, abstention conditions, and escalation path before building conversational polish.
3. Integrate read-only evidence first. Build provenance, access controls, source-quality signals, and direct links to detailed evidence. Validate that the route is reproducible by a specialist.
4. Evaluate against held-out or parallel cases. Test relevance, traceability, error modes, and safe abstention on cases not used to shape the response. For forecasts, avoid retrospective leakage and state the baseline used for comparison.
5. Add governed handoff deliberately. Only after answer quality is proven should the architecture create drafts, route reviews, or connect to approved workflows. Keep approval, execution, and verification independent.

What to measure

There is no credible universal claim that this architecture will reduce cost, prevent incidents, or improve response time by a fixed percentage. Each organization should establish its own baseline and measure its own decision quality. Useful measures include: the proportion of answers with recoverable evidence links; correctness of scope and authorization; frequency and quality of abstention; time from inquiry to a specialist-reviewable record; discrepancy rate found during expert review; successful completion of required approval steps; and, where changes are made, verification of the observed result against the stated plan.

These measures have a different purpose from generic engagement metrics. They test whether the architecture preserves decision integrity while reducing unnecessary navigation and coordination burden. A short answer with a complete evidence route is more valuable than a persuasive long answer that cannot be reconstructed.