App-Scoped KMS

An app-scoped KMS is a knowledge layer that lives inside a product — bounded to the product's domain, exposed through the product's UI, governed by the product's contracts with users. It is the strictest of the three tiers because every wrong answer becomes a product bug.

What this tier is

A knowledge layer that an end-user of an application interacts with through the application's UI. The KMS is invisible to the user as a "knowledge system" — they experience it as the product knowing things, remembering context, and getting smarter over time.

Examples: an app that helps users build a directory of providers; an app that ingests customer communications and surfaces relevant history; an app that maintains a project tracker with auto-extracted decisions.

Trust is asymmetric. The product owner trusts the system more than the end-user does. The end-user is judging by what they see in the UI — so visible mistakes have outsized cost.

Which principles it uses

All eight, with these adjustments:

• Route, Don't Organize — same, but routing rules are baked into the app, not editable by users.
• Separate State / Knowledge / Interface — same, with the interface layer being the product UI rather than a conversation.
• Automatic Compilation — more conservative than personal; user-visible compiled content needs review before display, often via a promote step in the UI.
• Bouncer-Promoter — strict; the bouncer protects the product's UX, not the user's vault.
• Design for Neglect — the system itself doesn't get neglected (it's running on the product), but individual user tenants do; the system has to remain useful when a single user disengages for months.
• Entity Context — the schema is fixed by the product; users can't introduce new entity types.
• Ripple & Contradiction — runs but is bounded to the user's tenant; cross-tenant ripple is forbidden.
• Hybrid Authorship — the most restrictive of the three tiers. LLM-derived content that surfaces in the UI must be marked, sourced, and ideally regeneratable.

Tier-specific divergences

• Source immutability. User-provided sources (uploads, integrations) are never mutated by the system. Compilation produces derived artifacts; the source remains untouched.
• Manual-friendly tracking. Even though the system can auto-compile, the UI has to make manual review and editing trivial. Users want a system that does the work and lets them correct it.
• Less autonomy. The agent does not take destructive actions without confirmation. No silent overwrites, no auto-archives without recovery, no irreversible decisions.
• Tenant isolation. Each user's data lives in its own tenant; cross-tenant retrieval is impossible.
• Versioned compilation. When a compilation changes (because a source changed, or the rules changed), the prior version is preserved with a diff. Users can see why the system's view of their data shifted.

What it is NOT

• A CRM. CRMs are flat record stores; an app-scoped KMS synthesises across records.
• A chatbot bolted onto a product. A chatbot answers; an app-scoped KMS remembers and propagates.
• A SaaS feature. It's an architectural choice that touches the whole product, not a module.

The reference implementations

Three live examples from the projects I work on:

• A BD pipeline KMS — an app-scoped KMS for pre-signature deal work, where each deal is a tracked entity with notes, decisions, and signals.
• A second-brain KMS — bouncer/promoter as an app-scoped KMS for personal-brain users, filtering raw input before it enters the store.
• An investment research KMS — an app-scoped KMS for building investment theses, where source immutability and provenance are non-negotiable.