Active product development
SDVM is a deterministic system for characterizing how multi-step agentic workflows degrade — and for guiding design, instrumentation, and evidence choices so workflows under construction are structurally less susceptible to predictable failure modes. It computes only what the available evidence supports.
Active product development · External product use is not yet available.
In long-horizon agentic workflows, steps can be skipped without hard errors. Repair pressure accumulates across cycles. Handoffs inject noise. Outputs can still look plausible. By the time a visible failure appears, the workflow has often already drifted — and evaluation that watches only final outputs arrives late.
Silent degradation is a path, not a single event: skipped steps, repair loops, and handoff friction can accumulate while runs still look successful.
The failure signal arrives late. The drift started earlier. SDVM is being built to surface that earlier path — and to inform design choices that make those paths less likely.
Stable execution
Skipped steps, repair pressure and handoff noise accumulate while the run still looks plausible.
The failure signal appears late
Agentic systems are moving into operational use faster than diagnosis of mid-trajectory degradation has matured. Independent research and enterprise analysis describe the same class of gap SDVM is being built to examine. These references establish that the problem exists; they do not validate SDVM’s approach.
Aggregate success metrics can hide critical operational failures—inconsistency, weak robustness, unpredictability, and unsafe error behavior.
Towards a Science of AI Agent Reliability arXiv preprint
Agentic systems no longer stop at outputs. They trigger actions, call tools, and affect downstream systems—raising the cost of weak monitoring and governance.
State of AI trust in 2026: Shifting to the agentic era McKinsey Tech Forward
SDVM is being built around a single evidence-supported diagnostic model — not another observability dashboard that only records activity or final outcomes. The same contracts that bound diagnosis also orient how workflows are designed.
For workflows already running, SDVM is intended to characterize where degradation emerges, how patterns persist or change across cycles and runs, and which diagnostic hypotheses the available evidence can support — while keeping unsupported claims blocked.
For workflows still being built, the same diagnostic contracts are intended to orient decisions about stages, handoffs, instrumentation, evidence-bearing artifacts, uncertainty handling, and correction loops. A workflow shaped this way is not merely easier to tune later — it is structurally less susceptible to certain failure modes because design and evidence choices follow the same rules used for diagnosis.
SDVM does not promise to understand arbitrary raw traces. Decisions, evidence, uncertainties, and revisions reach the deterministic core only when the workflow produces or preserves them — and when adapters can normalize them into a common representation the core can consume.
Identifying decisions, evidence links, uncertainties, and counter-hypotheses in arbitrary traces would require semantic inference the deterministic core does not claim. Those structures must be produced, preserved, or explicitly mapped — they are not recovered by guessing from unstructured logs.
A future assistive AI layer may help above this core — for explanation, instrumentation planning, or design discussion — but it must not replace the deterministic system of record or silently alter computed facts.
One controlled path from a synthetic fixture to a bounded finding for Repair Rate (RR) — enough for a technical reader to see what is calculated, what is refused, and where determinism starts.
Synthetic example derived from a real controlled fixture and contract tests already present in the product repository’s canonical mainline. Reduced to a public projection for disclosure. Not a production workflow, not external validation, and not the private scoring surface.
A four-event cycle window records start, an LLM call, a tool call, and an end. Two of those events carry an explicit is_repair label supplied by the fixture. Tier 0 RR can run because the trace is parseable and non-empty; the labels determine the repair count — a structural repair-density counter, not a quality judgment.
Public projection of the fixture events. Fields shown are the ones this path actually uses. This is not the full private wire format.
{
"cycle_id": "sync-trace-counter-audit-pos-001",
"events": [
{ "timestamp": "2025-01-01T00:00:00", "event_type": "start", "agent": "agent-1", "is_repair": false },
{ "timestamp": "2025-01-01T00:01:00", "event_type": "llm_call", "agent": "agent-2", "is_repair": true },
{ "timestamp": "2025-01-01T00:02:00", "event_type": "tool_call", "agent": "agent-3", "is_repair": false },
{ "timestamp": "2025-01-01T00:03:00", "event_type": "end", "agent": "agent-4", "is_repair": true }
]
}
In this controlled fixture, is_repair is an explicit contractual label supplied with each event. The events are already shaped for the common cycle-trace representation the core consumes. Adapters map external traces into that shape and preserve the label; they do not infer repair semantics from free-form text. In a real workflow, an equivalent fact would need to be emitted or preserved upstream under the evidence contract.
cycle_id, timestamp, event_type, agent, and boolean is_repair when present."is_repair": true → common event field is_repair = true (eligible for the repair count). An event_type such as llm_call is not treated as a repair unless the label says so.is_repair unset — they do not recover it from unstructured logs.
Evidence Sufficiency answers whether RR can be computed from the trace. The explicit is_repair labels answer which valid events enter the repair count. These are separate questions. Private sufficiency thresholds beyond this gate are not published here.
sufficient Non-empty parseable events
Present: four valid parseable events. Computation is authorized for Tier 0 RR on this controlled path. The is_repair labels do not authorize the compute; they feed the numerator once computation is allowed.
insufficient Empty event list
Same cycle shape with events: [] yields status insufficient_evidence, blocking reason empty_trace_events, and computed_value: null. The calculation does not run.
An empty trace blocks computation. A non-empty valid trace with no is_repair: true events can still produce a computed RR of 0.0 — that is a computed result, not insufficient evidence. Still prohibited after a sufficient compute: treating the density as proof of repair effectiveness, workflow improvement, or production-ready diagnosis.
Variable RR · status computed · Tier 0 structural. Deterministic output from the fixture above (exact test expectation):
{
"variable_key": "rr",
"computation_status": "computed",
"computed_value": 0.5,
"auxiliary_values": {
"repair_count": 2,
"total_valid_events": 4
}
}
Evidence link: two events labeled is_repair: true among four valid events produce computed_value: 0.5. The basic arithmetic relation shown here — repair events over total valid events — is public. Thresholds, weights, composite scoring, and private interpretation rules are not disclosed.
On this controlled fixture, a structural repair-density counter for the cycle window was computed. The value is a lower-level signal under an explicit input contract — a repair-rate candidate, not a completed diagnosis.
Same public path with an empty event list. Status and blocking reason match the product’s Tier 0 / Evidence Sufficiency tests for RR.
{
"variable_key": "rr",
"computation_status": "insufficient_evidence",
"computed_value": null,
"blocking_reasons": ["empty_trace_events"]
}When input contracts are met, the deterministic core computes thirteen fixed measures — the canonical variables. They are reproducible lower-level signals. They are not, by themselves, an integrated diagnosis, a recommendation, or proof of cause.
These structures are inputs to diagnosis and design levers during construction: choosing how stages, handoffs, and evidence-bearing artifacts are shaped changes what can later be inspected and corrected.
The four dimensions below are design vocabulary for reading coupling health. The thirteen variables have primary associations to these dimensions in the current technical design. The grouping is not an exclusive taxonomy.
Plain-language descriptions of what each deterministic computation measures. Thresholds, weights, composite scoring, and private interpretation rules are not published here.
Implementation, internal validation, runtime integration, and external product readiness are different layers. They must not be read as the same claim.
Thirteen canonical computation modules are implemented and covered by controlled fixtures and contract tests. That is computational implementation — not integrated diagnosis, not runtime completeness across every path, and not external validation.
Work advances from individual deterministic signals toward an integrated diagnostic product that can pass a formal readiness gate. The same path supports diagnosis of workflows in operation and design guidance for workflows still being built. Fronts may progress in parallel.
An evidence tier describes the quality and availability of instrumentation and supporting material for a workflow — what can be computed and what claims remain out of bounds. Tiers limit what outputs may claim; they do not lower the product standard or substitute for readiness.
For SDVM, pilot-ready means product-ready for bounded external use. Human assistance may support framing, instrumentation, and explanation — it must not substitute for a missing diagnostic engine.
Current status: BLOCKED — not ready for external diagnostic pilot.
Computing a signal correctly under fixtures is not the same as proving diagnostic utility or real-world value.
Real-world value evidence comes after external product validation — not before. ROI is not claimed.
While the readiness gate remains blocked, the useful next step is technical interlocution — not a product engagement. Open a public GitHub issue when you want to discuss one of the topics below.
Open a technical collaboration issue
Issues go to the public Action Preview channel so technical discussion stays inspectable. Use an issue for instrumentation, evidence contracts, workflow fit, or validation design — not for confidential traces, credentials, or a diagnostic pilot request.
SDVM is developed by Ibrahim José Jamhour, an independent researcher working on Distributed Relational Cognition and the operational risks of agentic systems. The work builds on published research and the formal SDVM V3 technical specification.
Jamhour also brings prior executive experience in institutional finance and risk-sensitive operations, including the Stanford Sloan Fellows program.