Unit 06 · Chapter 1 · 10 min read

Compliance architecture and policy as code

Connect legal requirements to product behavior and retained evidence.

The policy says customers receive a notice. The code sends an email. The email bounces. Compliance engineering asks whether the duty was met, what the system knows, and what must happen next.

Build an obligation register

An obligation register maps a requirement to the entity, product, event, control, owner, evidence, and effective dates. It separates legal requirements, contractual commitments, and internal preferences. This distinction matters when requirements conflict or change.

Use a stable requirement identifier in policy documents, implementation tickets, tests, and audit evidence. A paragraph in a policy is hard to trace if the code uses an unrelated label. Record the authoritative source and the approved interpretation. Engineering should implement a defined obligation rather than improvise legal scope from a brief product request.

An obligation register connects a requirement to the product behavior that satisfies it. The record should identify the authority, covered entity or activity, trigger, required action, responsible owner, evidence, and relevant date. This structure lets an engineer distinguish a product requirement from a general legal reference. It also shows where interpretation is needed before implementation.

A source update can change only one part of the chain. A new effective date may alter when a control begins; a scope change may alter which accounts enter it; a revised notice rule may alter customer communication. Track these dimensions separately. Replacing a paragraph in a policy document is incomplete if the old behavior remains in the service, queue, or message template.

Build an obligation register Build an obligation register — the flow Follow the sequence. Connect implementation owner and evidence. Source Identify the authoritative requirement Scope Map entity product and trigger Control Connect implementation owner and evidence — Follow the sequence. Connect implementation owner and evidence. Chapter sources · Open image

Build an obligation register Build an obligation register — the distinction These concepts answer different questions. Read each definition in the context of the section. Legal requirement Applies under the relevant law Internal policy Additional operating choice made by the firm — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Build an obligation register Obligation record Fictional teaching record. Supports verification. Obligation record Illustrative data; not a real customer record or a prescribed policy. ID notice-014 Stable reference Trigger defined decision event Starts the workflow Evidence notice version and delivery record Supports verification The duty must connect to observable behavior — Fictional teaching record. Supports verification. Chapter sources · Open image

Build an obligation register Build an obligation register — control and failure modes The duty must connect to observable behavior. The branches show why alternative designs fail. Control design Trace requirements through code and evidence. The duty must connect to observable behavior. Failure mode 1 Mix law and preference without labels. Change decisions become confused. avoid Failure mode 2 Use an undated source summary. Applicability may change. avoid Failure mode 3 Let a developer infer legal scope alone. Interpretation needs the accountable owner. avoid — The duty must connect to observable behavior. The branches show why alternative designs fail. Chapter sources · Open image

Separate rules from orchestration

A policy rule answers a defined question about eligibility or required action. Orchestration manages the sequence of evidence collection, decisions, notices, and follow-up. Mixing them into one large function makes both hard to change safely.

Represent policy versions explicitly. The decision record should identify which version applied at the event time. Use effective dates rather than assuming the newest rule applies to every historical record. When a rule changes, analyze in-flight work as well as new transactions. A mid-case update can otherwise create inconsistent treatment.

Separate rules from orchestration Separate rules from orchestration — the flow Follow the sequence. Preserve which policy governed the event. Rule Determine the required action Workflow Execute the action lifecycle Version Preserve which policy governed the event — Follow the sequence. Preserve which policy governed the event. Chapter sources · Open image

Separate rules from orchestration Separate rules from orchestration — the distinction These concepts answer different questions. Read each definition in the context of the section. Policy evaluation Computes a result under a rule Workflow execution Completes the resulting tasks and evidence — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Separate rules from orchestration Policy transition Fictional teaching record. No silent historical rewrite. Policy transition Illustrative data; not a real customer record or a prescribed policy. Decision time before new rule Old version may apply Notice time after release Workflow continues Applied version recorded No silent historical rewrite Release time and legal applicability can differ — Fictional teaching record. No silent historical rewrite. Chapter sources · Open image

Separate rules from orchestration Separate rules from orchestration — control and failure modes Release time and legal applicability can differ. The branches show why alternative designs fail. Control design Version rules and handle in-flight work. Release time and legal applicability can differ. Failure mode 1 Apply newest policy to all history. That can rewrite past decisions. avoid Failure mode 2 Hide rules inside notification code. The logic becomes difficult to audit. avoid Failure mode 3 Treat a computed action as completed. Execution may still fail. avoid — Release time and legal applicability can differ. The branches show why alternative designs fail. Chapter sources · Open image

Turn requirements into observable states

A required notice can move through prepared, approved, sent, delivery failed, and resolved states. The appropriate completion evidence depends on the actual duty and communication method. A successful API response from an email provider is only one technical event.

Design the workflow with the legal and operations owners. Define retries, alternate channels, deadlines, and escalation. Preserve the exact content and recipient reference under the retention policy. Do not report a notice as complete merely because a job was queued. The difference between intended action and evidenced action is where many compliance defects live.

Observable states make obligations testable. A requirement to investigate an eligible report becomes a sequence of receipt, classification, evidence collection, decision, communication, and any required financial adjustment. Each transition needs a timestamp and a responsible system or person. The exact workflow follows the applicable requirement, but the general engineering principle is stable: evidence must show what happened for the individual case. An aggregate dashboard that says 99% complete cannot explain the remaining customer’s experience.

Turn requirements into observable states Turn requirements into observable states — the flow Follow the sequence. Handle failure and retain evidence. Prepare Create the correct content and recipient Dispatch Use the approved communication route Resolve Handle failure and retain evidence — Follow the sequence. Handle failure and retain evidence. Chapter sources · Open image

Turn requirements into observable states Turn requirements into observable states — the distinction These concepts answer different questions. Read each definition in the context of the section. Queued Work is waiting to run Completed duty Required action has sufficient evidence under the rule — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Turn requirements into observable states Notice lifecycle Fictional teaching record. Needs the defined follow-up. Notice lifecycle Illustrative data; not a real customer record or a prescribed policy. Content version-7 Exact template used Provider accepted Technical submission Delivery bounced Needs the defined follow-up A queued job does not prove the duty was met — Fictional teaching record. Needs the defined follow-up. Chapter sources · Open image

Turn requirements into observable states Turn requirements into observable states — control and failure modes A queued job does not prove the duty was met. The branches show why alternative designs fail. Control design Model failure and completion evidence explicitly. A queued job does not prove the duty was met. Failure mode 1 Count provider acceptance as every form of legal delivery. The applicable requirement may differ. avoid Failure mode 2 Drop bounced notices. The workflow remains unresolved. avoid Failure mode 3 Retain only the current template. Past content becomes unprovable. avoid — A queued job does not prove the duty was met. The branches show why alternative designs fail. Chapter sources · Open image

Test the boundary conditions

Compliance defects often occur at the edges: incomplete applications, changed addresses, weekends, time zones, account closure, or an outage during a deadline. Build tests from the approved requirement, not just the code’s current behavior.

Use examples that vary one legally relevant fact at a time. Record the expected result and source interpretation. Test both the ordinary route and the exception route. A test that repeats the implementation formula can pass while both are wrong. Independent expected cases make the verification meaningful.

Test the boundary conditions Test the boundary conditions — the flow Follow the sequence. Exercise normal and exception paths. Identify boundary Find facts that change the duty Specify outcome Use approved interpretation Test Exercise normal and exception paths — Follow the sequence. Exercise normal and exception paths. Chapter sources · Open image

Test the boundary conditions Test the boundary conditions — the distinction These concepts answer different questions. Read each definition in the context of the section. Implementation mirror Repeats what the code already does Requirement test Checks a separately specified expected behavior — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Test the boundary conditions Boundary test Fictional teaching record. Observable outcome. Boundary test Illustrative data; not a real customer record or a prescribed policy. Input address changed mid-case Relevant event Expected approved routing behavior Requirement-defined result Evidence delivered fixture and state Observable outcome Passing code-shaped tests can still miss the duty — Fictional teaching record. Observable outcome. Chapter sources · Open image

Test the boundary conditions Test the boundary conditions — control and failure modes Passing code-shaped tests can still miss the duty. The branches show why alternative designs fail. Control design Test independently specified outcomes. Passing code-shaped tests can still miss the duty. Failure mode 1 Test only the happy path. Exceptions often carry the defect. avoid Failure mode 2 Ignore time zones. Date boundaries can alter behavior. avoid Failure mode 3 Use production customer records as fixtures. Synthetic cases can test the rule. avoid — Passing code-shaped tests can still miss the duty. The branches show why alternative designs fail. Chapter sources · Open image

Manage corrections as customer events

When a compliance defect affects customers, fixing the code is only part of the work. Identify the affected population, determine the appropriate remedy, execute it, and verify completion. Preserve the difference between potential and confirmed impact.

Use a reproducible population query with reviewed assumptions. Reconcile remediation records against that population. Track failed contacts and exceptions. A release note saying fixed does not show whether past customers received the required correction. The final evidence should connect the original defect, affected records, remedy, and remaining unresolved work.

Manage corrections as customer events Manage corrections as customer events — the flow Follow the sequence. Confirm each record has an outcome. Identify Define and review the affected population Remedy Execute approved corrective actions Reconcile Confirm each record has an outcome — Follow the sequence. Confirm each record has an outcome. Chapter sources · Open image

Manage corrections as customer events Manage corrections as customer events — the distinction These concepts answer different questions. Read each definition in the context of the section. Code repair Stops the defect in future processing Customer remediation Addresses the consequences of past failures — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Manage corrections as customer events Remediation record Fictional teaching record. Eight remain unresolved. Remediation record Illustrative data; not a real customer record or a prescribed policy. Potentially affected 1200 Initial population Confirmed affected 940 Reviewed scope Completed 932 Eight remain unresolved A code fix does not repair past harm by itself — Fictional teaching record. Eight remain unresolved. Chapter sources · Open image

Manage corrections as customer events — control and failure modes

Control design

Verify remediation against the affected population. A code fix does not repair past harm by itself.

Failure mode 1avoid: Close after deployment. Historical cases may remain.
Failure mode 2avoid: Assume potential impact equals confirmed impact. The scope needs evidence.
Failure mode 3avoid: Ignore failed remediation attempts. Those customers still need resolution.

A code fix does not repair past harm by itself. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

Continue with Consumer protection, errors, and complaints to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17