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.
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. No formulas, thresholds, weights, or private scoring logic are 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.