The limits of CI templates for standards enforcement at scale

Where templates work, where they don’t, and what to use for the rest.

Every new engineering standard becomes a migration project when enforcement depends on teams upgrading their CI templates.

CI templates and golden paths remain foundational platform infrastructure. They standardize build environments, accelerate new-service creation, and codify organizational opinion in a reusable form. The question is how much of the standards-enforcement load a template can carry, and where that work needs to live elsewhere.

Five recurring failure modes expose the limits. Understanding the visibility problem underneath them lets you keep the value of templates while enforcing standards across the whole organization.

The goals

Platform teams need a system that delivers:

• Consistent standards across every repo and team. When a control applies, it applies the same way everywhere it is relevant.
• Context-aware controls. A payments service or internet-facing application needs stricter controls than a purely internal tool.
• Real-time visibility. Adherence is grounded in what actually happens in code and CI, rather than quarterly surveys or self-reported scorecards.
• Fast time to enforce. A new vulnerability, incident finding, or regulatory requirement should become an enforced standard in hours, not quarters.
• Innovation freedom. Teams retain autonomy over how they build while meeting shared standards for reliability, security, and operational readiness.
• The same bar for human- and AI-written code. The same guardrails apply to both.
• Compliance evidence as a byproduct. Audit preparation follows from enforcement instead of becoming a separate investigation.

What mechanism delivers all of these?

The intuitive answer, and where it stalls

The plan is straightforward: build a shared CI template, roll it out to every repo, and let the template enforce the standards. At small scale, with a limited set of repos and workflows, that is a reasonable approach.

At larger scale, it stalls for reasons that better template design and more rollout effort cannot fully resolve. The constraint is architectural: enforcement depends on every team adopting and continuing to use the prescribed workflow.

What CI is built for

CI scripts and shared workflows are a strong fit for:

• Repository-specific build, test, and package logic.
• Standardized build environments, including toolchains, base images, and caching.
• Golden paths that reduce setup work and give new services a supported starting point.
• Language- and framework-specific verification, such as Python linting, go vet, and JUnit suites.

A well-designed shared template saves substantial engineering time. Its limits appear when it must also provide organization-wide enforcement across diverse stacks, current adherence data, rapid rollout of new controls, and coverage of services that never adopted it.

Those jobs require structured, queryable evidence across the organization. The five failure modes explain why template adoption alone cannot provide it.

The recurring failure modes

1. The version-drift problem

A new version of the shared template means another round of upgrades across repos with different assumptions. The platform team can publish v43 today and still be supporting v37 next year.

Even organizations with extensive migration tooling spend years getting shared infrastructure changes adopted:

Spotify introduced its first backend Golden Path around 2014. Six years later, it described a “Golden State” initiative whose goal was to bring most of the engineering organization onto the supported path. That initiative included checks to determine whether systems followed it.

Airbnb’s migration of its JVM monorepo from Gradle to Bazel took 4.5 years. The team had to preserve existing behavior while handling build logic, dependencies, deployment differences, and service-specific failures. Its retrospective also acknowledged that combining migration with optimization extended the work.

At Google, migrating 200,000 build files from Python to Starlark took two years, according to engineer Laurent Le Brun’s account. The languages coexisted during the transition, and the migration had to account for numerous corner cases.

These projects differ from a template version upgrade, but they illustrate the same coordination burden: changing shared infrastructure means preserving the behavior of its consumers.

AI can reduce the authoring work. It doesn’t remove that burden. In Slack’s Jenkins-to-GitHub-Actions migration, the initial importer converted about 50% of pipelines without errors, partially converted roughly 45%, and failed on about 5%. Slack then built additional scripting and targeted AI-assisted corrections. Some changes still required knowledge held by the teams using the pipelines.

Google’s research on AI-assisted code migrations found substantial benefits too: participating developers estimated a 50% reduction in time spent compared with previous manual migrations. The paper explicitly notes that this was an estimate rather than a measured reduction in elapsed time. Validation and code-owner review remained part of the workflow.

The hard part is the behavior nobody wrote down: hidden requirements teams rely on and edge cases the old template supported accidentally. A migration has to preserve that behavior across hundreds of variations.

For a platform team maintaining templates, that creates three recurring problems:

• Forced upgrades can break builds. A changed step or tighter constraint can fail in combinations the platform team hasn’t tested. The platform team then inherits the work of diagnosing failures across other teams’ pipelines.
• Optional upgrades leave repos on old versions. Teams adopt on their own schedules. Some never prioritize the migration, leaving a long tail of versions to support.
• Adherence becomes version-dependent. A control introduced in template v40 doesn’t reach a repo pinned to v37. The standard exists in some places and not in others.

Workflow maintenance research reinforces the importance of external pressure. An empirical study of GitHub Actions histories observed spikes in modifications around ecosystem migrations and deprecations in 2022 and 2023. Routine publication of an update and widespread adoption are different events.

The failure: a control in v40 leaves services pinned to v37 outside its reach. Knowing the template version still does not establish what actually ran.

2. The adoption problem

Even before version drift becomes an issue, teams have to adopt the template. The reasons they don’t are usually legitimate.

Competing priorities. Migrating CI is another chore on a backlog full of features and fixes. The migration may deliver no visible improvement to the product that team is shipping, so it slips down the queue.

Teams have requirements the template didn’t anticipate. A service may be older, more critical, on an unusual stack, subject to a different compliance requirement, or halfway through another migration. It may have arrived through an acquisition with its own conventions. The long tail of exceptions is where much of the non-adoption lives.

Some teams use a different CI vendor. Acquisitions, legacy infrastructure, and operational constraints can leave multiple systems running for years.

You cannot keep making a template more customizable without taking on the visibility problem described in the next section. Nor does consolidating on one CI vendor eliminate differences in how teams build, test, and release.

Eventually, leadership asks: “Where is my standard pipeline?” The answer is that part of the organization uses it, some of that group has drifted, and the rest have exceptions the template still doesn’t cover.

The failure: the organization has a standard pipeline, but only part of the organization uses it. Standards enforcement still has to reach the teams with legitimate exceptions.

3. The customization black-box problem

To make a shared template useful across a large organization, it needs extension points: hook scripts, override variables, opt-out flags, and additional steps.

Once those exist, teams use them.

The template ends up wrapping CI scripts inside CI scripts. There is now a layer between what the platform team expects and what actually runs. The most important parts of a pipeline may be the parts a team customized because the standard implementation couldn’t meet its needs.

You can answer “did this repo invoke the template?” and still not know “did the required scanner run?”

A scanner inside a custom hook might be skipped, run against the wrong input, or have its failure suppressed. The template can pass while the requirement goes unchecked.

Making those hooks observable requires instrumentation and evidence collection. The platform team has to account for different commands, output formats, and failure behavior. Without that work, template adoption gives an incomplete picture of adherence.

The failure: every repo can pass the template’s basic checks while critical work remains hidden inside customization hooks.

4. The enforcement-versus-innovation tradeoff

When the template is the enforcement mechanism, changing the pipeline also changes the path through which standards are applied.

That pushes platform teams toward two uncomfortable choices:

• Strict enforcement. Every team must use the template as published, with tightly controlled deviations. Consistency improves, but the platform team becomes responsible for accommodating new tools, frameworks, and release requirements. Teams wait for changes or look for ways around the restriction.
• Loose enforcement. Teams can fork, customize, or replace the template. Autonomy survives, but the platform team loses a consistent basis for knowing which controls still apply.

Most platform teams are trying to be strict on the important parts and flexible on the rest. Every override adds another path to verify. Without visibility into those paths, the compromise can turn into a cycle: tighten until builds break and teams complain, then loosen until controls can be bypassed.

A team should be able to change its build tool while still meeting the same test-coverage requirement. A service should be able to use a different packaging process while still producing the required software bill of materials. Teams can implement those outcomes differently.

The failure: tightening the template breaks workflows; loosening it reopens gaps in enforcement. The middle ground requires evaluating outcomes across different implementations.

5. The incident-response problem

A vulnerability is disclosed. An approved image becomes unacceptable. A postmortem produces an action item: this failure should never happen again.

Through a template-based mechanism, the path to enforcement looks roughly like this:

1. Author a new template version.
2. Test it against known consumer patterns.
3. Release it.
4. Communicate the upgrade.
5. Field migration questions and breakages.
6. Wait for adoption.
7. Chase the repos that remain on older versions.

The incident needs an answer now. The new control is waiting for teams to upgrade their pipelines.

The difficulty of completing urgent changes across an organization is well documented. After the December 2021 Log4Shell disclosure, Wiz and EY found that organizations in their study had patched an average of 30% of vulnerable cloud resources by day six and 45% by day ten. Identifying affected workloads, testing changes, and updating older systems all took time.

Two years later, Veracode found vulnerable Log4j versions in 38% of the Log4j-using applications it analyzed. That figure included several vulnerabilities and unsupported versions; 2.8% still used versions affected by Log4Shell itself.

Equifax provides a particularly stark example of the gap between a published requirement and verified execution. In March 2017, its vulnerability-management team emailed approximately 430 individuals and distribution lists, instructing responsible personnel to patch Apache Struts within 48 hours. Scanning failed to identify the affected component, and the consumer dispute portal remained vulnerable. The congressional investigation documented failures in ownership, accountability, and execution of the patching policy.

These incidents weren’t studies of CI templates. They demonstrate the broader failure that template-based enforcement can reproduce: a central team publishes a requirement, distributes it, and lacks reliable confirmation that it has taken effect everywhere.

The failure: the incident-response cycle is faster than the template-adoption cycle. Adding a guardrail to the latest template leaves repos on older versions outside its reach.

The hidden problem underneath: visibility

You can publish all the templates in the world and still struggle to answer the questions a Head of Platform needs answered:

• Who has migrated to the new SDK?
• Where are the action items from the last postmortem enforced?
• Which services use the approved scanner version?
• Which services have the required liveness-probe configuration?
• Which repos still pull base images from Docker Hub instead of the private registry?
• Are the same required checks running for AI-generated PRs?

The data exists in CI logs, repository configuration, scanner output, test artifacts, and deployment manifests. But it is scattered across repos and inconsistent in format.

A CI template can insert a step into a pipeline. To establish adherence across the organization, something also has to observe whether the step ran, collect its output, and evaluate that output against the requirement. A missing scan result has to remain distinguishable from a passing scan.

That requires collection, normalization, and storage in a structure the platform team can query. It requires coverage of nonstandard pipelines as well as the teams that adopted the shared template.

There is a template, a step, and a check. The work looks done until someone asks where it’s actually enforced.

Cortex’s 2026 engineering benchmark reports a related gap in AI governance: 32% of respondents had formal policies with enforcement, 41% relied on informal guidelines, and 27% had no formal governance. The survey doesn’t establish why those gaps exist, but it shows how far policy adoption can remain from enforced practice.

CI templates are a rollout mechanism. Governance also needs a reliable source of truth about what actually happens across the organization.

The architectural shift

Templates struggle as the sole standards-enforcement mechanism because they combine two distinct problems:

1. Rollout: How do we get a pipeline to do something?
2. Truth: How do we know whether the organization is doing it?

When both depend on template adoption, every governance change becomes a pipeline rollout. Non-adopters become holes in visibility. Customization hooks become paths that need separate inspection. Old versions delay the reach of new controls.

Control evaluation lives outside the pipeline, running centrally against a consistent posture model across repos, regardless of CI vendor or template adoption. Pipeline execution stays in the pipeline.

The mental model is production monitoring applied to the software development lifecycle: observe centrally, without requiring each service to opt in.

How do we observe and enforce standards across every repo, regardless of which template it uses, or whether it uses a template at all?

Five things are worth designing for, whether you build the system or buy it:

1. Continue investing in templates and golden paths. They provide shared starting points, reusable build and test logic, and a supported approach for new services. Those benefits remain valuable.
2. Build or buy a posture data layer independent of template adoption. Observe what actually runs, normalize the signals, and store the results so they can be queried across services, including those outside the golden path.
3. Enforce at the PR boundary, not only inside pipelines. The PR provides a consistent control point across CI vendors and template versions, with feedback where developers act on it.
4. Measure adherence using observed evidence. Track the actual configuration, test result, or scanner output behind a standard. Template versions and self-reported status can provide context, but they don’t establish the result on their own.
5. Separate template upgrades from policy rollout. A pipeline migration can take quarters; a new centrally evaluated control can reach services in hours when the necessary evidence is available. New requirements may still need collection or validation work, but should not require every repo to adopt another template version.

What this looks like in practice

Earthly Lunar is a guardrails engine built on this separation. It centrally instruments repos and CI/CD, collects structured SDLC posture data, and evaluates and enforces engineering standards in AI authoring workflows, on pull requests, and at deploy gates.

• Central instrumentation through a repository app and a CI agent alongside existing runners. No per-repo rollout or template adoption is required.
• Structured posture data records what tools ran, their versions, scanner output, and deployment configuration for each repository and commit.
• Deterministic, centrally managed policies evaluate that data. Enforcement can progress from reporting to PR feedback and blocking.
• PR-level feedback applies independently of the CI vendor or template version a repo uses.
• Real-time dashboards show adherence across services and teams, grounded in observed activity.

Lunar complements existing CI investments. Templates and golden paths keep providing build environments and reusable workflows; Lunar supplies the central observation and enforcement layer. See how Lunar works for the architecture.

Plan for rollout and verification

Platform teams often discover this separation after years of pursuing standards through template adoption alone. Planning for both responsibilities earlier avoids making every new control depend on the same migration cycle. Keep investing in templates, and give standards enforcement a foundation that also reaches the services outside them.

For a broader account of the engineering diversity behind this problem, read our interviews with 100 engineering teams.

To see central collection and enforcement applied to your own standards, book a Lunar demo.