Trajectory Memory Ledger
The Trajectory Memory Ledger is the formal paper behind KARL. It describes the append-only schema, six-signal reward engine, OAPL-Lite export, and entity bridge used to turn real agent work into reviewed training data.
Paper workspace
Live draft structure
Artifacts
Markdown paper source
The Trajectory Memory Ledger paper is mapped from the KARL paper source.
source-only
Editable source
Paper source exists. Public artifact should be rendered after privacy-sensitive example review.
Source anchors
karl/paper/karl-paper.md
Trajectory Memory Ledger deployment notes in MEMORY.md
KARL trajectory-ledgerd and SFT exporter
Method tags
Ingest intersections
Status
Paper drafted from the KARL deployment corpus; public abstract safe, raw traces private.
Key claims
01
Experience replay for coding agents should preserve full tool-use trajectories.
02
Reward can be derived from observable behavior without explicit preference labels.
03
Schema normalization is what makes cross-project training data possible.
Public reading note
Readable public page; full manuscript needs privacy review.
Standard skeleton
What this paper must keep proving
problem
A coding agent cannot improve from work it cannot replay, score, or normalize across projects.
method
Record complete tool-use sessions into an append-only schema and score them with a six-signal reward engine.
implementation
Four-tap instrumentation, Rust ledger daemon, schema-v2 normalization, SFT export, and entity bridge.
data
Real private session traces; public release should expose schema and aggregate behavior, not raw conversations.
evaluation
Schema consistency, reward separation, export quality, and downstream training/routing lift.
references
Agent observability, experience replay, process reward models, telemetry schemas.
openQuestions
Which anonymized examples can be safely published as canonical ledger rows.
Checkpoints and references
Proof chain
Claim checkpoint
central-claim slot
Every central claim must point to a proof anchor or remain labeled as speculative.
Implementation checkpoint
implementation-map slot
Every method should identify the code path, harness, schema, or protocol that embodies it.
Evidence checkpoint
evidence-manifest slot
Every reported result should point to run IDs, packet IDs, data snapshots, commits, or review artifacts.
Reference checkpoint
references slot
Every external claim should resolve to a cited paper, benchmark, standard, or documented prior system.
Release checkpoint
release-gate slot
Every PDF needs a named condition before it can move from draft to citation-ready.