Risk Triggers & Exclusion Enforcement

CommunityPay evaluates risk conditions in real-time and creates enforcement holds — called exclusions or bind blocks — when conditions warrant intervention. This page describes how triggers are defined, how exclusions are created and managed, and what audit trail is produced at each step.

What Is an Exclusion?

An exclusion is an active enforcement hold on an entity (HOA or vendor). When an exclusion is active, it restricts specific operations depending on its effect type:

Exclusions are not punitive. They are protective controls that prevent high-risk operations from executing before the risk condition is evaluated and addressed.

Trigger Architecture

How Triggers Are Defined

An ExclusionTrigger is a versioned definition that specifies:

1. What to evaluate: Which signal namespace to query (FINANCIAL, GOVERNANCE, COMPLIANCE)
2. What condition to check: A JSON expression format that references specific signal values
3. What to do when the condition is met: Block, require review, or warn
4. How severe the condition is: LOW, MEDIUM, HIGH, or CRITICAL
5. How long the resulting exclusion lasts: Configurable duration in days, or indefinite until manually resolved

Trigger Types

Immutability of Active Triggers

When a trigger is in DRAFT status, its conditions can be modified freely. Once a trigger is activated (status = ACTIVE), its conditions become immutable.

This is enforced at the application layer:

1. At every save, a SHA-256 hash of the conditions JSON is computed and stored in conditions_hash
2. If an existing ACTIVE trigger is being saved and the new conditions_hash differs from the stored hash, the save is rejected with a ValueError
3. To change an active trigger's conditions, a new version must be created (the old version is archived)

This ensures that every ExclusionTriggerHit can always reference the exact conditions that were in effect when it fired. Historical evaluation can be reconstructed precisely.

Version Management

Triggers use a correlation-based versioning model:

• trigger_id: A stable UUID that remains constant across all versions of the same logical trigger
• version: An incrementing integer (1, 2, 3...)
• parent_version: A foreign key to the previous version

Only one version of a given trigger_id can be ACTIVE at any time. Attempting to activate a second version raises a ValidationError. The workflow is: archive the current version, then activate the new version.

Exclusion Lifecycle

When a trigger fires, the following sequence occurs:

1. Trigger Evaluation

The exclusion monitor evaluates active triggers against current signal values. When conditions are met, an ExclusionTriggerHit is created.

The trigger hit is an ARTIFACT — fully immutable. It captures: - The trigger version that fired - All evaluated signal values at the moment of evaluation - The computed result - The timestamp

2. Exclusion Creation

An Exclusion record is created with status ACTIVE. The exclusion references: - The trigger hit that caused it - The affected entity (HOA or vendor) - The effect type (copied from the trigger) - The severity - The expiration date (current time + trigger's exclusion_duration_days, or null for indefinite)

3. Notification

If the trigger has auto_notify enabled, the notification service sends alerts to configured recipients. Notification events are recorded in the append-only ExclusionNotificationEvent log.

4. Enforcement

While the exclusion is ACTIVE, the enforcement dispatcher considers it when evaluating financial operations. The specific enforcement depends on the effect type:

• BLOCK: Operations matching the exclusion scope are rejected by the guard chain
• REVIEW: Operations are queued for manual review; they cannot proceed until a reviewer approves
• WARN: Operations proceed, but the warning is logged in the EnforcementDecision

5. Resolution

An exclusion can be resolved in three ways:

All status transitions are recorded in the append-only ExclusionStatusHistory table. No status history record can be updated or deleted.

Cooldown Periods

After an exclusion is resolved, the trigger enters a cooldown period for the affected entity. During cooldown, the same trigger cannot fire again for the same entity.

The default cooldown is 30 days, configurable per trigger. This prevents rapid cycling of exclusion creation and resolution that could indicate an unresolved underlying condition.

Escalation Chain

Unresolved exclusions follow a notification escalation chain:

Each escalation is recorded as an immutable event. The escalation service runs on a scheduled interval and checks for exclusions that have exceeded their SLA without resolution.

SLA Tracking

The escalation system tracks: - Acknowledgment: Has the responsible party acknowledged the exclusion? - Response time: How long between notification and acknowledgment? - Resolution time: How long between creation and resolution? - SLA breaches: Which exclusions exceeded their expected resolution time?

These metrics feed into the Control Effectiveness measurement system and the Governance Controls Attestation (GCA).

Severity Classification

What This System Proves

The exclusion enforcement system creates a complete, verifiable record of risk management:

1. Detection is systematic: Triggers are evaluated automatically — risks are not discovered by accident
2. Response is documented: Every notification, acknowledgment, and escalation is recorded
3. Resolution is auditable: Every exclusion closure includes who resolved it, when, and why
4. History is preserved: Trigger hits, exclusion records, and status transitions are immutable
5. Controls are measurable: SLA tracking and escalation metrics prove that the system operates, not just that it exists

An auditor reviewing the exclusion history can reconstruct: what triggered the hold, what the signals showed at that moment, who was notified, whether they responded within SLA, how the hold was resolved, and what documentation supported the resolution.

CARI Integration

Exclusion trigger history and resolution patterns are direct inputs to CARI score computation. Active exclusions impact CARI scores in real-time and may trigger webhook notifications to monitoring subscribers when severity thresholds are crossed. The enforcement telemetry measured here — trigger hit frequency, resolution time, SLA compliance, and escalation rates — feeds the CARI Enforcement Integrity sub-score.

For published methodology and component weights, see CARI Methodology and Scoring Framework.