MULTI-DSL EVIDENCE ENGINE

Turn production questions into evidence.

AutoObserve plans and executes the queries required to answer production questions across metrics, logs, traces, changes and system context—while preserving the queries, sources and evidence behind every answer.

Specialised DSLs underneath. One evidence model above them.

Multi-DSL ≠ multiple query editors. Multi-DSL = evidence execution substrate.

See Multi-DSL in Action ↓Explore the Architecture →Become a Design Partner

THE PROBLEM

Production data speaks different languages. Incidents don't.

Specialised query languages are good at their domains. Production investigations aren't confined to one domain.

TODAY

INCIDENT
METRICS · LOGS · TRACES
PromQL · LogQL · TraceQL
Result · Result · Result
ENGINEER
Manual correlation

AUTOOBSERVE

QUESTION
EVIDENCE INTENT
PLANNER
Metrics · Logs · Traces
PromQL · LogQL · TraceQL
NORMALISATION
EVIDENCE

Keep specialised query languages. Remove manual orchestration.

01 / EXPRESS

Start with what you need to know.

Evidence Intent — not natural-language querying, not AI, not DSL translation.

HUMAN

“Did checkout latency change after deployment?”

Evidence Intent

INVESTIGATION

Hypothesis

Deployment caused checkout regression.

Need

Pre/post latency evidence.

Evidence Intent

PROGRAMMATIC

CONCEPTUAL MODEL

Entity: checkout-api
Signal: request.latency
Comparison: before / after change

Evidence Intent

WHAT DO YOU NEED TO KNOW?

“Did checkout latency increase after the deployment?”

Evidence Intent

HOW CAN WE FIND OUT?

MetricsPromQL
LogsLogQL
TracesTraceQL
ChangesEvent Query
TopologyGraph Context

02 / PLAN

Turn one question into an evidence plan.

An execution plan — not an AI conversation.

Why did checkout failures increase after 14:31?

Evidence Plan

4 requests

01
ESTABLISH DEGRADATION
Did checkout latency and errors change?
Source · Metrics
02
IDENTIFY ERROR SIGNATURES
Did new application errors appear?
Source · Logs
03
LOCATE FAILURE ORIGIN
Where do failed requests first break?
Source · Traces
04
IDENTIFY RECENT CHANGE
What changed immediately before degradation?
Source · Deployment events

Query translation

QUESTION
PROMQL

AutoObserve

QUESTION
EVIDENCE REQUIREMENTS
SOURCE SELECTION
EXECUTION PLAN
DSL COMPILATION
EXECUTION
NORMALISATION
EVIDENCE

Translation produces a query. Planning produces an investigation strategy.

03 / EXECUTE

Use the right language for each evidence source.

Abstraction when useful. Control when required.

Metrics evidence

Question: Did checkout p95 latency increase after deployment?
Backend: Prometheus
DSL: PromQL
Window: 14:25 → 14:35

Query

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service="checkout-api"}[5m])) by (le))

Every generated query is inspectable — infrastructure engineers can verify what ran.

04 / NORMALISE

Different languages shouldn't mean different reasoning models.

CIR decouples production reasoning from the syntax and semantics of individual query backends.

PromQL

{service="checkout"} 684.2

LogQL

{"level":"error","msg":"connection acquisition timeout"}

TraceQL

span.service.name = "checkout-api"

Event

deployment/v2.14.7

Different structures. Different semantics. Different metadata.

CIR

Canonical Intermediate Representation

Normalised execution semantics

Don't replace specialised languages. Orchestrate them.

PromQL stays PromQL. LogQL stays LogQL. TraceQL stays TraceQL. AutoObserve adds an evidence abstraction above them.

05 / UNIFY

A query returns data. An investigation needs evidence.

Multi-DSL returns evidence — not conclusions. Investigation interprets what the evidence means.

Raw result

684.2

Evidence

Metrics
Latency deviation
+184%
Logs
New error signature
Connection acquisition timeout
Traces
Failure origin
checkout-api
Changes
Recent change
v2.14.7 · 83s earlier

5 coordinated evidence requests

Multi-DSL stops at evidence. Investigation determines what the evidence means for the hypothesis.

Evidence · Metric

Latency deviation

strong

+184% vs baseline

Entity: Checkout
Signal: request.latency · p95
Window: 14:31–14:36
Observed: 684 ms
Baseline: 241 ms
Source: Prometheus
Backend: Prometheus
DSL: PromQL
Coverage: 98%
Executed: 14:35:03

EVIDENCE PLAN EXPLORER

Trace every evidence requirement from plan to result.

Select an evidence requirement to inspect the query, raw result, and normalised evidence. Architecture progression tabs show how each requirement becomes trustworthy evidence.

INCIDENT 14:31

Why did checkout failures increase after 14:31?

Plan

Execution

Question

Did checkout p95 latency increase after deployment?

Source: Metrics
Backend: Prometheus
Window: 14:25 → 14:35

Evidence

+184%

Before: 241 ms
After: 684 ms
Deviation: +184% vs baseline

strong

Evidence plan 1 / 5

Latency

Metrics · PromQL

✓ COMPLETE

Question

Did checkout p95 latency increase after deployment?

Source: Metrics
Backend: Prometheus
Window: 14:25 → 14:35

Evidence

Evidence · Metric

Checkout p95 latency

strong

Checkout p95 latency increased 184% relative to baseline.

Observed: 684 ms
Baseline: 241 ms
Deviation: +184% vs baseline
Source: Metrics
Backend: Prometheus
DSL: PromQL
Coverage: 98%

5 evidence requests · 4 complete · Coverage 82%

EXPLAINABILITY

See how every piece of evidence was produced.

Evidence · Metric

Latency deviation

strong

+184% vs baseline

Entity: Checkout
Signal: request.latency · p95
Window: 14:31–14:36
Observed: 684 ms
Baseline: 241 ms
Source: Prometheus
Backend: Prometheus
DSL: PromQL
Coverage: 98%
Executed: 14:35:03

Abstraction when useful. Control when needed.

KNOW PROMQL?
Write PromQL directly.
KNOW LOGQL?
Write LogQL directly.
NEED CROSS-SIGNAL EVIDENCE?
Use an evidence plan.
AUTONOMOUS INVESTIGATION?
Let Investigation request the evidence it needs.

BUILT FOR HUMANS + MACHINES

One evidence engine. Human and machine consumers.

Investigations ask questions. Multi-DSL finds the evidence.

Hypothesis → evidence required → Multi-DSL → evidence set → hypothesis strengthened or weakened.

Explore Investigation →

AIDDE decides attention. Evidence updates confidence.

Incident candidate → needs more evidence → Multi-DSL → evidence → confidence updated → decision.

Explore AIDDE →

What happened + where it lives = production context.

Multi-DSL answers what, when, and how much. Topology answers where and what depends on what.

Explore Topology →

Evidence flows back through the platform loop—consumers reassess with every new result.

MULTI-DSL

What evidence do we need?

INVESTIGATION
What explains this?
1. 01Confidence insufficient
2. 02Request investigation
3. 03Generate competing hypotheses
4. 04Test against evidence
5. 05Updated evidence
6. 06AIDDE reassesses
Explore Investigation →
TOPOLOGY
What is related?
1. 01Root vs downstream
2. 02Blast radius
3. 03Causal consistency
4. 04Suppression with evidence retained
Explore Topology →
MULTI-DSL
What evidence do we need?
1. 01Evidence request
2. 02Investigation planner
3. 03Metrics · Logs · Traces
4. 04Unified evidence
5. 05AIDDE reassessment
Explore Multi-DSL →

Evidence returns

→ AIDDE reassesses

EXTENSIBILITY

Add evidence sources without rewriting the intelligence layer.

Higher-level consumers reason over evidence semantics rather than backend-specific query syntax.

Evidence Intent

CIR

PromQL Adapter

LogQL Adapter

TraceQL Adapter

New Adapter → New Backend

TECHNICAL ARCHITECTURE

From evidence intent to executable query.

Enough architecture to reward platform engineers — diagram must reflect implemented Multi-DSL architecture.

Consumers
Evidence Intent
Evidence Planner
CIR
Execution Planner
Adapters
Result Normaliser
Evidence Builder
Evidence Set

Evidence Intent: What information the consumer needs.
Evidence Plan: The evidence requirements necessary to answer the question.
CIR: Backend-independent representation used between higher-level evidence requirements and query execution.
Adapter: Translates an execution requirement into a backend/DSL-specific query.
Evidence: Normalised information with source, execution and quality provenance preserved.

Read the Architecture →