> ## Documentation Index > Fetch the complete documentation index at: https://docs.alkera.ai/llms.txt > Use this file to discover all available pages before exploring further. # Knowledge Base > Your project's memory: what the data means, and what your team already decided about it. Schemas tell you what columns exist. Your team has undocumented knowledge that goes beyond schemas and the knowledge base holds that. The [agent](/foundations/agent-and-tools) reads it before it plans, and writes to it as it learns. It is scoped to your project. ## Two lanes All items in the knowledge base are team knowledge or auto-generated catalog knowledge. **Team knowledge** is what people and agents recorded: decisions, conventions, and the gotchas that never appear in a schema. **Catalog** is generated: schema cards for your relations, reference queries, and docs pulled from your connected tools. ## Subject paths Every entry is filed under a **subject path**: a lowercase, `/`-delimited path that works like a folder. Together the paths form a tree, and that tree is how knowledge stays findable as it grows. ``` jaffle_shop/ main/ customers facts about the table customers/customer_id facts about one column orders connections/ snowflake/prod auth, endpoints, quirks conventions/ sql team standards dbt glossary/ net_revenue what a metric means ``` Subjects follow conventions for their paths. | Subject | Path | | --------------------------- | ------------------------------------- | | A table, view, or dbt model | `//` | | A single column | `///` | | A pipeline task | `//` | | A dashboard or report | `//` | | A connection itself | `connections//` | | Team standards | `conventions/` | | A metric definition | `glossary/` | Facts about an asset live under that asset, together. Its lineage, its gotchas, its quality, and who owns it all sit at the same path. ## Provenance and freshness An entry is only as good as where it came from, so each one carries that with it. * **Trust.** Whether the entry is verified, and by what. A human wrote it, the agent verified it against the data, the agent re-derived it, or the agent simply asserted it. * **Age.** How long ago it was written. * **Stale sources.** Whether a source file changed after the entry was written, which means the entry may no longer hold. The agent weighs these rather than treating every entry as equally true. A human-verified convention outranks something it asserted for itself last week. ## Visibility Every entry is private to you or shared with your team. Private entries never leave your machine. Sharing an entry promotes it to your team or your organization. Before it leaves, Alkera scans it for secrets and personal data. A hit blocks the share outright rather than quietly stripping it, and the entry stays private. Writing to the knowledge base is a write action. In a read-only session the agent can search and read entries, but it cannot record new ones. ## Team sync Sync is off by default. It turns on only when **both** of these are true, so no knowledge leaves a machine by accident. In [Teams](/foundations/teams), an admin turns on **Knowledge sync** for the organization. Each project carries its own switch. By default a project follows whatever the organization is set to, and one can opt out explicitly. If either switch is off, nothing syncs. Only shared team knowledge syncs, so private entries and generated catalog entries do not sync. ### Working with a teammate's entries A shared entry arrives in your knowledge base attributed to whoever wrote it. It belongs to them, so it is read-only to you. | You want to | What to do | | ---------------------- | ---------------------------------------------------------------- | | Correct it | Write your own entry with the correction. Theirs stays as it is. | | Stop seeing it | Hide it. | | Remove it for everyone | Ask the author. | ## Related How the agent reads and writes project memory. The structural counterpart: how your data is produced.