Preserve source provenance for imported and bootstrap memory

[MichaelSchmidle]

Migrated from legacy Fizzy card #81 after Memrok work moved to GitHub Issues + milestones.

Goal

Preserve source-level provenance and shape when Memrok ingests or bootstraps imported memory.

Why

• imported memory is not just “more nodes”
• source pages / imports / corrections / labels / preference signals can carry structure that helps later inspection and judgment
• Memrok currently risks flattening imported material too quickly into graph facts, which makes later hygiene, supersession, and debugging harder

Include

• retain enough source/import identity to trace where a memory came from
• make imported/bootstrap memory distinguishable from live native graph growth
• preserve useful source metadata for later inspection and selection logic
• support later features like better inspectability, safer hygiene heuristics, and re-judgment of compressed memories

Non-goal

• do not turn Memrok into a wiki clone
• this is about provenance-preserving curation, not raw page retrieval UX

[MichaelSchmidle]

Ripe architectural follow-up from the v0.6.0 quality-loop work and the recent Honcho/Hermes comparison.

Goal

Introduce perspective-aware local vs global representations in Memrok as a first-class architectural concept.

Why

We keep encountering the same structural problem:

• broad/global memory is often useful in some contexts
• but it bleeds into topic-local contexts where it becomes noise

Right now this often looks like a retrieval bug. It may actually be a representation problem.

Instead of treating Memrok as one flat memory field with better or worse ranking, we should explore a model with at least:

• durable global representation
• local/topic/session representation
• clear rules for how local and global memory influence retrieval and injection

Motivation

This turns a recurring bug shape into an architectural move:

• global memory is not wrong
• local memory is not always sufficient
• the missing piece may be an explicit distinction between the two

Desired outcomes

• better topic-local precision without throwing away durable global context
• clearer reasoning about why a memory belongs in a given prompt
• stronger foundation for provenance, supersession, and future retrieval-mode control

Questions to answer

• what counts as global vs local in Memrok?
• how are local views created, updated, and expired?
• when should local memory override global memory?
• how should critic/eval tooling inspect failures across these layers?
• how does this relate to imported/bootstrap memory provenance?

Non-goal

• not a full policy-update loop
• not a service/platform sprawl move
• not a UI feature first

Likely impact

This may require revisiting the framing of provenance/import work (#10) and structural retrieval work (#12), because both could become cleaner when local/global representation is explicit rather than implicit.