The central problem in transaction fraud detection is not data scarcity — financial institutions generate enormous volumes of event data with every interaction. The problem is signal quality and reasoning depth. Transaction metadata alone — amount, merchant category, channel — describes what happened but reveals almost nothing about who performed the action, whether they were acting freely, or whether the request was generated by a human or a machine. Behavioral signals answer the question that transaction data cannot: is the entity behind this session a legitimate account holder behaving normally, or is something else in control?

Rule-based fraud systems, which dominated the industry through the 2010s, operate on a fundamentally deficient model. They encode known fraud patterns into explicit logical conditions — "flag if amount exceeds X and merchant category is Y and IP is in country Z." This works precisely once per fraud pattern, against adversaries who have not yet observed the rule. Modern threat actors adapt faster than rule sets can be maintained. The half-life of a new fraud rule against a sophisticated adversarial actor is measured in hours.

QUORUM's approach inverts the problem. Rather than defining fraud by its observable characteristics, the system defines authentic human behavior by its measurable properties — typing rhythm, interaction entropy, physical plausibility, and transactional consistency — and treats deviations from that envelope as the primary risk signal. Critically, QUORUM does not rely on a single model or algorithm to make this determination. Three independent intelligence tiers — each specialized for a different fraud surface — evaluate every request simultaneously. Their conclusions are compared, debated, and adjudicated before a final verdict is issued.

A single model — however sophisticated — produces a single perspective. It has blind spots determined by its training data, its objective function, and the signal categories it was optimized to evaluate. An account takeover that is invisible from a behavioral perspective (the attacker has spent weeks training on the victim's patterns) may be obvious from a financial perspective (the first transaction is a maximum-limit withdrawal). A technically clean request (no injection patterns, valid browser fingerprint) may still be behaviorally implausible (superhuman typing speed, robotic mouse trajectory). QUORUM's three-tier architecture ensures that each fraud surface is evaluated by an intelligence specifically configured for that domain — and that no single tier can unilaterally clear a high-risk session.

When tiers disagree — one calling block while another calls allow — the system does not simply average the scores or defer to the most conservative verdict. Instead, it initiates a structured internal debate: the blocking tier is presented with the opposing tier's reasoning and asked to reconsider. This cross-tier challenge cycle catches false positives before they reach the user, while ensuring that genuine disagreement (which is itself a signal of ambiguity) receives the additional scrutiny of a fourth-tier arbitrator. The debate mechanism is described in full in Section 7.

Before any intelligence tier can evaluate a session, signals must be collected and structured. QUORUM organizes its signal inputs into four distinct layers, each contributing independent evidence about the nature of the session and the identity of the actor behind it. Layers are designed to degrade gracefully — a mobile session without mouse data is not penalized for the absence of cursor movement signals.

Interaction signals describe the physical mechanics of how a user engages with the interface. QUORUM collects three primary interaction signal types from a lightweight browser SDK:

• Typing speed — measured in words per minute from the cadence of keypress events. Human typing speed falls within well-characterized bounds; superhuman speeds (above 250 WPM with no hesitation events) are a strong automation indicator. Zero typing activity on a form that requires text input is equally diagnostic.
• Typing variance — the inter-keystroke interval variance. Human typing exhibits natural variance reflecting cognitive load and motor imprecision. Robotic typing patterns produce variance below 2ms — physically implausible for any human keyboard interaction — indicating scripted form population.
• Mouse entropy — the unpredictability and organic quality of cursor movement. SENTINEL evaluates this holistically: human cursor paths are curved, velocity-varied, and exhibit micro-corrections near click targets. Automated cursor paths tend toward geometric perfection or noise injection with implausible frequency characteristics.

Session signals describe the context and environment of the interaction rather than the mechanics. These are collected server-side and via browser probes:

• Headless browser detection — a boolean flag derived from a suite of browser capability probes. Headless Chrome, Puppeteer, Playwright, and similar automation frameworks expose characteristic gaps in their browser environment simulation: missing WebGL capabilities, atypical JavaScript API behaviors, absence of browser-native UI elements. Detection of a headless environment contributes +45 to the base risk score before any LLM tier is consulted.
• User-agent string analysis — cross-referenced against the detected browser environment. A claim to be Mozilla Firefox accompanied by headless browser indicators is itself a fraud signal independent of the underlying session behavior.
• Timezone consistency — the claimed timezone in browser signals is compared against the IP geolocation timezone. Mismatches are common in VPN use but are also characteristic of credential stuffing operations run from centralized infrastructure serving geographically dispersed account pools.

Device and network signals are collected at the connection level, before any application-layer processing:

• JA3 TLS fingerprint — the TLS ClientHello parameters (cipher suites, extensions, elliptic curves) produce a hash that is characteristic of the TLS library in use. QUORUM maintains a dictionary of 15+ known-bad JA3 fingerprints associated with automation tools: python-requests, curl, golang net/http, sqlmap, Burp Suite, Nmap-SSL, and others. A matching JA3 fingerprint contributes +55 to the risk score and is reported to the ADVERSARIAL tier as an explicit indicator.
• JA4 fingerprint prefix matching — a newer fingerprinting standard that provides tool-family identification from TLS negotiation prefix patterns. Used as a secondary signal when JA3 is absent or has been spoofed.
• Datacenter IP range detection — IP prefixes associated with known datacenter and hosting infrastructure are flagged. Legitimate consumer banking sessions originate from residential and mobile ISPs; datacenter IPs are characteristic of automated infrastructure regardless of claimed user agent.

QUORUM supplements its own signal collection with external threat intelligence at inference time:

• IP reputation — the originating IP is checked against abuse reputation databases. The response includes an abuse confidence score, TOR exit node status, and known hosting provider flags. The IP abuse score contributes directly to the composite risk score.
• Email breach status — where an email address is available in the request context, it is checked against known breach databases. A breached email address submitted for account registration or password reset is a credential-stuffing indicator.

Before signals reach the LLM intelligence tiers, they pass through a statistical pre-analysis layer that compares current session behavior against the user's established historical baseline. This layer operates independently of the LLM tiers and provides a fast, statistically grounded risk contribution that augments the LLM verdicts in the final score composition.

QUORUM maintains a per-account behavioral profile storing the mean and standard deviation of key interaction signals observed across confirmed-authentic sessions. At inference time, the current session's signals are compared against this profile using Z-score analysis — measuring how many standard deviations the observed value departs from the account's established norm:

A three-sigma deviation represents an event that occurs with less than 0.3% probability under the normal distribution of that user's behavior. At this threshold, the signal is strong enough to contribute meaningfully to the risk score without generating excessive false positives from natural behavioral variation.

The behavioral profile for each account is maintained as a running statistical estimate, updated incrementally with each new confirmed-authentic session. The update algorithm uses an online variance computation that does not require storing historical session data:

A minimum of five session samples is required before baseline-relative analysis is activated. Sessions prior to this threshold are evaluated using pure signal analysis only — raw signal values compared against population-level plausibility bounds rather than account-specific norms. This prevents false positives for new accounts while still catching gross automation artifacts on first-session access.

For accounts without sufficient history, and as a secondary check for accounts with established baselines, QUORUM applies a set of absolute signal plausibility tests that do not require historical context:

These scores are additive. A session with a headless browser, zero typing activity, and a datacenter IP arrives at the SENTINEL tier pre-scored at +90 before the LLM has rendered any verdict — effectively pre-determining the outcome for obvious automation while preserving the LLM analysis for ambiguous cases.

SENTINEL is QUORUM's first intelligence tier, specialized for behavioral biometrics analysis. It operates as a fine-tuned language model running on dedicated inference infrastructure, isolated from the other tiers to prevent cross-contamination of reasoning. SENTINEL's sole mandate is to analyze behavioral telemetry — the interaction signals described in Section 2 — and produce a structured risk verdict.

SENTINEL is implemented as a specialized configuration of a large language model (llama3.1:8b base), fine-tuned through a structured system prompt that establishes its domain, constraints, input format, output schema, and decision rules. The model runs on a dedicated Ollama inference instance, ensuring that SENTINEL's inference does not share compute resources with INQUISITOR or ADVERSARIAL — eliminating cross-tier timing side channels and ensuring independent throughput.

The fine-tuning approach encodes behavioral fraud domain knowledge directly into the model's system context: what constitutes superhuman typing, what datacenter IP presence implies, how timezone mismatches interact with behavioral signals, and how to reason about absence of expected signals. Temperature is set to 0.05 — near-deterministic — ensuring consistent, reproducible verdicts for equivalent inputs.

SENTINEL evaluates the following signal categories, applying domain-specific reasoning that goes beyond simple threshold comparison:

• Keyboard interaction entropy — assesses whether typing patterns exhibit the natural variability of human motor control, or the artificial regularity of scripted input. SENTINEL is specifically configured to reason about the combination of signals: high typing speed with low variance is more diagnostic than either alone.
• Mouse movement quality — evaluates the plausibility of cursor trajectory, velocity profile, and the presence or absence of micro-corrections. SENTINEL applies negative constraint reasoning: it is configured to identify reasons not to flag, specifically looking for patterns consistent with legitimate hardware profiles before concluding automation.
• Headless environment indicators — synthesizes multiple headless detection signals. A single headless indicator may be a false positive from an unusual browser configuration; SENTINEL weighs the combination of headless flags against the full behavioral context.
• Temporal consistency — evaluates whether the session's time characteristics (timezone, interaction timing relative to claimed geography) form a coherent picture.

SENTINEL produces a structured JSON verdict on every invocation. The output schema is enforced by the model's instruction set and validated by Zod schema parsing before the verdict enters the consensus pipeline:

The confidence field is critical to the consensus protocol. A SENTINEL verdict of "block" with confidence 0.95 carries substantially more weight in the arbitration process than a "block" with confidence 0.40. Low-confidence verdicts from any tier trigger arbitration even in the absence of explicit polarization between tiers.

SENTINEL operates behind a circuit breaker with configurable failure threshold and reset window. If SENTINEL inference fails consecutively (network timeout, model unavailability), the circuit opens and the tier returns a pre-configured fallback verdict. The fallback behavior is institution-configurable between two policies: fail-closed (block all sessions during SENTINEL outage) and fail-degraded (challenge all sessions, flagging for manual review). Fail-closed is the default for institutions in high-risk transaction categories.

INQUISITOR is QUORUM's second intelligence tier, specialized for financial fraud pattern recognition. Where SENTINEL asks "is this a human?", INQUISITOR asks "is this human behaving consistently with legitimate financial intent?" The distinction is important: a genuine human can still be committing fraud, and an account takeover operator who has carefully studied their victim's behavioral patterns may pass SENTINEL's scrutiny while presenting clear financial anomalies to INQUISITOR.

INQUISITOR analyzes the action type, user account context, transaction metadata, velocity data, and risk context submitted with each request. Its fine-tuning encodes a comprehensive set of financial fraud heuristics:

• Velocity abuse — many transactions within a short time window. INQUISITOR evaluates velocity relative to the account's historical transaction frequency, not just against absolute thresholds. A user who normally transacts three times per day performing 15 transactions in an hour is anomalous; a user who normally transacts 20 times per day performing 15 transactions in an hour is not.
• Deposit-withdrawal timing — a large withdrawal occurring immediately after a recent deposit is a classic money mule pattern. INQUISITOR is specifically calibrated to detect this sequence and weight it appropriately based on the magnitude and timing of both transactions.
• New device combined with high-value transaction — a first-time device accessing an account and immediately initiating a significant transaction is a strong account takeover indicator. INQUISITOR adds +25 to the risk contribution for this combination.
• Geographic anomalies — transactions from geographies inconsistent with the account's history or with the account holder's declared location. INQUISITOR evaluates geographic context in conjunction with velocity and transaction value.
• Round number indicators — card testing operations frequently use round-number amounts (exactly $1.00, $10.00, $100.00) to probe card validity with minimal exposure. INQUISITOR treats round amounts as a mild positive indicator contributing +5 when combined with other signals.
• Failed attempt sequences — multiple failed authentication or transaction attempts preceding a success are characteristic of brute-force and credential-stuffing attacks. INQUISITOR adds +35 for this pattern.

INQUISITOR classifies detected patterns into one of six fraud categories in its output, enabling downstream evidence packages and human review queues to be routed to the appropriate specialist team:

INQUISITOR's velocity analysis is backed by a dedicated velocity analytics service that maintains sliding-window event counts across four temporal windows: 1 minute, 5 minutes, 15 minutes, and 1 hour. Each window tracks the maximum burst count within that window, not just the total count — this captures short-duration spikes that a simple rolling count would undercount. Burst thresholds are 3 events/minute, 8 events/5-minutes, 15 events/15-minutes, and 30 events/hour; exceedance is reported as a percentage excess and fed to INQUISITOR as a structured input alongside the raw telemetry.

ADVERSARIAL is QUORUM's third intelligence tier, operating as a red-team intelligence capability embedded directly in the request path. Where SENTINEL and INQUISITOR evaluate the human and financial dimensions of a session, ADVERSARIAL asks the technical question: "Is this request structurally attempting to exploit the system?" ADVERSARIAL works in close integration with QUORUM's AST-based Web Application Firewall, receiving pre-processed threat assessment data alongside the raw request context.

Before ADVERSARIAL's LLM inference runs, every request passes through a deterministic AST-analysis layer that provides structured threat intelligence. This layer uses Abstract Syntax Tree parsing — not pattern matching alone — to identify malicious intent in request payloads:

• JavaScript AST analysis — the Acorn parser constructs a JavaScript AST from any string values in the request body. Executable function declarations, call expressions, and arrow functions in user-submitted data are identified structurally, defeating obfuscation techniques that simple regex would miss.
• SQL AST analysis — the node-sql-parser constructs a SQL AST from request values. Structural tautologies (OR 1=1), data destruction operations (DROP, DELETE, UPDATE), and compound statement injection are identified by AST node type, not surface string patterns.
• Recursive encoding detection — three rounds of URL decoding, Base64 decoding, and hex decoding are applied before analysis, defeating layered obfuscation that encodes payloads to bypass first-pass analysis.
• Eight additional pattern categories — path traversal, command injection, LDAP injection, SSTI, NoSQL injection, and HTTP header injection are detected through semantic heuristic patterns applied after encoding normalization.

The WAF assessment — threat level, detected attack types, severity classification — is passed to ADVERSARIAL as structured context, allowing the LLM to reason about the combination of technical attack indicators rather than treating each detection independently.

ADVERSARIAL evaluates eight attack categories in its structured output:

ADVERSARIAL operates beyond the LLM verdict: when the WAF layer produces a "block" or "ban" disposition, the originating IP is automatically added to a blocked IP list with an expiry appropriate to the severity. An autoban mechanism evaluates the 100 most recent security events from a given IP within the last hour; five or more high/critical events within that window triggers automatic permanent block without LLM consultation, preventing the inference tier from becoming a resource exhaustion target under sustained attack.

The three intelligence tiers — SENTINEL, INQUISITOR, and ADVERSARIAL — execute in parallel for every request. Their verdicts arrive simultaneously, and the consensus protocol determines the final action. This parallel architecture means that the latency of the three-tier analysis is bounded by the slowest single tier, not the sum of all three — a critical design decision for maintaining sub-50ms SLA compliance.

When all three tiers agree — all allow, all challenge, or all block — and no individual tier score exceeds 60, the system forms a consolidated verdict without invoking the ARBITRATOR. The final action reflects the unanimous direction, the composite score is the maximum of the three tier scores, and the confidence is set to 1.0 reflecting full inter-tier agreement. This happy-path resolution avoids unnecessary arbitration overhead for the large majority of clearly legitimate sessions.

Polarization occurs when tiers reach contradictory verdicts — one calling block while another calls allow. The system identifies three specific polarization patterns:

• SENTINEL blocks + INQUISITOR allows (behavioral automation without financial anomaly)
• INQUISITOR blocks + SENTINEL allows (financial fraud from behaviorally authentic actor)
• ADVERSARIAL blocks + (SENTINEL or INQUISITOR) allows (technical attack from session that appears human)

High-risk conditions — any single tier score exceeding 60 — also trigger the arbitration pathway even in the absence of explicit polarization between verdicts, ensuring that ambiguous high-stakes sessions receive additional scrutiny.

Before the ARBITRATOR is invoked, QUORUM initiates a cross-tier debate: the blocking tier is presented with the opposing tier's reasoning and asked to reconsider its verdict. This challenge prompt includes the blocker's original reasoning, the opponent's verdict, and the opponent's supporting rationale. The blocking tier has the opportunity to maintain its position or update its verdict based on the new context.

This debate mechanism catches a specific failure mode: a tier that reached a block verdict on ambiguous evidence that would be resolved by the other tier's perspective. The reconsideration result is recorded as a rebuttal and passed to the ARBITRATOR as additional context, allowing the arbitrator to understand whether the original block was maintained under adversarial scrutiny or updated in light of new reasoning.

The ARBITRATOR is QUORUM's fourth intelligence tier, invoked only when the consensus protocol identifies polarization or high-risk conditions. It operates as an executive decision-maker: its mandate is to review the findings of all three primary tiers, assess the cross-tier debate rebuttal, and issue a final binding verdict that resolves the conflict.

The ARBITRATOR is fine-tuned with a distinct mandate from the primary tiers. Its configuration prioritizes accuracy over caution — when confidence is low, it is instructed to prefer CHALLENGE over BLOCK, recognizing that a false positive has real cost to the user experience and to the institution's relationship with legitimate customers. Its decision rules encode an explicit hierarchy of evidence:

• Technical and adversarial evidence (ADVERSARIAL tier findings, WAF detections) takes priority over behavioral heuristics from SENTINEL
• High-confidence verdicts from any tier outweigh low-confidence verdicts from the other tiers
• A tier that maintained its block verdict through the debate cycle provides stronger evidence than one that issued a first-pass block
• The rebuttal context — whether the blocking tier updated its reasoning under challenge — is explicitly weighted in the final determination

The ARBITRATOR outputs a final verdict in the same schema as the primary tiers, which becomes the binding resolution for score composition.

Every session that reaches the ARBITRATOR tier — indicating a disputed or high-risk determination — generates a Zero-Knowledge Proof compliance record. This record cryptographically commits to the fact that a risk decision was made, the verdict reached, and the inputs that were evaluated, without exposing the raw behavioral telemetry, transaction data, or user identity information to any external system.

ZKP generation uses snarkjs with a Circom circuit that takes the organization ID, verdict, and a hash of the evaluation inputs as private witnesses, producing a compact proof that can be verified by a compliance auditor without access to the underlying session data. This is particularly relevant for GDPR/PIPEDA compliance: the system can demonstrate to a regulator that a block decision was made on a principled, documented basis without disclosing the personal data that was evaluated.

When the final verdict — whether from the consensus protocol or the ARBITRATOR — is "block," the forensic service automatically generates an evidence package. This package is a cryptographically signed PDF document containing the complete risk assessment, the tier verdicts, the reasoning from each tier, the OSINT findings, the WAF detections, and a case identifier. The evidence package serves multiple purposes:

• Regulatory documentation for suspicious activity report (SAR) filing
• Internal audit trail for dispute resolution
• Human review queue input for analyst investigation
• Automatic account freeze trigger for critical technical breach events

Evidence packages are stored in a dedicated forensics directory and referenced in the immutable audit ledger described in Section 9.3 of the Zero-Knowledge Compliance Framework (QRM-ZKCP-001).

The final risk score is not simply the verdict from the consensus protocol or ARBITRATOR. It is a composite that integrates signals from multiple independent sources, each contributing an additive component bounded to prevent any single source from dominating the outcome.

The composite score is assembled from five sources:

The transitive graph risk contribution is capped at 50% weight to prevent a compromised upstream entity from deterministically blocking all sessions sharing an association with it — preserving the system's ability to distinguish between a user who occasionally shares a device with a flagged account and one who is actively part of a fraud ring.

The composite score maps to four risk levels, each with a default action:

The composite score can override the LLM verdict in specific conditions. A session where the LLM consensus produced "allow" but the composite score reaches 85 or above is escalated to "block" — the additive signal contributions from OSINT, JA3, and graph risk have accumulated enough evidence that the LLM's behavioral verdict is insufficient to clear the session. Conversely, the system does not downgrade a block verdict issued by the LLM tiers based on a low composite score: if the LLM determined "block" through reasoning, that verdict is preserved regardless of the additive score.

Fraud does not operate in isolation. Accounts share devices; devices appear across multiple sessions from the same coordinated infrastructure; IP addresses link geographically dispersed attack nodes. QUORUM's graph intelligence layer maps these relationships and propagates risk through the network — so that a new account with no fraud history is not evaluated in isolation if it shares a device with three recently-blocked accounts.

QUORUM maintains a directed entity graph with three primary node types: users, IP addresses, and devices. Edges represent observed relationships, created automatically at session time:

• user → IP — created when a user session originates from an IP address (user_ip_session edge type)
• user → device — created when a user session uses a specific device fingerprint (user_device_fingerprint edge type)
• device → IP — created when a device fingerprint is seen from an IP address (device_ip_association edge type)

The graph is stored in two layers simultaneously: a Neo4j graph database for Cypher-query-based relationship analysis, and a PostgreSQL relational fallback for environments where Neo4j connectivity is unavailable. This dual-storage approach ensures graph intelligence degrades gracefully rather than failing entirely if graph database connectivity is interrupted.

When a session is evaluated, the graph service queries the entity relationships for the current user, IP, and device. The risk score associated with each linked entity — derived from prior fraud determinations against that entity — is retrieved and propagated to the current session. The propagation mechanism takes the maximum transitive risk score across all linked entities, applies the 50% weight cap described in Section 9.1, and contributes that value to the composite score.

This means that a user whose device was previously used in a confirmed fraud — even if the user's own account has no fraud history — inherits elevated risk from the device relationship. The elevated risk does not automatically block the session; it contributes to the composite score and may trigger additional scrutiny without preventing the session outright if other signals are clean.

When a device fingerprint carries a transitive risk score above 75, QUORUM initiates a Sybil cluster analysis. The Neo4j graph is queried for all user nodes linked to the device through the USER_DEVICE_FINGERPRINT relationship:

Three or more distinct users sharing a single device fingerprint is a statistically implausible coincidence in legitimate usage and constitutes a Sybil cluster — a coordinated network of accounts sharing physical or virtual infrastructure. Detection is reported as a critical security event and propagated to all nodes in the cluster. The PostgreSQL fallback performs equivalent cluster detection using the relational edge ledger when Neo4j is unavailable.

QUORUM's defensive perimeter begins before any request reaches the Node.js backend. The Sentinel Edge Worker operates as a Cloudflare Workers-compatible edge function deployed at the CDN layer, performing high-speed threat pattern scanning at the network edge and injecting risk telemetry headers into forwarded requests. This architecture ensures that the most obvious attack payloads are neutralized before they consume any backend compute, and that edge-detected threat context is available to the ADVERSARIAL tier without re-scanning.

The Sentinel Edge Worker applies a lightweight regex-based scan across the URL path, query string, and request body for five high-confidence attack categories: SQL injection, XSS, path traversal, command injection, and SSTI. The scan runs against URL-decoded values, defeating single-layer encoding obfuscation. Unlike the full backend WAF — which uses AST parsing and eight attack categories — the edge scanner prioritizes throughput over comprehensiveness: it catches only the highest-severity, highest-confidence patterns that can be identified without parse overhead.

The Sentinel Edge Worker operates under the same dual-policy model as the backend intelligence tiers:

• Fail-Closed — detected attack patterns result in immediate 403 rejection at the edge. The request never reaches the backend. This is the default for institutions in high-risk transaction categories where false positive cost is acceptable.
• Fail-Degraded — detected patterns are flagged via injected headers (x-quorum-edge-threats, x-quorum-edge-policy) and the request is forwarded to the backend ADVERSARIAL tier for deep analysis. This preserves backend visibility into the attack while avoiding edge false positives for institutions with lower risk tolerance for incorrect blocks.

If the backend itself is unreachable, the Sentinel Edge Worker applies its own fail policy — returning 503 under fail-closed or a degraded-mode response under fail-degraded — ensuring that backend outages do not create an unguarded attack surface.

At the backend layer, a persistent Cognitive Watchdog process runs continuously alongside the main API server. The Watchdog implements two independent monitoring loops:

• Real-time event processing loop — polls the compliance event store every 10 seconds for unprocessed events. Each pending event is automatically submitted to the full three-tier LLM risk scoring engine, transforming retrospective logging into active re-analysis. Events confirmed as clean are marked processed; events that score high in re-analysis generate new security events and trigger appropriate escalation paths. The loop includes a circuit breaker: five consecutive failures open the circuit and suppress polling to prevent hammering a degraded database.
• Systemic reflection cycle — runs every 5 minutes, pulling the 500 most recent security events and submitting them for aggregate pattern analysis. When the systemic analysis identifies a new risk vector not addressed by existing rules, it automatically proposes a new rule to the rule engine for human review. This transforms the Watchdog from a reactive monitoring tool into a proactive threat intelligence generator.

QUORUM maintains detection quality through four scheduled automated systems that operate without requiring engineering intervention between cycles: an internal rule verification cycle, an adaptive threshold tuning loop, an infrastructure health monitor, and a governance orchestrator. All rule changes proposed by these systems require human administrator review before activation.

Every hour, the AI Orchestration Worker initiates an autonomous logic verification session. The ARBITRATOR LLM — the same model that adjudicates cross-tier disagreements in the request path — is given a different mandate: act as a sophisticated protocol auditor, examine the active rule set, and synthesize a verification vector describing a potential protocol edge case, logical bypass, or resource exhaustion scenario.

The synthesized vector — a JSON object describing the attack surface, target endpoint or rule, and expected effect (bypass, exhaustion, or deviation) — is then executed against the live fraud engine in a controlled internal session. The fraud engine either catches the vector (demonstrating the rule set covers the identified attack surface) or does not (demonstrating a logical gap):

Proposed rules created by the red team are placed in pre-flight (shadow) mode — they observe matching events and log detections without blocking — until a human administrator promotes them to active status. This prevents the autonomous system from unilaterally changing the blocking policy while still capturing the intelligence value of the identified gap. The result is a system that continuously tests its own rule logic and surfaces gaps for human review.

Every five minutes, the AI Orchestration Worker executes a reinforcement learning epoch to tune the system's risk sensitivity threshold. The epoch follows a three-step process:

1. The 500 most recent security events are retrieved and classified by outcome: high/critical events that received a manual override are counted as false positives; high/critical events without override are counted as true positives.
2. The current false positive rate and true positive rate are submitted to the ARBITRATOR LLM as a "current state" context, with the instruction to recommend an optimal risk sensitivity multiplier.
3. The recommended multiplier is written to Redis configuration, taking effect on subsequent risk scoring calls without requiring a backend restart.

The ARBITRATOR's threshold recommendations are constrained: conservative adjustments of no more than ±0.2 per epoch, preventing oscillation or runaway sensitivity shifts. A false positive rate above 15% triggers a downward threshold adjustment (reducing sensitivity to reduce false alarms); a low false positive rate combined with a low true positive rate triggers an upward adjustment (increasing sensitivity to catch more true fraud).

The Compliance Healer monitors AI service health every 5 minutes using the AI Diagnostics module, which sends a ping to each of the three Ollama inference instances (SENTINEL, INQUISITOR, ADVERSARIAL). If any tier returns an offline or failed status, the Compliance Healer automatically triggers a Docker container restart for the affected service — without human intervention. The restart uses the Docker API directly, bringing the service back to operational state and confirming recovery before resuming normal operations.

This self-healing loop operates in parallel with the circuit breaker mechanisms in the risk scoring engine: while a tier is down, the circuit breaker prevents the inference failure from propagating into the request path; the Compliance Healer works to restore the service so the circuit can close. The combination means that individual tier failures produce a graceful degradation in real-time scoring (fewer tiers consulted) while the infrastructure autonomously restores full capacity.

Once per day, the Governance Orchestrator runs a full entropy audit across the platform's rule set and telemetry store. The audit has four components:

• Heuristic garbage collection — rules that have not matched in 180 days are demoted from active to pre-flight (shadow) mode and flagged for review. A rule that does not match for six months is either obsolete (the attack pattern it detects has disappeared) or misconfigured. In either case, keeping it in active mode creates dead weight in the rules engine evaluation path.
• Logic consistency verification — the rule set is analyzed for logical contradictions: scenarios where a high-priority allow rule would override a lower-priority block rule in ways that might violate expected policy (for example, a VIP user exception that inadvertently creates an unblockable account regardless of IP or device risk).
• Telemetry sanitization — security event records older than two years are purged. Behavioral baselines derived from sessions two or more years old are not representative of current user behavior and would introduce systematic bias into Z-score computations for accounts with long histories.
• Exception TTL enforcement — manually-entered rule exceptions are evaluated against their expiry dates and removed when they lapse. This prevents "temporary" exceptions granted for specific operational events from silently becoming permanent policy.

The following table documents all signals collected by QUORUM, their source layer, the intelligence tier(s) that consume them, and their risk contribution mechanism.

The following matrix documents how the consensus protocol resolves all combinations of tier verdicts. "Arbitration" indicates invocation of the ARBITRATOR tier. All high-risk conditions (any tier score above 60) trigger arbitration regardless of verdict alignment.

ZKP compliance records are generated for all sessions resolved through the ARBITRATOR tier. Evidence packages are generated for all sessions resulting in a final "block" action, regardless of resolution path.