Chapter 8
Why Data Wins
"Software becomes easier to evolve when knowledge is described instead of embedded."
Why This Chapter Exists
Modern software is built upon information.
Configurations.
Relationships.
Assets.
Rules.
Capabilities.
Yet many architectures continue embedding this information directly into code.
Values become constants.
Relationships become switch statements.
Behavior becomes tightly coupled to implementation.
Initially, this feels efficient.
The information is close to the code that uses it.
Over time, however, every change requires modifying the software itself.
The Cube Framework follows a different philosophy.
Knowledge should exist independently of the systems that consume it.
Code Should Solve Problems
Code excels at one thing.
Making decisions.
Executing algorithms.
Transforming information.
Coordinating systems.
What code does not excel at is storing knowledge that changes frequently.
Weapon statistics.
Available attachments.
Visual assets.
Audio references.
Gameplay balancing.
These are not programming problems.
They are authored knowledge.
Treating them as code unnecessarily couples design decisions to implementation.
Data Describes Reality
Data does not execute.
It describes.
A mesh describes appearance.
A gameplay tag describes meaning.
A configuration describes behavior.
A definition describes possibility.
The role of data is not to perform work.
Its role is to provide the knowledge required for systems to perform work correctly.
This distinction allows responsibilities to remain clear.
Data informs.
Systems decide.
This separation allows the same infrastructure to serve entirely different gameplay domains without modification.
Stable Systems, Flexible Content
One of the greatest advantages of data-driven architecture is the separation between infrastructure and content.
Infrastructure evolves slowly.
Content evolves constantly.
Weapons receive balancing changes.
Vehicles gain new configurations.
Equipment receives additional attachments.
None of these changes should require architectural redesign.
By moving changing knowledge into data, the framework allows content to grow while infrastructure remains stable.
Data Is Not Logic
A common misunderstanding is that data-driven architecture attempts to eliminate programming.
It does not.
Data should never replace algorithms.
Data should never contain decision-making.
Instead, data provides the information that algorithms require.
The distinction is subtle.
Algorithms answer:
How should this work?
Data answers:
What should this work with?
Both are equally important.
Neither replaces the other.
Data Enables Reuse
When knowledge is separated from execution, systems naturally become more reusable.
The same Runtime Builder can assemble countless different runtime objects.
Not because it contains special-case logic...
...but because the data it receives describes different outcomes.
The implementation remains stable.
Only the authored information changes.
This greatly reduces duplication while preserving flexibility.
The Cost of Hardcoded Knowledge
Every hardcoded value introduces an assumption.
Every assumption reduces flexibility.
Initially, these assumptions appear harmless.
Soon they become dependencies.
Changing a balancing value requires recompilation.
Adding a new configuration requires extending existing code.
Introducing new content begins affecting unrelated systems.
The architecture slowly shifts from describing knowledge...
...to hiding it.
The Cube Framework deliberately resists this transition.
Data Is a Language
Perhaps the greatest strength of data is not flexibility.
It is communication.
Artists can understand it.
Designers can author it.
Programmers can consume it.
Documentation can describe it.
Data becomes a shared language between disciplines.
Software development becomes collaboration rather than translation.
Design Note
Data should never exist merely because a value might change someday.
Data should exist because the knowledge belongs to the authored world rather than the implementation.
When deciding whether something belongs in code or data, ask:
"Is this an algorithm, or is this knowledge?"
The answer often determines its proper home.
Framework Law VIII
Code transforms knowledge. Data preserves it.
Healthy architectures allow each to focus on its own responsibility.
Looking Ahead
Data explains what exists.
The next chapter explores how these descriptions should be organized.
Rather than building large inheritance hierarchies, the Cube Framework prefers composition as its primary mechanism for creating complex systems.
Revision History
Version 1.0
Initial publication.