Execution Kernel

ADK can improve estimates for slow operations by learning from similar work that has already completed. These 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.

Many ADK systems can safely run less often, wait for a relevant change, or switch to a lighter method when the server is busy. Chronos keeps a registry of those controls and chooses how each kind of work should run from the needs of the framework as a whole.

For example, market estimates may move to a slower staggered refresh while the server is under pressure, but immediate danger reactions keep their protected timing. Individual systems report what they need and how they are performing; they do not privately decide that their own work is the most important thing on the machine.

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.

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.

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.

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.

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.

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.