LANDMARK · 6 MIN · BUILD
Logging and traces
After this landmark, you can specify what an AI system’s logs need to capture to make a bad output debuggable after the fact.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
A model’s output is the end of a chain (retrieved context, tool calls, intermediate reasoning steps, the exact prompt sent), and if that chain isn’t logged, a bad output is nearly impossible to diagnose after the fact. Traditional application logs (an error message, a stack trace) don’t capture what an AI system needs: what context the model actually saw, what it decided, and what it did with that decision.
Logging for AI systems means capturing the full trace (inputs, retrieved content, tool calls and their results, and the final output), so a bad result can be traced back to its cause instead of shrugged off as unexplainable.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
What this looks like for you
Not your layer directly, but it’s why some AI tools can tell you ‘here’s the source I used’ when you ask, and others can only say ‘I’m not sure why I said that.’
MAKE A DECISION
A customer reports that an AI assistant gave them incorrect account information. The team wants to understand what happened. What do they need?
CARRY THISFor one AI feature you build or maintain, check whether a bad output from last week could actually be traced back to its cause. If not, what’s missing from the logs?