Feature Request: Decision Graph & Entity Timelines for Long Sessions

[simuxipalacheshi]

Context

Using Magic Context for multi-hour, multi-day sessions on a Holochain + Android project. The historian summarization and cross-session memory work well, but for very long sessions there are gaps in how "why" and "evolution" are preserved.

The current database has session_facts, compartments, and memories — but they are flat, independent records. The missing piece is the graph that connects them.

Proposed Features

1. Structured Decision Extraction

Currently session_facts capture conclusions but not the reasoning behind them. Historian should extract:

```json
{
"decision": "Use lair native API for key derivation",
"reason": "Follow Holochain best practices, avoid self-built key storage",
"rejected": ["Self-implemented PBKDF2 derivation"],
"confidence": "high",
"compartment_id": 8
}
```

This prevents loss of the "why" during compression.

2. Entity Timelines

When a topic (e.g., "auth module", "key architecture") spans multiple compartments, there is no way to see the evolution chain. An automatic tracker that links:

```
C3: discovered JWT in middleware
C8: decided to move to zome call
C15: tests pass, refresh token pending
```

would restore narrative continuity after compression. The historian already identifies entities — it just needs to link them across compartments.

3. Contradiction Detection

When a new decision contradicts an earlier fact, the system should flag it. Example:

⚠️ C15 sets LTO=thin, but C3 records LTO=thin is non-deterministic. Confirm intentional override.

Currently facts are flat — no cross-referencing or conflict detection.

4. Session Handoff Summary

When a session ends or context pressure forces a new session, the active working state is lost:

• What was being worked on
• Next immediate step
• Temporary assumptions in flight

A generated handoff card injected at the start of the next session would bridge the gap.

5. Layered Summaries

Instead of flat compartment summaries, support three levels:

• L1 — title-only (minimal tokens, all compartments)
• L2 — full summary (recent N compartments only)
• L3 — raw via ctx_expand (on demand)

This extends practical session length before hitting the history budget.

Why This Matters

For sessions spanning days, the structure of decisions and their relationships is more valuable than the narrative. A user restoring context should see:

```
Key Architecture Evolution:
C1: Root seed must never be network-visible
C5: Decided lair native APIs only (rejected self-built derivation)
C12: Implemented export_device_seed wrapper
C18: Added mnemonic recovery flow

Decision: Use lair native APIs
Reason: Holochain best practice, no self-built key storage
Rejected: Self-implemented PBKDF2
Status: Implemented
```

Instead of 6 separate compartment summaries that the agent must mentally piece together.

Database Impact

The existing schema already supports this:

• compartments table has id, session_id, sequence
• session_facts has category, content, session_id
• memories has superseded_by_memory_id, merged_from

What is needed:

• A decisions table (or extend session_facts with reason, rejected, related_entity, supersedes_fact_id)
• An entity_timeline table linking entities to compartment ranges
• A historian prompt update to extract structured decisions, not just flat facts

[ualtinok]

Hey, thanks for suggestions. I will take into account for the upcoming historian and dreamer overhaul. Layered summaries already exists and it is already 5 level exactly as you proposed. Once there's pressure on history limit a separate compressor pass either merges and/or put higher compression to compartments, at level 5 they become title only.