TAMS Version 8.2 Released

Published: Aug 12, 2026 by

The TAMS (Time-Addressable Media Store) community is pleased to announce the release of API Specification version 8.2. This is a substantial feature release with major additions that expand what TAMS can do and how implementations can be deployed at scale. From first-class support for fragmented MP4, through improved content discovery, to simplifying Flow management through Profiles, version 8.2 is built directly on community feedback about what would make implementing TAMS simpler and more capable.

Fragmented MP4 and Initialisation Segment Support

One of the most requested features lands in 8.2: native support for media formats that use initialisation segments, including fragmented MP4 (fMP4), CMAF, and MPEG-DASH.

TAMS has historically modelled media as independently-decodable objects — a natural fit for formats like MXF or TS-wrapped essence. But many modern delivery and production workflows use container formats where a decoder must first read an initialisation segment before it can process media segments. Until now, these formats didn’t fit neatly into the TAMS data model.

The new approach (detailed in ADR0045) models init segments as object-level properties. Each Media Object can reference an init Object, which is uploaded, stored, and has URLs generated exactly like any other object in TAMS. This means:

• Multiple init segments per Flow are supported — essential for multi-period manifests and C2PA-signed content
• Edit-by-reference works unchanged — init segments follow the media objects they’re associated with
• Existing implementations are unaffected — the init_segments boolean on the Flow signals when this feature is in use
• Existing object patterns are reused — no new storage mechanisms required

AppNote 0024 provides detailed implementation guidance, including notes on reference counting for garbage collection, the relationship between init and media objects, and terminology alignment with CMAF.

Flow Profiles

Creating Flows with the correct technical metadata can be repetitive and error-prone, particularly in environments with strict house formats. Version 8.2 introduces the Profile resource — a reusable template of technical parameters that can be referenced when creating a Flow.

Profiles serve two purposes:

1. Simplified creation — rather than specifying codec, resolution, bitrate, and other parameters individually, reference a Profile and the metadata is populated automatically
2. Discovery and matching — Flow listings can be filtered by Profile, making it straightforward to find all content in a given format, or to match compatible Flows in edit-by-reference workflows

This is documented in AppNote 0020.

Better Content Discovery and Ordering

Building a content browser on TAMS requires two things: finding the right content, and presenting it in a predictable order. Previously, both of these had to be handled client-side — clients fetched all Sources, manually discarded those that were collected by another Source to find the “top-level” content, and then applied their own sorting logic. This broke pagination, scaled poorly, and pushed complexity into every UI implementation.

Version 8.2 solves both problems at the API level.

Filtering by collected_by

The new collected_by_ids query parameter on Source and Flow listings (ADR0049, PR #183) moves content-tree filtering into the API:

• ?source_collected_by_ids= (empty value) — returns only uncollected Sources, i.e. the top of the content tree
• ?source_collected_by_ids=<uuid> — returns Sources collected by that specific Source
• ?source_collected_by_ids=<uuid1>,<uuid2> — returns Sources collected by any of the listed Sources

Because the filtering happens server-side, pagination now works correctly — requesting 25 results returns 25 matching items, not 25 items of which an unknown number will be discarded.

Defined ordering of resource listings

Alongside filtering, this release brings explicit and client-controllable sorting to resource listings across two changes:

• Segments (PR #223) — The default ordering of the segments listing (by timerange) has always been implied by the specification text. This is now explicit, and the existing reverse_order parameter is formally documented against it.
• Sources, Flows, and other resources (PR #224) — Defines the default sorting of all other resource listings and provides a means for clients to specify the sort order where appropriate.

Together, these changes mean a content browser can request “the first 25 uncollected Sources, sorted by creation date” in a single paginated call — no client-side filtering, no ambiguous ordering, and predictable page boundaries.

Rethinking Collection Roles: Editorial Purpose as a First-Class Concept

The role field in multi-essence collections has been a source of inconsistency across implementations. Some used it for editorial purpose (“programme”, “commentary”), others for media type (“video”, “audio”), and many for an ad-hoc combination of both. This made it difficult to build interoperable clients that could reliably identify what a piece of content is and what it’s for.

Version 8.2 addresses this with a two-part change:

Role becomes optional, collections become ordered

ADR0056 concludes that most of what role was being used for are properties of the Source or Flow itself, not its position in a collection. The field is now optional — a human-readable label only — and collections are ordered lists where position conveys priority and default selection.

Editorial purpose moves to a tag on the Source/Flow

ADR0053 introduces the editorial_purpose tag, stored directly on the Source or Flow. This means editorial purpose is captured regardless of whether the content is part of a collection, and can be queried independently.

AppNote 0025 defines recommended values, drawing on SMPTE ST 377-41 for audio terminology:

Architectures for Media Transformation

As TAMS grows beyond single-format ingest, the question of “how do I transcode content?” needs a clear answer. AppNote 0022 provides architectural guidance — not normative specification — describing potential patterns for media transformation:

Tag-based transcode triggering

Set an experimental transcode_trigger tag on a Flow, and a watching service can automatically trigger a transformation when new content arrives. The AppNote describes error handling, status signalling, and how this integrates with webhooks.

Transform on Request (Just-in-Time)

A more experimental pattern where Virtual Objects represent content that doesn’t physically exist until it’s requested. When a client requests a get_url for a Virtual Object, the transformation is triggered on-demand. This enables just-in-time transcoding without pre-populating every possible format.

Flow Status Elevated to Core Metadata

The flow_status tag has been widely adopted by implementations to signal the lifecycle state of a Flow — whether it is actively being written to, complete, or in some other state. Until now it has been an experimental tag, meaning its behaviour was not guaranteed by the specification.

Version 8.2 promotes this to a first-class status attribute on the Flow resource itself. This reflects its importance in real-world deployments where clients and automation need a reliable, standardised way to determine whether a Flow is still receiving content or is ready for downstream processing. Moving it into the core specification means implementations can depend on consistent behaviour across TAMS services.

Fine-Grained Authorisation on Storage Backends

As TAMS deployments grow more complex — multiple teams, multiple storage tiers, regulatory boundaries — the ability to control access at the storage backend level becomes essential.

ADR0055 adds read-only tags to Storage Backends, extending the authorisation proxy patterns described in AppNote 0016. Tags are set at deploy time and can be used to:

• Allocate costs by team or department
• Designate read-only archive storage
• Enforce geographic or regulatory data residency
• Restrict access to sensitive content storage

The approach follows existing patterns — if you’ve already implemented fine-grained auth on Sources and Flows using AppNote 0016, the same mechanisms now work for Storage Backends.

Pre-signed URL Control

Different deployment architectures need different approaches to authenticating object storage access. Some environments use pre-signed URLs for direct client-to-storage uploads; others use a reverse proxy that attaches credentials.

Version 8.2 (ADR0054) makes this explicit:

• Clients can request pre-signed or non-pre-signed put_urls via a presigned parameter
• Responses signal whether returned URLs are pre-signed
• Additional documentation clarifies the authentication methods available for both put_urls and get_urls

This change is fully backwards-compatible — existing implementations that don’t specify a preference continue to work as before.

Other Improvements

• include_object_timerange on webhooks — Aligns webhook behaviour with the HTTP API and fixes an inconsistency where object_timerange was sometimes omitted even when requested

Bug Fixes

• Missing return codes have been added to the webhooks specification.
• Tag endpoints that should permit lists now correctly do so.
• The generation field is now described more clearly.
• Example code in the README has been corrected to match the adjacent diagram.

Implementation Notes

⚠️ This release significantly re-factors the schemas in the TAMS specification. Implementations relying on schema structures for automatic code generation should carefully review the changes before upgrading.

Key actions for implementers:

1. Review schema changes if your build pipeline auto-generates code from the OpenAPI spec
2. Adopt Profiles if you have house formats or want simpler Flow creation
3. Implement collected_by_ids filtering for improved content discovery UIs
4. Plan for init segment support if you’re targeting fMP4/CMAF workflows
5. Review editorial purpose tags for multi-essence content labelling
6. Consider Storage Backend tags for fine-grained auth in multi-tenant deployments

Get Involved

TAMS is an open specification developed collaboratively. The full 8.2 release is available on GitHub, including all ADRs, Application Notes, and the updated OpenAPI specification. Contributions, feedback, and implementations are welcome.