Chapter 27
Extending the Build Pipeline
"The Build Pipeline should grow by accepting new information—not by changing its purpose."
Why This Chapter Exists
Once new Definitions and Operations have been introduced, the framework understands new knowledge and new architectural requests.
The next question naturally follows.
How does this information become part of runtime construction?
Within the Cube Framework, this responsibility belongs to the Build Pipeline.
The Build Pipeline prepares runtime construction.
Its responsibility does not change simply because the framework grows.
Instead, the information flowing through the pipeline becomes richer over time.
The Pipeline Should Remain Stable
The purpose of the Build Pipeline is deliberately narrow.
It prepares runtime construction.
Nothing more.
New gameplay features should not redefine this responsibility.
Instead, they should integrate with the existing preparation process.
The architecture remains recognizable because the pipeline itself remains stable while the information it processes continues to evolve.
Extending Information, Not Behavior
Many developers instinctively extend a Build Pipeline by adding new execution logic.
The Cube Framework encourages a different approach.
New features should first introduce additional authored knowledge.
The Build Pipeline then prepares this knowledge alongside everything that already exists.
Rather than inventing new execution paths, the pipeline simply becomes capable of preparing more complete runtime descriptions.
Every Build Answers the Same Question
Regardless of which module is being assembled, every Build ultimately answers the same architectural question:
"What information is required before Runtime Assembly can begin?"
The answer may differ between modules.
A Weapon Build prepares weapon data.
A Vehicle Build prepares vehicle data.
An Equipment Build prepares equipment data.
The responsibility, however, remains identical.
Every Build exists to remove uncertainty before construction begins.
Build Pipelines Should Not Become Runtime Systems
As frameworks evolve, there is often a temptation to let Build Pipelines perform runtime work directly.
This should be avoided.
The Build Pipeline prepares.
Runtime Assembly constructs.
Gameplay interacts.
Each stage exists because it solves a fundamentally different architectural problem.
Preserving these distinctions keeps every subsystem focused and predictable.
Growth Through Preparation
Extending the Build Pipeline rarely requires replacing existing infrastructure.
Instead, new Build information is introduced naturally.
Additional validation.
Additional authored relationships.
Additional runtime descriptions.
The pipeline becomes more capable without becoming more complicated.
Its architectural responsibility remains unchanged.
A Shared Foundation
Every Cube module participates in the same architectural preparation process.
Although individual modules prepare different kinds of information, they all contribute to the same Runtime Pipeline.
This consistency allows future modules to reuse existing infrastructure rather than introducing their own construction process.
The framework grows.
The architecture remains familiar.
Design Note
Whenever additional runtime information becomes necessary, avoid asking:
"Can Runtime Assembly discover this later?"
Instead ask:
"Should this information already exist before Runtime Assembly begins?"
Preparation should eliminate uncertainty rather than postpone it.
Framework Law XXVII
Within the Cube Framework, extending the Build Pipeline means preparing richer information—not performing additional runtime work.
Preparation grows.
Its responsibility does not.
Looking Ahead
A prepared Build contains everything required for construction.
The next chapter explores how Runtime Assembly can be extended while preserving the deterministic architectural process introduced earlier.
Revision History
Version 1.0
Initial publication.