Foundational And Internal Dotabases

Every workspace starts with four canonical foundational Dotabases plus internal Dotabases that are always seeded for specific platform capabilities. All of them use the same rows, schemas, edges, and views as any Dotabase you create; the distinction describes their platform role, not a different runtime.

The Foundational Four

• Memory Bank — episodic memories that decay, reinforce, and graduate into DOTs. Memories carry spaced-repetition state, so what you reinforce sticks and what you ignore fades, and durable ones graduate into permanent knowledge. Its rows are prefixed MEM, and it is the one foundation placed in the Intelligence Space.
• Conversations — live conversations with your coding agents, the chat persistence layer. Each conversation is a row, so your chat history is queryable knowledge like everything else. Rows are prefixed CONVO.
• Artifacts — durable AI-produced work products: plans, the trail an agent workflow leaves behind, and documents or code saved out of Chat. Rows are prefixed ART.
• HUMAN.md — your HUMAN.md documents: who you are, in the context of the work, for the AI you work with. It is the human-owned counterpart to an agent's instructions, and the one that gets read into a conversation. Rows are prefixed HMD.

Conversations, Artifacts, and HUMAN.md all sit in the Context Space. That placement is a filing decision, not a classification one: none of the four runs the per-row DIIICE classifier, because their rows already have a settled meaning. Being in a DIIICE Space and being classified into DIIICE are separate switches.

Always-seeded Internal Dotabases

• Context Cabinet — every file and document, raw and searchable, and the default home for context that arrives without a more specific place to go. It is the one seeded Dotabase that does classify each incoming row into DIIICE, because what lands there is unrouted by definition.
• Glossary — your organization's proprietary vocabulary: the terms and definitions your business runs on — frameworks, products, processes, and acronyms — each with a markdown definition, aliases, and a category, so a term resolves the same way across every Dotabase.

Several more are seeded for capabilities you may reach later. Projects, Tasks, Guardrails, and Tool Recipes back the work-tracking and policy surfaces; Automations holds scheduled Chat Automations and locally executed Routines; Git Commits, Pull Requests, Git Repositories, Repo Files, and Code Symbols are where an ingested repository lands as a code knowledge graph; and Questions & Answers is derived from your imported coding-agent conversations by a binding that is wired and enabled at provisioning time, so it fills on the first import without any setup of your own.

Internal Dotabases are not optional. Context Cabinet and Glossary are always present because they back stable platform jobs, but they are not part of the canonical foundational set. Seeding is idempotent and keyed by slug: a workspace provisioned twice gets one of each, never a duplicate estate.

Beyond The Seeded Set

You create your own Dotabases on top of the seeded estate; the seeding exists so the platform's core capabilities have somewhere to write on day one, not to bound what the workspace holds. A seeded Dotabase is also open to you on every axis — you can add properties to its schema, save new views over it, draw edges from its rows into a Dotabase you built yourself, and read it from the CLI or an agent exactly as you would your own.