---
title: Data model
description: How Foundation structures and stores your shared context, and the rules that keep you in control of it.
---

Foundation breaks your unstructured context down into *entities*, whether that is a definition, a document, a number you track or a list of meetings. Each one has a name, a short
description written for the agents that will read it, and a strict set of
properties that dictate who can read it, who can write to it, and how. An
entity is the template for its content rather than the content itself: a
text's versions, a metric's observations and a list's entries all live under
one entity, so two hundred FAQ answers are two hundred entries in one list.

## Five types

| Type       | Holds                                             | A write                                                           | Served as                                              |
| ---------- | ------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------ |
| **text**   | One body, revised as a whole                      | Replaces the body; the previous version is kept                   | Data                                                   |
| **term**   | One of the team's words, defined                  | As a text                                                         | Data; the description is the definition                |
| **skill**  | Something agents act on: a process, a house style | As a text                                                         | Instructions, while a person wrote the current version |
| **metric** | One figure over time                              | Appends one dated observation, verbatim                           | The latest value, formatted by the server              |
| **list**   | A collection of like things                       | Appends one named entry; a living entry can be rewritten in place | An index of entries, then one in full                  |

The type is chosen when the entity is created and never changes.
A listing of a workspace's terms is its glossary. Skills are served by their own tool and
left out of the shortlist, which says how many it left out.

## The description
One or two sentences, written to an agent: when to retrieve this, when to
write to it, what it holds. It is the only thing most agents read before
deciding whether to fetch an entity, so it carries the weight a page title
would elsewhere.

## Tags
Tags are the topics the team organizes by, coined by admins. An unfiltered
shortlist opens with the tag index, and an agent answers a topical question by
listing one tag rather than reading everything. Two labels for one topic
split the branch, and an admin can retag an entity that landed under the wrong one.

## The two guides
An **authoring guide** says how content for this entity is composed: what
one write contains, what it leaves out, how an entry is named. Agents read
it before writing. A **retrieval guide** says where content is fetched from
and what one unit of the answer is; it is served only to
couriers. The entity's owner writes both.

## Update expectation
An entity can declare how often the team expects new content: daily,
weekly, monthly or quarterly. Reads show the frequency beside the date of
the latest content. That is a fact for the reader, not a deadline or a
verdict, and a [routine](/concepts/routines) keeps it true without a person.

## Provenance and the fence
Every write is stamped with who made it: a person, an agent acting for a
person or a courier. Content is served wrapped as data unless the entity is
a skill and a person wrote the current version. Content a courier wrote is
always wrapped, whatever the entity.