Skip to main content
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

Governance models

The top-level container for everything else.

Taxonomies

Ordered groupings of fields. The form people fill in.

Fields

Single named pieces of data, user-entered or computed.

Picklists

Named option lists that power dropdown fields.

Submissions

Draft batches of entries, before approval.

Records

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.
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. 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. 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, 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.

​
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 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 and 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.
ConceptKindWho manages itHow often it changes
Governance modelDefinitionAdminRarely
FieldsDefinitionAdminWhen the business changes
PicklistsDefinitionAdmin (automated ones update from records)Occasionally
TaxonomiesDefinitionAdminWhen the business changes
SubmissionsOperationPeople entering dataConstantly
RecordsOperationPeople entering dataConstantly
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.