Runtime Rules and Validation
These notes explain how ADK checks configuration changes, rejects updates based on old information, and stops plugin work that exceeds its approved limits.
For example, if two changes were based on different versions of the same setting, ADK should reject the older one instead of silently overwriting the newer choice. A work limit can cover time, memory, processor use, or output size, depending on the operation.
The goal is to make failure visible and explainable. These are requirements for the ADK design, not a claim that every safeguard is already running today.
Checking That a Planned Change Is Still Valid
A plugin may plan an action using information that changes before the action is ready to happen. This service asks whether the particular facts behind that plan are still current.
Plugins report what they observed, but Brain performs the check and decides whether the proposed change remains acceptable. An unrelated change to the same player or object does not automatically invalidate the plan. This service checks validity only; it does not schedule the action or decide its place in the execution order.
Configuration Decision Process
This service selects the best configuration from all suggestions. It follows rules to decide which settings to use. Only one version is active at a time. Plugins cannot change settings directly. No changes override others based on arrival order.
Stopping Overused Plugins
This service stops plugins that use too much time or memory. It prevents issues without changing the main system state.
The Brain service handles plugin budget termination. A plugin must not change Warehouse data directly during calculation. The service does not let a plugin modify committed data after being canceled. It uses safe methods to stop plugins.