SouveraineOS/docs/substrate/tasks/ledger-entry-lifecycle.md

Cross-Referenced Ledger Entry Lifecycle

Priority: Low (design phase — no code exists, no bug to fix) Scope: Design the lifecycle of cross-referenced ledger entries — how commitments tied to specific narrative files are created, tracked, resolved, and archived.

The Problem

Aster's mandate now includes "Cross-Referenced Tracking" — ledger entries that reference a narrative file path and track an unresolved commitment or question about it. The mandate says things like "once resolved, the reference falls out of active attention" — but there is no mechanism for this. No archive trigger, no deletion policy, no TTL, no compaction rule. The words pretend a system exists that doesn't.

A ledger that accumulates resolved references forever becomes noise. A ledger that never cleans up becomes useless. The question is: what is the actual lifecycle?

What Exists

• ledger/ files are git-backed markdown with frontmatter
• Ledger entries are append-only timestamped lines: [YYYY-MM-DD HH:MM] content
• Resolved entries are marked: [YYYY-MM-DD HH:MM] RESOLVED — note
• Compaction (sliding_window / summary) operates on the subconscious's conversation session, not on her ledger files
• No tool exists to prune or archive resolved ledger entries

Questions to Answer

1. What does "resolved" mean operationally? Is it a flag in the ledger line (current: text convention only), a separate RESOLVED suffix on the same line, or something else?

2. When does a resolved entry leave active attention? Three options:

   • Manual: The subconscious notices it during a pass and deletes/archives it herself via the memory tool
   • Automatic: A compaction or archivist pass prunes entries resolved for >N days
   • Scroll: Entries simply accumulate and the subconscious reads the tail — old resolved entries naturally leave her context window

3. Is archive separate from delete? If a commitment is resolved, should it remain searchable somewhere (an archive file, a git history) or is delete acceptable since git preserves history?

4. Who decides? Does the subconscious have discretion to leave resolved entries in place if she thinks they may re-open? Or is there a hard rule: resolved = archived within N passes?

5. What about the primary? Does the primary ever need to see resolved entries, or are they purely the subconscious's tracking?

Constraints

• No new database or storage backend. The ledger files are markdown — whatever solution exists must work within that.
• The subconscious has limited tool rounds per pass. Any cleanup mechanism must not compete with her primary duties (Phases 1-4).
• Git history preserves everything — delete is never truly destructive.

Recommendation (placeholder)

This needs a design decision before it gets implemented. The simplest starting point: rely on the subconscious's existing ledger pattern. When she resolves an entry, she appends RESOLVED (she already does this). Over time, resolved entries accumulate at the bottom of the file. Her reads naturally focus on unresolved entries at the top. If a file grows too large, she can use the memory tool to archive old resolved entries to a ledger/archive/ file during an idle curiosity pass. No automation needed until the pattern proves insufficient.

Status: Design needed

Move to scoping once someone has time to design the full lifecycle. Until then, the subconscious operates on best-effort with the existing append-and-resolve pattern.