Déjàdsr-verifier-cli
Open-source · offline-capable · independently auditable

The verifier.

dsr-verifier-cli is the reference implementation of the DSR/1.0 verification protocol. It reads a signed projection, independently recomputes every signature and chain hash, detects anomaly patterns automatically, and writes an unsigned JSON verification report — all without network access to Déjà. Heads of Risk, CISOs, audit-firm technologists, internal auditors, and regulators use it to verify evidence bundles on their own infrastructure under SOC 2 Type II, ISO 27001, NYDFS Part 500, DORA, or SR 11-7 obligations. Compatible with audit engagements at KPMG, Deloitte, EY, PwC, BDO, Grant Thornton, and independent firms.

version: v1.1.0 · pre-releaselicense: Apache-2.0standard: DSR/1.0platforms: linux · macOS · windowsnetwork: optional
Scenario 1 · Clean vaultIllustrative example

Verifying an intact projection.

Sarah Chen runs the verifier against the SOX Q1 2026 engagement after download. All 6,689 receipts verify, the chain is intact, and the tool writes a JSON verification report she can attach to her workpapers.

sarah@kpmg-mbp~/audits/ubs-sox-q1-2026
dsr-verifier-cli v1.1.0exit 0
$ dsr-verifier-cli verify-bundle SOX_Q1_2026_bundle.json --key ed25519:7fBxK2mP4nQ8vR3eL6jF1w

─── dsr-verifier-cli v1.1.0 ────────────────────────────────────────
  Bundle:       SOX_Q1_2026_bundle.json (18.2 MB)
  Engagement:   eng_01hxk4m9pq
  Vault:        vault_01hx2k · UBS Wealth Management
  Signer:       charles@ubs.com (vault admin)

 Bundle envelope valid
  Signed by vault admin · RE_01hxk4mp · 2026-02-04T09:02:11Z

 Manifest loaded
  6,689 receipts enumerated across 3 zones
  0.8s

 Signatures recomputed
  Signature      Algorithm   ed25519
  Content hash   Algorithm   sha256
  [████████████████████████████████████] 6,689/6,689
  3.2s · all signatures match

 Chain integrity verified
  Verifies the seven currently supported DSR/1.0 receipt types
  R1 → R2 chains:          2,308 / 2,308
  R1 → R1 (prior_match):      412 / 412
  0.1s

 Pattern analysis (cluster_analysis_v1)
  Anomaly count:           0 / 6,689
  No clustering analysis performed (threshold: anomalies ≥ 10)

─── Result ────────────────────────────────────────────────────
  ✓ VERIFICATION PASSED
  6,689 receipts · 100% integrity · 0 anomalies
  Total time: 4.1s

 Verification report written
  Output:        SOX_Q1_2026_bundle.verification.json (unsigned JSON summary)

Next steps:
  · Attach SOX_Q1_2026_bundle.verification.json to your audit workpapers
  · Share with engagement admin at charles@ubs.com

$ 
The verifier does not call home. The bundle is self-contained — receipts, signatures, verifier public keys, and the chain graph all travel with it. Sarah could run this on an air-gapped machine inside KPMG's SCIF and get identical results. The .verification.json report can then be attached to audit workpapers as the record of verification.
Scenario 2 · Anomalies detectedIllustrative example

Verifying a compromised vault.

The same command, run later on a different bundle, detects 50 anomalies across 4 categories. The built-in cluster_analysis_v1 module automatically surfaces the pattern — the auditor doesn't have to spot it by eye.

sarah@kpmg-mbp~/audits/ubs-sox-q1-2026
dsr-verifier-cli v1.1.0exit 2
$ dsr-verifier-cli verify-bundle SOX_Q1_2026_bundle.json --key ed25519:7fBxK2mP4nQ8vR3eL6jF1w

─── dsr-verifier-cli v1.1.0 ────────────────────────────────────────
  Bundle:       SOX_Q1_2026_bundle.json (18.2 MB)
  Engagement:   eng_01hxk4m9pq
  Vault:        vault_01hx2k · UBS Wealth Management

 Bundle envelope valid
  Signed by vault admin · RE_01hxk4mp · 2026-02-04T09:02:11Z

 Manifest loaded
  6,689 receipts enumerated across 3 zones · 0.8s

 Signatures recomputed — mismatches detected
  [████████████████████████████████████] 6,689/6,689
  6,677 valid · 12 mismatched signatures
  3.3s

 Chain integrity — references broken
  Verifies the seven currently supported DSR/1.0 receipt types
  R1 → R2 chains:          2,304/2,308 (4 broken)
  R1 → R1 (prior_match):      412 / 412
  0.1s

 Manifest reconciliation — missing entries
  Projection references 31 receipt hashes that resolve to no receipt.
  Affected zone: payments-checkout
  First occurrence: 2026-02-14T09:22:11Z
  Last occurrence:  2026-02-17T14:08:44Z

 Temporal consistency — inversions detected
  Receipts whose prior_hash references a FUTURE-signed receipt.
  This is physically impossible in an honest chain.
  3 inversions across 3 receipts · payments-checkout
  0.0s

─── Pattern analysis (cluster_analysis_v1) ─────────────────────────
  Anomaly count:            50 / 6,689 (0.7%)

  Categories:
    · missing_entries:         31
    · signature_mismatches:    12
    · broken_chain_refs:        4
    · timestamp_inversions:     3

   zone_concentration:    94% (47/50) in payments-checkout
     Expected under null (uniform): ~33%
     p-value:                       < 0.001

   temporal_clustering:   72h window · 2026-02-14 → 2026-02-17
     Anomaly rate in window:        ~50× baseline
     p-value:                       < 0.001

   cascade_detected:      yes
     All 4 broken_chain_refs target receipts in missing_entries.
     All 3 timestamp_inversions target receipts in missing_entries.
     Conclusion: single underlying event, not independent failures.

   pattern_signature:     consistent_with_targeted_deletion
     Plus partial replacement attempt (inversions suggest forged receipts
     with implausible timestamps, then inserted into chain).

   confidence:            0.91
     Bounded. The CLI does not conclude tampering occurred — further
     investigation required. See full report in .verification.json.

─── Result ────────────────────────────────────────────────────
  ✗ VERIFICATION FAILED
  6,689 receipts · 99.30% integrity · 50 anomalies in 4 categories
  Total time: 4.2s

 Verification report written
  Result:        invalid
  Anomalies:     50 (across 4 categories)
  Pattern:       consistent_with_targeted_deletion (confidence 0.91)
  Output:        SOX_Q1_2026_bundle.verification.json (unsigned JSON summary)
  Manifest:      ./anomalies_01hxr8ym.json (50 entries)

Next steps:
  · Preserve current vault state and adjacent infrastructure logs
  · Review full anomaly manifest: jq '.anomalies[]' anomalies_01hxr8ym.json
  · Re-verify after remediation (passing verification supersedes failed report)

$ 
The CLI verifier writes an unsigned JSON report for both outcomes. The hosted web verifier issues a signed RV on a clean run and raises an integrity incident on failure. The CLI report carries verification_result: "invalid" and an anomaly_categories block matching the pattern analysis. A subsequent passing re-verification supersedes this report; it does not erase it.
About cluster_analysis_v1

Automated pattern detection.

The verifier's cluster_analysis_v1 module runs whenever the anomaly count crosses 10. It does not make subjective calls; it runs three statistical tests, plus a deterministic pattern label derived from them, and reports the results. Pattern detection is machine work, not auditor interpretation — which makes findings more defensible in regulatory correspondence.

zone_concentration
Spatial clustering
Tests whether anomalies concentrate in specific zones vs. the uniform null distribution. Reports percentage and p-value. Thresholds: > 80% concentration in one zone is flagged.
temporal_clustering
Temporal clustering
Applies a scan-statistic over the signing-time distribution. Identifies the smallest time window containing the highest anomaly density. Reports baseline anomaly rate multiplier.
cascade_detected
Cross-category cascade
Tests whether anomalies in different categories reference the same set of receipts. A cascade suggests a single underlying event, not independent failures — collapses N anomalies into 1 root cause.
pattern_signature
Named pattern matching
Matches anomaly distribution against known tampering signatures. Output values include consistent_with_mass_rekey, consistent_with_targeted_deletion, consistent_with_isolated_corruption, nominal. Never asserts; reports best match with confidence.
Access

The verifier is in active development. Charter customers receive early access ahead of public release, including direct support from the founding team during their first audit engagement. The reference implementation will be published under Apache-2.0 with binaries for linux-amd64, linux-arm64, darwin-amd64, darwin-arm64, and windows-amd64 as Charter deployments come online.

Audit-firm technologists running pre-release evaluation against test vaults, regulators conducting protocol review, and Charter customers preparing their first audit engagement should reach out directly.

Reach out to the founding team
REFERENCES · DEEPER MATERIAL
Receipt Types · DSR/1.0 →
Ten receipt types · canonical envelope · spec-vs-implementation note
The Engine →
CCS scoring · validation gates · what the verifier verifies
System Documentation →
Glossary · entity model · integrations · service-level objectives
Security →
Cryptographic posture · SHA-256 signing · tenant isolation · DPA
Patent Family →
Filed claim language · Edge Parser embodiment · USPTO record
Déjà →
Product overview · pricing · audit-firm verification model