Sometime around year six at Encore, a new front-end developer changed a color variable in the wrong partial. He wasn’t careless. He found a color he needed to update, opened the file where it was defined, and changed it. The problem was that the color was defined in two places. The one he changed was a local override that existed because someone three years earlier had needed a one-off variant for a specific component. The canonical definition lived in the global variables partial. He changed the override. The canonical value stayed. Now we had two sources of truth, and the override was winning in twelve components while the global was winning everywhere else.

It took two days to find the discrepancy. Not because it was hidden. Because it was four pixels of visual difference across a dozen screens, and nobody files a ticket for a color that’s 93% correct.

That incident taught me more about governance than any process document I’ve ever read.

The SCSS cascade (variables, mixins, partials, the import order that stitches them together) is a governance system. I don’t mean that metaphorically. I mean it functions identically to any other system that establishes defaults, manages overrides, and determines which authority wins when two authorities conflict. The import order IS the chain of command. A variable defined in _variables.scss governs everywhere unless a more specific partial overrides it. A mixin centralizes a decision so it gets made once and applied consistently. The cascade determines precedence.

Change a variable at the top, and the whole system updates. Override in the wrong place, and the whole system fractures. This is governance in the most literal sense: the structure determines what the defaults are, and deviation requires intent.

I maintained the Encore SCSS architecture for twelve years. [VERIFY: exact duration and whether Peter was sole maintainer or primary maintainer] Three ownership changes. Multiple engineering teams. Redesigns, feature additions, entire sections of the product rebuilt from scratch. The architecture survived all of it. The parts that were encoded in structure (the variable naming conventions, the partial organization, the import chain) held. The parts that were encoded in people’s understanding (why this mixin exists, what this override was compensating for, which components depend on this specific token) eroded with every team transition.

This is the same principle that eventually became FormWork. A single source of truth, encoded in structure, that makes the default path produce the correct output. The SCSS cascade was my first encounter with that idea in practice, years before I had the vocabulary for it.

Here’s what I learned about what survives.

Variable names survive if they describe the role, not the value. $color-primary survives. $blue-dark doesn’t, because the first redesign changes the blue to a green and suddenly the variable name is a lie. I watched this happen. A variable called $brand-blue persisted through a rebrand where the primary color became teal. For two years, $brand-blue returned a teal value. Nobody renamed it because renaming a variable that’s referenced in 200 files is a project, and nobody had budget for it. The name became noise. The system still worked, but it stopped communicating.

Mixins survive if they encode a decision, not just a pattern. A mixin that outputs a consistent box-shadow across components is useful but fragile. It’s a convenience. A mixin that encodes the rule “all interactive elements have a visible focus state with these specific properties” is governance. The first one gets bypassed the moment someone needs a slightly different shadow. The second one gets respected because bypassing it means making a conscious choice to break accessibility.

Import order survives because nobody thinks about it. This sounds counterintuitive, but it’s the strongest point. The import order in a well-structured SCSS architecture is invisible infrastructure. Variables load before mixins. Mixins load before base styles. Base styles load before components. Components load before overrides. Nobody changes this order because nobody has a reason to. It just works, and because it just works, it governs silently. The cascade enforces precedence without requiring anyone to understand why the precedence exists.

The parts that don’t survive are the parts that require human memory. Why was this component extracted into its own partial? Because three years ago there was a performance issue with a specific page, and the component needed to be conditionally loaded. The performance issue got fixed. The component stayed extracted. Now it’s just a weird organizational choice that new developers route around instead of understanding.

Every codebase accumulates these fossils. The SCSS cascade is particularly vulnerable because CSS is forgiving. It doesn’t throw errors when you duplicate a declaration. It doesn’t warn you when an override makes a global variable irrelevant. It just applies the last rule that matches, and the visual result is close enough that nobody notices the governance has fractured.

I think the reason I eventually moved from SCSS architecture to governance as a general practice is that the cascade taught me the core mechanic. Defaults are stronger than rules. If the default output is correct, people don’t need to think about it. If the default output requires intervention to be correct, every intervention is an opportunity for drift. The twelve years at Encore gave me a laboratory for watching this play out at scale: hundreds of engineers, thousands of commits, three complete changes in organizational leadership. The structure held where the structure was structural. It failed where the structure depended on someone remembering why.

Code is methodology in practice. The SCSS cascade doesn’t describe a governance philosophy. It is one.