PM-Triggered Business Rule Automation — Integration

​

Overview

Note on channel naming: The cl_pm_events channel uses a cl_ prefix because it was originally established for CL↔PM cross-core events. PM-only events reuse this channel for consistency with EVENT_CONTRACTS.md. A future rename to pm_events may be considered if the channel scope is formalized.

• Trigger type: pm_event (stored as trigger_type: 'pm_event' in fw_automation_rules)
• Trigger config (JSONB): { "event_type": string, "new_status"?: string, "payer_id"?: string | null }
• Channel: cl_pm_events (EVENT_CONTRACTS)
• Governance: All executions logged to fw_automation_logs; circuit breaker and dry-run per constitution §12.

​

Quick Reference

​

Decision Tree

1. Receive PM event on cl_pm_events.
2. Load rules where trigger_type = 'pm_event'.
3. Match trigger_config.event_type to payload event_type.
4. Apply optional filters (new_status, payer_id) when configured.
5. Execute actions for matching rules and persist run logs to fw_automation_logs.

​

Pattern Library

• Event subscriber pattern: FW-03 consumes PM events and drives automation dispatch.
• Publisher pattern: PM-07/PM-08/PM-09 emit domain events with automation-ready payloads.
• Contract-first pattern: Payload shape governed by EVENT_CONTRACTS.md.

​

Common Mistakes

​

Pre-Flight Checklist

• Event payload includes organization_id.
• Rule execution enforces rule.organization_id = event.organization_id.
• Runtime writes execution trails to fw_automation_logs.
• Dry-run/circuit-breaker behavior validated for high-volume bursts.
• Payload schema matches EVENT_CONTRACTS.md definitions.

​

Integration Points

​

Event Contracts (Consumed by FW-03)

​

Event types available as triggers

​

Trigger config shape (FW-03 rule)

interface PMEventTriggerConfig {
  event_type: 'claim_submitted' | 'claim_status_changed' | 'claim_created' | 'denial_received'
    | 'charge_approved' | 'charge_status_changed' | 'payment_posted' | 'write_off_approved';
  new_status?: string;   // e.g. 'denied', 'approved', 'paid'
  payer_id?: string | null;     // UUID or null; omit = any payer
}

{
  organization_id: uuid,
  trigger_type: 'pm_event',
  trigger_config: {
    event_type: 'claim_status_changed',
    new_status: 'denied',
    payer_id: null  // omit or null = any payer
  },
  actions: [
    { type: 'send_notification', config: { template: 'claim_denied_alert', ... } },
    { type: 'create_task', config: { queue: 'denial_review', ... } }
  ]
}

​

Multi-tenancy and security

• Event payloads MUST include organization_id.
• Automation executor MUST only run rules where rule.organization_id = event.organization_id.
• Payloads use IDs only (no PII/PHI); actions resolve display data via authorized APIs.

​

API Contracts

​

References

• EVENT_CONTRACTS.md — Payload schemas and channel cl_pm_events
• PM-19 Spec
• Constitution §12 (Automation Governance)