Cross-Tier Risk

Knowledge layers get more useful when they link across tiers — personal context informs team work, team decisions inform app-scoped deployments. The risk of linking is not that a link exists; it is that the link permits reads in a direction that shouldn't exist.

The directional asymmetry

Three tiers, three sensitivity profiles, three different blast radiuses if compromised.

The personal tier holds the most fine-grained, least reviewed content — half-formed opinions, private observations about colleagues, draft reasoning, personal financial or health notes. Compromise of one person's personal tier is bounded to that person; the content is not typically referenced by other systems.

The team tier holds consolidated institutional knowledge — customer context, strategic decisions, internal playbooks. Compromise of the team tier has organisational blast radius: a determined insider with access to the team tier holds the equivalent of the company's memory.

The app-scoped tier holds end-user content — customer conversations, product data, deployment-specific facts. Compromise of app-scoped has external-party exposure: the organisation becomes responsible for its customers' data, not only its own.

These blast radiuses are different. The control that matters when tiers link is therefore the direction of the read.

The default position

Personal reads team. Team does not read personal.

The reasoning: a team-tier compromise that could pivot into every user's personal tier would turn a bounded incident into a catastrophic one — every employee's private notes, observations, and draft thinking exposed through a single breach of the team system. The asymmetry is justified because the failure modes are asymmetric. Reading from personal into team, by contrast, is the kind of motion that compounds knowledge without creating new attack paths: a user can pull their own personal reasoning into a team concept, and the team concept inherits its author's judgement, not the person's full personal store.

Explicit promotion is the only team-direction flow. When personal content has to surface in the team tier, the user deliberately promotes it — with awareness, with authorship marked. There is no silent copy, no background sync. The principle that enforces this is hybrid-authorship: content in each tier has a knowable provenance, and cross-tier writes require a human decision.

For app-scoped the pattern is stricter still. App-scoped does not read team by default; team reads app-scoped on explicit authorisation only. This is because app-scoped is where customer-facing data lives, and a team-side compromise should not translate into a customer-side exposure.

Worked example

In the team KMS, the MCP interface is where cross-tier intent becomes enforceable. An MCP token carries a scope — which tier, which role, which agents are permitted — and the allowlist determines what the token can reach. A personal agent can query the team tier through an appropriately-scoped token; the team tier has no token that grants it read access into any user's personal tier by default. If a team-scale agent needs a user's personal input, the user's agent writes it into the team tier explicitly. The read never happens the other way around.

The same pattern plays out at the boundary of two connected entities post-acquisition. When a second organisation's systems are brought onto the same knowledge layer, the sensible default is that staff of one entity do not automatically see the other entity's customer records, financial data, or operational detail. Executives see both; department leads see their own entity; specific cross-entity access is granted case-by-case as integration progresses. This prevents the common post-acquisition failure where "everyone can suddenly see everything" creates a compliance incident before the integration team has drawn the new boundaries.

Caveats

The directional rule has a genuine tension with contradiction detection. If personal and team tiers hold conflicting claims about the same entity — a team concept says a customer's contract value is X, a personal note says X was renegotiated to Y — the correct behaviour is to flag the contradiction. But contradiction detection requires one side of the flag to see the other side's claim, at least at the level of the claim's existence.

The mitigation I ship is partial: contradictions are detected by the personal tier's agent reading against the team tier, not the other way around. The team tier is told "a personal note has flagged a contradiction" without being told what the personal claim is. The user decides whether to surface the substance, explicitly, into the team layer.

This is close-enough for most uses. For deployments where contradiction detection at the team side is structurally required — regulated reporting, audit-driven environments — the right pattern is not to relax the directional rule but to move the contradictable claim into the team tier explicitly in the first place. The directional rule is a shape of system, not a workaround for one.