Everything Bradford Lab helps you do.

The platform is focused on the operational parts of post-production that create real downstream risk when handled loosely — especially across teams, vendors, and delivery partners.

Pre-delivery QC has never scaled by hiring more humans. A single feature delivery package can contain dozens of video masters, audio stems, caption files, and proxy renditions — each with its own codec profile, bit depth, chroma subsampling, color space metadata, resolution, frame rate, container conformance, and loudness target. Manual QC catches the obvious failures and misses the structural ones: a stereo downmix that drifts 0.4 LUFS over target, a ProRes file flagged as Rec. 709 with the wrong transfer characteristics, a caption file whose final cue overruns the program by two frames.

Bradford Lab runs automated technical QC across every file that enters the platform. Codec, bit depth, and chroma subsampling are probed and compared against the delivery spec on file. Loudness is measured to EBU R128 (integrated, short-term, and momentary), ATSC A/85 (CALM Act), and platform targets including Netflix (-27 LUFS dialogue-gated), Apple TV+ (-24 LUFS dialogue-gated), and standard broadcast. Resolution, frame rate, color space metadata, and container conformance are validated against ProRes (Proxy through 4444 XQ), DNxHD, DNxHR, H.264, H.265/HEVC, AV1, JPEG2000, XDCAM, AVC-Intra, MPEG-2, and uncompressed profiles.

What runs, and when, is governed rather than hard-coded — because a single facility rarely has a single standard. Three layers separate concerns that most tools collapse together. Standards profiles define what a delivery target requires.QC profiles define which checks run and at what severity.Policy profiles define what has to be true before something can ship. Those profiles resolve through a scope hierarchy: platform-level defaults apply everywhere, and an organization's administrators define their own profiles that override the defaults for that organization, narrowing further for a specific client or project. A facility can run several delivery specifications in parallel without rebuilding QC logic for each one, and update a spec in one place without touching the rules that consume it. Checks are dispatched by trigger policies attached to a QC profile, so QC fires on the events an organization chooses — such as a new version landing on an asset. DCPs are the case where validation always runs automatically: structural and deep validation execute at import, before the asset record is created. Automatic triggering across the remaining check types is rolling out through the beta; any profile can be run on demand in the meantime.

A Digital Cinema Package is the theatrical delivery format: a directory of JPEG2000 MXF reels, WAV MXF audio reels, optional subtitle and closed caption tracks, and a cluster of XML files (CPL, PKL, ASSETMAP, VOLINDEX) that describe how the parts fit together. DCPs break in characteristic ways. Multi-reel compositions desynchronize when reel dimensions disagree. Encrypted packages fail to play because a KDM doesn't match the certificate of the target server. SMPTE 428-7 packages get authored with Interop DCSubtitle XML, or the reverse. ISDCF naming gets the audio descriptor or aspect ratio in the wrong slot. Subtitles defined by entry-point plus duration overrun a reel boundary and the projector throws an error five minutes before showtime.

Bradford Lab validates DCPs structurally on ingest. CPL, PKL, and ASSETMAP integrity is checked. Reel boundaries, encryption state, and KDM expectations are surfaced. ISDCF naming is parsed and the encoded fields (content type, aspect ratio, audio configuration, resolution, frame rate) are validated against the package contents. Inline validation runs through both clairmeta and easyDCP, so the same package gets checked against two independent reference implementations rather than one. In-browser playback supports inspection without spinning up a DCP-aware desktop player. On the authoring side, Bradford Lab supports DCP creation including Version File (VF) authoring from an imported Original Version (OV) — caption emission is standard-aware, producing either Interop DCSubtitle or SMPTE 428-7 timed text to match the parent package.

Deliverables management is the operational discipline of tracking every version of every asset against every distributor's spec, and being able to answer — at any moment — what has been delivered, what is approved, what is pending, and what is at risk. The failure modes are familiar: a vendor delivers a 5.1 stem when the spec called for 7.1, a caption file ships in WebVTT to a partner who only accepts TTML/IMSC, a final master is replaced by a revision but the older version stays attached to the delivery record. None of these are technical problems individually; together they are the bulk of the operational overhead in finishing.

Bradford Lab tracks specs as first-class objects. Every deliverable is bound to a spec — video codec and profile, audio configuration, caption format, container, naming convention, and any platform-specific requirements — carrying the distributor, platform, territory, format, color space, HDR format, and loudness target the delivery has to satisfy. Caption delivery spans SubRip (SRT), WebVTT, SCC for CEA-608, MCC for CEA-708, Netflix TTML, Amazon TTML, IMSC 1.1 for Disney+ and Hulu, iTunes ITT, SMPTE-TT per SMPTE 428-7, and Interop DCSubtitle. Audio coverage includes PCM WAV, Broadcast WAV with embedded timecode, multichannel stems (stereo, 5.1, 7.1), AAC, and Dolby Digital. Editorial interchange covers CMX 3600 EDL, FCPXML, and OpenTimelineIO (OTIO), with turnover packages generated from sequences in the platform. Every delivery ties back to a status state, so "what shipped" and "what's pending" are never separate spreadsheets.

Notes get lost in email. Approvals get verbal-only on calls. A producer signs off on v7 in Slack while the colorist is already working on v9 because someone sent v8 to the director directly. Review and approval is not a creative problem — it is a state problem. The state of a cut, a grade, a sound mix, or a delivery master is the compound result of every note left on every version, every approval given by every decision-maker, and every outstanding fix still on the list. When that state is scattered, finishing slows down and mistakes ship.

Bradford Lab keeps review state inside the same system that holds the assets, the specs, and the delivery records. Notes are timecoded and frame-accurate. Approvals are recorded against specific versions, not against "the cut" in the abstract. The difference between Bradford Lab and a dedicated review tool like Frame.io is one of scope, not competition: Frame.io is the review-and-approval layer where directors, producers, and creative leads leave notes on cuts; Bradford Lab is the operational layer that tracks what those notes mean for delivery state, version control, and spec adherence. The two integrate. Frame.io review activity flows into Bradford Lab's version history; Bradford Lab can route assets to Frame.io for review and pull approval status back into the delivery record. The result is one chain of custody from creative note to final delivery.

"Agent" is an overloaded word. In Bradford Lab it means something specific and bounded: a software process that runs a defined check, compares a result to a known specification, flags an exception, or advances a state — and stops there. Agents don't approve deliveries. Agents don't sign off on creative. Agents don't decide whether a borderline loudness measurement is acceptable for a particular distributor. Humans do that. Agents do the work that doesn't need a human in the loop: probing a file, running an EBU R128 measurement, comparing a codec profile to a spec, checking a CPL against a PKL, generating a proxy rendition, packaging a deliverable.

The architecture underneath this is Temporal — durable workflows that survive node restarts, network partitions, and long-running jobs that take hours to complete. Render and processing work is distributed across electron-based render nodes that run on macOS (signed and notarized) and can be self-hosted on facility hardware. Human checkpoints are explicit: every approval gate, every spec exception, every decision that is not trivially mechanical is presented to a human operator with the relevant context. Agents work asynchronously and surface their results when they're ready, which matters for distributed teams operating across time zones — the overnight QC pass is done by morning, the proxy renditions are ready when the editor opens the project, and the delivery package is built and waiting for human review by the time the post supervisor sits down.

General-purpose large language models are good at general-purpose questions. They are less good at post-production questions, where the right answer often depends on the difference between Rec. 709 and Rec. 2020, between EBU R128 integrated loudness and short-term loudness, between SMPTE 428-7 and Interop, between a ProRes 4444 XQ container that carries alpha correctly and one that doesn't. The cost of a generic answer in post is a re-delivery, a rejected QC report, or a missed slot on a broadcast schedule.

Bradford Lab includes a domain-specific assistant built around post-production knowledge: codec profiles and their characteristics, container limitations, loudness specifications across distributors, caption format requirements, DCP authoring rules, ISDCF naming, color space and transfer characteristic combinations, and the integration details of the tools Bradford Lab connects to. Digital Cinema Package standards questions are answered against a maintained standards registry rather than from general recall. The assistant is aware of project context — it can answer "what's blocking delivery on this title" by reading the project's actual state, not by guessing, and it can troubleshoot a specific QC failure by looking at the actual measurement rather than a hypothetical one. Worth being precise about the division of labor: the durable workflows described above are what perform operations — transcodes, measurements, validation, packaging. The assistant is how you understand and direct that work, not a second path for executing it.

A virtual post house is only useful if it connects to the tools post-production already runs on. Bradford Lab integrates with Frame.io for review and approval and for asset ingest, and the integration runs in both directions: accounts and project trees import, media browses and pulls in as a source, and comments synchronize both ways — frame-accurate annotations, threaded replies, and owner attribution — with webhook and custom action support so activity in Frame.io reaches into Bradford Lab workflows. Dropbox and Google Drive are supported as storage and intake sources, and file requests let clients and vendors deliver material straight into a project, which matters for the practical reality that footage, deliverables, and reference materials don't always start their life inside a finishing facility.

The deepest integration is with DaVinci Resolve, and it runs through Bradford Post Assistant — the desktop application that sits on the workstation where Resolve is installed. Running locally is the point: it connects to the application directly rather than through an export-and-upload round trip, using the Bradford Toolkit MCP (Model Context Protocol) server to expose Resolve operations to the platform and to agents working within it. This goes well beyond import/export. The toolkit automates project operations (creation, save, archive), timeline manipulation (importing media, building sequences from EDL or AAF, conforming against OpenTimelineIO), color grading via DRX presets (Resolve's native grade-export format, applied programmatically against shots that match defined criteria), and render queue management (adding jobs, monitoring progress, retrieving outputs). Color grading in particular follows a deliberate workflow — grab a still as undo, export a "before" reference, generate a DRX from the look library, apply, export an "after" reference, and label the still — so automated grade application stays auditable and reversible. The result is that Resolve becomes a programmable component of the Bradford Lab pipeline rather than a standalone destination that requires a colorist to manually perform every operation.

Pre-release content has a value that drops to roughly zero the moment it leaks. Studios, distributors, and rights-holders enforce this with contractual security requirements that govern who can access an asset, from what location, on what device, and with what audit trail. A finishing platform that doesn't take these requirements seriously is not usable for studio-level work, full stop.

Bradford Lab is built with organization-based access control as a foundational concept rather than a bolt-on. Every asset, project, and delivery record belongs to an organization; access is scoped by organization membership and role. Storage is encrypted. Share links to pre-release assets can be scoped to specific recipients, restricted, expired, and revoked, and access to shared material is recorded. Governance actions carry provenance: policy profiles are versioned, standards requirements carry source citations back to the specification they came from, and changes to the rules that gate delivery are recorded and reviewable. Broader per-file access auditing is being expanded through the beta. The platform's distributed architecture (render nodes that can be self-hosted on facility hardware) is relevant here too: organizations that need media to stay on-premises for the most sensitive titles can run processing locally while still using the platform for orchestration and state tracking, rather than choosing between cloud convenience and on-prem control.

Bradford Lab understands the kinds of details that actually break deliveries: