Intent and Mutation
This part of ADK explains how a request becomes a safe change in the game.
Plugins and framework services describe what they want to happen. ADK checks the request, resolves any conflicts, decides whether the change is allowed, and sends an approved action to the game engine.
Each step has one clear job. This makes changes easier to understand, test, and stop when something is wrong.
For example, if two plugins try to change the same item, neither plugin writes the change directly. They submit requests, and ADK checks the rules before the game is changed.
Atomic Mutation Envelopes
Related changes to game data can be grouped together. All changes in a group either happen or none happen. Each group has one clear result. Other systems can respond without waiting for the next update cycle. The Brain makes the final commit decision for each envelope.
Example: Related proposals in one envelope either commit together through Brain or reach a clear outcome without a partial commit.
How Brain Chooses Changes
Brain picks which changes to accept when they conflict. The choice is clear and does not depend on plugin order. Approved rules guide the choice. Silent removal or automatic merging of all changes are not allowed. This policy only applies to admitted proposals. Brain never discards changes without a reason. The decision is always clear and fair.
Intent Submission Boundary
Plugins and non-authoritative workers must submit structured proposals to Brain. They cannot write Warehouse state directly. Brain reviews each proposal. It decides if changes are allowed. Once a proposal crosses this boundary, it is independent framework-owned data and no longer depends on the submitting plugin remaining loaded. This boundary prevents direct state mutation. It ensures Brain controls all changes. The Warehouse is not part of this boundary. Only Brain can mutate state after review. This boundary does not define proposal fields, conflict policy, or mutation internals.
Example: A plugin submits a structured change proposal. Brain validates it instead of letting the plugin write Warehouse state directly.
Brain Mutation Control
Brain owns the final say on which changes are saved. Plugins prepare requests but cannot decide what gets applied. The system uses lanes to manage work. Each lane has one owner who controls commits. Brain never allows unauthorized access to Warehouse. This keeps state updates clear and safe.
Mutation Proposal Contract
This contract defines how Brain processes requests to change system state. A proposal is not a direct write or command. It is evidence for Brain to review and decide on changes. The exact format and structure are left to later decisions. This keeps proposal semantics stable while allowing implementation details to vary.
Outflux Deduplication
This reduces redundant work after Brain commits its decisions but before operations go to Pinky. It only removes operations that are the same or replaced by others. Valid work is kept in order. Bad work is rejected.