What triggers a recidivism increment?

Whenever a promotion is submitted for an actor that already exists in the registry under the same (actor_kind, actor_id) key, the atomic upsert appends the new confirming engagement identifier to the existing array and increments the recidivism count in a single conflict-resolved database operation.

How does the system alert on a resurfacing bad actor?

When a screening pass in a new engagement matches an entity already controlled by a registered actor, a recidivism alert is generated referencing the detecting engagement, the registry entry, the full list of prior confirming engagements, and a severity level, and remains queryable until a human acknowledges it.

Can two engagements confirm the same actor at the same instant without corrupting the count?

Yes. The increment is implemented as a single atomic conflict-resolved SQL statement (INSERT ... ON CONFLICT DO UPDATE), so concurrent promotions from independent engagements serialize correctly at the database level rather than racing on a read-modify-write cycle.

Is recidivism intelligence visible across unrelated customers by default?

No. Cross-customer visibility is opt-in per registry entry, recorded as an explicit scope listing which customer identifiers may see the cross-customer signal, rather than being globally exposed.

Cross-Engagement Bad-Actor Recidivism Registry

Executive Summary

JIL Sovereign's cross-engagement bad-actor recidivism registry is a companion mechanism to the multi-severity bad-actor registry (Patent Claim 113), focused specifically on measuring and alerting on repeat confirmation across independent engagements. Every promotion of an actor - a UBO, entity, premise, or bank fingerprint - into the registry is recorded as an atomic upsert keyed (actor_kind, actor_id): if the actor already exists, the new confirming engagement identifier is appended to an existing array and a recidivism_count is incremented in the same database operation.

When a screening pass in a new engagement identifies an entity already controlled by a registered actor, the system generates a recidivism alert referencing the detecting engagement, the prior confirming engagements, and a severity level - converting a static one-time confirmation into an ongoing, cross-engagement tripwire.

Core Innovation: Recidivism is tracked as a single atomic, conflict-resolved database operation rather than a read-then-write sequence, so concurrent promotions from independent engagements can never corrupt the count or silently drop a confirming engagement identifier - correctness under concurrency is structural, not procedural.

Problem Statement

Fraud investigations are typically scoped to a single engagement or case file. A bad actor confirmed in one engagement has no mechanism forcing that confirmation to surface automatically the next time the same actor appears in a different, unrelated engagement - the second team starts from zero, re-investigates from scratch, and often confirms the same actor again without ever learning it is a repeat.

Atomic SQL operation appends the confirming engagement and increments recidivism count together - no separate read-then-write race window

Confirming engagement identifiers silently dropped under concurrent promotion, by construction

$200B+

Federal improper payments reported in a recent fiscal year - a share of which recurs precisely because engagements lack this cross-visibility

Why Existing Solutions Are Insufficient

Per-engagement case management systems: store findings scoped to a single case with no structural mechanism connecting the same actor across unrelated cases.
Manual cross-referencing: depends on an investigator remembering to search prior cases, which does not scale and misses actors operating under superficially different entity names.
Non-atomic "check-then-increment" registries: a naive read-modify-write implementation loses updates under concurrent promotion from two engagements confirming the same actor near-simultaneously.

Technical Architecture

Atomic Promotion

Promotion is implemented as a single conflict-resolved insert:

INSERT INTO bad_actor_registry
   (actor_kind, actor_id, display_label, confirmed_engagement_ids, confirmation_evidence)
 VALUES ($1, $2, $3, ARRAY[$4], $5)
 ON CONFLICT (actor_kind, actor_id) DO UPDATE SET
   confirmed_engagement_ids = array_append(bad_actor_registry.confirmed_engagement_ids, $4),
   last_confirmed_at = now(),
   recidivism_count = bad_actor_registry.recidivism_count + 1,
   confirmation_evidence = $5,
   updated_at = now()
 RETURNING registry_id, recidivism_count

Because the array append and the count increment execute inside the same ON CONFLICT clause against the row's current committed state, two engagements confirming the same actor concurrently serialize correctly at the database level - neither promotion's confirming engagement identifier is lost, and the count reflects every promotion exactly once.

Recidivism Alerting

Field	Purpose
Detecting engagement ID	The engagement whose screening pass surfaced the match
Registry ID	Points to the existing bad-actor registry entry
Prior confirming engagement IDs	Full history of every engagement that previously confirmed this actor
Alert severity	Defaults to high; escalatable
Acknowledgment	Alert remains open (queryable, unacknowledged) until a named reviewer acknowledges it

Alerts are queryable by engagement and by acknowledgment state, so a downstream workflow can surface every unacknowledged recidivism hit across an entire portfolio of engagements in a single query, rather than requiring per-engagement polling.

Cross-Customer Visibility Scope

Recidivism intelligence is not globally exposed by default. Each registry entry carries a cross_customer_visible flag and an explicit customer_visibility_scope listing which customer identifiers have opted into seeing cross-customer intelligence for that entry - so an organization's confirmed bad-actor finding can be shared deliberately with named counterparties without becoming globally public, preserving confidentiality boundaries between unrelated customers who both happen to use the same underlying registry infrastructure.

Prior Art Differentiation

Approach	Cross-engagement key?	Atomic concurrent-safe increment?	Automatic resurfacing alert?	Scoped cross-customer sharing?
Per-engagement case management	No	N/A	No	No
Manual cross-referencing	Manual	N/A	No	No
Naive read-then-write registry	Yes	No	Varies	Varies
JIL Recidivism Registry	Yes	Yes	Yes	Yes

Patent Claim

Independent Claim 114: A computer-implemented recidivism-tracking system, comprising: a registry data store keyed by actor kind and actor identifier, each entry maintaining an array of confirming engagement identifiers and a recidivism count; a promotion module configured to atomically, within a single conflict-resolved database operation, append a new confirming engagement identifier to the array and increment the recidivism count when an actor already present in the registry is re-confirmed by an independent engagement; a screening module configured to detect, within a new engagement, an entity controlled by an actor already present in the registry; and an alert generator configured to produce, upon such detection, a recidivism alert referencing the detecting engagement, the registry entry, the full array of prior confirming engagement identifiers, and a severity level, the alert remaining queryable until acknowledged.