---
title: "Consistency by construction beats consistency by discipline"
date: 2026-08-17
summary: "One address had to appear in the application config, the network attachment and two policy objects - four artefacts, four update paths. Rendering every one of them from a single required value made divergence something the tooling can no longer express."
tags: ["automation", "helm", "iac", "openshift", "fleet"]
draft: false
hero: "/blog/one-value-many-enforcers.webp"
heroAlt: "A single source node feeding four identical threads of light into four separate gates"
---

Every cluster in a small fleet runs a workload that talks to one device across a second network
interface, and that device's address has to appear in four artefacts. The application config, so the
workload knows what to call. The network attachment, so it gets the right address on the right
interface. The egress rule, so the traffic is permitted. And the policy governing the second
interface, for the same reason.

Four places. Four chances for someone to update three of them.

<!-- DIAGRAM: one cluster value feeding the application config, the network attachment, the primary policy and the secondary policy - one source, four renders -->
![Diagram of one cluster value feeding four rendered artefacts - the application config, the network attachment and both policies - with the required-field check failing the render when the value is absent.](/diagrams/one-value-many-enforcers.svg)

## The failure mode has no error message

That is not hypothetical - a version of it had already happened here. An address changed in one
artefact and not another, and the mismatch produced no error. It produced a policy that permitted
traffic to somewhere nothing lived, while the actual traffic went somewhere unpoliced. Everything
reported healthy. The enforcement had simply stopped meaning anything.

Config that must agree across several artefacts will eventually disagree, because the update path
requires a human to remember all of them at once, under time pressure, months after writing them.

## Template from one source

The change that held: the address lives once, in the cluster's values, and every artefact that
needs it renders from there. The application config, the attachment definition, both policies - all
templated from the same field.

Now they cannot disagree. Not "are unlikely to" - *cannot*, because there is nothing to update
twice. Changing the address is one edit, and every enforcement point follows automatically because
they were never independent copies to begin with.

## Make absence fail loudly

The other half is refusing to render without it. The schema marks the field required, so a cluster
that has not supplied an address fails at template time with a message that names the missing field.
That failure is a gift: it lands in the pipeline, before anything ships, instead of surfacing months
later as enforcement pointed at nothing.

## The render that refuses

Discipline was the old control here, and it had already failed once. Construction does not tire and
cannot half-finish an edit: every consumer renders from the one field, or nothing renders at all.
The failure you want is the render that refuses, not the deployment that polices the wrong address.

*Since fixed: the address field is required in the schema, and a render without it fails the pipeline.*
