Triggers for Promoting Patterns to Policy

A surfaced pattern is a candidate, not a commitment. Most candidate patterns get tracked, watched, and eventually either promoted or quietly retired. This chapter is about the conditions that warrant promotion — when a pattern crosses from project-level concern into organization-wide policy or standing function.

The four conditions for promotion

A pattern is ready for promotion when four things are true at once.

Recurrence is established. The pattern has appeared enough times, in similar form, across different projects, that calling it a pattern is no longer a stretch. Chapter 15 covered the surfacing work; this is its threshold.

The cost of not codifying is rising. Each new project that hits the same issue pays a tax. The organization is spending capacity re-solving what it has already solved, or watching projects stall on something predictable. When the running cost of inaction has become visibly larger than the cost of addressing the pattern at the organizational level, the pattern is ready.

The shape of the right answer is becoming visible. The organization has accumulated enough evidence to know what an actual policy or standing function would look like. If projects keep hitting the same data access bottleneck but the evidence about what process would actually work is thin, the pattern is real but not ready. Promotion requires both a recognized problem and a legible response.

There is an owner who can take it on. No policy gets written without an owner; no standing function gets stood up without one. If a pattern is real, costly, and shaped, but nobody can plausibly own the resulting structure, the promotion is premature. Either an owner gets identified, or the pattern stays a candidate.

When all four conditions are present, promotion happens. When any of them is missing, the pattern waits.

Two failure modes

The framework threads between two equally damaging mistakes.

Premature codification produces policy that anticipates the wrong problems. Rules get written before the organization has hit the issue often enough to know what the right rule actually is. Standing functions get stood up to handle problems that turn out to be smaller than expected, or different in kind. The cost is wasted structure — overhead that constrains valuable work without addressing real friction.

The opposite failure is no codification at all. Patterns surface, get tracked, and never get promoted. Each new project re-encounters the same issue, solves it locally, files the lesson somewhere, and moves on. The organization gains experience and produces no policy. The cost is exhausted capacity — every project paying a tax that the organization already knows how to remove.

The four conditions exist to hold the framework between these. They are deliberately conjunctive: all four together, not any one alone. Two recurrences without a clear answer is not enough. A clear answer without an owner is not enough. The framework is patient.

Rules versus standing functions

When a pattern is promoted, the promotion takes one of two forms.

A rule is a written constraint: a mandatory practice, a thou-shalt-not, a decision framework that all projects in some category must apply. Rules work well when the right action is consistent across cases — when the same answer applies regardless of context. All AI deployments touching customer data must clear a consent review. That is a rule. It freezes the decision once and applies it everywhere it fits.

A standing function is an organizational structure: a team, a program, a permanent role. Standing functions work well when the right action requires judgment, attention, or expertise — when no fixed rule can specify what to do because the cases are too varied. The organization has a data hygiene program is not a rule; it is a function. It does not tell projects what to do; it institutionalizes a capability the organization can draw on.

The choice between the two is not arbitrary. A pattern that consistently produces the same answer across cases wants a rule. A pattern that requires fresh judgment each time wants a standing function. Choosing the wrong form produces predictable failure: rules where standing functions belong are too rigid; standing functions where rules belong are too vague.

Sometimes a pattern produces both. A new function gets stood up, and a small set of rules govern how the function operates. That is fine. The two forms are not exclusive; they answer different parts of the same question.

What this layer is not

It is worth naming, briefly, what the policy layer is not, because the term carries assumptions.

It is not a governance committee that pre-approves projects. The strategic alignment work happens in the Strategic Loop, and project-level decisions happen on the canvas. The policy layer is what the organization has learned to handle as a standing concern — not a gatekeeping mechanism for new work.

It is not a compliance regime. Some of what ends up in the policy layer overlaps with compliance, but the layer’s logic is different. Compliance asks what regulators require. Policy in this framework asks what the organization has discovered it needs.

It is not built all at once. The layer fills in over time, as patterns move into policy. An organization newly running this framework has a near-empty policy layer. That is correct. An organization that has been running it for some time has a policy layer that has accumulated through honest work, not theoretical foresight.

The next chapter takes up who owns this layer once it begins to fill in.