The Enforce-in-Code Flow 2.3C.3-1

The enforce-in-code flow is a decision guide for determining whether a specific decision, process, or risk should be hard-encoded into structure — code, policy, or ceremony — or left to trained judgment with guardrails.

This sidebar provides the framework as a working tool. Apply it to your institution's critical decisions and document the results.

Step 1 — Name the Decision or Process

What specifically are you evaluating? A decision type ("whether to approve a data access request"), a process ("the workflow for promoting an employee"), a risk ("unauthorized changes to financial records"), or a boundary ("access to customer personal information"). Be specific enough to evaluate. "Communication" is too broad. "Who decides whether to send a company-wide email about a layoff, and what review process applies?" is workable.

Step 2 — Assess the Four Criteria

For the named decision, evaluate each criterion.

Table 2.3C.3-1 — Enforce-in-Code Assessment

Four-criteria evaluation for determining encoding requirement

Document each rating with evidence: not just "High" but "High — unauthorized data access violates privacy, creates legal liability, and damages trust."

Step 3 — Determine the Encoding Decision

Plot the ratings against the encoding spectrum.

High stakes + Constant frequency + High variability + Low reversibility: hard-code the decision. System enforcement. No human discretion at the decision point.

High stakes + any concerning combination: mandatory policy with approval gates. Human discretion exists but overrides require documented authority.

Medium stakes + multiple concerning factors: mandatory review. Decision is made by authority but checked before or after implementation.

High stakes + genuine complexity requiring varied judgment: structured ceremony. The process is encoded; the conclusion is not predetermined.

Low stakes + Rare + Low variability + High reversibility: judgment with training. No encoding required.

The middle ground is where the craft happens. Most organizational decisions fall between "obviously encode" and "obviously leave to judgment." The enforce-in-code flow makes the reasoning visible and auditable.

Step 4 — Specify the Encoding Mechanism

If encoding is required, choose the mechanism and document:

Hard code: System enforcement. The decision rule is built into software, database constraints, or access control. A person cannot override without triggering an audit trail and escalation. Strongest enforcement. Least flexible. Use for high-stakes, constant-frequency decisions where consistency is non-negotiable.

Mandatory policy: Decision follows a defined path with approval thresholds. Exceptions are possible with proper authority and documentation. Middle-ground between structure and judgment.

Mandatory review: Decision is made by the authority holder but reviewed before or after implementation. Review can veto or modify. Preserves judgment while adding oversight. Depends on reviewer diligence.

Structured ceremony: Decision process is defined to force rigor — research phase, option presentation, structured discussion, decision recorded with dissenters named. Content of the decision is not predetermined.

Step 5 — Document Enforcement, Change Control, and Rollback

Every encoded decision requires three operational components.

Enforcement: Who is responsible for ensuring the rule is followed? Not "everyone." One person or system. What monitoring mechanism verifies compliance?

Change control: How does this rule change? Who proposes the change? Who reviews? How long is the review period? When does the change take effect?

Rollback: If the rule change causes problems, how do you revert? What triggers rollback? Who has authority to initiate? How quickly can you revert?

If you encode a rule without these three components, you have built a system that cannot adapt. If you encode it with all three, you have built a system that is rigid about what matters and flexible about what is discovered.

Example: Data Access Decisions

Decision: Whether to grant a user access to customer personal data.

Assessment: Stakes: HIGH (unauthorized access violates privacy, creates liability). Frequency: CONSTANT (hundreds of requests per week). Human variability: HIGH (different managers use different criteria). Reversibility: LOW (once seen, data cannot be unseen).

Encoding decision: Hard-code. Role-based access control. Access granted if role, project assignment, and security clearance all align; denied if any misalign. No human override without audit trail and escalation.

Enforcement: Security team monitors all access grants; quarterly audit of access vs. need; annual recertification.

Change control: Access role definitions changed by security team + chief privacy officer review; thirty-day notice; rollback available within twenty-four hours if access grants spike.

Integration Points

• Institutional charter (2.3C.1-1): The charter specifies which decisions are hard-coded, which are policy-gated, and which are left to judgment.
• Restraint principle (2.3C.2): Restraint disciplines encoding — not every risk requires a hard-coded rule. The complexity budget (2.3C.2-1) prevents encoding overreach.
• Organization evidence pack (2.3C.4-3): Enforce-in-code decisions are documented as evidence that the institution has thought through what to structure and why.
• Hazard heatmap (2.3C.4-1): The enforce-in-code flow identifies which decision domains are highest-risk; the hazard heatmap tracks whether encoding is working.