> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminus.app/llms.txt
> Use this file to discover all available pages before exploring further.
# The Terminus Hub data model
> A one-page map of how governance models, taxonomies, fields, picklists, submissions, and records fit together.
A **governance model** holds your **taxonomies** (groupings of fields) and **picklists**. People submit data against a taxonomy; an approved submission becomes a **record**. Every record has a stable identifier and can carry a short URL and QR code.
Terminus Hub has a small set of concepts that fit together in one hierarchy. Once you know the pieces and how they nest, every screen in the product maps back to one of them. This page is the map. Each concept gets a short explainer and a link to its reference page for the full detail.
## The hierarchy at a glance
The top-level container for everything else.
Ordered groupings of fields. The form people fill in.
Single named pieces of data, user-entered or computed.
Named option lists that power dropdown fields.
Draft batches of entries, before approval.
Approved, validated entries. The unit of data.
## How it nests
Read this top to bottom. Each level contains the one below it:
* A **governance model** is the top-level container. It owns your fields, your picklists, and your taxonomies.
* **Fields** are the reusable pieces of data: `campaign_name`, `goal`, `launch_date`, `tagged_url`. A field is defined once in the model and can be reused by many taxonomies.
* **Picklists** are the option lists that dropdown fields choose from: a `Goals` picklist with `awareness`, `consideration`, `conversion`.
* **Taxonomies** are ordered groupings of fields. Each taxonomy is the actual form a person fills in for one kind of record (for example: `Email Campaigns`, `Social Campaigns`, `Ad Campaigns`).
* People enter data by making a **submission** against a taxonomy, inside a **workspace**. A submission is a draft batch of one or more rows.
* When a submission is approved, each row becomes a **record**: the final, validated entry.
* Every record has a **stable identifier** (a `trm0…` Terminus ID) that never changes.
* A record can also carry a **short URL** and a **QR code**, generated from its other fields.
```text theme={null}
Governance model
├── Fields (campaign_name, goal, launch_date, short_url, ...)
├── Picklists (Goals, Countries, Regions, ...)
└── Taxonomies (Email Campaigns, Social Campaigns, Ad Campaigns)
│ references fields, in order
▼
Submission (draft batch of rows, in a workspace)
│ approval
▼
Record (validated entry; Terminus ID + short URL + QR code)
```
Most companies have one governance model for the whole business. Some keep two or three (for example: Marketing, Finance, HR) when the domains are genuinely separate and share no definitions.
## Governance model
A **governance model** is the container that holds your taxonomies, fields, and picklists together. Everything inside it shares one namespace: two fields in the same model cannot have the same name, and the same goes for picklists and taxonomies. That shared namespace is what lets you reuse one `campaign_name` field across several campaign taxonomies and know it means the same thing everywhere.
You edit a governance model live, then **publish** it as a revision before anyone can submit against it. A model with no published revision cannot accept data entry. See [Publish a revision](/guides/publish-revision).
Reference: [Governance models](/reference/governance-models).
## Taxonomies and fields
A **taxonomy** is an ordered grouping of fields: the concrete form shape someone fills in for one kind of record. A taxonomy references fields; it does not own them. That is the key relationship: the field lives in the governance model, and each taxonomy points at the fields it needs, in the order it wants them.
Because references are shared, you can reuse a field across taxonomies and still tune its behavior per taxonomy. A **field reference override** can make `goal` required on `Ad Campaigns` but optional on `Email Campaigns`, or narrow which dropdown options show in one taxonomy, without touching the underlying field. See [Field reference overrides](/reference/field-reference-overrides).
A **field** is a single named piece of data with a type. Fields fall into two families:
* **User-entered fields** (Text, Date, URL, Dropdown) where a person types or selects the value.
* **Computed fields** (Concatenation, Tagged URL, Short URL, QR Code, Auto Number, Random, Constant, Terminus ID) where the value is derived and fills itself in. Computed fields never accept direct input and recompute when their sources change.
References: [Taxonomies](/reference/taxonomies), [Fields](/reference/fields).
## Picklists
A **picklist** is a named list of options that powers a dropdown field. You define the list once and point one or more dropdown fields at it. Picklists come in three kinds:
* **Static**: you maintain the list by hand.
* **Hierarchical**: options have a parent and child relationship, so dropdowns cascade. Pick a country, and the region dropdown narrows to that country's regions.
* **Automated**: options are drawn from the approved records of another taxonomy. This is the feedback loop: data you have already approved becomes the options for future submissions, so the model grows with your data instead of being frozen the day it is defined.
Static picklists can allow users to add new options during data entry (`allow_additions`), so a submitter can propose a value instead of waiting on an admin.
Reference: [Picklists](/reference/picklists).
## Submissions and records
A **submission** is a draft batch of entries someone has filled in but not yet approved, made against one taxonomy inside one workspace. A submission can hold one row or many. While it is a draft, the [submission pipeline](/concepts/submission-pipeline) runs on every save, so computed fields fill in and errors surface immediately.
A **record** is what you get after a submission is approved: the final, validated entry. Records are the unit of data in Terminus Hub. They are what automated picklists draw from, what analytics tracks, and what integrations read.
Each record has:
* a **Terminus ID**, a unique, immutable identifier of the form `trm0` followed by a short alphanumeric string (for example `trm0abc123def456ghi7`). It is how a campaign row is referenced everywhere, and it never changes.
* an optional **short URL**, materialized when the record is approved if its taxonomy has a Short URL field.
* an optional **QR code**, generated from another field on the record.
Records are read-only. To change or remove a record, you create a new submission seeded from it and approve that. See [Submissions](/reference/submissions) and [Records](/reference/records).
## Definitions versus operations
A useful way to keep the concepts straight: split them into **definitions** (what the governance model looks like) and **operations** (what people do inside it). Revisions are the bridge, the moment a set of definitions becomes the contract that operations run against.
| Concept | Kind | Who manages it | How often it changes |
| ---------------- | ---------- | ------------------------------------------ | ------------------------- |
| Governance model | Definition | Admin | Rarely |
| Fields | Definition | Admin | When the business changes |
| Picklists | Definition | Admin (automated ones update from records) | Occasionally |
| Taxonomies | Definition | Admin | When the business changes |
| Submissions | Operation | People entering data | Constantly |
| Records | Operation | People entering data | Constantly |
When you troubleshoot, ask first whether it is a definitions problem (a field is misconfigured, a picklist is missing an option, a change is not published yet) or an operations problem (a submission failed validation, a computed field did not update). The fix lives in a different place depending on the answer.
## Related
* [The submission pipeline](/concepts/submission-pipeline): how a submission becomes a record.
* [Fill modes](/concepts/form-vs-grid-mode): the fill modes for entering data.
* [Publish a revision](/guides/publish-revision): freeze your definitions so a workspace can collect data.
* [Tutorial: Campaign URL Builder](/tutorial): a worked example that builds each of these concepts end to end.
* [Fields reference](/reference/fields): full settings for every field type above.