Architecture
QUORUM separates a deterministic real-time decision path from asynchronous AI analysis, and records every decision so that it can later be proven to a third party. This page summarises the architecture; the full technical reference (QRM-ARCH-001 Rev 2.0) is available to institutions under NDA.
01 // Decision Pipeline
02 // Decision Channels
Every channel maps its input to the same rule facts and leaves out anything the input does not carry, so no channel invents defaults such as "CVV matched". Requests are authenticated and scoped to one institution.
Channels
03 // Fail-Closed Behaviour
If the rule engine cannot evaluate an event, or the decision cannot be recorded, QUORUM issues no verdict rather than a silent "allow". The response says so in each channel's own terms.
No-Verdict Responses
04 // Decision Flow
Real Time, Then Review
The verdict is computed and recorded synchronously. Deep analysis by the three AI tiers — Sentinel (behaviour), Inquisitor (financial context) and Adversarial (evasion) — runs afterwards from a worker queue. When the tiers disagree or risk is high, an arbitrator weighs their reasoning. The result is evidence for analysts.
05 // Performance & Measurement
Rule Evaluation
Rules run inside the decision service; the AI models are not on the real-time path.
Latency Percentiles
Per-channel latency under a defined load will be measured and published with its test conditions. No latency SLA is claimed today.
Detection Accuracy
Not yet measured on a labelled dataset. Pilots run in shadow mode to measure detection, false positives and analyst effort.
06 // Audit Logging Structure
Tamper-Evident Decision Ledger
Each decision is stored as a canonical record — verdict, score, flags, reference, time and a SHA-256 digest of the inputs (never the raw inputs). Every few seconds a sealer places each institution's new records under a Merkle root and appends one ledger entry carrying that root. Each ledger entry holds the previous entry's hash and is signed with Ed25519 and ML-DSA-65.
The ledger is stored in PostgreSQL, so it is tamper-evident rather than immutable: a privileged database user could change it, but any change to an anchored entry is detectable without trusting QUORUM. Institutions should restrict write access and archive anchored roots outside the database.
Decision Proof
Record → batch root → signed ledger entry → ledger root.
Timestamp
Ledger root timestamped by an RFC 3161 authority when one is configured.
Score Proof
Zero-knowledge proof that the score was within stated bounds.
Counterfactual Certificate
Signed per block: what each fired rule contributed and what would change the verdict.
07 // Cryptographic Trust Stack
Keys & Privacy
In production, signing keys are held in an AWS Nitro Enclave and never seen by the application; production start-up requires the enclave. This has been implemented but not yet exercised on Nitro hardware. All WebAssembly cryptography modules are hash-pinned and checked before loading.
Between institutions, VOPRF pseudonyms (RFC 9497) let members match the same card or device without revealing it, and private sanctions screening lets an institution check names without QUORUM seeing them. Encrypted scoring with Microsoft SEAL computes a risk score on data only the institution can decrypt.
08 // Architecture Depth
Six pages that go one level deeper into governance, evidence, orchestration, rule lifecycle, deployment and cryptographic audit.
Per-institution rule sets, shadow mode, operator promotion with FROST approval, and the role of the AI tiers.
Decision record → Merkle batch root → signed ledger entry → RFC 3161 timestamp, and how a third party verifies each step.
How a request moves through the decision path, how AI analysis runs asynchronously, and what happens when a component fails.
Shadow evaluation, operator promotion, AI red-team proposals and rule-change audit records.
On-premise and private-cloud deployment, deployment profiles, key custody in Nitro Enclaves, and hardware attestation.
Hash-chained signed ledger, Merkle proofs, RFC 3161 timestamps, Bulletproofs score proofs and offline verification.
See the Decision Flow
Step by Step
An illustrative simulator that runs in your browser and walks through the stages of a decision. It uses sample values, not the production engine.