The Architecture Canontruth · evidence · projection
Pattern

Enforcement over Verification

pattern-enforcement-over-verification · canon/patterns/enforcement-over-verification/unit.md

Enforcement over Verification

Verification asks 'did this actor prove who it is?'; enforcement asks 'may this actor participate right now?' Keep them separate and make enforcement the live, structural gate — identity proven once does not mean permitted forever. Security as an enforced property, not a one-time check.

Problem

Systems often treat verification as permission. Once an actor proves identity, downstream flows assume the actor may continue participating. That fails when a verified actor is suspended, restricted, out of scope, missing approvals, or no longer allowed to use a capability.

Context

Use this pattern when participation depends on changing status: commerce eligibility, discovery visibility, monetization, delegation, module access, profile completeness, safety review, or market availability.

Forces

  • Identity verification may be durable while permission changes frequently.
  • Teams want a simple boolean, but real participation depends on current status.
  • UI hiding is insufficient if APIs, workers, or imports can still act.
  • Enforcement must fail closed when required state is missing or stale.
  • Operators need to suspend or restrict without rewriting identity history.

Solution

Separate verification state from enforcement state. Verification records what an actor proved. Enforcement decides whether that actor may participate right now. Put enforcement at the live action boundary for commerce, discovery, monetization, delegation, and other consequential behavior.

Consequences

Verified actors can be paused without deleting truth. Permissions become current and reviewable. Security becomes a structural gate instead of a historical badge. The system can distinguish "we know who this is" from "this is allowed now."

Failure Modes

  • A verified=true flag is used as permission everywhere.
  • Suspension hides UI but scheduled workers continue acting.
  • Enforcement logic is duplicated across endpoints and drifts.
  • Missing enforcement state defaults to allowed.
  • Support tooling can override live permission without an evidence trail.

Proof Points

commerce participants still need live enforcement for participation, monetization, discovery, and delegated action.

  • Ampriot — verified organizations, artists, venues, and

Full source pattern: 06-enforcement-over-verification.md.

Incoming References

Case Study 1