Observability

ArmorEdu doesn't ship its own observability bridge. An education agent's telemetry comes entirely from whichever ArmorIQ SDK it's integrated with (the same TypeScript or Python SDK used in Getting Started), so what you see in the dashboard is the shared SDK trace model, not an ArmorEdu-specific view.

What a turn records

Session
└── IAP plan trace
    ├── Policy call   (allow / allow_log / hold / block)
    ├── Tool execution
    ├── Model generation
    └── Event or error

Each capture_plan → get_intent_token → invoke cycle from Getting Started becomes one IAP plan trace. The policy check against your ArmorEdu policy is recorded as a policy_call span: its decision field is allow, deny, hold, or ask, derived from the enforcement action your policy resolved for that tool. So a call to export_student_records that your course bundle blocks appears as a policy_call span with a denied status; a call to create_privileged_account that your OIT bundle holds appears as a span reflecting the hold, correlated with the plan that's now waiting in approvals.

Additive and fail-open

Observability is telemetry, not an enforcement dependency. If the SDK's telemetry shipper is unreachable or a span fails to record, the policy decision your agent already received is unaffected: a blocked share_dataset_external call stays blocked whether or not the trace for it ever ships. See the SDK observability reference for the shared shipper, retry, and buffer behavior, and observability overview for the full producer and freshness model.

When traces appear

Traces are shipped on a periodic flush (5 seconds by default) rather than streamed live, and the dashboard itself polls on its own interval. A tool call your agent just made (an allowed get_grade_distribution, a held submit_grant_proposal) can therefore complete before its trace is visible. This is normal SDK behavior, not something specific to education agents.

What's not captured

The domain control blocks (ferpaAccessControl, researchDataControl, privilegedAccessControl, and the rest) shape what a policy decides, but they aren't separately recorded as their own span type: the resulting allow / hold / block decision on the policy_call span is what you see, along with the enforcement action and reason. There's no per-control-block audit trail beyond the policy decision itself in the current observability model.

Next steps