Intent and Mutation
This part of ADK explains how an intent 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.
Grouping Related Changes
Related changes inside one declared Brain-owned state scope can be grouped so they all commit or none commit. Each group has one clear logical result, and Brain makes the final commit decision for the envelope.
This guarantee does not make several game-engine operations atomic; Pinky applies resulting host work through its own receipts and reconciliation.
Example: A complete starter kit can commit as one Brain transaction, while the later native inventory application still reports and reconciles what the game accepted.
How Conflicting Changes Are Handled
When changes conflict, Brain chooses which ones to accept. The choice is clear and does not depend on the order plugins submitted them.
Approved rules guide this decision. Silent removal or automatic merging of all changes is not allowed. This policy only applies to admitted proposals.
Brain never discards changes without a reason, and every decision is clear and fair.
How Proposals Get Reviewed
Plugins and non-authoritative workers must submit structured proposals to Brain. They cannot write Warehouse state directly.
Brain reviews each proposal and decides if changes are allowed. Once a proposal crosses this boundary, it becomes independent framework-owned data and no longer depends on the submitting plugin remaining loaded.
This boundary prevents direct state mutation and ensures Brain controls all changes. The Warehouse is not part of this boundary. Only Brain can mutate state after review.
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.