Key Concepts

🚧

This page is partially complete. Core concepts for AI, content definitions, assets, and the data model are covered below. Security groups and additional topics are coming soon.

AI and Machine Learning

Nomad Media uses AI to enhance the metadata of assets stored within the customer's AWS account. The platform takes a secure, customer-controlled approach: all generated metadata stays within the customer's own AWS environment.

Data Privacy Model

1. Media storage — All media is stored in the customer's S3 bucket. When media needs to be analyzed, a read-only, time-limited link (typically less than 24 hours) is provided to the AI model.
2. Metadata storage — All AI-generated metadata is stored in the customer's S3 account as supporting JSON files accompanying each asset. Files are linked to the asset through a registry in the customer's DynamoDB tables.
3. Face recognition — If the customer enables face recognition, any customer-supplied naming information (the mapping of AI-generated face IDs to person names) is stored only in the customer's DynamoDB tables and never shared outside the customer's AWS account.
4. No training use — Nomad Media does not use customer data for AI training. If a customer creates and trains their own custom models, those models and results remain the exclusive property of the customer.

Supported AI Models

All AI models and analysis are optional and can be individually enabled or disabled.

Content Definitions

A content definition is a schema — similar to a database table — that defines the structure of a type of content in Nomad Media. Each content definition has a name, a unique ID, and a set of typed fields. Examples include "Committee," "Meeting," "Session," or "Chamber."

Content definitions are created and managed in the Admin UI under Site Manager. They do not require engineering involvement to set up or modify, but changes to fields — especially changing a field's type after data has been entered — can have data integrity implications. Coordinate schema changes with Nomad before making them in a live environment.

Field Types

Each field in a content definition has a type that determines how data is stored and displayed:

Important: Changing a field's type after data has been entered will cause data integrity problems. Set field types correctly before ingesting data.

Display Field

Each content definition has a designated display field — the field that appears as the label when that content definition is referenced in a dropdown from another record. For example, if "Committee" is referenced from a "Meeting" record, the committee's display field value is what appears in the meeting's dropdown selector.

Concatenated Fields

Nomad Media does not automatically concatenate multiple fields into a single display value. If a combined value is needed (e.g., "Committee Code + Committee Title"), it must be stored as a separate, manually populated field.

For the full list of reserved field and content definition names, see Content Definition Naming Restrictions.

Assets

An asset is a file stored in object storage (AWS S3 or Azure Blob Storage). On ingest, Nomad Media automatically extracts and stores technical metadata for each asset — including format, dimensions, duration, frame rate, and codec information.

Assets and content definition records are linked through relationship fields (the Asset Selector field type). A record in a content definition can hold a reference to one or more assets; the asset and all its metadata are then retrievable via the API alongside the record's other fields.

The folder structure of your object storage is fully customizable. Media placed under a content-public folder is accessible publicly; other areas are private.

UUIDs as Universal Identifiers

Every record and every asset in Nomad Media is assigned a UUID at creation time. This UUID:

• Never changes — renaming a file, moving it to a different folder, or renaming a content definition record does not affect its UUID
• Is the basis for all relationships — when one record references another (via a Related Content Definition field), the reference is stored as the UUID of the related record, not as a string name
• Is stable across migrations — if an asset moves from S3 to Azure Blob Storage, the UUID remains the same and all relationships continue to resolve correctly

External ID Strategy

When integrating with an external system (e.g., a database or third-party platform that has its own IDs), the recommended approach is:

1. Let Nomad Media assign its own UUID for each record
2. Store the external system's ID in a dedicated External ID field on the content definition
3. Use the External ID field as the lookup key during synchronization

Do not attempt to use the external system's ID as Nomad Media's primary key. External ID schemas can change, and Nomad's UUID is the authoritative identifier within the platform.

Data Model

Nomad Media content is organized as a hierarchy of content definition records linked by UUID references, with assets attached at appropriate levels. A typical example for a legislative archive:

Chamber
  └── Committee
        └── Meeting
              ├── VOD Asset  (if recorded and archived)
              └── Live Channel  (if currently broadcasting)

Each level is its own content definition. The Meeting record holds either a reference to a VOD asset (populated after the meeting concludes) or a reference to a Live Channel (populated while the meeting is in progress) — determined by which pointer field is set.

This hierarchy is traversable via the API: retrieving a Meeting record returns the UUIDs of its parent Committee and any attached assets, which can then be fetched individually.

Admin API vs. Portal API

Nomad Media exposes two API surfaces:

For all server-to-server integrations, always use the Admin API. The Portal API is designed for end-user client applications, not for backend data synchronization or programmatic content management.

See API Setup for base URLs and environment configuration.