LifePath OI Ecosystem
DSK V1.0
Deterministic-Testing Standard
DSK V1.0 Multi-Domain Deterministic-Testing Standard
1. Purpose
This standard defines the mandatory deterministic-testing categories every decision engine must pass to claim conformance with the DSK V1.0 determinism contract. It is published to force the market to prove determinism — or fail publicly. Any vendor may submit their engine's input → output pairs to the executable conformance harness; systems that pass appear on the public scoreboard.
2. Scope
The standard applies to any automated decision engine operating in the six regulated domains: credit, claims, clinical, trading, procurement, and employment. Conformance is per-domain — a system may be conformant in credit and not in clinical.
3. Test Categories
Every domain is evaluated against the seven test categories below. A domain passes iff no category fails and at least one case is exercised. The harness recomputes canonical hashes and verifies replay parity over the submitted pairs.
4. Submission Protocol
An evaluator with active Bridge access submits a vendor name, system label, and an array of { domain, input, output } pairs. The harness recomputes canonical input and output hashes, checks replay parity across duplicate inputs, aggregates per-domain verdicts, and returns a report with a cryptographic evidence hash. A clean full pass publishes the system to the public scoreboard; a partial pass returns the report only.
5. Scoreboard & Publication
Passed systems appear on the public conformance scoreboard showing vendor name, system label, domains passed, total and passed case counts, the evidence hash, and the submission timestamp. Failed submissions are not published — the scoreboard records only conformance, not failure.
6. Versioning
This standard is versioned (DSK-CONF-1.0). The harness version that produced a score is stamped on every scoreboard entry so historical conformance claims stay verifiable as the standard evolves.
Test Categories
1. Replay Parity
The same canonical input must produce a byte-identical output on every execution. Duplicate inputs in the submitted pair set must yield identical outputs — the defining determinism property.
2. Input → Output Hash Stability
A SHA-256 over the canonical input and a SHA-256 over the canonical output must be stable across runs. The submitter's claimed hashes must match the harness's recomputed hashes.
3. Canonical Serialization Determinism
Recursive key-sorting and deterministic ordering produce a canonical byte form independent of insertion order. The same logical input always serializes to the same bytes.
4. Constraint Inheritance Fidelity
Soft constraints must fire in a fixed precedence order, bound to the ruleset version that produced the receipt. The constraint chain is carried on the decision-state receipt.
5. Lineage Propagation Integrity
The prev_hash → chain_hash chain must be structurally intact: each link's prev_hash equals the prior link's chain_hash, with a null genesis prev_hash.
6. Drift Detection Across Ruleset Versions
Pinned regression cases must produce zero output drift across ruleset evolution. A historical receipt re-executed against its frozen ruleset version must reproduce the stored output hash.
7. Load-Tier Stability
Determinism must hold under load — p50, p90, and p99 latency parity must not introduce output drift. Volume and concurrency must not perturb the decision.
Conformance Domains
Self-Assessment Checklist
0/7