Linking Tiers

The open question

The three tiers exist in real life simultaneously. I have a personal KMS, I work in a team KMS, and I build app-scoped KMS into products. Right now they are separate systems that I manually bridge — copying a customer note from the team KMS into my personal one, surfacing a personal insight in a team doc.

The question: what would it look like for these to link?

Not "merge" — they have different trust boundaries, different update rates, different schemas. Linking means: shared entities are recognised as the same thing across tiers; updates in one can be surfaced (with consent) in another; insights compound across the boundary.

Current thinking

Three sub-questions, no clean answer to any of them yet:

1. Entity identity across tiers

If Sam is an entity in my personal KMS, in the team KMS, and in a BD-focused app-scoped KMS, are those three Sam-pages the same entity? Three views of one entity? Three independent entities that link? My current bias is three views of one entity — with a canonical entity ID that lives in a small shared registry, and each tier rendering its own view.

Open: who owns the registry? Personal-tier-first feels right (the canonical Sam lives in mine and other tiers reference it), but that breaks the moment Sam appears in a team KMS without first appearing in a personal one.

2. Insight propagation

If I learn something in a personal session that's relevant to a team decision, the insight should propagate — but not silently and not without consent. Current best guess: a "promote to" action on every insight in the personal KMS, with explicit destinations (team KMS, BD-app KMS, public) and a one-line statement of what's promoted and why.

The ripple principle wants this to be automatic. The trust boundaries want it to be explicit. The compromise is automatic detection, manual promotion.

3. Contradiction across tiers

The most valuable cross-tier behaviour would be cross-tier contradiction detection: "the personal note says Sam is leaning toward staying; the team note says Sam is leaning toward leaving." Today that requires me to remember both notes. A linked system would surface the conflict.

But: contradiction across tiers is also the most invasive behaviour. It implies the team tier can read into the personal tier (or vice versa) deeply enough to compare claims. This is where the directional asymmetry in cross-tier risk collides with the ambition to detect contradictions in both directions.

Known positions

• Personal KMS answer: cross-tier links are first-class but propagation is one-way (the personal KMS reads from other tiers; never writes into them without explicit promotion).
• Team KMS answer: tenant-isolated; cross-tenant linking is forbidden by design. A user's personal KMS sits outside the tenant boundary.
• Other practitioners: I haven't seen a serious published treatment of cross-tier linking. Tana, Anytype, Roam all gesture at it; none I've used solves it.

What would settle it

A working prototype where one shared entity (Sam) is rendered correctly across the personal, team, and BD-app KMS, with a tiny shared registry, and where I can answer "what does each tier say about this entity?" in one query without manually concatenating. That's the next experiment.