Feature Implication Build Gate

Feature Implication Build Gate

Feature flags are architecture when they encode the supported shape of the system. If one capability requires another, the build should know it. Incoherent combinations should fail before runtime.

Problem

Configurable systems often accept combinations nobody intends to support: replication without a store, network access without a pool, production mode without security defaults, or a module without its platform contract. The build looks flexible, but the flexibility is fake. It moves architectural work from the build gate to the operator's incident.

Context

Use this pattern when a product has compile-time flags, build profiles, deployment modes, edition switches, optional packages, modules, plugins, or framework profiles with real dependencies.

Forces

• Teams want optional features and multiple product shapes.
• Dependency relationships between features are easy to forget.
• Reviewers cannot reliably inspect every configuration combination.
• Runtime validation catches incoherence late.
• Unsupported combinations still create support, testing, and security burden if they can be built.

Solution

Declare feature implications at the earliest enforceable boundary. A dependent feature should automatically require its substrate, enable its prerequisite, or fail the build. Mutually incoherent features should be rejected. Each flag or mode should answer: what does this require, what requires this, what does this forbid, and what becomes impossible if this is off?

Treat the build gate as part of the architecture. The supported matrix is a product contract, not a release-engineering afterthought.

Consequences

The system has fewer accidental shapes. Tests, documentation, and operations align around supported combinations. New contributors get stopped early when they ask for impossible assemblies. The tradeoff is that some experiments require changing the implication rules instead of bypassing them.

Failure Modes

• Unsupported combinations are described in docs but still build.
• Startup validation catches a relationship the build could have enforced.
• Feature flags accumulate without an owner for the matrix.
• Tests assume coherent builds while packaging can produce incoherent ones.
• A dependent capability fails open when its prerequisite is absent.

Proof Points

network implies pool, replication implies store, and store implies pool.

constraint management when the rule is enforced by structure rather than memory.

• CapDB — compile-time flags encode implication rules:
• Law II — architecture is

Full source pattern: feature-implication-build-gate.md.