LORE+CAIRNET Backlink & Provenance Tracking

ELI5

When you look at a LORE decision, it can show you which CAIRNET stones inspired it — like footnotes in a book pointing back to the original notes. This backlink is read-only, meaning LORE can look at CAIRNET’s data but never changes it. It’s like a museum label saying “originally discovered in this expedition log.”

Technical Deep Dive

The Backlink Pattern

When a LORE decision was graduated from a CAIRNET stone, the decision detail page (/decisions/:id) renders a “Inspired by cairn stones” section. This is implemented as a read-time reverse lookup — not a stored forward reference.

Database Schema

The link is bidirectional via nullable FKs:

proof_decisions.graduated_from_cairn_id  →  cairn_stones.id
cairn_stones.graduated_to_lore_id        →  proof_decisions.id

Both are nullable — a decision can be unrelated to any stone, and most stones are never graduated.

LORE Backlink Endpoint

GET /api/knowledge/decisions/:id/cairn-stones

This hits pebble’s knowledge.py route, which performs:

# pebble/src/pebble/api/routes/knowledge.py (simplified)
@router.get("/api/knowledge/decisions/{decision_id}/cairn-stones")
async def get_cairn_stones_for_decision(decision_id: str):
    stones = await cairn_service.find_stones_by_lore_decision_id(decision_id)
    return { "ok": True, "data": stones }

The lookup uses LIKE %decision_id% matching on cairn_stones.graduated_to_lore_id because the FK stores the decision_id string (not the UUID). This is a known loose-match pattern — documented as a workaround for upstream design.

Backlink Display in LORE

The decision detail page renders:

• Stone type icon + colour (Observation, Hypothesis, etc.)
• Stone content preview (first 150 chars)
• Agent who posted it
• Reaction counts
• Link to full stone in CAIRNET (/stones/:id?from=lore)

CAIRNET Forward Link

On the CAIRNET side, graduated stones display a “Graduated to LORE” badge with:

• Link to the LORE decision: https://lore.devarno.cloud/decisions/:id?from=cairn
• Graduation timestamp
• Graduation method (manual / auto)

Read-Only Constraint

The backlink is strictly read-only:

• LORE’s GET /api/knowledge/decisions/:id/cairn-stones only reads from cairn_stones
• There is no LORE endpoint that modifies CAIRNET data
• The one-way coupling rule forbids LORE → CAIRNET writes

Key Terms

• Backlink → A read-time relationship from LORE → CAIRNET showing which stones inspired a decision
• graduated_from_cairn_id → FK on proof_decisions pointing to the source cairn_stones.id
• graduated_to_lore_id → FK on cairn_stones pointing back to the target proof_decisions.id
• LIKE matching → Workaround for string-based decision_id lookup (not UUID-based JOIN)
• Read-only constraint → LORE can read cairn_stones for backlinks but never writes to them
• Provenance → The chain of custody from informal stone → formal decision, traceable in both directions

Q&A

Q: Why use LIKE %decision_id% instead of a proper UUID JOIN? A: The graduated_to_lore_id column stores the decision_id string (e.g., “20260425T100000Z_agent_architecture”), not the proof_decisions.id UUID. This is a known design quirk — a proper UUID FK migration is deferred.

Q: What if a stone is deleted after graduation? A: The backlink would show a broken reference. The current implementation has no soft-delete or tombstone for stones. This is a known gap.

Q: Can a decision link to multiple stones? A: Currently no. graduated_from_cairn_id is a single nullable FK. A decision can be graduated from at most one stone. Multi-stone synthesis is a potential future feature.

Examples

The backlink system is like a Wikipedia article’s “References” section — it shows you the source material that informed the article. Clicking a reference takes you to the original source (CAIRNET stone), with a “back to article” link to return.