Controlled validation — not a general product release
For teams that can see traces, but still struggle to understand where the workflow is drifting, why repairs accumulate, and what tuning step should be tested next.
SDVM refers to four diagnostic dimensions: Synchrony, Depth, Vulnerability and Metacognition.
In long-horizon agentic workflows, the most expensive failures are often the ones that look like normal operation. Steps get skipped without triggering errors, repairs accumulate across cycles, handoffs introduce noise, and plausible outputs can mask gradual workflow drift.
Existing observability tools provide traces, events, costs and errors. SDVM is designed to add a diagnostic layer over that evidence: where the workflow is drifting, how strong the evidence is, and what targeted tuning step should be tested next.
The visible failure often appears late, after the workflow has already drifted.
Some runs look normal while degradation is already accumulating. The risk is the path that remains plausible before the failure becomes visible.
Stable execution
Skipped steps, repair pressure and handoff noise accumulate
The failure signal appears late
Trace evidence becomes comparative diagnosis and edge-focused tuning guidance.
SDVM is being developed as a diagnostic and tuning layer for agentic workflows. It is designed to sit on top of existing observability surfaces and convert trace evidence into workflow diagnosis.
SDVM reads workflow degradation through four diagnostic dimensions.
Its focus is not simply whether an agent produced a bad answer. The focus is how the workflow behaves across cycles: where it drifts, where it requires repair, where handoffs create friction, where expected steps are skipped, and where available evidence is still too weak for a strong conclusion.
SDVM takes a set of traces from the same recurring workflow — runs of the same task type across two observation windows — and applies its four diagnostic dimensions to produce a structured PRE/POST/DELTA comparison.
The output is not another trace view. It shows which signals moved between windows, what the magnitude of the shift was, how strong the evidence is for each finding, and which intervention lever is most likely to address the identified pattern.
Where evidence is insufficient for a strong conclusion, the report flags it explicitly. Interpretation limits are a first-class output, not a footnote.
A typical SDVM output is not another trace view. It is a compact diagnostic view of how a workflow changed, what evidence supports the assessment, and what tuning decision should be tested next.
Synthetic example — not client data PRE/POST/DELTA excerpt
| Signal | PRE | POST | DELTA |
|---|---|---|---|
| Repair pressure | 3.1 repairs / cycle | 1.2 repairs / cycle | −61 % |
| Handoff noise | 4 of 7 handoffs flagged | 1 of 7 handoffs flagged | −75 % |
| Step skip rate | 4 skips observed | 1 skip observed | −75 % |
| Evidence strength | 0.51 | 0.74 | +0.23 |
| Interpretation limit | Medium | Low-medium | Stronger, not definitive |
Recommended next intervention: Tighten checkpoint summaries and handoff contracts on the flagged edges where repair pressure and handoff noise increased before expanding workflow scope.
SDVM recommendations are designed to focus tuning on the workflow edges where the diagnostic signals concentrate, rather than applying generic fixes to the entire workflow.
Example only. Values are illustrative; actual reports depend on trace quality, workflow structure and available evidence.
Preferred early pilots are coding or bugfix-style workflows, but the fit is structural rather than domain-specific. Other agentic workflows may qualify if they have recurring task types, traceable multi-step execution, observable revisions, repairs or handoffs, and enough comparable runs for PRE/POST analysis.
SDVM pilots are intentionally narrow. The goal is to evaluate whether structured trace diagnosis can identify degradation patterns and guide one controlled workflow intervention.
Typical pilot shape: 2–4 weeks, depending on trace availability and team cadence.
In coding-oriented pilots, SDVM findings may be linked to workflow artifacts such as commits, pull requests or issue tickets to make diagnostic recommendations easier to review and act on.
SDVM is designed to be workflow-engine agnostic. The first validation track is narrow by design: coding and bugfix-style workflows, trace-based diagnosis, and Langfuse-first ingestion. This track was chosen because it provides repeatable, traceable, multi-step agentic runs with clear intervention points.
The broader design is intended to remain surface-agnostic, with future compatibility paths that may include observability surfaces such as Phoenix/OpenInference and LangSmith.
The goal is to validate the diagnostic model on real or semi-real workflows, refine evidence thresholds, and test whether the reports help teams make better workflow tuning decisions.
SDVM is being 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, a formal SDVM V3 technical specification and ongoing controlled validation on AI-assisted workflows.
Jamhour also brings prior executive experience in institutional finance and risk-sensitive operations, including the Stanford Sloan Fellows program.
I am currently looking for a small number of controlled pilot conversations with teams running recurring, traceable agentic workflows, with priority for coding or bugfix-style cases in the first validation track. The best candidates have traceable multi-step runs, enough history for PRE/POST comparison, and a clear owner for workflow tuning decisions.
Pilot analysis can be performed on anonymized traces and metadata. Data scope, access method and retention expectations are agreed case by case. NDA support is available when required.
If this matches how you work, you can start a scoped conversation using the email link below.
Pilot conversations are exploratory and scoped case by case.