A business rule changes, a new workflow is added, or orchestration logic shifts — absorbed by Manager and Engine, leaving infrastructure and shared concerns untouched.

An estimate was wrong or new work has been added to the schedule. Nothing in the code changes — the architecture is intact. You adjust the work packages, recalculate the critical path, and re-evaluate float. The same structural decomposition that produced the original plan still governs the updated one.

Non-functional volatility covers the stability qualities: performance, scalability, reliability, availability, extensibility, maintainability, security, and observability. Most are addressed outside the application — scalability through infrastructure, security and observability through cross-cutting Utilities. Extensibility requires a one-time structural investment: expose configuration points, support injection where hardcoded behaviour exists. Once done, new behaviours arrive as configuration, not code. The design itself is the primary answer to most non-functional concerns — which is why a well-decomposed system rarely generates ongoing churn from them.

An external API changes, a database is migrated, a vendor is replaced — absorbed entirely by the Resource Accessor. Nothing above it changes.

Logging standards change, auth conventions shift, observability tooling is replaced — absorbed by Utilities, which are consumed by all tiers but owned by none.