Performance and Diagnostics

This policy decides which AI decisions can run based on system conditions. It allows AI behavior to slow down predictably.

It does not use unpredictable timers. It keeps safety rules intact.

This service decides when approved AI tasks can run. It uses set times, triggers, and updates instead of random checks.

It keeps budget limits and data safety rules. The system controls when AI work starts based on permissions and load.

This service validates diagnostic events. It controls their cost and groups repeated events.

It prepares projections for reports or analysis. It does not write data to disk or show it on screens during live operation.

This service records the small amount of timing and pressure information Brain needs to keep work within its limits. Its records stay compact and in memory so measuring performance does not itself become a performance problem.

It does not use privileged processor counters, write logs to disk, or build detailed text diagnostics in the time-critical path. Broader reports, storage, and Kestrel displays are handled elsewhere.

This policy says how Brain handles non-critical tasks when system pressure threatens live operations. It makes sure safety and integrity work always runs.

Deferred or degraded results must be clear to callers and diagnostics. The system does not hide lower fidelity outcomes. Brain only reduces or delays work that is not required for safety. This policy protects the core functions of the system.

ADK registers important operations so it knows what kind of work is running, but it does not place an expensive stopwatch around every function call. Most of the time it watches low-cost signals such as queue growth, total processing time, memory pressure, and how much work finishes.

If those signals show a problem, ADK can take occasional samples to identify likely causes and briefly enable more detailed measurement around a suspected plugin or operation. Once it has enough evidence, the heavier monitoring is removed again.

For example, if NPC planning suddenly takes much longer but normal counters explain only half of the delay, ADK can inspect the relevant planning operations for a short period. A statistical suspicion may start that investigation, but it is not enough on its own to punish or suspend a plugin.

This service monitors real-time system workload. It uses observed runtime cadence and approved policy to set budget states for scheduler, plugin runtime, and other hot-path services.

It protects the host-facing runtime by deciding when work must continue, yield, defer, or degrade. The Brain owns the budget state and does not use universal numeric limits.

It only publishes budget facts and does not make decisions for other services. It does not control plugin operations directly.

ADK divides processing time into protected work and work that can wait, so one expensive feature cannot consume an entire game tick. Important game-facing work keeps its reserved time.

When another processor core is available and the work can be separated safely, Brain may briefly use an extra worker before queues grow too large. For example, NPC planning may borrow an idle core while accepted game changes keep their protected place on the main thread.