Skip to main content

5th Grade Summary

A trace says what happened.

A workload ID says what kind of job was supposed to happen.

Kam needs both.

Without workload IDs, all failures look like random chat mistakes. With workload IDs, Kam can see which product lane needs work.

The move from logs to traces is a big step.

The move from traces to workload IDs is the step that makes the traces useful.

A log can say an answer was generated. A trace can say which route ran, which tools were used, which hot reads loaded, and which answer contract was followed. A workload ID adds the product meaning: this was a team trend answer, a market-shape answer, a saved-ticket review, a fixture-promotion workflow, or a release-packet workflow.

What a trace needs

A useful Kam trace should answer five questions:

  1. What did the user or workflow ask for?
  2. What workload did Kam think this belonged to?
  3. What data, route, tools, and hot reads did the system use?
  4. What answer or artifact did it produce?
  5. What evidence says the result was safe, stale, incomplete, or wrong?

Trace fields that matter

Field family
Identity
Example
traceId, workloadId, sessionId
Why it matters
Makes behavior searchable
Field family
Intent
Example
route, sport, entity, market
Why it matters
Explains what Kam thought the user meant
Field family
Evidence
Example
hotReads, sourceFamilies, freshness
Why it matters
Shows what the answer was built on
Field family
Tooling
Example
toolPlan, calls, retries, latency
Why it matters
Debugs orchestration and cost
Field family
Contract
Example
requiredFields, forbiddenSources, caveats
Why it matters
Enables deterministic graders
Field family
Output
Example
answerShape, citations, nextAction
Why it matters
Connects system behavior to user value
Field family
Review
Example
labelState, judgeState, fixtureState
Why it matters
Turns production into learning

Takeaway: A trace should be useful to a grader, reviewer, SRE, and product owner.

Why workload IDs change the loop

Without workload IDs, production telemetry becomes a generic quality dashboard.

With workload IDs, it becomes an active-learning system.

Workflow

Trace-to-learning loop

Kam should help the user move from a question to evidence, caveat, decision, result, and review.

  1. 1

    Trace captured

  2. 2

    Workload assigned

  3. 3

    Failures grouped

  4. 4

    High-value examples selected

  5. 5

    Human labels expectation

  6. 6

    Deterministic graders run

  7. 7

    Fixture candidate created

  8. 8

    Release scorecard updated

The workload ID turns one answer into a reusable improvement path.

For example, a trace from chat.team_trends.v1 may fail because the answer says "the Spurs have covered recently" without naming the games, dates, closing spreads, final scores, and ATS outcomes. That is not just bad prose. It is a denominator failure.

The workload ID lets Kam group similar denominator failures together. It can send one representative packet to review, create a label, promote a fixture, and monitor whether the same failure drops over time.

Before and after

The before version of telemetry is:

request id
latency
status code
model response

That helps with uptime. It does not fully help with answer truth.

The after version is:

trace id
workload id
route
hot reads
source rules
contract checks
label state
fixture state
scorecard impact

That helps with product quality.

What workload traces improve

Failure diagnosis

Clearer

Duplicate review reduction

Likely

Fixture promotion quality

Stronger

Raw log usefulness

Limited alone

Takeaway: The point is not the exact number. The point is that structured workload evidence beats raw event logs.

What gets deduped

Kam should dedupe failures by product meaning, not by identical text.

Two users can phrase the same failure differently:

Which games counted in that ATS trend?
Show me the denominator behind that Spurs trend.
What was included in the 6-2 number?

Those are not three unrelated issues. They may all belong to the same workload and failure label:

workloadId = chat.team_trends.v1
failureLabel = missing_historical_denominator

That makes the review queue smaller and the fix more durable.

A good trace receipt

Trust receipt

What Kam should prove before confidence

A useful answer should leave a small receipt: route, scope, freshness, evidence, missing data, and confidence state.

Route

chat.market_shape.v1

Scope

A market-shape answer explaining what moved while keeping sportsbook odds separate from prediction-market context.

Freshness

Sportsbook odds are current; prediction-market context is delayed and should be caveated.

Evidence loaded

  • route: market_shape_explain
  • sportsbook odds loaded
  • prediction-market context separated

Missing or caveated

  • label required if source separation is unclear
  • prediction-market freshness caveat required
Status: Review if source separation was ambiguous

The lesson

Trace maturity is not about collecting every possible event.

It is about collecting the events that let Kam improve a specific product workload. The best trace is not the biggest trace. It is the trace that can become a label, a fixture, a release gate, or a scorecard data point.

The next action is to make workload ID mandatory anywhere Kam records answer or agentic behavior.

Read next

Related field notes

View all posts
intelligence-registryworkload-id

The Kam Intelligence Registry

How a workload-centered registry connects traces, labels, fixtures, judge evidence, agentic runs, work items, and release gates.

8 min read

kamsrescorecards

KamSRE Turns AI Quality Into Scorecards

How daily health digests, workload scorecards, drift checks, and release evidence make Kam AI operable.

8 min read