Knowledge base

The schema.

Mindframe's knowledge base is per-install. A fixed four-layer meta-schema is the contract; the entities inside it are assembled for each deployment — core entities, domain packs, and custom — and recorded in that vault's own schema.yaml.

The meta-schema

Four layers.

Every entity belongs to exactly one layer. The four layers never change — they are the fixed part of the schema, the contract every deployment is built against. A layer is a category of entity types, not an entity itself.

Thing what exists persistent entities you track the current state of

Event what happened immutable, dated records of an occurrence

Knowledge what's true declarative reference — rules and terms

Process how you operate the procedures and practices it runs

Core entities

Ten entities every organization has.

Core entities are in every deployment, unchanged. They are the things true of any organization — a software company, a paper mill, and a law firm alike.

Entity	Layer	What it is
person	Thing	A member of the organization.
team	Thing	A group of people with a shared remit.
customer	Thing	Who the organization serves.
partner	Thing	An external organization it works with — supplier, vendor, collaborator.
project	Thing	In-flight work with a goal and an end.
product	Thing	What the organization provides.
decision	Event	A choice made, with its rationale.
incident	Event	Something that went wrong, with cause and resolution.
convention	Knowledge	A rule or standard the organization follows.
glossary	Knowledge	The organization's domain terms.

The Process layer has no core entities — procedures are domain-specific, so they arrive through packs and custom entities.

Domain packs

Packs add the entities your domain needs.

A pack is a named set of entity types for a domain. Setup activates a pack from what it finds when it probes your environment — you don't choose them by hand. A pack may also extend a core entity with extra fields.

Pack	Activated by	Adds
software-ops	GitHub, Sentry, a container runtime	service, repository, integration (Things); runbook, deployment, code-review, release (Processes)
communications	Slack, Teams	channel (Thing)

A software company's vault has service and repository; a paper mill's does not. Neither has entities it has no use for.

Custom entities

Whatever's left, setup proposes.

When an organization has an entity no pack ships — a paper mill's machine, a law firm's matter — setup defines it for that install. A custom entity is new in its name and fields, never in its structure: it must obey the meta-schema, so it plugs into the same machinery as everything else.

Setup first asks whether the entity is genuinely new or just a renamed core entity — a "Squad" is a Team, a "Matter" may be a richer Project. A renamed core entity is an alias, not a new type. Only what's genuinely new becomes a custom entity, defined against the meta-schema with the operator and recorded for that install.

The manifest

schema.yaml — the contract for one vault.

Each deployment assembles its schema — core entities, activated packs, custom entities — and records it in the vault's own schema.yaml. That file, not a central document, is the contract for that vault: the librarian and skills read it; the librarian validates every write against it.

schema_version: 2
packs: [software-ops, communications]
entities:
  person:
    layer: thing
    source: core
    identity: name
    directory: People
    foreign_keys: { team: team, manager: person }
  service:
    layer: thing
    source: pack:software-ops
    identity: name
    directory: Services
    foreign_keys: { team: team, repos: repository }
  mill:
    layer: thing
    source: custom
    identity: name
    directory: Mills
    foreign_keys: { facility: facility }

Because every vault owns its schema, there is no central schema to migrate against — a deployment evolves its own schema.yaml as the organization changes.