The product · v0.2.1
A local, stateless assurance sidecar.
A self-hosted, stateless omission-assurance sidecar. You send it a prompt and the response your system produced; it returns an assurance result and a portable evidence bundle. It runs entirely on your machine; in the primary pattern it makes no provider call and retains nothing between requests.
DSI produces evidence-backed omission reports: expected points, surfaced points, omitted points, source evidence, and a reproducible fingerprint.
Where DSI fits
One layer in your assurance stack.
DSI is designed to sit beside an existing AI system as a visibility and evidence layer. It audits the response your system already generated, identifies configured expected paths that may be missing, supports re-audit after regeneration, and exports evidence.
The advisor optimises for an answer; DSI checks whether configured decision paths remain visible. It does not make the primary recommendation. It audits what was preserved, omitted, or narrowed.
DSI does not authorize actions, certify compliance, or replace policy enforcement. It measures whether configured expected paths remain visible in AI-generated responses and records evidence of that audit.
Positioning
Decision control is not language generation.
DSI does not compete with model architecture. It changes what advisory systems are measured against. A language model can generate a fluent answer while still narrowing the visible decision space. DSI treats decision-space visibility as a separate measurement problem: which configured paths remained visible, which were omitted, and whether recovery preserved the structure of meaningful choice under configured constraints.
DSI measures configured expected-path visibility. It does not measure advice quality, factual correctness, user outcomes, regulatory compliance, or model superiority.
The assurance loop
Four steps, on a response you supply.
Audit
The response is assessed against a configured map of reasonable option paths for the domain. You get expected-path visibility, the surfaced paths, and the missing expected ones (with required ones flagged).
Visibility recommendation
Where a configured policy warrants it, DSI recommends which paths to surface and supplies an instruction for your system to regenerate. DSI does not generate the response.
Re-audit
Supply your regenerated response and DSI reports the visibility change (before → after). This is a visibility re-audit, not a quality or safety improvement.
Evidence bundle
A portable, fingerprinted, reproducible record with a stable audit identifier.
Regression Audit
Compare two builds under one instrument.
Give DSI paired outputs — a baseline and a candidate over the same prompt set — and it reports which configured expected paths changed in visibility between them, under the same fixed instrument. Useful when a model version, prompt, or configuration changes and you want reproducible evidence of what moved. It reads paired output sets and returns a per-trajectory verdict with provenance.
Regression Audit reports instrument-relative changes in expected-path visibility. It does not conclude that one build is objectively better, safer, or of higher quality, and it marks behaviours it cannot reliably measure as instrument-limited rather than a regression.
The trust chain
Where did this come from?
Every result answers that question in seven steps. Each step is reproducible from the fingerprints in the bundle, so a third party can reproduce and bound any number DSI reports.
Configured expected map
Context projected
Response classified
Visibility analysed
Visibility recommendation
Re-audit
Evidence available
How you run it
A package, or a container.
- Python package: pip install the API/dashboard extra and run one command; open the local dashboard, paste a prompt + response, and audit it.
- Container: docker run the image; same dashboard and API, nothing written to disk.
- Interfaces: a small HTTP API (audit · control-loop · evidence, with /health, /ready, /version) and a local dashboard. No provider keys, no database, no cloud dependency.
- Verify: dsi doctor checks the install is ready to run audits; dsi validate-install runs a real audit end to end.
Both paths are verified to build and run from a clean install. See the four supported deployment profiles, the security & operations notes, and getting started.
What DSI is not
Not a generator
It audits a supplied response and recommends what your system should surface; it never writes the advice.
Not a safety or compliance certification
It reports configured expected-path visibility, not quality, safety, correctness, or compliance.
Not a monitoring platform
It is stateless and keeps no history; if you want trends or retention, export the evidence bundles to a system you already run.
Not a replacement for your stack
It does not replace your model, retrieval, or policy stack. It sits beside them.
What DSI does — and does not — measure
This work measures visibility of configured expected paths in model outputs. It does not measure advice quality, factual correctness, user outcomes, or regulatory compliance.
DSI is designed to complement, not replace, factuality checks, safety reviews, domain validation, or compliance processes. It supports governance documentation; it does not certify governance or safety.