Data model
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 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.