Get started

Custom Reports

Six views.
One knowledge graph.
Every role covered.

PULSAR renders purpose-built analytical views directly from the Digital Twin — scoped to a specific role and engineering question. Not dashboards. Not metric streams. Structural views of dependency, causality, deviation, and health derived from the same continuously updated graph.

Get started Explore views
PULSAR · Living knowledge graph
ECU-Gateway Root cause ADAS-Core Middleware SW-Stack-B Symptom Timeout ECU-C2 Topology view · Causal trace · Deviation map · same graph
Every other tool
Configure a view. Populate it with data.
Decide what matters before analysis runs.
Generic observability and BI tools require you to pre-define what to display. You build dashboards. You set thresholds. You pick metrics. Everything the tool shows is something you already decided to look at — which means everything you didn't configure is invisible.
PULSAR
Ask the graph. The view is rendered from what the system already knows.
PULSAR continuously builds a living knowledge graph from runtime telemetry and architecture artefacts. Every view is derived from that graph — what components were active, how the anomaly propagated, where behavior diverged from baseline, which supplier boundary the failure crossed. The view follows the analysis. Not the other way around.
View types

Six views. All from the same graph.

Each answers a specific engineering question. Each draws from the same continuously updated knowledge graph — rendered for the role and context that needs it.

01
Runtime Topology View
Which components communicated during this run, and through which paths?
Actual communication graph from runtime traces — not the documented architecture. Active nodes, live edges, timing relationships, deviation overlay against specified design.
Graph: dependency graph · comm. edges · timing
E/E ArchitectIntegration
02
Causal Propagation Trace
How did this anomaly propagate, and where did it originate?
Traces a detected anomaly backwards through the causal graph. Each hop weighted by causal strength. Resolves the propagation path from observable symptom to origin node — across domain and supplier boundaries.
Graph: causal graph · weighted edges · anomaly nodes
IntegrationE/E Architect
03
Baseline Deviation Map
Where does current run behavior diverge from healthy reference runs?
Per-node deviation score overlaid on the topology graph, derived from the learned baseline model. Shows where behavioral drift first appeared and how far it propagated — colored by divergence magnitude.
Graph: baseline model · deviation scores · topology
QualityE/E Architect
04
Supplier Boundary View
Which supplier domains does this signal path traverse?
Extracts signal paths from the knowledge graph and annotates them with supplier and domain attribution. Identifies exactly which organizational boundary a failure chain crosses — enabling one targeted ticket instead of multi-party escalation.
Graph: dependency graph · supplier attribution · domain partitions
Program LeadQuality
05
Event Sequence Timeline
What was the exact sequence of events and state transitions in this run?
Queryable timeline of canonical events enriched with channel, domain, and run context. Trace the precise order components activated, communicated, or failed — without manually inspecting raw log files.
Graph: canonical event log · timing enrichment · channel metadata
IntegrationValidation
06
Health Index Surface
Where is dependency complexity generating the highest operational risk?
Continuously computed health index mapped across the component topology — derived from behavioral patterns, dependency density, and historical anomaly frequency. Shows where complexity is approaching a failure-prone state before it manifests.
Graph: health index · dependency density · anomaly history
Program LeadQuality Lead
Role lenses

Same graph. Different lens per role.

The knowledge graph is shared. The rendered view is scoped to the engineering role and the question being asked. Different structural information surfaces — enabling different decisions.

Role 01
System / E&E Architect
Does observed runtime behavior match the specified architecture — and where has it drifted?
Active views
Runtime Topology View
Actual paths vs. specified graph
Baseline Deviation Map
Per-node behavioral drift over time
ECU-GW ADAS ⚠ Deviation HCP3 runtime topology · deviation flagged in orange
Decision enabled
Architecture risk assessment. Deviation escalation to responsible domain owner.
Role 02
Integration / Validation Engineer
What caused this failure — and what was the exact causal path from origin to symptom?
Active views
Causal Propagation Trace
Origin node → symptom · hop-by-hop
Event Sequence Timeline
Exact event order · state transitions
cfg_sync · Domain C t=0ms MW propagation · Domain B +14ms ADAS timeout · Symptom +31ms causal path · 3 hops · confidence 0.94
Decision enabled
One targeted ticket to the responsible component owner. No war room required.
Role 03
Program / Quality Lead
Where is risk concentrated — and which supplier boundaries are active failure paths?
Active views
Health Index Surface
Risk concentration · complexity density
Supplier Boundary View
Cross-supplier paths · domain attribution
Supplier A High Risk Supplier B OK Stable Supplier C Low activity health surface · supplier attribution
Decision enabled
Launch readiness gate from evidence. Supplier escalation priority. Fact-based governance.
The structural differentiator

Every view draws from one graph. Not six separate data sources.

Most tools maintain separate data stores per view type — a monitoring platform, a requirements tool, a log aggregator, a ticketing integration. Views are isolated. Cross-referencing is manual. Context is lost between tools.

PULSAR maintains one living knowledge graph — continuously built from runtime telemetry and architecture artefacts. Every view type is a different lens on the same structure. Context is preserved. Switching from a causal trace to a supplier boundary view means traversing the same graph — not opening a different tool.

One graph, six views — not six tools with six data models
Context preserved — a causal trace leads directly into a supplier boundary view on the same incident
Continuously updated — every new test run refines the graph; views reflect current system state
Sits above your toolchain — ingests from Vector, Dynatrace, SPREAD, replaces none
Living Knowledge Graph Traces Logs Arch. docs Topology View E/E Architect Causal Trace Integration Eng. Deviation Map Quality Eng. Supplier View Program Lead Health Surface Quality Lead All views render from one graph · Context preserved across views

See your system through the right lens.

PULSAR renders focused views of your system's runtime behavior from your existing telemetry — no dashboard configuration, no rip-and-replace.

Request a demo ↗