Compliance and policy enforcement monitoring

Requirements describe capabilities the pattern needs in your environment, not the vendors you must buy. Any system that fills a requirement satisfies it — that’s what makes the catalog portable across the long tail of SMB tooling.

1. monitored_activity_streams

   REQUIREDREADevent

   The streams of activity the pattern watches. Multiple sources, one pattern.

   DATA SHAPE

   Event records from various systems with consistent metadata: actor, action, target, timestamp, optional context.
   COMMONLY FILLED BY

   • expense system event stream
   • access management logs
   • communications archives
   • purchase requisition events
   • code repository commits and pull requests for change-control
2. policy_rule_library

   REQUIREDREADcorpus

   The firm's policies expressed as testable rules. Critical that this is explicit and maintained: the pattern is only as good as the rules it checks against.

   DATA SHAPE

   Per-policy: applicability conditions, the test, severity, suggested response. Mix of structured rules (amount thresholds) and content-based checks (does this communication contain prohibited claims).
   COMMONLY FILLED BY

   • structured policy library maintained by compliance and legal
   • rules engine the pattern reads from
   • small admin UI for policy authoring
3. actor_context_lookup

   REQUIREDREADrequest

   Who the actor is: their role, their authority limits, their reporting line. Many policies depend on who's doing what.

   DATA SHAPE

   Per-person: role, team, manager, approval authority, any active flags (e.g. probation, special handling).
   COMMONLY FILLED BY

   • HR directory with role and reporting structure
   • identity management system with permission grants
   • RACI matrix maintained by operations
4. violation_review_queue

   REQUIREDWRITErequest

   Where flagged violations go for human review. Most violations are not clear-cut and need someone to decide.

   DATA SHAPE

   Flagged event with policy violated, evidence, actor context, severity, suggested action. Reviewer can confirm, dismiss, or escalate.
   COMMONLY FILLED BY

   • compliance review queue in the GRC tool
   • ticket queue for compliance officers
   • dashboard with prioritized cases
5. escalation_route

   REQUIREDWRITEevent

   Where high-severity violations route directly without waiting for queue processing.

   DATA SHAPE

   Escalation event with full context and immediate notification to the responsible authority.
   COMMONLY FILLED BY

   • direct chat alert to the compliance officer or general counsel
   • phone call escalation for severe cases
   • automated email to the CEO or designated executive
6. audit_evidence_archive

   REQUIREDWRITEcorpus

   Long-term retention of all flags, reviews, and resolutions. Critical for the audit story this pattern is supposed to support.

   DATA SHAPE

   Per-event: original activity, what policy was checked, the verdict, the human review if any, the resolution, retention period.
   COMMONLY FILLED BY

   • compliance archive in the GRC system
   • structured audit log with retention policies
   • evidence store accessible to external auditors
7. false_positive_feedback

   REQUIREDREAD + WRITEevent

   How reviewers flag that something was incorrectly identified as a violation. Critical for tuning: false positives erode trust faster than missed violations.

   DATA SHAPE

   Per-flag: was it valid, was the policy wrongly applied, was the rule too aggressive.
   COMMONLY FILLED BY

   • dismissal reason capture in the review queue
   • false-positive tag reviewers can apply
   • weekly retrospective with the compliance team