Keep useful detail
Compact binary events separate changing values from information already known at build time. The design reduces repeated metadata and defers readable message formatting until investigation.
COMMERCIAL PRODUCT / SARVALEKHA
The whole story
of your software.
A platform in development for software-lifecycle accountability, stability, and analytics. Connect code, builds, runtime behavior, and the evidence your team needs to make a product better.
AccountabilityEvidence tied to the exact software build
StabilityContext for investigating failures
AnalyticsThe next layer of product insight
THE OPPORTUNITY
Make every investigation
start with better evidence.
When a customer reports a failure, the useful questions are connected: which build ran, what happened, and where in the code did it begin? Sarvalekha brings those relationships into the diagnostic workflow.
Investigate the right build
Automatically generated catalogs connect events to their exact build. Source verification helps an engineer move from a readable event to the code that produced it.
Connect development and support
Give developers, quality engineers, and support teams a common evidence trail: structured events, retained logs, build identity, and supported crash data.
CURRENT FOUNDATION
From application behavior
to an understandable record.
The implemented foundation focuses on native C++ applications and practical investigation. These capabilities are in development and evaluation; release qualification is still in progress.
Compiler-assisted logging
Supported logging calls, structured key/value data, and named events produce compact runtime records. Build tooling generates their descriptions and identities automatically.
Exact-build catalogs
Pair logs with the catalog created for the same build. Keep message descriptions and source identity together so diagnostic evidence retains its meaning across releases.
Local and IDE investigation
Inspect logs and managed log sets in the desktop viewer or active VS Code integration. Read events, filter details, and navigate to verified source when it is available.
Crash evidence
Recover retained, committed log records from supported Windows x64 full-memory minidumps using the exact catalog. What can be recovered depends on the memory captured in the dump.
Collection and shared access
A Windows Helper and server preview support resumable uploads of completed native log files, catalog lookup, and durable artifact storage for a scoped evaluation.
Browser investigation
The current server provides bounded event search, event details, and native export in a browser. Search can narrow results by time, severity, category, and message.
THE WORKFLOW
Describe once. Understand later.
Build
Discover logging descriptions and generate the matching catalog alongside your application.
Run
Record event identity, timing, and changing values in the native binary format.
Investigate
Reconstruct readable events using the exact catalog, locally or through the server preview.
Improve
Use the evidence to diagnose a failure, examine behavior, and guide the next software change.
A CONNECTED PRODUCT VISION
A fuller account of the
software lifecycle.
The direction is a single platform connecting development, release evidence, customer incidents, and operational learning. Today's logging and diagnostic foundation is the starting point for that broader view.
Evaluate the foundation today
Start with one C++ application and a real investigation: capture useful events, retain the matching catalog, and reconstruct the evidence in the intended viewer.
Measure application overhead, retained storage, and investigation effort against your existing workflow. The value should be demonstrated on your workload.
Planned platform capabilities
Broader analytics, dashboards, alerting, first-class distributed tracing, and managed collaboration extend the product vision. Enterprise identity and wider deployment support also remain on the roadmap.
The current server searches bounded native logs; it is not yet the full analytics platform. Scope and availability can be discussed for a specific evaluation.
Current fit: performance-sensitive native products, customer-installed applications, quality and release engineering, and teams that need build-specific diagnostic evidence. Supported configurations and rollout requirements are agreed during evaluation.
LET’S EXPLORE THE FIT
Bring a difficult
diagnostic problem.
Tell me about your application, its environment, and the evidence you wish you had. We can shape a focused Sarvalekha evaluation around it.