Foundry's automated grading needs the trace to carry the content it grades

A log line has a timestamp and a string. A span has a start time, an end time, a parent span for nesting, and a set of key-value attributes ^[3]. The parent pointer is the difference: the backend rebuilds the tree at read time. That is how you can see that a wrong price came from a tool call that returned a cached response older than your cache TTL, and not from the model ^[10]. Flat logs do not record which model call belongs to which tool result, nested inside which user turn ^[2].

The portability claim depends on the attribute names. Foundry populates them from the OpenTelemetry GenAI semantic conventions, which the post describes as a community-driven spec co-developed with contributions from Microsoft and Cisco Outshift for multi-agent scenarios ^[6]. The three names it cites are `gen_ai.request.model`, `gen_ai.usage.input_tokens` and `gen_ai.tool.name` ^[7]. All three sit under one prefix ^[16]. That shared prefix is why a viewer built for one GenAI framework can render another framework's trace ^[6].

The evaluation loop runs on the same structure. The post's argument is that a structured trace can be sampled and run through quality and safety evaluators continuously, without a human ever opening a trace viewer ^[13]. An evaluator can only score what the span stores. The attribute list in the post includes model name, token counts, tool name, arguments, HTTP status and error flags ^[5]. So the Application Insights resource behind the trace store holds tool inputs and model content for whatever share of traffic you sample ^[17]. The access policy on that resource now governs who can read that content.

The post gives two figures as illustrations of what tracing lets you see. One is a single span consuming 80% of a run's tokens ^[11]. The other is average latency moving from 2s to 9s after a deployment, with the responsible span type identifiable as tool call, model call or retrieval ^[12]. Neither is measured against a named workload. For the first to describe your system, your SDK has to emit per-span token counts at all. For the second, the fan-out has to be deep enough that span type distinguishes anything. The post's own example run is a planning call to the model, a tool call to an MCP server, a retrieval against a vector index, a synthesis call, and possibly a handoff to another agent ^[9].

The post lists sections on server-side versus client-side setup, production, security and cost considerations. The text supplied here stops at the definition of the trace exporter, the component that ships span data out of the process ^[15][18]. Sampling rate and attribute redaction are the two settings I would fix before looking at a dashboard. Both are chosen at instrumentation time, and both bound what the evaluators can score later.