Diagnostics

What you can read

Diagnostics expose the four things that explain a decision: the active goal, the current plan, the last rejection with its reason and evidence, and resource spend against declared budgets.

local report = Runtime.inspect(actor)

-- report.goal          -> the active normalised goal
-- report.plan          -> ordered declared actions
-- report.last_rejection -> { action, reason, at_tick }
-- report.resources     -> spend against declared budgets
-- report.authority     -> the capability set in force for this role

-- Diagnostics are redacted by the same rules as external evaluation:
-- no player identifiers, no raw account data, no unrelated world state.

Redaction

Diagnostics are filtered by the same allowlist that governs observation. A field an adapter never declared is not in the trace, because it was never collected. Turning diagnostics on cannot widen what leaves the server.

Reading a rejection

A rejection carries a typed reason such as constraint.max_payload_tonnes or capability.missing, together with the observation fields the validator decided from. Two questions are usually enough to resolve any behaviour problem:

1. Which check failed? Capability, constraint, ownership or precondition.
2. What did the world look like? The evidence tells you whether the check was wrong or the observation was.

In Studio

The plugin renders the live observation frame, the plan and the verdict history for a selected actor, and lets you step a decision. What it shows is the runtime’s own state, not a parallel model of it — what you inspect is what the planner used.

In a live experience

Diagnostics can be sampled rather than always-on, and the trace can be routed to your own logging. Because redaction happens at collection, sampling changes volume, not exposure.