Active product development
SDVM is being developed to characterize how multi-step agentic workflows degrade across runs and to inform the design of workflows that are less susceptible to predictable pathologies. It uses reproducible computation, evidence sufficiency, and claims bounded by what the 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.
This is the problem space SDVM is being built to examine — not a claim that the integrated product already solves it end-to-end.
The failure signal arrives late. The drift started earlier. SDVM is being built to surface that earlier path.
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.
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 as an evidence-supported diagnostic system for agentic workflows — not another observability dashboard that only records activity or final outcomes.
For workflows already operating, 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 model is intended to inform the design of stages, handoffs, evidence-bearing artifacts, uncertainty handling, and correction loops — helping make the workflow less susceptible to predictable pathologies from the outset, and therefore more robust.
The construction-oriented use is part of the target product direction. It is not an externally available design-assurance service today, and the integrated diagnostic product remains under maturation.
SDVM does not start from a finished diagnosis. It starts from observable workflow activity and asks, step by step, what can be represented, checked, and computed without inventing missing context.
These structures are not only inputs to later diagnosis. They also expose design choices that can make a workflow easier to inspect, correct, and strengthen while it is still being built.
Different measures need different kinds of supporting material. A trace may show that activity happened without showing enough chronology, identifiers, revision links, or context to support a particular computation. SDVM is designed to report that limit — for example as insufficient, partial, or undefined — rather than fill the gap with inference. Sufficiency for a computation is not product readiness.
When input contracts are met, the core computes thirteen fixed measures — the canonical variables. They are lower-level, reproducible signals. They are not, by themselves, an integrated diagnosis, a recommendation, or proof of cause.
The four dimensions below are design vocabulary for reading coupling health. The thirteen variables are the operational measures with primary design associations to those dimensions in the current technical design. Several signals can also inform other dimensions; the grouping is not an exclusive or closed taxonomy.
Plain-language descriptions of what each deterministic computation measures. The variables are organized below by their primary design association. Some variables can also inform other dimensions; the grouping is not an exclusive or closed taxonomy. No formulas, thresholds, weights, or private scoring logic are published here.
A single run can show an event. Longitudinal analysis asks whether the same pattern persists, changes, or returns across cycles and repeated runs — and whether artifact versions and comparison windows make that reading valid. That layer is under active maturation; it is not offered as a finished external capability.
One variable rarely sustains a diagnostic hypothesis alone. Combinatorial diagnosis means combining multiple computed signals into a bounded hypothesis while preserving contrary evidence, sufficiency limits, and provenance. Correlation between signals is not causation. Example direction only: a workflow may generate many alternatives yet rarely revise decisions when new evidence appears — that combination can support a bounded hypothesis about shallow exploration, without proving why the behavior occurred.
Computed values still need a governed record that connects each signal to the observations, provenance, sufficiency status, and interpretation limits that support it — Diagnostic Evidence. Above that, the target Integrated Diagnostic Object is a governed consolidation of variables, supporting evidence, longitudinal patterns, bounded hypotheses, contrary signals, and claim limits. It is not merely a report, and it is not available as an integrated product today.
PRE preserves observations from a before state. POST preserves observations after a documented change. A valid DELTA requires more than subtracting two reports: the runs must be comparable, the evidence must support the same computations, and the interpretation must remain bounded. Difference is not proof of effectiveness or cause. An external PRE/POST/DELTA product contract is not available while the readiness gate remains blocked.
Trustworthy diagnosis requires a reproducible system of record — not a model improvising conclusions from incomplete traces.
This architecture is meant to create confidence: when SDVM can say something, the method is inspectable; when it cannot, it should say so.
A substantial technical foundation is in place. An integrated external diagnostic product is not.
Thirteen completed computation modules are not the same as an integrated diagnosis. Architecture documentation is not product availability.
Development advances from individual deterministic signals toward an integrated diagnostic product that can pass a formal readiness gate. The same maturity path supports both diagnosis of workflows in operation and, later, design guidance for workflows still being built. Fronts may progress in parallel.
Passing individual technical milestones does not authorize external diagnostic use. That decision belongs to the External Product Readiness Gate.
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 are not product versions, commercial grades, or shortcuts around the readiness standard. Tiers limit what outputs may claim; they do not lower the product standard.
For SDVM, pilot-ready means product-ready for bounded external use. A pilot is not a maturity exception. 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.
Public presence is not External Product Readiness. Public presence is not product availability.
Validation progresses in layers. Computing a signal correctly 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.
Before the External Product Readiness Gate passes, SDVM welcomes research, development, and strategic conversations — not external diagnostic pilots.
These activities are not external diagnostic pilots and do not promise integrated workflow diagnosis.
Discuss a research or strategic collaboration
Collaboration uses the public Action Preview Issues channel. Issues are public — do not post confidential data, private traces, or credentials. This is not 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.