Transaction Trace Analysis Skill

Transaction Trace Analysis

Use this skill when the task provides concrete logs, tables, counters, timestamps, or partial records and asks you to infer transaction behavior.

This skill is about reconstruction under partial evidence:

normalize columns into a stable event vocabulary
reconstruct per-transaction intent and per-object version timelines
join them through explicit fields (not through row order guesses)
produce a minimal, auditable classification for the required output

Quick Reference (pick the next file to read)

| If you need… | Read | |---|---| | Mapping weird columns into tx/key/op/timestamp/counter/status/reason | trace-schema-normalization.md | | Grouping events per transaction and avoiding “attempt vs request” mixups | transaction-history-reconstruction.md | | Reconstructing a per-key version timeline from writes/validation | object-version-history.md | | Interpreting timestamp/counter semantics and scope correctly | timestamp-and-ordering-fields.md | | Understanding validation failures, abort reasons, and conservative checks | validation-and-abort-records.md | | Avoiding overclaims when the trace is incomplete | evidence-quality-and-uncertainty.md | | Emitting deduped/sorted ids and minimal justifications | output-classification-patterns.md |

Trace Ledger (what you build first)

Build two tiny ledgers before doing any deep inference:

Transaction ledger

txn_id -> {
  seen_keys: [...],
  read-evidence: (key, observed_version_fields...),
  write-evidence: (key, installed_version_fields...),
  validation/abort-evidence: [...],
  candidate_commit_fields: ...,
}

Object ledger

key -> timeline [
  { event: write/abort/validate, txn_id, version_fields, counter_fields },
  ...
]

Only after both exist should you attempt joins like “did T’s read become stale?” or “could an aborted T have committed?”

Workflow (operational)

Schema normalization: name every column; identify scope for each counter/timestamp.
Per-txn reconstruction: summarize each txn’s evidence and candidate serialization point fields.
Per-key reconstruction: build a timeline per key; validate what orders it (wts? counter?).
Decision modeling: re-express the protocol’s decision rule in terms of trace fields.
Classification: prove “must abort” vs “could commit” vs “unknown from evidence.”
Output: dedupe ids, sort if required, write exact format.

Common Pitfalls

Treating per-key counters as global order.
Using file row order as time order without justification.
Calling something ‘unnecessary’ without exhibiting a safe order consistent with evidence.

Agent Skills: Transaction Trace Analysis

Install this agent skill to your local

Skill Files