EdictumDecision Telemetry
Decision, audit, event, and OpenTelemetry attributes for proving what happened after an agent action was evaluated.
Right page if: you need the decision telemetry model across local audit events, OTel spans, server-backed events, run/session correlation, and workflow snapshots. Wrong page if: you need only sink setup -- see https://docs.edictum.ai/docs/reference/audit-sinks. For exact OpenTelemetry setup, see https://docs.edictum.ai/docs/reference/telemetry. Gotcha: telemetry records Edictum runtime decisions. It does not mean the reference API/app stack made the runtime decision; enforcement still happens in the SDK or Gate runtime.
Decision telemetry is the evidence layer for runtime governance.
Every evaluated action should be explainable later: what the agent tried, which rule or workflow boundary applied, whether the action was allowed or blocked, whether a human approved it, and which ruleset version was active.
Proof Loop
attempted action -> decision -> allow/block/approval -> audit recordCore Fields
| Field | Why it matters |
|---|---|
run_id | Groups decisions into one agent run |
call_id | Identifies the specific tool-call decision |
tool_name | Shows which tool the agent tried to use |
tool_args | Captures the attempted action payload, after configured redaction |
side_effect | Separates pure/read/write/irreversible risk |
principal | Carries identity, role, ticket, org, or claims context |
action | Records allow, block, would-block, approval, execution, or timeout outcome |
decision_source | Shows whether a hook, rule, sandbox, session limit, or approval path produced the decision |
decision_name | Identifies the rule or boundary that made the decision |
reason | Gives the human-readable block or approval reason |
policy_version | Ties the decision to the active ruleset hash |
mode | Distinguishes enforce from observe mode |
For the full local event schema, use Audit and Observability.
OpenTelemetry Attributes
Use OpenTelemetry when the question is operational: block rate, allow rate, policy errors, tool distribution, or environment-level trends.
Important OTel attributes include:
| Attribute | Meaning |
|---|---|
edictum.tool.name | Tool being evaluated |
edictum.decision | Evaluation verdict |
edictum.decision.reason | Summary reason for the verdict |
edictum.decision.name | Rule ID or decision name |
edictum.decision.source | Decision source |
edictum.side_effect | Tool side-effect class |
edictum.environment | Runtime environment |
edictum.mode | enforce or observe |
edictum.policy_version | Active ruleset hash |
edictum.policy_error | Whether evaluation hit a policy error |
edictum.principal.role | Principal role, when supplied |
edictum.session.attempt_count | Attempts in the current session |
edictum.session.execution_count | Executions in the current session |
For setup and the exact span/metric reference, use OpenTelemetry Integration.
Reference Stack Events
The optional reference API/app stack can ingest events, approvals, runs, agents, and audit records. It coordinates visibility and review; it does not make runtime decisions for the agent.
Use server-backed events when you need:
- central audit feed across agents
- run and agent visibility
- approval records tied to operator decisions
- ruleset version history and replay windows
- SSE hot reload of server-backed rulesets
Workflow Snapshots
Workflow Gates add process evidence to decision telemetry:
- active stage
- completed stages
- blocked reason
- pending approval state
- last blocked action
- last recorded evidence
Use these fields to prove that an agent read required context, produced verification evidence, waited for approval, or stopped at a terminal stage.
Related
Last updated on