Chapter 26
Designing New Operations
"Within the Cube Framework, extending behavior begins by introducing a new request—not a new execution path."
Why This Chapter Exists
Once new Definitions have been introduced, the framework understands new knowledge.
Knowledge alone, however, does not produce behavior.
Something must express the intention to use that knowledge.
Within the Cube Framework, this responsibility belongs to Operations.
Operations describe what should happen.
The participating framework systems determine how that request is fulfilled.
For this reason, introducing new behavior usually begins by designing a new Operation rather than modifying existing runtime systems.
Operations Describe Requests
An Operation is not gameplay.
It is not Runtime Assembly.
It is not networking.
An Operation simply represents a request made to the architecture.
It answers one question:
"What should the framework do?"
It deliberately avoids answering:
"How should the framework do it?"
This distinction allows multiple framework systems to cooperate without becoming tightly coupled.
New Behavior Begins With New Requests
When developers introduce a new gameplay capability, the first architectural decision should not be how to execute it.
Instead, they should determine whether the framework already understands the requested behavior.
If an existing Operation already represents that request, it should be reused.
If the request introduces genuinely new architectural intent, a new Operation may be appropriate.
This keeps the architectural language stable while allowing behavior to evolve.
Operations Should Remain Small
Every Operation should communicate one architectural intention.
Examples include:
- Build a runtime representation.
- Validate authored data.
- Import an existing Build.
- Equip a runtime object.
- Acquire a framework resource.
Attempting to combine multiple independent requests into a single Operation usually indicates that architectural responsibilities have started to merge.
Smaller Operations remain easier to understand, document and extend.
Operations Do Not Own Execution
One of the defining characteristics of the Cube Framework is that Operations never execute themselves.
They carry information.
They describe intent.
They identify the requested architectural action.
Execution belongs entirely to the framework systems responsible for fulfilling that request.
This separation allows execution strategies to evolve without changing the Operations themselves.
Stable Operations Support Stable Architectures
As the Cube Framework continues growing, new runtime systems will naturally appear.
Operations should remain stable throughout that growth.
A Runtime Builder may change.
The Build Pipeline may evolve.
The Data Manager may become more sophisticated.
The Operation requesting those systems should remain recognizable.
Stable requests encourage stable architecture.
Operations Strengthen Communication
Every subsystem participating in the Cube Framework understands the same architectural language.
Definitions describe knowledge.
Operations describe intent.
Builds prepare construction.
Runtime Assembly creates execution.
Because every subsystem shares this language, architectural communication remains remarkably consistent across the entire framework.
Design Note
Whenever new behavior is required, avoid asking:
"Which system should execute this feature?"
Instead ask:
"Does the framework already have an Operation that describes this request?"
Behavior should begin with architectural intent rather than implementation.
Framework Law XXVI
Within the Cube Framework, new behavior is introduced through new architectural requests—not new execution paths.
Operations define intent.
Framework systems fulfill it.
Looking Ahead
Once a new Operation exists, the framework must prepare the information required to fulfill it.
The next chapter explores how new functionality becomes part of the Build Pipeline without disrupting the existing Runtime Pipeline.
Revision History
Version 1.0
Initial publication.