Local Reconstruction Inspector · Public beta

Inspect what your trace can establish.

Tracevity Inspect applies an explicit dialect binding and a named reconstruction requirement to a local trace, then produces a deterministic, evidence-linked report. The trace remains on your machine.

What does Tracevity Inspect do?

It evaluates reconstruction sufficiency, not telemetry volume.

Inspect safely decodes a supported trace, preserves exact structural trace locators and privacy-preserving bindings for external locators, evaluates each requested capability, and reports what is established, partial, missing, indeterminate, or dependent on external evidence. It does not infer hidden reasoning and never produces a universal score.

The operational sequence

Trace Map → compatibility → Inspect → Gate

Public research defines the evidence vocabulary. Exercised bindings establish the narrow representations Tracevity has handled. Local inspection applies both to the artifact and reconstruction target you select. Gate carries the resulting semantics into repeatable release and migration checks.

01

Declare

Choose the trace dialect, exact version, signal kind, and requirement profile.

02

Correlate

Preserve IDs, hierarchy, structural trace locators, privacy-preserving external locator bindings, and explicit external evidence.

03

Conclude

Return each result with the evidence used, limitation, and proof ceiling.

04

Gate

Compare baseline and candidate reconstruction outcomes under one evaluator.

Supported surface · exact declarations

Four declared dialects. One primary signal.

The primary input must be an OTLP trace payload. OTLP logs and metrics are recognized as unsupported signals rather than treated as traces. A compatible attribute signature does not prove which product produced the artifact.

Declared dialectPinned versionInterpretation boundary
OpenTelemetry GenAIopentelemetry_genaiPinned development revision 67dff024OTLP trace protobuf only; a declared dialect does not prove producer identity.
OpenInferenceopeninference0.1.33OTLP trace protobuf carrying compatible OpenInference attributes.
MLflow Tracing nativemlflow_native3.15.2Native MLflow semantics carried in OTLP trace protobuf.
MLflow GenAI-transformedmlflow_genai_transformed3.15.2The bounded MLflow GenAI transformation represented in OTLP traces.

Does my trace leave my machine?

No. Inspect is local-only by construction.

The public website has no file input, upload endpoint, server action, trace store, or remote Inspector. The local engine has no analytics, model call, hosted callback, crash reporter, or update check. It parses trace contents strictly as data.

$ tracevity inspect --manifest manifest.json --requirements requirements.json --out report.json

This build does not assert public package availability. Inspection remains network-free, and the website publishes synthetic examples only.

Installation and quickstart

From reconstruction to regression policy

Use the same evidence semantics to gate a release or migration.

Tracevity Gate replays baseline and candidate inputs through the same current Inspector, then blocks when a required reconstruction outcome becomes weaker. A valid trace can still fail when correlation, verification, support, or capture quality regresses.

Read the Gate guide

Machine-readable contracts

Validate the Inspector inputs and report.

These versioned JSON Schemas define the local invocation boundary. They do not authorize upload or expand the four declared dialects.

JSON Schema

Inspection Manifest v0.1

Declares the local artifact, exact dialect, version, signal, and binding.

Download schema

JSON Schema

Correlated Evidence Envelope v0.1

Carries explicit external evidence with provenance and correlation keys.

Download schema

JSON Schema

Reconstruction Report v0.1

Defines the deterministic result, evidence locators, limitations, and digest.

Download schema

Trace-only answer → required evidence

Proof ceilings stay visible.

External evidence can strengthen a reconstruction only when its provenance and strong correlation meet the named requirement. Providing a JSON record does not make its real- world claim independently authenticated.

Can an OTLP trace identify the person who initiated an agent?

Trace-only answer
Only when qualifying principal evidence is explicitly present and correlated.
Required evidence
Otherwise, a strongly correlated identity record is required.
Proof ceiling
Agent or service identity alone cannot establish the initiating principal.
initiating_principal = NOT_ESTABLISHED

Does a successful tool span prove an external action settled?

Trace-only answer
It can establish the recorded request and tool-reported result.
Required evidence
Destination-system or external-state evidence joined by a strong identifier.
Proof ceiling
Tool-reported success is not provider acceptance or destination settlement.
external_effect_state = EXTERNAL_EVIDENCE_REQUIRED

Does missing trace data prove an event did not happen?

Trace-only answer
Not when sampling, dropped records, or truncation leave capture incomplete.
Required evidence
Capture provenance or another complete, correlated evidence source.
Proof ceiling
An incomplete capture cannot support a definitive negative conclusion.
reconstruction = INDETERMINATE_CAPTURE_INCOMPLETE

Conformance vs reconstruction

Different questions, complementary tools.

OpenTelemetry and OpenInference conformance work asks whether instrumentation follows its declared semantic contract. Tracevity consumes resulting evidence and asks whether it is sufficient for a named reconstruction need. Parseable or conformant telemetry can still lack principal, authority, correlation, completeness, or destination-state evidence.

Standards conformance

Was the representation emitted as specified?

Tracevity does not replace standards-owned conformance or reference tooling.

Trace reconstruction

What can this evidence establish for this use case?

The Inspector reports concrete evidence, missing evidence, correlation, and the strongest conclusion justified by the inputs.

Safe synthetic examples

Read deterministic Reconstruction Reports.

These examples contain synthetic evidence only. They illustrate report semantics, not vendor certification, comprehensive support, or independently authenticated production truth.

Synthetic JSON report

Basic debugging report

Model and tool evidence reconstructed from a supported synthetic OTLP trace.

Open sample report

Synthetic JSON report

Tool success without settlement

A synthetic trace that establishes a tool-reported result while leaving external state unverified.

Open sample report

Synthetic JSON report

Destination evidence closes a bounded gap

Strongly correlated synthetic destination evidence strengthens only the external-state result.

Open sample report

Synthetic JSON report

Incomplete capture remains indeterminate

Sampling, drop, and truncation evidence prevents an absent record from becoming a negative fact.

Open sample report

Start with Trace Reconstruction Requirements, inspect the exact tested boundaries in compatibility, and read the evidence methodology before interpreting a result.