← ANTI-PATTERNS

Point Approval Governance

Central function scales by reviewing each decision — a ticket queue disguised as platform ownership

Principle violated

Cross-cutting functions scale as platform products with self-service guardrails — not as approvers on every in-set action.

Coordination as architectureMisaligned incentivesPath dependencyMissing principle

Point approval governance is what happens when a cross-cutting function — security, architecture, compliance, ethics, platform — scales by approving each decision instead of shipping platform self-service guardrails. The organisation names it a “platform team” but operates a ticket queue: every firewall rule, integration, transaction, or feature launch needs human sign-off. Work scales as O(decisions); product teams experience the function as gatekeepers, not enablers.

Introduction: One Authority Per Invariant — At Scale — the anti-pattern to platform self-service.

The anti-pattern

What they sayWhat they do
“We are a platform team”Review every request
“We have guardrails”Principles in slides — not encoded in software
“Self-service coming”Empty in-set — everything escalates
“Async approval”Locking organisation with a faster backlog

Traditional function shape: security approves each firewall rule; architecture board on every significant PR; compliance analyst on every transfer; ethics board on every feature or release. Even with reservation at the boundary, every irreversible action still waits on a human platform bind because no evaluable contour exists.

In software systems

Central approval microservices, manual CAB tickets for each deploy, security review queues per repo, “platform” APIs that only create Jira tasks. Automation wraps routing to humans, not policy evaluation. Teams script around gates; shadow IT reimplements checks locally — diffuse write authority returns.

In human organisations

Platform KPIs are tickets closed and SLA to first responseMOP theatre without MOE on whether the organisation moved faster safely. Incentives reward being in the loop on every decision; widening the in-set feels like losing visibility. Headcount grows with product teams; Conway’s Law produces matching approval chains in software.

In socio-technical systems

Product teams learn that “platform” means delay. They batch changes to minimise tickets, hide work until review day, or skip gates — producing exactly the inconsistent enforcement and audit fragmentation one authority per invariant at scale was meant to fix.

Why it persists

DriverMechanism
Safety theatreApproving each point feels safer than trusting encoded rules
Career incentivesReviewer role visible; platform product work invisible until failure
Missing product skillFunction never built policy engines — only process
Contour too scaryFear of Goodhart blocks widening in-set without meta-loop discipline

Principled alternative

Platform self-service guardrailsenable, shift work, constrain in software; single writer for rules and exceptions; maximize in-set; closed-loop on contour MOE. See platform self-service and platform guardrails.

Corpus stance

Context A2 — working stance — name the failure mode when “platform” org charts hide ticket-queue operations; pair with the guardrails pattern as remedy.