Change one number in a decision record, and the verifier refuses it.
These packages write a record for each AI-assisted go/no-go decision, with the inputs and frozen rules that produced it. Anyone can recompute the decision offline later, without the system that made it.
The record as written
$ experiment-gate-verify run/decision.json run/decision.json: verifiedexit 0
Treatment conversions edited from 5486 to 5600
$ experiment-gate-verify edited.json edited.json: mismatch: input_sha256, metricsexit 1
Output of expgate 0.1.0 from PyPI, run on its bundled offer-ranker-v2 example (synthetic data).
The verifier recomputes the statistics from the stored input, so a changed number
changes the result.
Three decision points
Three small, independent packages. Each needs only Python 3.11+ and the standard library, and each verifies its own records offline.
| Decision | Package | Verify a record |
|---|---|---|
| Promote an experiment: SHIP, HOLD, ROLLBACK or INVALID from exported A/B aggregates | expgate |
experiment-gate-verify decision.json |
| Accept a typed model answer: yes/no, choice or score, gated on labeled cases | jevdecision |
jev-decision-verify answer.json |
| Approve an action: frozen routing policy, separate human reviewer, local ticket action | decisioncontrol |
decision-control replay --record record.json |
RELIA, the model-release gate in the same repository, is not published; its release is human-gated.
Install and verify
pip install expgate jevdecision decisioncontrol git clone https://github.com/BichengWang/ai-decision-system cd ai-decision-system experiment-gate --input ai-workflows/experiment-gate/examples/offer-ranker-v2.json --out /tmp/expgate-run experiment-gate-verify /tmp/expgate-run/decision.json
Features on main that are newer than the latest PyPI release install from
source; the quickstart
has the commands and each package's changelog says what is unreleased.
Schemas and conformance vectors
Each JSON Schema is served at the path its $id names. The conformance
vectors are records that must verify (valid), must be refused after an edit
(tampered) or must fail their schema (invalid), so a verifier in another
language can be tested against the same files. Digests use RFC 8785 canonical
JSON. The record conventions
describe the manifest format.
Schemas
schema/decisioncontrol/evaluation.v1.jsonschema/decisioncontrol/evaluation.v2.jsonschema/decisioncontrol/record.v1.jsonschema/decisioncontrol/record.v2.jsonschema/decisioncontrol/record.v3.jsonschema/decisioncontrol/record.v4.jsonschema/decisioncontrol/record.v5.jsonschema/expgate/decision.v2.jsonschema/expgate/decision.v3.jsonschema/jevdecision/answer.v1.jsonschema/jevdecision/answer.v2.jsonschema/jevdecision/evaluation.v2.jsonschema/jevdecision/provenance.v2.jsonschema/conformance/manifest.v1.json
Conformance vectors
conformance/decisioncontrol/manifest.json: 33 valid, 41 tampered, 40 invalidconformance/expgate/manifest.json: 15 valid, 10 tampered, 13 invalidconformance/jevdecision/manifest.json: 6 valid, 11 tampered, 11 invalid
What a record does not prove
- A digest detects a change, not a forger: whoever holds the tool can write a new record with matching digests. Signed records (an in-toto Statement in a DSSE envelope) show that the holder of a key signed the bytes, not who that person is.
- Names of proposers and reviewers are what the caller supplied; nothing here authenticates people or model providers.
- The examples and fixtures are synthetic. They show how the software behaves, not how any model or team performs in production.
- A record is not compliance evidence. The regulatory mapping says which logging questions it answers and which it does not.