DSI · decision-space integrity

Getting started

Run the audit spine locally.

DSI is a local advisory-assurance sidecar. It audits a supplied prompt and response against a configured expected map, then returns coverage, omission, intervention, and evidence outputs. This page shows the quickest way to inspect the product, run an audit, and understand the repository structure. It runs entirely on your machine; in the primary pattern it makes no provider call and retains nothing between requests.

Quick start

Run DSI locally in minutes.

DSI installs as an ordinary Python package. One command creates a virtual environment, installs it, and starts the local server; the manual steps are below if you prefer to run them yourself.

What you'll see: the test suite passing, then a local server at http://127.0.0.1:8000/ serving the audit dashboard.

# one command: venv + install + serve
./run_local.sh                 # Windows: .\run_local.ps1

# or step by step:
git clone <dsi-product>
cd dsi-product
python -m venv .venv
. .venv/bin/activate           # Windows: .venv\Scripts\Activate.ps1
pip install -e ".[api]"        # core only: pip install -e .
python -m pytest               # run the test suite

Run the local API

Serve the dashboard and API.

One command starts the local server (dashboard at /, interactive OpenAPI at /docs). It prints whether API authentication is enabled.

python -m dsi serve             # serves on 127.0.0.1:8000
curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/version

Docker is also supported: docker build -t dsi-product:local . then run it bound to 127.0.0.1:8000. See the runbook in the product repository for the full install / verify / package guide.

Minimal audit

Submit a prompt and response.

You send the prompt and the response your system already produced; DSI returns an assurance result. Worked request, response, and evidence payloads ship in the repository's examples/ directory.

# audit a supplied prompt + response
curl -X POST http://127.0.0.1:8000/v1/audit \
     -H "Content-Type: application/json" \
     --data @examples/audit_request.json

If API authentication is enabled, add a -H "X-API-Key: …" header. The example files below are ready to use as request bodies.

  • examples/audit_request.json · audit_response.json — a single audit.
  • examples/control_loop_request.json · control_loop_response.json — audit, control decision, and re-audit visibility delta.
  • examples/evidence_bundle.json — the portable evidence bundle (with a deterministic audit_id).

What the audit returns

Visibility outputs, with evidence.

  • expected-map fingerprint
  • per-trajectory classifications (surfaced / partial / omitted / discouraged)
  • coverage score
  • omitted paths (required paths flagged)
  • an intervention recommendation, if triggered (a regeneration instruction — DSI does not generate the response)
  • a re-audit visibility delta, if control-loop mode is used and you supply the regenerated response
  • a portable evidence bundle (JSON or Markdown)

These outputs measure configured expected-path visibility. They do not measure advice quality, factual correctness, safety, regulatory compliance, or user outcomes.

Deployment modes

The same spine, your choice of retention.

A · STATELESS

Stateless audit

Evidence is returned to the caller and not retained by DSI. Lowest footprint; privacy-sensitive environments.

B · PERSISTENT

Persistent audit

Evidence may be retained for review or operational monitoring. Persistence is a deployment choice over the same measurement spine, not a new capability.

C · GOVERNANCE

Governance evidence

Evidence can be exported to an existing governance or audit system. DSI supplies evidence; external systems manage governance.

DSI does not require ownership of evidence persistence. Evidence may be caller-managed, DSI-managed, or externally managed — the measurement spine is unchanged in every case.

Repository structure

What is in the product repository.

dsi-product/
├── README.md
├── pyproject.toml
├── Dockerfile · docker-compose.yml
├── run_local.sh · run_local.ps1
├── src/
│   └── dsi/
│       ├── core/          # audit spine, maps, scoring
│       ├── api/           # local API server
│       ├── ui/            # dashboard
│       └── version.py     # version source of truth
├── examples/              # request / response / evidence
├── docs/                  # runbook, deployment modes
└── tests/                 # contract, unit, golden, stateless

Where to start

Four ways in.

Run the product

Install and serve locally (above). The full install / verify / package runbook is in the product repository.

Understand deployment

Stateless, persistent, or governance-evidence — over one unchanged spine. Documented in the product repository's deployment-modes guide.

Inspect evidence

Worked evidence bundles ship in examples/; the export patterns are documented in the product repository.

Read the research

The phenomenon, the measurement framework, and the evidence status. Research & evidence →

The public site summarises these documents; the full deployment runbook, deployment-modes guide, and export examples are available in the private product repository.

DSI audits supplied AI advisory outputs against configured expected maps. It is a visibility and evidence layer — not a language model, recommender, policy engine, governance workflow system, or safety-certification tool.