DIAL. Diagnostics, turned into an asset.

A platform that changes how an organization handles software incidents: less time wasted, knowledge that compounds, faster response toward customers.

More services, less visibility: the microservices paradox.

The more distributed a system becomes, the slower and more expensive its incident diagnosis gets. Three recurring symptoms, one common root cause: diagnostic knowledge stays scattered, unshared, unreusable.

The data in the scenes are made-up examples. DIAL provides for anonymising data at the source, before it enters the package.

Scattered data

Logs, payloads and application state live on different systems, in different formats, behind different access rules. Reassembling the picture of a single incident is manual work.

Broken context

TraceIds get lost in transit between services. Seeing a business transaction from start to finish becomes hard, even when the individual steps are observable.

Knowledge that evaporates

Diagnostic times keep growing. Every time you start from scratch: the same problem, already solved in the past, gets re-tackled as if it were new. Solutions stay in the head of whoever found them, or in the session of the agent that found them, and vanish with it. Almost always the case lands on a developer, pulled away from their work because neither support nor its agents have the tools to diagnose on their own.

Diagnostics by design, not by auto-capture.

Whoever develops — the team, more and more often alongside development agents — decides what domain information to expose. DIAL collects it, indexes it, makes it available to whoever needs to analyze an incident, person or agent, and learns from previous resolutions.

Why auto-instrumentation isn't enough

Auto-instrumentation tools capture large volumes of infrastructure data — CPU, memory, latencies, network calls — without business context. For most real incidents, what matters is the application domain: which operation was being performed, on which entity, with which parameters. DIAL starts from there.

Intentional design

The development team chooses what to expose using a dedicated kit: semantic traits (tenant identifier, transaction identifier, operation type), state datasets, correlation rules. It's an upfront cost in exchange for a compounding payoff: the data collected is the data that actually matters.

Inside is everything needed for analysis: logs, application payloads, system state, domain traits, metadata.

.cdpkg format: compressed, encrypted, portable.

Transferable, archivable, analyzable even offline.

End-customer support

Whoever provides assistance gains in responsiveness and — above all — in diagnostic autonomy.

With the diagnostic package in hand and a Knowledge Base suggesting patterns it has already seen, first- and second-level support, people and agents working together, resolves a large share of incidents.

Without involving the development team.

Perceived customer value goes up; the people who build the product stay free to build.

Running systems in production

Whoever maintains mission-critical applications — internal or customer-facing — shortens resolution times and reduces dependence on a few expert individuals. The learning curve for new team members shortens too: incident history, with resolutions and patterns, is queryable, by the people on the team and by the agents working alongside them in operations.

Search across domain data

Not just logs and error messages: application payloads (JSON, XML, CSV) also become full-text searchable. "All orders above a given threshold with error status in the last seven days" is a query, not a manual extraction exercise.

Collection from federated applications

When an incident crosses multiple services, DIAL queries each of them and gathers the evidence into a single package. Correlation between traces and identifiers is reconstructed automatically. No more copy/paste across log windows.

Software development

The team building the product stops being the bottleneck of every non-trivial diagnosis.

The context needed to understand an incident is available to whoever handles it first, whether a person or an agent.

Developers go back to developing.

Knowledge about error patterns stays in the platform, not in individual heads nor in the context of a single session.

AI-powered Knowledge Base

Every analyzed incident leaves a trace: error patterns, identified root causes, applied solutions. An AI agent indexes them and surfaces them as references on new cases, with citations to the original packages. Knowledge no longer stays with individuals: it is distilled and made available to projects, to the people and the agents working on them.

On top of that material, an AI-powered Knowledge Base accumulates the patterns it has already seen and proposes solutions the next time around.

Knowledge flows back to projects.

The Knowledge Base is not an archive to search only by hand. DIAL exposes it via API and MCP to projects and to the agents working on them.

A development agent touching the customer registry module already knows which errors it has produced and how they were solved. A support agent opens the package and finds the similar case without waiting for anyone.

People and agents draw on the same body of knowledge. Every incident solved, by anyone, adds to it.

Product and offering

DIAL can be embedded as an observability module in the projects you propose to customers, or delivered as a dedicated SaaS service.

Advanced diagnostic capability becomes part of what you sell — not an invisible implementation detail, but a describable advantage.

Progressive adoption, no disruption.

DIAL activates in three cumulative phases. You start with a minimal footprint that requires no network ports to be opened; you progressively add more advanced capabilities as the customer's context allows.

Phase 1 · Offline acquisition

From the customer's perspective nothing changes.

A dedicated CLI collects diagnostic packages directly on the machines where the applications live and transfers them out in a controlled way.

No network ports to open, no new accesses to grant — suitable even for the most constrained security and compliance contexts, like banking or healthcare.

Phase 2 · Centralized online hub

Applications expose dedicated diagnostic endpoints. DIAL queries them, correlates, and materializes packages into a single hub. The viewer shows logs, payloads and traits in a common interface, browsable by trace, by project, by application.

Phase 3 · Knowledge Base and AI suggestions

The pipeline that indexes error patterns and surfaces them as references on new incidents is activated. The agent becomes contextual on individual packages and capable of querying the entire corpus. From here value starts to compound: every new incident analyzed feeds the next ones. The distilled knowledge is exposed via API and MCP to projects and their agents.

DIAL alongside traditional APM systems, not in place of them.

Tools like Datadog, Dynatrace or New Relic solve infrastructure monitoring. DIAL is designed for the layer above: incident diagnosis that requires domain context. On the dimensions that matter for that problem, the choices are different.

• APM / Auto-instrumentation
• DIAL model

Implementation

Auto-installing agent, active from day one on infrastructure metrics.

Requires the development team to expose domain information. Upfront cost, in exchange for data that actually matters.

Data volume

Captures everything, always. Volume and cost grow with traffic.

Captures only what is relevant for diagnosis.

Business context

System metrics (CPU, memory, latencies, HTTP errors). Application domain is absent.

Native in the domain. Application payloads, business identifiers, operation state.

Reusable knowledge

Data stays in the system, resolutions stay in the heads of those who found them or in sessions no agent remembers.

Cumulative Knowledge Base, AI pattern recognition, cross-references to original cases; queryable by people and agents, via API and MCP.

Portability

Lock-in on the chosen platform. Exporting evidence is laborious.

Self-contained diagnostic packages, transferable, analyzable even offline.

Want to know more?

Let's talk.

For your team, people and agents.

For the customers you serve.

As a module to include in an offering.

The best way to understand whether DIAL fits your situation is to tell us about your context.

If it makes sense, a few-week proof of concept is the natural next step.