These notes explain how Brain schedules work, runs isolated plugins, resolves competing intents, commits accepted changes, and observes performance. Plugins can request outcomes, but the kernel keeps final mutation order and authority deterministic.

The same area also covers activation, validation, shared queries, diagnostics, snapshots, and safe degradation when the server is under pressure.

Time Estimates That Learn

When ADK shows how long a slow operation may take, it can learn from comparable completed work instead of repeating a fixed guess forever. Estimates are ranges with confidence, not promises.

For example, a report initially estimated at twenty minutes may later show ten to twelve minutes for servers with similar data volume and hardware because that is what comparable runs actually achieved.

Chronos Scheduler

Chronos Scheduler is a Brain service that handles delayed tasks and timing. It manages when work should happen without relying on real-time clocks or other systems. It only wakes up eligible tasks, but does not decide what happens next or change game state. It works with approved Brain execution paths to validate and control what can proceed.

Efficient Plugin Triggers

ADK is designed to let plugins declare exactly which events should wake them. A plugin may subscribe to a broad event family, add detailed conditions, or connect a simple trigger directly to a framework-managed action without running custom plugin code.

For example, a plugin could declare that using a particular medical item submits a health-adjustment request. ADK would still attribute the request to that plugin and apply the usual permission, rule, validation, and receipt checks.

Answers That May Arrive Later

ADK can continue safely when a useful calculation does not need to finish in the current game tick. The framework first reuses a compatible ready answer, then joins compatible work already running, and starts new work only when needed and affordable.

For example, an NPC may take cover immediately and learn a distant attacker's likely identity a few ticks later. It does not freeze, launch the same calculation every tick, or pretend it knew the later answer earlier.

Failures That Mean Something

Framework operations return named outcomes instead of an unexplained success flag or exception. The operation owner defines what each outcome means, which failures a plugin must handle, and which safe response ADK supplies automatically.

For example, an inventory grant may return target_full. A plugin may request mailbox delivery, but it cannot relabel the failed inventory insertion as successful. If its custom recovery also fails, the framework still has the inventory owner's standard recovery path.

Decisions Before An Action Happens

Some actions must be allowed, denied, or adjusted before the game commits them. This contract gives each request one decision owner, one deadline, and one declared safe fallback. Plugins may contribute bounded advice, but response timing does not decide which rule wins.

For example, a building-placement decision may combine protected-zone and construction-policy evidence. The placement owner makes the final decision before its deadline; a slow cosmetic plugin cannot hold the player action open forever.

Numbers Must Keep Their Meaning

This contract prevents plugin and API numbers from silently changing through unsafe conversion. Every numeric field declares whether it is an integer, decimal/fixed-point amount, ratio, or approximate floating-point measurement, together with its unit, range, precision, scale, and rounding rules. Compatible units can be converted explicitly, while incompatible dimensions such as distance and time cannot be mixed. Safe declared cleanup may continue with a warning; ambiguous or critical values are rejected.