A virtual post house is a software platform that provides the operational infrastructure of a traditional post-production facility without requiring the people, media, or sessions to be in the same physical building. Where a brick-and-mortar post house owns suites, storage, machine rooms, and a staff that coordinates dailies, QC, finishing, and delivery, a virtual post house provides the same workflow scaffolding as cloud-native software: ingest from camera or editorial, a media library that understands versions, automated quality control, review and approval, deliverables packaging, and technical validation against broadcast, theatrical, and streaming specifications. The "virtual" part is not just remote viewing. It refers to the operating layer itself moving into software so that distributed teams, freelance specialists, and vendor partners can coordinate the same way an in-house team coordinates down the hallway. A virtual post house does not replace creative tools such as DaVinci Resolve, Pro Tools, or Nuke. It surrounds them. It handles the work that traditionally fell to assistants, coordinators, and post supervisors: chasing files, running checks, comparing media to delivery specs, and keeping the project current. The category emerged because post operations are still largely held together by memory and messages, even at facilities with serious technical pipelines. Centralizing that operational layer in software makes the work auditable, repeatable, and faster to ship.
A virtual post house performs the operational and technical work that surrounds creative finishing. Concretely, that includes media intake from cameras, editorial systems, and cloud storage; a library that tracks every asset and every version rather than a folder of files with names ending in FINAL; automated quality control on incoming and outgoing files for codec, resolution, frame rate, color space, bit depth, chroma subsampling, audio configuration, and metadata; loudness measurement against standards such as EBU R128 and ATSC A/85; caption editing, conversion, and validation across the formats broadcasters and streamers require; Digital Cinema Package inspection and authoring; deliverables packaging against distributor specifications; review and approval flows with timecode-accurate notes and drawn markup; secure share links and file requests for moving material to and from clients; and project state tracking across vendors, episodes, versions, and reels. Underneath all of this, a well-built virtual post house records what happened: which file was checked, against which specification, when, and what passed or failed. That record is what makes the operating layer trustworthy. The platform is not the place where color decisions or sound mixes are made. It is the place where the dozens of small coordination tasks that historically required a producer and an assistant editor and a finishing supervisor are handled in software, with humans staying on the creative and client-facing decisions.
A traditional post-production facility is a physical location with suites, storage, and a staff. A client books a colorist, a sound mixer, or a finishing artist, and the facility handles everything around that session: media management, QC, deliverables, archiving, and project coordination. A virtual post house provides the same operational backbone in software, decoupled from any specific room or staff. The differences are practical. A traditional facility scales by hiring more assistants and buying more storage. A virtual post house scales by orchestrating distributed workers and cloud or self-hosted compute. A traditional facility has institutional memory in the heads of its supervisors. A virtual post house captures that knowledge as encoded standards, QC profiles, and policy rules. A traditional facility coordinates by email, phone, and shared drives. A virtual post house coordinates through structured state that humans and software agents can both read. Neither model replaces the other for every project. Theatrical finishing, ADR stages, color suites with calibrated displays, and Atmos mix stages remain physical work. But the operational layer around those sessions, the part that historically required runners, coordinators, and assistants, is the part a virtual post house absorbs. Facilities that adopt a virtual post house alongside their suites keep the creative work in-house and offload the coordination overhead to software.
A traditional post-production facility prices its overhead into everything it sells. Suite day rates carry the cost of real estate, calibrated rooms, storage infrastructure, capital equipment, and the staff of assistants, coordinators, and engineers who keep the operation running. For a feature or a series, the operational portion of a post budget, meaning the QC passes, deliverables creation, media management, and coordination labor, commonly runs from the low tens of thousands of dollars into six figures depending on the delivery count. A virtual post house moves that operational layer to software pricing: a platform subscription plus usage, with creative talent hired directly rather than booked through a facility markup. The savings come from three places. Physical overhead is not in the price, because there is no building. Automated QC and validation replace hourly human passes for the checks that are mechanical, while humans still review what needs judgment. And coordination work that used to be billed as labor, chasing files, tracking versions, comparing deliveries to spec sheets, is absorbed by the platform. What does not change is the cost of creative work. Colorists, mixers, and finishing artists cost what they cost, and a virtual post house does not discount their craft. The honest framing is that a virtual post house reduces the operational and coordination portion of a post budget, often the least visible and least controlled portion, rather than the creative portion. Many facilities run a hybrid: physical suites for creative sessions, and a virtual post house for the operational layer around them.
Bradford Lab is your media library in the cloud, with a post house built around it. Every asset on a project is tracked with every version of it, reachable from the suite, a laptop, or a client’s browser. What makes it a post house rather than storage is that everything which happens to the media stays attached to the exact version it happened to: the QC report, the caption pass, the loudness measurement, the frame-accurate note, the approval, the share link and whether the recipient opened it, the processing job, the storage-tier change. That is what makes the state of a deliverable something the system can answer rather than something a coordinator reconstructs from memory and a spreadsheet. On top of that record sit the services a finishing facility would otherwise perform by hand. Versions are tracked as first-class records rather than filenames. Share links send material to clients and reviewers with scoped, expiring, revocable access and frame-accurate notes and drawn markup coming back. File requests collect material from clients and vendors without an email thread. Quality control runs against delivery specifications, with Digital Cinema Packages validated automatically at import. Captions are edited, converted, and delivered in the formats broadcasters and streamers actually accept. Audio loudness is measured against the target for the delivery, not a generic default. Deliverables are bound to specifications, packaged, and tracked through to what shipped and what is still pending. Bradford Lab was built by Bradford Operations and started by Samuel Gursky, who ran Irving Harvey, a brick-and-mortar post house in New York, from 2012 to 2024. The product reflects what a working facility actually needed and could not buy off the shelf. It is currently in closed beta. Bradford Post Assistant extends the same library to the workstation, attaching DaVinci Resolve and the local creative tools to the records the platform is built on.
They are not two separate products so much as one system of record and the bridge that attaches the workstation to it. Bradford Lab is the library: every asset in a project, every version of that asset, and every QC result, caption pass, note, approval, share link, and processing job defined as a relation on a specific version. Bradford Post Assistant is a desktop application that runs on the workstation next to the creative tools, principally DaVinci Resolve, connecting into the application directly to read and drive project, timeline, color, and render operations where the session and the media actually live. What makes it more than a plugin is that it reaches into the same library. From inside the application on the workstation, a user selects a project, an asset, and a specific version out of the cloud library and runs work against it, including quality control on the render fleet. There is no export, upload, and hand-off in between, because both sides are addressing the same record. This matters because post-production has always been half local and half distributed. Grading, conform, and mixing happen on specific machines with specific hardware and terabytes of media attached, while review, approval, delivery, and coordination involve people nowhere near those machines. Historically an assistant bridged the two by moving files and sending emails. Here the library is the shared substrate, Bradford Post Assistant attaches the local creative tools to it, and the render fleet executes against it. Bradford Lab can be used on its own by teams who only need the cloud operational layer.
Agent-first means the platform is designed so that software agents can do real operational work against a known data model, rather than treating automation as a feature bolted onto a tool built for clicking. The foundation is the library. An agent cannot meaningfully act on a folder of files, but it can act on a versioned record: read what a file actually is, compare it against the specification it is meant to satisfy, run a check, write the result back, and advance a state. Because every operation in Bradford Lab attaches to a specific asset version, there is something structured for an agent to read and write in the first place, which is the part most automation stories skip. Two further properties complete it. Operations are exposed through well-defined contracts rather than screen-scraping, including the connection into DaVinci Resolve that Bradford Post Assistant provides on the workstation. And the work runs as durable workflows that survive restarts, network failures, and jobs that take hours, so an agent can start something long-running and be trusted to finish it. What agents actually do inside Bradford Lab is bounded and specific: probe a file, measure loudness against the assigned target, validate a Digital Cinema Package against its composition, generate proxies and playback renditions, package a deliverable, run a QC profile, keep project status current. Agents do not approve deliveries, sign off on color, accept mixes on a client behalf, or decide whether a borderline measurement is acceptable for a particular distributor. Those decisions have explicit human checkpoints. Separately, Bradford Lab includes a conversational assistant that answers questions in post-production language, both general domain questions about codecs, captions, loudness, and Digital Cinema Package standards, and specific questions about the state of a project it can read. The distinction worth being precise about: the durable workflows do the operational work, and the assistant helps you understand and direct it.
Yes, and it is the platform’s deepest technical capability. On the inspection side, Digital Cinema Packages are validated structurally when they are imported: CPL, PKL, and ASSETMAP integrity, multi-reel composition coherence, SMPTE versus Interop conformance, encrypted package detection, and package and content naming validated against ISDCF conventions through a maintained naming registry. Deep validation runs through clairmeta, so packages are checked against a reference implementation rather than only against assumptions built into the platform. Validation runs inline at import, which means asset records are created against packages that have passed structural checks rather than against packages that merely finished uploading. Imported DCPs play back in the browser, with the JPEG 2000 essence decoded and packaged for streaming so a reviewer can confirm picture and sound without a theatrical playback chain or a DCP-aware desktop player, and with audio rendition selection for stereo and surround configurations. On the authoring side, Bradford Lab creates Digital Cinema Packages through easyDCP, including Version Files derived from an imported Original Version, with preflight checks on the OV before the VF is built. Caption emission is standard-aware: the platform produces Interop DCSubtitle or SMPTE 428-7 timed text to match the target package, which avoids one of the most common causes of DCP rejection. For facilities delivering features, trailers, or theatrical advertising, DCP review, validation, and packaging happen inside the same platform that handles file-based deliverables.
Bradford Lab includes a full caption editor with timeline editing, segment-level controls, format conversion, and delivery presets for specific distributors. On import it reads SRT, WebVTT, TTML, SCC, and Digital Cinema Package subtitle assets. On export it produces SubRip (SRT) for general use, WebVTT for HTML5 and HLS delivery and YouTube upload, SCC for CEA-608 line 21 broadcast captions, MCC for CEA-708 ATSC digital captions, Netflix TTML conforming to the Netflix timed text specification, Amazon TTML for Prime Video and Amazon Studios delivery, IMSC 1.1 for Disney+ and Hulu delivery, iTunes ITT for Apple submission, SMPTE-TT per SMPTE 428-7 for Digital Cinema Package packaging, Interop DCSubtitle for legacy theatrical packages, and plain transcript for reading, search indexing, and AI ingestion. The editor integrates Whisper-based automatic transcription for first-pass caption generation and audio event detection for identifying the non-speech sounds that closed captions are required to describe. Caption tracks carry sentence-end and long-pause information used downstream when captions become animated graphics or burned-in titles. On the validation side, Bradford Lab checks caption files for timing overlaps, frame-rate drift between picture and captions, characters-per-line and reading-speed compliance against the target preset, and standard-specific requirements for theatrical and broadcast delivery. For Digital Cinema Packages, the platform emits the correct caption standard, Interop or SMPTE, based on the target package type. EBU-STL is not currently supported for delivery; European broadcast clients requiring STL should raise that during early access.
Bradford Lab measures program loudness against the standards that broadcasters, streamers, and theatrical distributors actually require. That includes EBU R128, the European broadcast standard targeting minus 23 LUFS integrated with defined true peak and loudness range tolerances, and ATSC A/85, the United States broadcast standard codified by the CALM Act targeting minus 24 LKFS. The platform also validates against platform-specific targets including Netflix at minus 27 LUFS dialogue-gated and Apple TV plus at minus 24 LUFS dialogue-gated, along with other streaming and broadcast specifications that publish their own integrated loudness, true peak, dialogue loudness, and loudness range requirements. Measurements include integrated loudness, momentary and short-term loudness, true peak in dBTP, and loudness range in LU. Audio is measured against the specific delivery profile assigned to the project, so a mix targeted at theatrical delivery is not falsely flagged for failing a broadcast target, and a mix conformed for one streamer is not assumed to pass another with a different target. Bradford Lab handles multichannel configurations including stereo, 5.1, and 7.1, and recognizes Broadcast WAV files with embedded timecode, multichannel stems, AAC, and Dolby Digital. When a file fails a loudness check, the platform surfaces the specific measurement, the target it failed against, and where in the program the failure occurred, so a mixer or assistant can locate the issue rather than guessing. Loudness can also run as a gate, meaning a deliverable does not advance until the measurement passes the target assigned to it.
Quality control in Bradford Lab is driven by profiles rather than by a fixed list of checks, 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, meaning the codec, resolution, frame rate, color, audio configuration, caption, and loudness requirements published by a distributor or platform. QC profiles define which checks run and at what severity. Policy profiles define what has to be true before something is allowed to ship. Separating them means a facility can run several delivery specifications in parallel without rebuilding QC logic for each one, and can update a specification in one place without touching the rules that consume it. These profiles resolve through a scope hierarchy: platform-level defaults apply everywhere, and an organization’s administrators can define their own profiles that override those defaults for the organization, and narrow them further for a specific client or project. The QC catalog covers video technical checks, audio technical checks, audio-video sync, captions and accessibility, photosensitive epilepsy screening, HDR metadata, Digital Cinema Package and IMF package validation, checksum verification, and reference-versus-export comparison. Checks are dispatched by trigger policies attached to a QC profile, so QC runs on the events an organization chooses, such as when a new version of an asset is created. Digital Cinema Packages 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, and organizations can run any profile on demand in the meantime.
Yes. Bradford Lab validates file-based deliveries against the technical specifications broadcasters, streamers, and distributors publish. That validation spans video and audio codec compliance, resolution and frame rate, scan type, color primaries and transfer characteristics, HDR metadata for HDR10 and Dolby Vision deliverables, bit depth, chroma subsampling, audio channel configuration, embedded timecode, loudness against EBU R128 or ATSC A/85 or a platform target, caption presence and format, and container-level metadata. The platform reads and validates common professional codecs including ProRes from Proxy through 4444 XQ, DNxHD and DNxHR, H.264, H.265 and HEVC, AV1, JPEG 2000 in DCP MXF, XDCAM, AVC-Intra, MPEG-2, and uncompressed video. Audio formats include PCM WAV, Broadcast WAV with embedded timecode, multichannel stems for stereo, 5.1, and 7.1, AAC, and Dolby Digital. Delivery specifications are first-class records in Bradford Lab rather than PDFs in a folder: a specification carries the distributor, platform, territory, format, color space, HDR format, and loudness target it requires, and deliverables are bound to the specification they are meant to satisfy. That binding is what makes the question "is this ready to ship" answerable by the platform instead of by a person reading a spec sheet next to a QuickTime inspector.
Yes, through Bradford Post Assistant, the desktop application that runs on the workstation where Resolve is installed. Because it runs locally, it connects to Resolve directly rather than through an export-and-upload round trip, using the Bradford Toolkit MCP server to expose Resolve project and timeline operations both to the platform and to AI agents working within it. Through that connection, project and timeline structure can be read, clips and source media inspected, timeline items manipulated, color grades applied through DRX preset files including a curated look library, the render queue managed, playback controlled, markers set, and stills and frames exported. It is used for automation, such as preparing a Resolve session against a delivery specification, and for editorial review, where timeline state is read to produce clip cards, pacing analysis, and editorial notes. Bradford Lab does not attempt to replace Resolve. Resolve remains the finishing application where color, edit, and Fairlight work happens. The integration handles the operational scaffolding around those sessions: project setup, timeline conform, deliverables prep, and the many small Resolve tasks that historically required an assistant. Beyond Resolve, editorial interchange is supported through CMX 3600 EDL, Final Cut Pro XML, and OpenTimelineIO, so cuts can move between Resolve, Avid Media Composer, Premiere Pro, and other systems, with turnover packages generated from sequences in the platform.
Frame.io and Bradford Lab solve different problems, and they are integrated rather than exclusive. Frame.io, owned by Adobe, is primarily a review and approval platform with strong Camera to Cloud ingest. Its core strengths are timecode-accurate notes, version stacks, share links, and getting footage from set into editorial. Bradford Lab is the operational layer around finishing: a media library with version tracking, automated quality control, Digital Cinema Package validation and authoring, loudness and caption work, deliverables packaging against distributor specifications, and delivery state across vendors and versions. Bradford Lab’s Frame.io integration is deep and bi-directional rather than a one-way import. Accounts and project trees can be imported, media browsed and pulled in as a source, and comments synchronized in both directions, including frame-accurate annotations, threaded replies, and owner attribution, with webhook and custom action support so activity in Frame.io can reach into Bradford Lab workflows. A team using both might pull dailies through Frame.io for editorial review, then hand finished masters into Bradford Lab for QC, DCP creation, caption delivery, and deliverables packaging, with review notes flowing between the two rather than being retyped. The simplest framing is that Frame.io handles the review layer where humans look at picture and leave notes, and Bradford Lab handles the operational layer where files are validated against technical specifications and packaged for delivery. A facility standardized on Frame.io does not need to choose.
MediaSilo and Wipster are review and approval platforms in the same general category as Frame.io, with particular strengths in secure review, forensic watermarking, and client-facing presentation. They are designed around the moment when a human watches a cut and leaves notes. Bradford Lab is designed around the operational work that happens before and after that moment: file ingest into a version-aware library, automated quality control against codec and metadata specifications, loudness measurement, caption editing and delivery, Digital Cinema Package inspection and authoring, deliverables packaging, and delivery state tracking. A facility using MediaSilo or Wipster for client review can run Bradford Lab alongside them to handle the technical layer those platforms are not built to address. There is some surface overlap, since any platform that touches media offers some level of playback and commenting, and Bradford Lab does include frame-accurate review with drawn markup and threaded comments on scoped share links. But the centers of gravity are different. Review platforms compete on viewer experience, security, and approval workflow. Bradford Lab competes on operational depth: how thoroughly it understands the file, the specification, and the delivery target, and how much of the coordination work it can absorb so that humans stay on the creative and client-facing decisions.
Bradford Lab is downstream of high-speed transfer and media asset management tools rather than a direct replacement for them. Aspera, Signiant Media Shuttle, and similar products specialize in fast, resumable transfer of large media files across networks. Iconik and similar media asset managers specialize in cataloging, search, and metadata across large libraries. Bradford Lab handles what happens to media once it has arrived and needs to move through QC, finishing, and delivery: a version-aware library, automated validation, Digital Cinema Package handling, caption and loudness work, deliverables packaging, and delivery state tracking. For most facilities, the right model is to keep using a dedicated transfer or MAM tool for what it is best at, and use Bradford Lab as the operational layer that consumes media from those tools and prepares it for delivery. Bradford Lab does provide ingest from Frame.io, Dropbox, and Google Drive, along with file requests that let clients and vendors deliver material directly into a project, so for teams whose media flow is already on those platforms a separate transfer tool may not be necessary. For larger facilities with petabyte-scale archives and complex rights management, Iconik-style asset management remains a distinct concern from the operational finishing layer that Bradford Lab covers.
Yes, in the way that matters for most facilities. Bradford Lab’s render and processing nodes are distributed workers, signed and notarized for macOS, that run on hardware inside a facility’s own machine room. When nodes are self-hosted, media processing, QC measurement, rendering, and packaging happen on premises: the platform coordinates the work while the media itself stays inside the facility’s infrastructure. This matters for sensitive titles where contractual security requirements restrict where content may live, and for facilities with existing storage investments where moving media to the cloud and back would be slower than processing it in place. Media can also be ingested from the systems where it already lives, including Frame.io, Dropbox, and Google Drive, rather than forcing a migration into a new storage silo. What Bradford Lab is not, today, is a fully air-gapped deployment with no external coordination: the control plane that handles orchestration, project state, and review is cloud-hosted. Productions that require complete network isolation should raise that with the team directly during early access, since requirements at that level are always project-specific.
Bradford Lab is built around the security expectations that studios, distributors, and rights holders place on vendors handling pre-release content. Access control is organization-based and foundational rather than bolted on: every asset, project, and delivery record belongs to an organization, and access is scoped by membership and role. Storage is encrypted. Share links to pre-release assets can be scoped to specific recipients, restricted, set to expire, and revoked, and access to shared material is recorded. For the most sensitive titles, self-hosted processing nodes keep media inside a facility’s own infrastructure while the platform handles orchestration and state. 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, and productions with specific contractual security requirements should raise them during onboarding so the deployment can be configured to match. The team’s background is relevant here: Bradford Operations ran a facility handling pre-release studio and distributor work for twelve years, and the platform reflects requirements that were enforced on it as a vendor.
Bradford Lab is in closed beta and pricing has not been published yet. Early access participants work directly with the team, and beta participation is how pricing is being shaped: against real projects with real delivery counts rather than abstract tiers. What can be said now is structural. Bradford Lab is priced as a software platform, not as facility day rates, and the intent is that the operational layer of post, meaning the library, QC, validation, deliverables management, and coordination, costs meaningfully less as software than it costs as billed labor. Creative work is not part of the equation either way: colorists, mixers, and finishing artists are hired directly by the production, not booked through the platform. Facilities and productions with specific budget questions should request early access and ask; the team answers directly.
Request early access from any page on this site. The form asks for a name and an email address, and access is rolling out gradually, with the team reaching out as capacity opens. Priority generally follows fit: teams with active delivery pressure, real deliverables lists, and concrete workflows help shape the product fastest and tend to be onboarded first. Existing users can sign in at bradfordoperations.com/software/lab. If your team has an unusual workflow, a large library, or a security requirement that needs discussion before any media moves, mention it in the request so the onboarding conversation starts from what you actually need.
No. Bradford Lab is built to absorb the repetitive technical and coordination work that historically consumed assistants, coordinators, and supervisors, not to replace the people who do creative finishing. Colorists, sound mixers, editors, finishing artists, and post supervisors continue to make the decisions that require human judgment, taste, and accountability. What changes is the proportion of their time spent on those decisions versus on chasing files, running QC manually, comparing media to spec sheets, and packaging deliverables. Inside Bradford Lab, software agents handle validation and coordination work: probing files, measuring loudness, validating packages, generating playback renditions, packaging deliverables, and keeping project state current. Those agents work inside guardrails with clear human checkpoints for review and approval. A creative producer still approves the cut. A colorist still grades the picture. A re-recording mixer still signs off on the mix. The platform handles the operational layer around those decisions so the team can focus on the work that actually requires them. For small teams and independent filmmakers, this often means shipping technically clean deliverables without hiring a full coordination staff. For established facilities, it usually means coordinators and assistants spend less time on file chasing and more time on the work that develops their craft.
Request early access and ask the team directly.