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: it shows how the pieces connect. For what each one is, see key concepts.

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

​
The whole picture

Solid arrows are ownership and flow: a governance model owns fields, picklists, and taxonomies; a submission becomes a record. Dotted arrows are the two references that make the model reuse its own parts: dropdown fields draw their options from picklists, and approved records feed back into automated picklists.

​
How the pieces relate

  • A governance model owns its fields, picklists, and taxonomies. Most companies have one for the whole business. Some keep two or three (for example: Marketing, Finance, HR) when the domains are genuinely separate and share no definitions.
  • Taxonomies reference fields; they do not own them. Each taxonomy points at the fields it needs, in the order it wants them.
  • Dropdown fields draw their options from picklists. One picklist can back many dropdown fields.
  • People make a submission against one taxonomy, inside one workspace. Approving it turns each row into a record.
  • Approved records feed automated picklists. That closes the loop in the diagram above.

​
One namespace per governance model

Everything inside a governance model 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.

​
Shared fields, tuned per taxonomy

Because taxonomies reference fields rather than copy them, a published change to a field reaches every taxonomy that uses it. When one taxonomy needs different behavior, a field reference override tunes the field for that taxonomy only: make goal required on Ad Campaigns but optional on Email Campaigns, or narrow which dropdown options show in one taxonomy. See Field reference overrides.

​
Picklists and the feedback loop

Static picklists hold options you maintain by hand, and a static picklist can have a parent so its dropdown cascades. Automated picklists draw their options from another taxonomy’s approved records, so data you have already approved becomes the options for future submissions and the model grows with your data. See picklist structures.
Automated picklists require the Business plan or higher. See Plans and limits.
Picklists are closed lists: submitters pick from the published options, and an admin changes the option set by editing the picklist and publishing. When a field’s values change too fast for that loop, model it as a Text field with Suggest from past entries rather than a dropdown.

​
Revisions connect definitions to data

You edit a governance model live, then publish it as a revision. The submission builder and validation always use the latest published revision, so a model with no published revision cannot accept data entry, and unpublished edits reach no one. When you publish again, submissions that are not yet approved pick up the new revision the next time they are opened or saved. Approval pins the revision: each record keeps the revision it was approved under. See Publish a revision.

​
Records are the unit of data

Records are what automated picklists draw from, what analytics tracks, and what integrations read. They are read-only. To change or remove a record, you approve a new submission seeded from it. See Work with records and the submission pipeline.

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