Skill: TraceMem Traces and Audit

Purpose

When to Use

• When you need to understand what TraceMem is actually recording.
• When generating reports or answering questions about past actions ("Why did you do that?").

When NOT to Use

• You generally do not "use" this skill to execute actions, but to inform how you execute them.

Core Rules

• The Trace is the Truth: If it's not in the trace, it didn't happen (legally/audit-wise).
• Append-Only: You cannot go back and fix history.
• Complete Picture: A trace includes your ID, the time, the policy version, the data schema version, and the exact outcomes.

Correct Usage Pattern

1. Design for Readability: When running a decision, imagine a human reading the trace 6 months later.
   • "Why did this agent delete this user?"
   • Look at the

     intent

     , look at the

     context

     you added, look at the

     policy

     result.
   • If the trace answers the question, you succeeded.
2. Linking: If you chain decisions (one decision triggers another workflow), reference the parent

   decision_id

   in the child's

   metadata

   or

   context

   .

Searching Past Decisions

decision_search

• Find precedent: Search by text, category, or tags before making a new decision
• Check supersession chains: Results include

  supersedes

  and

  superseded_by

  indicators -- follow the chain to find the current active decision
• Filter by status: Use

  status: "committed"

  to find only finalized decisions

Tool: decision_search
Parameters:
  - query: "authentication"  (free-text search)
  - category: "architecture"  (optional)
  - tags: ["jwt", "auth"]  (optional, all must match)
  - status: "committed"  (optional)
  - limit: 10  (optional, default 20, max 100)

• Answering "Why did we decide X?" questions
• Avoiding duplicate or contradictory decisions
• Building on prior context when making related decisions

Common Mistakes

• Phantom Actions: Doing side effects (like calling an external API) without recording it in TraceMem or via a Data Product. This creates "dark matter" — actions that have no record.
• Incomplete Evidence: Reading data via a side-channel (not a Data Product) and then acting on it. The trace will show the action but not the data that justified it.
• Not searching before deciding: Always check

  decision_search

  for existing decisions on the same topic before recording a new one.

Safety Notes

• Exoneration: A good trace protects you (the agent). If a policy was wrong, the trace proves you followed the policy correctly. If data was bad, the trace proves you acted on the bad data you were given.