Contents

Agentic AI, Dynamic Media Facility Architecture, and the Future of Software-Defined Production

Conceptual White Paper · Draft for Discussion · May 2026

Abstract

The broadcast industry stands at an inflection point. Decades of hardware-defined production infrastructure — racks of specialized equipment, proprietary signal chains, fixed facility designs — are giving way to software-defined architectures built on cloud-native principles. The European Broadcasting Union's Dynamic Media Facility (DMF) framework, together with its open-source Media eXchange Layer (MXL), provides the first coherent blueprint for this transition: a containerized, vendor-neutral ecosystem in which discrete media functions communicate over a standardized data plane.

This paper proposes a logical extension of the DMF concept: the Self-Assembling Broadcast Facility (SABF). In an SABF, an agentic AI system does not merely orchestrate pre-existing containerized media functions — it dynamically generates, validates, deploys, and interconnects new ones in response to real-time production requirements. The vision is a facility that synthesizes its own capabilities: one in which a request for a lower-third graphics engine produces not a call to a pre-licensed vendor application, but a purpose-built, conformant media microservice, instantiated on demand and retired when no longer needed.

Critically, SABF is conceived as a hybrid model. The agentic orchestrator remains free to invoke pre-licensed, vendor-supplied microservices from the existing function library whenever one is appropriate to the task; code generation is engaged only where no suitable licensed function exists, or where bespoke requirements make synthesis the more efficient path. Licensed and unlicensed services coexist within a single signal chain, selected by the orchestrator on a per-requirement basis.

We examine the architectural foundations that make this possible, the open standards on which it depends, the engineering and safety challenges that must be resolved, and the implications for broadcasters, technology vendors, and the production workforce.

1. Introduction

For most of its history, a broadcast facility was defined by its hardware. The switcher, the router, the graphics engine, the playout server — each occupied a physical slot in a rack, ran proprietary firmware, and was connected to its neighbors by dedicated cabling. Building a facility meant procurement cycles measured in years, capital expenditure measured in millions, and a fixed operational ceiling imposed by the equipment on the floor.

The IP transition — anchored by SMPTE ST 2110 and accelerated by the COVID-era collapse of the remote production model — began to dissolve those physical boundaries. Media signals became network traffic. Routing became software. The question shifted from what equipment do we install? to what software do we run?

The EBU's DMF initiative answers that question with a principled framework: a layered, containerized reference architecture in which media functions — encoding, decoding, mixing, compositing, graphics rendering, timing, synchronization — are implemented as stateless microservices, exchanging payloads over the MXL data plane, orchestrated by Kubernetes, and deployable across on-premise, edge, and cloud environments interchangeably. It is the broadcast industry's most ambitious attempt to apply hyperscaler infrastructure thinking to live production.

Yet DMF, as currently conceived, still assumes a catalog of known functions.

The orchestrator selects from available containers; it does not create new ones. The facility is flexible, but it is not generative.

This paper asks what happens when that assumption is removed.

The emergence of large language models capable of generating production-quality code — and agentic systems capable of executing multi-step engineering workflows autonomously — creates a new possibility: an orchestration layer that does not merely deploy software, but authors it. An AI agent, given a production requirement it cannot satisfy from the existing function library, could generate the code for a conformant MXL microservice, validate it against the DMF specification, containerize it, deploy it into the live environment, wire it into the signal chain, and monitor its performance — all without human intervention.

The implications are significant. A sports broadcaster requiring a bespoke animated lower-third package for a one-time event would not need to license a graphics system, configure templates, or schedule operator time. The facility would synthesize the capability, use it, and discard it. A news organization responding to a breaking story with unusual visual requirements — a specific split-screen geometry, a custom data overlay, a real-time locator graphic — could request it in natural language and receive a running microservice within the production environment in minutes.

It bears emphasis that this is not a wholesale replacement of the licensed vendor ecosystem.

The agentic layer continuously selects the appropriate path for each requirement — invoking a commercially licensed microservice already deployed in the function library when one fits the task, and synthesizing a new, unlicensed microservice only when no suitable licensed option exists or when cost, time, or specificity argues against using one. In a typical SABF deployment, licensed and unlicensed services are expected to operate side by side within the same production, with the orchestrator routing each request to whichever path best satisfies the constraints at hand.

This is not a distant prospect. The component technologies — DMF/MXL, Kubernetes, code-generating LLMs, agentic orchestration frameworks — exist today. What does not yet exist is their integration into a coherent, broadcast-grade system architecture. This paper is a first attempt to sketch that architecture, identify its requirements, and surface the engineering and operational challenges that must be addressed before it can be trusted in a live production environment.

Scope and Audience

This paper is addressed to broadcast engineers, facility architects, technology strategists, and standards bodies engaged in the evolution of software-defined production infrastructure. It assumes familiarity with the EBU DMF reference architecture and with general principles of containerized microservice deployment. Readers seeking background on DMF fundamentals are directed to the EBU's published white papers and the joint EBU-AMWA JT-DMF working group documentation.

The remainder of this paper is structured as follows. Section 2 reviews the DMF architecture and its role as a substrate for dynamic function deployment. Section 3 defines the Self-Assembling Broadcast Facility concept and its relationship to agentic AI systems. Section 4 examines a worked example — the dynamic generation of a graphics compositing service — in technical detail. Section 5 addresses the reliability, safety, and security challenges specific to AI-generated code in live broadcast environments. Section 6 considers implications for the broadcast technology industry and workforce. Section 7 outlines a research and standards agenda for the community.

Draft for Discussion — Not for Citation Without Permission

2. The Dynamic Media Facility as a Substrate

The Dynamic Media Facility (DMF) is the European Broadcasting Union’s reference architecture for software-defined live production. Developed under the joint EBU–AMWA JT-DMF working group and organized around the open-source Media eXchange Layer (MXL), DMF describes how a broadcast facility can be assembled from interoperable, containerized media functions rather than from fixed hardware appliances. This section reviews the architecture in outline and then identifies the specific properties that make it a viable substrate for the dynamic, AI-driven function deployment proposed in this paper.

2.1 Architecture in outline

DMF is a layered model. At the base sits a uniform compute fabric — in practice, Kubernetes — that can be instantiated on premise, at the edge, or in a public cloud, and that treats media workloads as ordinary container workloads. Above the fabric sits the data plane: the Media eXchange Layer, an open-source library and runtime that allows containerized functions to exchange uncompressed video, audio, ancillary data, and timing in a standardized, low-latency form. Above MXL sit the media functions themselves — encoders, decoders, mixers, compositors, graphics renderers, multiviewers, conformance monitors — each a stateless microservice that reads inputs from the data plane and writes outputs back to it. A control plane derived from NMOS (Networked Media Open Specifications) and SMPTE ST 2110 timing handles discovery, registration, and signal routing.

The principal departure from the preceding ST 2110 era is that the network is no longer the integration boundary. In a pure ST 2110 facility, IP multicast is the universal backplane and integration happens at the wire. In DMF, the integration boundary moves up to the container runtime: functions are packaged, deployed, and connected as software, with the data plane abstracted by MXL and the timing model preserved. The result is a facility whose topology can be rewritten without rewiring.

Figure 2.1. DMF Reference Architecture — A four-layer view of the EBU Dynamic Media Facility: compute fabric (Kubernetes) at the base, the MXL data plane above it, containerized media functions as the third layer, and an NMOS/ST 2110-derived control plane handling discovery, registration, and routing.

2.2 Properties that make DMF a substrate

Four properties of the DMF design make it more than a modern broadcast architecture; they make it a candidate substrate for dynamically generated functions.

First, the data plane is standardized and content-agnostic. Any container that produces or consumes MXL-conformant payloads can join the signal chain without prior integration. The orchestrator does not need to know what a function does — only that it speaks the data plane. This is the same property that makes Kubernetes a viable platform for arbitrary application workloads, applied to live media.

Second, the deployment lifecycle is software-native. New functions enter production through the same container build, registry, and Kubernetes deployment pipeline used for any other workload. There is no firmware to flash, no proprietary loader, no vendor portal. A microservice generated by an AI agent can be deployed through exactly the same path as one shipped by an established vendor.

Third, the orchestration layer is already designed to handle dynamic placement, scaling, and failure. Kubernetes treats media functions as fungible workloads; SABF extends this assumption from functions that exist in the catalog to functions that may not yet exist at the moment a production starts.

Fourth, conformance is testable. Because MXL and the surrounding NMOS specifications are explicit about payload formats, timing semantics, and registration behavior, a candidate function — including a synthesized one — can be validated against the specification before it is admitted to the live signal chain. The same conformance harness that protects a production from a buggy vendor release can protect it from a buggy generated one.

Figure 2.2. DMF as Substrate for Dynamic Function Deployment — How a newly synthesized media function enters the DMF lifecycle: container build → conformance validation against MXL/NMOS specifications → publication to registry → Kubernetes deployment → MXL data plane → admission into the live signal chain. The same path serves both vendor-supplied and AI-generated functions.

2.3 The unaddressed assumption

For all its flexibility, DMF as currently defined assumes a closed catalog. The orchestrator selects from the set of functions that exist in the registry at production start; the specification does not contemplate new functions being authored, validated, and admitted at production time. This is not an oversight — DMF is a deployment and integration framework, not a development framework — but it is the precise gap into which the Self-Assembling Broadcast Facility steps.

The architectural premise of SABF is that everything DMF specifies on the deployment side can be reused unchanged.

Containers, MXL, NMOS, Kubernetes, and the conformance harness all remain as defined. What must be added is an authoring layer above the orchestrator: an agentic system capable of generating new conformant functions, validating them, packaging them, and handing them to DMF’s existing deployment pipeline. Section 3 develops that authoring layer in detail and shows how it composes with — rather than replaces — the DMF substrate reviewed here.

3. The Self-Assembling Broadcast Facility

The Self-Assembling Broadcast Facility (SABF) is a Dynamic Media Facility extended with an authoring layer. Where DMF specifies how containerized media functions are deployed, interconnected, and operated, SABF specifies how new functions can be requested, generated, validated, and admitted to the same deployment pipeline at production time. The two layers compose cleanly: SABF does not replace DMF, and a SABF deployment running with the authoring layer disabled is indistinguishable from a conventional DMF facility.

3.1 Three modes of operation

In any SABF, the orchestration layer can satisfy a production requirement in one of three modes.

Library mode. A pre-existing function — a licensed vendor microservice, an in-house container, or an open-source community image — is already present in the registry and

can be configured to meet the requirement. The orchestrator selects the function, the authoring layer writes the configuration that adapts it to the specific intent, and the orchestrator instantiates and wires the configured pair. This is the path closest to standard DMF behavior, extended only by the agent-authored configuration step.

Composition mode. No single library function meets the requirement, but a graph of existing functions does. The orchestrator constructs a multi-function signal chain from registry entries and deploys it as a unit. This too is largely within reach of conventional DMF tooling, though SABF formalizes it as a distinct mode.

Synthesis mode. No combination of existing functions can satisfy the requirement within acceptable cost, latency, or specificity bounds. The authoring layer generates a new conformant microservice and an initial configuration for it, validates the pair against the DMF specification, builds and registers it, and hands it to the orchestrator for deployment alongside any other function in the registry.

The selection between modes is a routing decision made per requirement, not a global facility setting. A single live production may, within a single signal chain, draw on a licensed vendor mixer, a composed graphics chain, and a freshly synthesized data overlay — all coordinated by the same orchestrator and exchanging payloads over the same MXL data plane.

Figure 3.1. SABF Layered Architecture — SABF as a layered extension of DMF: the existing DMF substrate (compute fabric, MXL data plane, function registry, orchestrator) is overlaid by an authoring layer comprising intent intake, library evaluation and routing, code generation, configuration, conformance validation, functional and operational validation, packaging, and runtime monitoring. The authoring layer never touches the data plane directly; it produces deployable artifacts that flow into the DMF pipeline unchanged.

3.2 Components of the authoring layer

The authoring layer is composed of eight logical components. Each is implementable as one or more agents in a Claude-style or comparable agentic framework, and each communicates with the others through structured messages rather than shared state.

The intent intake receives a production requirement — expressed either in natural language by an operator or as a structured request from an upstream production-management system — and translates it through a brief interactive clarification dialogue into a formal specification covering required inputs and outputs, performance budget,

conformance class, security profile, and an economic and licensing profile (per-use license cost ceilings, cloud resource budget, expected duration of use, and any constraints on synthesis such as restricting generated functions to open-licensed components). The intake does not commit to a specification on first reading: it surfaces ambiguities one or two at a time, offers defaults from the template corpus where the operator is uncertain, and — for visual functions — generates a still-frame preview against a representative test fixture for the operator’s approval before the specification is locked, committing the approved preview as the visual ground truth against which the functional validator will later compare. The economic profile is what allows the routing decision downstream to weigh more than functional fit alone.

The library evaluator searches the function registry — including any licensed vendor catalogs the facility subscribes to — for a function or function graph that satisfies the specification, and then scores each candidate against the economic profile produced by the intake. A licensed vendor function that meets the requirement may still be passed over in favor of synthesis when its per-use license cost, cloud resource footprint, or expected idle overhead make synthesis the cheaper path; conversely, a perfectly synthesizable requirement may be routed to a paid vendor function when fast deployment, certified support, or risk profile argue for it.

The library evaluator is therefore not merely a gatekeeper that prevents unnecessary synthesis, but a routing engine that selects among modes on functional, economic, and operational grounds.

The cost-routing comparison deserves explicit comment. The licensed-side cost is generally observable in advance — per-use fees are catalogued, vendor container footprints are profiled at registration, and cloud quotas are known — but synthesis-side cost must be estimated before any code is generated. The evaluator relies on a synthesis cost model maintained by the runtime: a catalog of prior generation runs by function class (graphics overlay, audio mixer, codec wrapper, data ticker, and so on) recording observed generator inference cost, validation cycles, container image size, and steady-state runtime resource consumption. A new request is matched against the closest historical precedent to produce an estimate with confidence bounds. Where the estimate is too uncertain to support a confident routing decision, the evaluator defaults to the library option, invokes a lightweight scoping pass that estimates code complexity without committing to full generation, or surfaces the trade-off to a human operator with both options priced side by side. The cost spectrum is also not binary: between bare library use and full synthesis sits the more common case of a library function paired with an agent-authored configuration, which is usually the cheapest path for novel but not radical requirements.

A SABF deployment that has never synthesized a given class of function will routinely default to library mode for that class until enough data accumulates to support confident estimation. The introduction of agent-authored configuration further weights the comparison toward library mode: a licensed function paired with a generated configuration is almost always cheaper than full synthesis, so the routing decision in practice is most often a choice between library-with-default-config, library-with-agent-config, and full synthesis, in roughly increasing order of cost. Synthesis is also not irreversible mid-flight: if actual cost begins to overrun the estimate during generation or validation, the runtime can abort and fall back to the library option.

The code generator is engaged only in synthesis mode. It produces source for a new MXL-conformant microservice that meets the specification, drawing on a curated set of templates, prior synthesized functions, and the published DMF, MXL, and NMOS specifications. The generator is not asked to invent broadcast architecture; it is asked to fill in a well-defined slot in an existing one.

Several architectural commitments shape the generator’s behavior and connect it to the rest of the SABF lifecycle.

Dependency policy. Generated code draws only from a designated allowlist — the open-source MXL reference library, vetted broadcast-domain packages, the facility’s internal utility libraries, and any vendor SDKs the facility has licensed.

Novel dependencies require an explicit change-control update through the facility’s normal governance process; the generator may not pull arbitrary packages from the public ecosystem at synthesis time. The intent intake’s economic and licensing profile can tighten the allowlist further — for example, restricting a particular synthesis to open-licensed components only.

Persistence. Every synthesized function is committed to a versioned source repository at the moment of registration, with provenance metadata recording the originating intent, the model and template that produced it, the validation results, and the signing credential. The repository is the primary artifact for audit, post-event review, and reuse; the registry is a deployment surface, not the source of truth. A function used in a single live event remains in the repository indefinitely, even after it has been retired from the registry.

Security gating. Between code generation and conformance validation, the candidate passes through an automated security-audit pipeline — static analysis, dependency vulnerability scanning, secret detection, and AI-assisted review for broadcast-relevant failure patterns such as unsafe handling of untrusted ancillary data or insecure timing assumptions. Functions that fail security gating are returned to the generator on the same repair-or-reject loop used for conformance and functional failures, and a security failure that recurs across repairs is escalated to a human operator rather than being silently retried.

Iterative learning. The generator improves across productions through a closed loop with the runtime monitor and the post-event review process. Functions that performed well in production — high reliability, on-budget resource consumption, no operator interventions — are promoted into the template corpus for future synthesis. Functions that failed are retained as negative examples with their failure modes encoded, so the generator avoids similar patterns in subsequent runs. This loop operates over the facility’s own historical corpus rather than via continuous external training, which keeps generator behavior auditable and reproducible across runs.

The security model and the safeguards on the learning loop are developed in detail in Section 5; Section 4 walks through the dependency policy and persistence behavior in the context of the graphics compositor worked example.

The configurator authors the configuration payload that adapts a chosen function to the specific intent. Almost no library function is used as-is: a graphics engine has templates, fonts, color palettes, and data bindings; a mixer has channel maps and dynamics presets; an encoder has bitrate ladders; a multiviewer has layouts.

The configurator runs in all three modes — after the library evaluator in library and composition mode, and after the code generator in synthesis mode — and produces a structured configuration (a JSON or YAML document, an NMOS parameter set, a template or scene file, an asset binding, or any combination) that is validated against the function’s published parameter schema. The pair of function image and configuration, not the image alone, is what becomes a deployable unit; in the registry the configuration is a first-class artifact, signed and versioned alongside the function. Because authoring a configuration is structurally far cheaper than authoring code, library or composition mode paired with an agent-authored configuration is in practice the most common path through the authoring layer; full code synthesis is reserved for requirements that no configuration of any existing function can satisfy.

The conformance validator runs the candidate function against a specification testbench covering payload format, timing behavior, registration semantics, resource budget, and security policy. This stage answers the question, does this function speak the data plane correctly and behave as a well-formed DMF citizen? A function that fails conformance is either repaired by the generator on a bounded number of retries or rejected with a structured failure reason.

The functional and operational validator runs the candidate function in a sandboxed staging environment that mirrors the production signal chain.

Where the conformance validator asks whether the function meets the specification, the functional validator asks whether it actually performs the task it was generated to perform — under realistic load, against representative inputs, for the duration the production requires. This stage covers perceptual or visual verification where applicable (for graphics, compositing, and codec functions), latency and jitter under sustained load, behavior under input degradation, and any production-specific acceptance criteria carried in the original intent. Misconfiguration is one of the failure modes specifically targeted at this stage: a correctly chosen library function with the wrong configuration — graphics rendered in the wrong color space, audio panned to the wrong bus, an encoder set to the wrong bitrate ladder — will typically pass conformance but fail functional verification. A function that passes conformance but fails functional or operational verification is returned to the generator or configurator with the failure mode encoded, or rejected outright if repeated repairs do not converge.

The packager containerizes the validated function, signs it with a credential that identifies it as authoring-layer output, and publishes it to the function registry alongside vendor-supplied images. From this point onward the function is, to the DMF orchestrator, an ordinary registry entry.

The runtime monitor observes the deployed function in production: latency, drop rate, control-plane behavior, and

any conformance or functional anomalies that escaped staging. A misbehaving synthesized function can be quarantined and replaced — by another synthesized variant, or by falling back to a library function — without operator intervention.

Figure 3.2. End-to-End Function Lifecycle in SABF — The lifecycle of a single production requirement: intent intake (functional spec + economic and licensing profile) → library evaluation and routing (library, composition, or synthesis on functional and economic grounds) or → code generation (synthesis mode only) → configuration of the chosen function → conformance validation → functional and operational validation in a staging environment → packaging and registration → DMF deployment → MXL data plane → runtime monitoring → eventual retirement. Library, composition, and synthesis modes share the same downstream pipeline from registration onward.

3.3 How SABF composes with DMF

The compositional discipline that makes SABF tractable can be stated in three rules.

First, the authoring layer produces artifacts, not signals. Its output is a container image, a configuration payload, or a registry entry, never a live MXL frame. The data plane remains the exclusive province of DMF.

This is the property that allows the entire authoring layer to be added, modified, or removed without touching the broadcast-critical path.

Second, conformance is the contract. The authoring layer is bound to produce functions that pass DMF’s existing conformance and operational test harness. As long as that contract is honored, the orchestrator and the data plane do not need to know — and do not behave differently — based on whether a function was hand-coded by a vendor or generated by an agent.

Third, library functions remain first-class. Synthesis is invoked only when library and composition modes — even with the configurator adapting library functions to the intent — cannot meet a requirement on functional or economic grounds. Licensed vendor microservices, in-house containers, and open-source community functions continue to populate the registry and continue to be the orchestrator’s first choice. SABF expands the catalog from “everything that has been built” to “everything that has been built, plus everything that can be built on demand”; it does not deprecate the former.

Together these rules ensure that a SABF deployment degrades gracefully. If the authoring layer is disabled, the facility continues to operate as a conventional DMF facility against its existing function library. If a synthesized function fails in production, the runtime monitor can fall back to the nearest library equivalent. The agentic capability is additive: a new option offered to the orchestrator, not a new dependency imposed on it.

The remaining sections of this paper take this compositional foundation as given. Section 4 walks through a concrete worked example — the dynamic generation of a graphics compositing service — showing each authoring-layer component in action. Section 5 addresses the reliability, safety, and security concerns that follow from admitting AI-generated code into a live broadcast environment. Sections 6 and 7 consider the broader industry and standards implications.

4. A Worked Example: Dynamic Generation of a Graphics Compositing Service

This section walks the SABF lifecycle end to end through a single concrete production scenario: a regional sports broadcaster preparing a season opener with a novel last-minute graphics requirement. The example is constructed to exercise all three operational modes — library, configuration, and synthesis — within a single signal chain, and to make every authoring-layer component visible at the level of process, artifact, and measurable result. Notation in this section is illustrative; specific syntax for MXL function templates, configuration payloads, and registry records is representative of an SABF deployment but does not bind the eventual specification.

4.1 The production scenario

Context. A regional sports network is producing the home team's basketball season opener. The broadcast facility runs an established DMF deployment with a fully populated registry: licensed vendor microservices, internal utility functions, and an open-source community catalog. The SABF authoring layer has been live for six months and has accumulated a small but functional template corpus from prior productions.

The brief. Ninety minutes before air, the producer adds a creative requirement to the rundown: a season-opener lower-third treatment that must include a real-time animated

trajectory ribbon — a small in-frame data visualization that shows, for the player currently on screen, their prior-season scoring trend rendered as a colored ribbon flowing under the name plate. No vendor in the facility's library has shipped such a function; no open-source compositor in the catalog matches the visual specification.

Why the example is interesting. The lower-third proper is well within the capability of the facility's existing graphics engine; only the trajectory ribbon is genuinely novel. A binary library-or-synthesize decision would force one of two suboptimal outcomes: license a heavy commercial graphics suite that can do the ribbon among its capabilities (expensive, slow to spin up), or synthesize the entire lower-third from scratch (overkill, slower, less reliable than reusing a known-good engine). SABF's hybrid model lets the orchestrator reuse the existing engine for the parts it can do and synthesize only the trajectory ribbon, wiring them together as a small composition graph.

4.2 Intent intake

The producer's request enters the SABF authoring layer through the intent intake. The brief is delivered conversationally — through a chat with the production assistant agent in the facility's control room — and is paraphrased here:

"We want a custom lower-third for tonight. Use the team's primary blue gradient. Show name, position, and the player's scoring average for last season.

To the right of the name, add a small animated ribbon showing their trend across last season — like a small heartbeat-style chart but colored by win/loss. Sponsor lockup in the lower right. Animate in over half a second. Use it for player IDs all night."

Clarification dialogue. The intake does not commit the brief to a formal specification on first reading. The brief leaves several decisions implicit — "heartbeat-style chart" admits multiple chart families; "the team's primary blue gradient" assumes a brand-pack version that may have been refreshed for the new season; "win/loss" needs a numeric threshold; "use it for player IDs all night" needs to be reconciled with which player roles are tagged in the stat feed; what to do when a player has no prior-season trajectory (rookies) is not addressed at all. The intake agent surfaces these one or two at a time, with defaults proposed from the template corpus where the producer is uncertain:

Intake: "I have last season's brand pack — should I use the deep-blue gradient (#0A2A6E → #1A5BB8) or the lighter alternate (#1B4F9E → #4A82C4)?"

Producer: "Deep one. Match the on-court signage."

Intake: "For the trajectory ribbon, should I read win/loss from the team result for each game (binary), or from the player's individual scoring relative to their season average (continuous, threshold at 0.5)?"

Producer: "Player relative to average. Threshold at 0.5 is fine."

Intake: "Should the lower-third appear for every player on screen, or only the home team's starters and bench when first identified? And should the operator be able to trigger it manually?"

Producer: "Home team only, on first ID. Yes to manual trigger."

The clarification phase resolves six ambiguities in this brief, including two not shown above (treatment for rookies with no prior-season trajectory, and behavior when the stat feed is momentarily unavailable). The producer's answers are bound back into the candidate specification before any visual output is generated.

Visual preview and approval. For visual functions, prose alone cannot pin down intent reliably. The intake generates a still-frame preview against a representative test fixture — a recent game still with a known player whose data is in the stat archive — using the candidate configuration. The configurator drafts a working AvenirGFX configuration; the trajectory ribbon, having a corpus precedent in two prior overlay functions, is rendered using a fast preview path; a single composited frame is produced in roughly fifteen seconds and presented to the producer:

Figure 4.1. Approved Preview Frame — A still composited frame produced by the intake before the formal specification is locked. The producer reviews the frame and either approves it as the visual target, requests numeric adjustments ("ribbon thicker"; "name plate moved 40 pixels left"), or — rarely — rejects the direction and reopens the clarification dialogue. The approved preview is committed alongside the formal specification as the visual ground truth against which the functional validator will later compare.

In this example the producer requested two revisions before sign-off — making the trajectory ribbon slightly thicker and shifting the name plate 40 pixels to the left so the ribbon would not crowd the player's name on long surnames. Each revision absorbed back into the configuration in seconds and a new preview rendered. The approved preview closes a real gap in the lifecycle: without it, the perceptual-verification step in functional validation would depend on a producer-supplied mockup that may or may not exist.

With the clarifications resolved and the preview approved, the intake agent commits the formal specification covering function inputs and outputs, performance,

conformance, security, and the economic and licensing profile. The structured artifact is recorded for audit:

{
  "intent_id": "intent-2026-04-15-1827",
  "requirement": "player-id lower-third with trajectory ribbon overlay",
  "inputs": {
    "program":   { "plane": "mxl", "format": "video/2110-20", "resolution": "1080p59.94" },
    "stat_feed": { "plane": "nmos", "scope": "player.id, player.name, player.position, player.season_avg, player.last_season_trend" }
  },
  "outputs": {
    "program": { "plane": "mxl", "format": "video/2110-20", "resolution": "1080p59.94" }
  },
  "performance": { "max_added_latency_ms": 50, "frame_drop_budget": 0 },
  "conformance_class": "DMF-graphics-tier2",
  "security": { "network": "sandboxed", "egress": "none", "fs_writes": "scratch_only" },
  "economic": {
    "license_budget_usd": 50,
    "runtime_cpu_budget_m": 400,
    "runtime_ram_budget_mi": 512,
    "expected_runtime_min": 180
  },
  "constraints": ["open-licensed components preferred", "reusable for future games"],
  "acceptance": "visual diff against producer mockup; behavior under stat-feed degradation"
}

The specification is signed by the intake agent's credential and committed to the intent registry. Any subsequent action by the authoring layer — every tool call, every artifact produced — is traceable back to this record.

4.3 Library evaluation and routing

The library evaluator dispatches the specification against the function registry and constructs a candidate set. Three paths are scored against both functional fit and the economic profile from intake:

The evaluator routes to Path B. The reasoning recorded in the routing decision is summarized in three points: Path A's $240 license cost exceeds the intent's $50 license budget; Path B's synthesis surface is a single bounded function for which the cost model has a confident estimate (the template corpus contains two prior overlay functions of similar shape from earlier productions); Path C's two-component synthesis is not justified when AvenirGFX exists and is well-understood. The decision is committed to the intent record alongside its rationale.

4.4 Configuration authoring for the library function

The configurator pulls the published parameter schema for AvenirGFX v3.4 and authors a configuration payload that adapts it to the specific intent. The configuration is a structured document specifying layout, typography, asset bindings, animation timing, and data feed bindings. An illustrative excerpt:

function: avenirgfx@3.4
deployment_id: lt-opener-2026-04-15
inputs:
  program: mxl://ingest.program
  fill:    mxl://gfx-render.fill
  key:     mxl://gfx-render.key
  data:
    name:       nmos://stat-feed/player.name
    position:   nmos://stat-feed/player.position
    season_avg: nmos://stat-feed/player.season_avg
layout:
  template: lower-third-3-line
  origin: { x: 80, y: 920 }
  width:  720
  height: 140
typography:
  primary:   { font: "Roster Condensed Bold", size: 56, color: "#FFFFFF" }
  secondary: { font: "Roster",                size: 32, color: "#E0E6F0" }
animation:
  ingress: { kind: "wipe", direction: "left", duration_ms: 500, easing: "out-cubic" }
brand:
  gradient:        { start: "#0A2A6E", end: "#1A5BB8" }
  sponsor_lockup:  assets://brand/sponsor-bottomright-2026.png

The configuration is validated against the AvenirGFX parameter schema field by field; all 47 specified parameters

pass type and range checks. The configurator runs in 6 seconds and emits an artifact that is bound to the AvenirGFX function image as a paired (image, configuration) record in the registry.

4.5 Code generation for the synthesized trajectory ribbon

For the trajectory ribbon, no library function provides the required behavior. The code generator is engaged. Generation proceeds in three stages:

Template selection. The generator selects the published MXL graphics function template — a skeleton that defines the canonical structure for an MXL-conformant compositor: input/output declarations, MXL ingress and egress boilerplate, registration with the NMOS control plane, and a placeholder for the per-frame processing function. The template is approximately 80 lines of Go and is the same skeleton used by every graphics function in the facility's repository, ensuring conformance is structural rather than incidental.

Dependency selection. The generator selects from the allowlist: MXL reference library v2.1, an internal viz-utils package providing color-space and easing helpers, and gonum/plot (open-licensed) for the underlying trajectory rendering. No additional dependencies are pulled. The template-corpus match from the prior overlay functions narrows the dependency set further by confirming that gonum/plot has been used successfully in this conformance class before.

Generation. The generator produces approximately 240 lines of Go source implementing the trajectory ribbon. An illustrative excerpt of the per-frame processing function:

func (r *TrajectoryRibbon) ProcessFrame(in mxl.Frame, t mxl.Timestamp) (mxl.Frame, error) {
    // Resolve the player on-screen from the bound data feed; bail out if no ID is current.
    pid, ok := r.feed.CurrentPlayerID(t)
    if !ok {
        return in, nil // pass-through; nothing to overlay
    }
 
    // Fetch trajectory points for this player from the cached prior-season feed.
    pts, err := r.cache.Trajectory(pid)
    if err != nil {
        return in, mxl.WrapErr(err, "trajectory cache miss")
    }
 
    // Render the ribbon onto a transparent compositing surface sized to the ribbon area.
    surface := r.renderer.NewSurface(r.cfg.Geometry.Width, r.cfg.Geometry.Height)
    if err := r.drawRibbon(surface, pts, r.cfg.WinLossColors); err != nil {
        return in, mxl.WrapErr(err, "ribbon draw")
    }
 
    // Composite the ribbon over the program frame at the configured offset.
    out := r.compositor.Over(in, surface, r.cfg.Geometry.Origin, r.easing.Now(t))
    return out, nil
}

Code generation completes in 23 seconds, consuming approximately 18,000 tokens of inference. The full source — not shown — includes the function constructor, MXL registration boilerplate, configuration parsing, error paths, and resource cleanup.

The generated source is committed to the facility's synthesized-functions repository at the moment of generation, before validation begins, so that even validation failures are recorded for audit and future learning.

4.6 Configuration authoring for the synthesized function

A second configuration is authored, this time for the newly synthesized ribbon function. It is structurally similar to the library function's configuration: a YAML document validated against the schema declared by the generated function. An illustrative excerpt:

function: trajectory-ribbon@1.0.0
deployment_id: ribbon-opener-2026-04-15
geometry:
  origin: { x: 600, y: 940 }
  width:  220
  height: 80
data:
  trajectory: nmos://stat-feed/player.last_season_trend
animation:
  ingress: { kind: "draw-on", duration_ms: 500, easing: "out-cubic" }
win_loss_colors:
  win:       "#3CB44B"
  loss:      "#E6194B"
  threshold: 0.5
stale_behavior:
  hold_ms: 2000
  fade_out_ms: 1000

The configuration parses cleanly against the schema declared in the generated function's source.

Both configurations — the AvenirGFX adapter and the trajectory-ribbon initializer — are tied to their respective function-image hashes and committed as paired (image, configuration) records.

4.7 Conformance validation

Both functions — the configured AvenirGFX deployment and the synthesized trajectory ribbon — are run through the conformance harness. The harness exercises the contract that DMF expects of any function entering the registry.

4.8 Functional and operational validation

The candidate composition is wired into a sandboxed staging environment that mirrors the production signal chain. The orchestrator establishes the same composition topology that will be deployed in production: AvenirGFX as the lower-third compositor, the trajectory ribbon as a downstream overlay, and a final compositor merging both into the program output. Inputs are provided from a 60-second representative footage clip from the prior season and a synchronous feed of representative stats data.

4.9 Security gating

The synthesized function is run through the security audit pipeline. The library-mode AvenirGFX deployment is not regenerated, but its configuration and bindings are also subjected to the audit, since a configuration can introduce risk independently — for example, by binding a secret feed to an unsecured destination.

4.10 Packaging, signing, and registration

The validated function is containerized using the facility's standard build pipeline. The container image is approximately 38 MB (base image plus MXL runtime plus the 240-line generated function plus dependencies); build time is 47 seconds. Provenance metadata is attached:

{
  "function": "trajectory-ribbon",
  "version":  "1.0.0",
  "image_hash": "sha256:8f3a...c41e",
  "produced_by": "sabf-authoring-layer",
  "originating_intent": "intent-2026-04-15-1827",
  "generation": {
    "model":    "claude-3.5-broadcast-tuned",
    "template": "mxl-graphics-skeleton-v2",
    "corpus_match": ["overlay-2025-11-22", "overlay-2026-02-08"],
    "tokens":   18247,
    "duration_s": 23
  },
  "validation": {
    "conformance": "pass",
    "functional":  "pass-on-second-attempt",
    "security":    "pass-with-advisory",
    "advisory_id": "advs-7f2c"
  },
  "signing_credential": "authoring-layer-prod-2026",
  "repository_commit":  "c41e3f8"
}

The image is signed with the authoring-layer production credential and published to the function registry as a paired (image, configuration) record.

The source is committed to the facility's synthesized-functions repository, tagged opener-2026-04-15, with the provenance record attached. From this moment on, the function is, to the DMF orchestrator, an ordinary registry entry — discoverable, deployable, and indistinguishable in operation from a vendor-supplied image.

4.11 Deployment and runtime

Deployment proceeds through the standard DMF orchestration path. The orchestrator resolves the composition topology, allocates Kubernetes pods for the synthesized function (the AvenirGFX pods are already running in the facility; only the new ribbon function needs to spin up), and wires the MXL data plane bindings. NMOS control-plane registration occurs as the function instances come up; the ribbon function is registered, discoverable, and routable within 4 seconds of deployment start.

The broadcast goes live at 19:00 local time. The runtime monitor observes the new function continuously through the broadcast:

4.12 Post-event review and learning corpus update

After the broadcast, the runtime monitor's metrics are joined with the validation record and submitted to the post-event review process. The trajectory ribbon function is classified as performed well in production: it cleared all conformance, functional, and security gates without rework beyond the initial color-space repair; operated within all resource budgets across the full broadcast; drew zero operator interventions; and drew zero runtime anomalies.

The function's source, container image, configuration, and provenance are promoted into the template corpus: a curated subset of prior synthesized functions that the code generator draws from when handling future requests of similar shape.

A future request for a similar trajectory-style overlay — perhaps with different sport-specific data feeds or color schemes — will find this function as a near match, and will, in many cases, be satisfied by configuration alone rather than by a fresh code generation.

The configuration is also retained as a reusable preset, tied to the function in the registry. The operator can choose to redeploy the same combination for a future game; reuse takes seconds, not minutes. The advisory raised during security gating (the cache TTL question) is reviewed; the cadence assumption was correct in this production but is updated in the function's documentation as an explicit constraint, so a future configuration attempting to use this function with a faster-updating data feed will be flagged at the configurator stage rather than reaching the security review.

4.13 Lifecycle summary

The complete walk from brief to live broadcast, with elapsed times for each phase, is summarized below.

4.14 What the example demonstrates

The worked example is constructed to make several SABF properties concrete.

Hybrid mode is the common case. The interesting outcome here is not that synthesis was used, but that synthesis was used for one well-bounded function while the bulk of the visual treatment was satisfied by an existing library function configured by the agent layer.

A pre-SABF facility would have made a binary choice — license or build — and either spent ten times as much or taken three times as long. SABF's hybrid model produced the cheapest, fastest, and lowest-risk outcome by combining modes within a single composition.

Validation is a pipeline, not a checkbox. Conformance, functional and operational, and security validation each surfaced different kinds of evidence — and the functional stage caught a real defect (the color-space mismatch) that conformance alone would have admitted. Removing any one stage would have admitted a defective function to the live signal chain.

The artifacts are first-class. The container image, the source, the configurations, and the provenance metadata are all persisted, signed, and discoverable. The function can be audited, reused, modified, or retired through standard governance, and its presence in the live broadcast is fully traceable from the producer's spoken brief through to the runtime metrics.

Learning compounds. A future season opener for a different team — or a different sport with a similar visualization need — will find the trajectory ribbon function in the template corpus and will, in many cases, be satisfied without invoking the code generator at all. The marginal cost of synthesis decreases with each well-performing function added to the corpus, and the configuration burden decreases similarly as configurator presets accumulate.

The next section turns to the reliability, safety, and security concerns implicit in this example.

Admitting AI-generated code into a live signal chain raises real questions — about supply-chain integrity, learning-loop poisoning, the limits of automated validation, the role of the human operator, and the standards work that the broadcast community will need to undertake before SABF deployments can be trusted at scale. Section 5 takes those questions in turn.

5. Reliability, Safety, and Security

The earlier sections describe the SABF concept and walk it through a worked example. This section addresses the harder question of what happens when the concept meets a live broadcast environment that cannot tolerate the kinds of failures that AI-generated code is most likely to produce. The treatment here is deliberately conservative: SABF's value depends on being trustworthy enough to admit into the live signal chain, and the engineering and operational discipline required to reach that bar is substantial. Several of the concerns surfaced below remain open research questions for the broadcast and AI communities; they are flagged as such where appropriate.

5.1 The risk landscape

SABF's risk surface is unusual but not unprecedented. The same broad concerns that attend any agentic AI system — prompt manipulation, hallucination, supply-chain compromise, learning-loop integrity, accountability for autonomous action — appear in SABF, but in a domain with three properties that intensify them.

Defects are visible. A misbehaving function in a financial back-office system may produce a wrong number that a downstream check catches before the day is out. A misbehaving graphics function in a live broadcast renders that defect to several hundred thousand viewers within milliseconds. Reputational consequences arrive before remediation is possible.

Real-time constraints exclude many remediation patterns. SABF cannot lean on the rollback-and-retry idioms common in cloud applications. A broadcast frame either ships at the right moment or it does not; there is no opportunity to re-run the request on demand or to silently roll back a deployment between requests.

Regulatory and contractual obligations exist. Licensed content, advertiser contracts, and broadcast regulations all impose obligations that a defect in an AI-generated function can violate — incorrect attribution, dropped sponsor lockups, missed legally-required disclosures, miscaptioning of accessibility content. These obligations do not vanish because the function was generated rather than purchased.

These properties do not invalidate SABF; they shape how it must be defended. The remainder of this section organizes the defenses by where the risk arises in the lifecycle and closes with the standards and operational questions the broadcast community will need to answer collectively. Each chapter ends with a threat-summary table calling out the principal threat, the current mitigation, and the residual risk that remains after mitigation.

5.2 Generation and validation gaps

The authoring layer's outputs — generated code, generated configurations, and the routing decisions that produce them — are the most visible novel risk surface. Several failure modes warrant specific treatment.

Prompt injection at intake. The intake agent receives natural-language briefs from operators and structured requests from upstream production-management systems. A compromised upstream system, or an operator interface that includes uncontrolled content (chat history, third-party copy-paste, embedded metadata in attached assets), can introduce instructions intended to subvert the formal specification. The mitigation is structural: the intake operates against a constrained schema, every clarification answer is bound to the operator's authenticated identity, and any content outside the schema is dropped rather than absorbed. The clarification dialogue is recorded in full and is auditable, so an injection that successfully reaches the schema is at least visible after the fact.

Hallucinated APIs and non-conformant code. Code-generating models occasionally produce syntactically plausible but semantically incorrect references — calls to APIs that do not exist, misuse of timing primitives, incorrect MXL frame handling. The conformance validator catches the obvious cases. The deeper cases are caught by the functional and operational validator, which exercises the function against representative inputs in a staging environment that mirrors the production signal chain. The two-stage validation is not redundant: each stage is constructed to catch a class of defect the other will miss.

Gameable tests. If the generator has access to the conformance test suite during synthesis, it can produce code that passes the tests by construction without satisfying the underlying intent. The mitigation is to keep the conformance and functional test suites disjoint from the generator's training corpus and template inputs, and to validate against held-out test fixtures whose contents are not exposed to the generator. This is harder than it sounds: corpus contamination is easy to introduce inadvertently, and the discipline to maintain a clean separation is operational, not just technical.

Staging-versus-production drift. The functional validator runs in a staging environment that mirrors production, but mirrors are imperfect. Network conditions, GPU availability, NMOS topology, and the precise composition of upstream sources may differ subtly.

The mitigation is twofold: the staging environment is rebuilt from the production manifest at each validation pass rather than maintained as a long-running parallel deployment, and the runtime monitor in production is configured to detect functional anomalies that staging may have missed.

License violations in generated code. The generator may produce code that, in pattern or in incorporated snippet, infringes on a license that the facility is not entitled to. The dependency allowlist constrains import surfaces, and a pre-publication license-compliance check examines generated code for fingerprints of restricted-license sources, but no single tooling solution is yet authoritative. This is an active area of broadcast-community coordination.

5.3 Supply chain and provenance

Allowing AI-generated code into a live broadcast is, in supply-chain terms, a more disciplined version of allowing any third-party code in. The question is not whether SABF introduces a supply chain — it does — but whether the chain is auditable and constrained.

The allowlist as the first defense. The dependency allowlist (Section 3.2) is the boundary that defines what generated code can pull in.

It is governance-approved, version-pinned, and signed. The allowlist itself becomes a high-value target; it is held in a separate repository with restricted commit access and mandatory code review for any addition. Allowlist updates have their own change-management discipline, separate from the authoring layer's day-to-day operation.

Transitive dependencies. An allowlisted package may pull in further packages through its own dependency tree. The build pipeline resolves and pins the full transitive graph at allowlist-update time, not at synthesis time, so that a synthesized function's dependency surface is identical to what the security team approved. Floating versions are not permitted; lockfiles are signed.

Container base image integrity. Synthesized functions are built on a base image that is itself a curated, signed artifact rebuilt on a controlled cadence with a documented bill of materials. Base image vulnerabilities propagate to every synthesized function; the supply chain treats the base image as the most security-sensitive object in the registry, with a corresponding update discipline.

Signing and attestation chain. Every artifact produced by the authoring layer — generated source commit, container image, configuration, registry entry, validation result — is signed with credentials issued from a hardware-rooted key store. The chain of attestations is verifiable by any orchestrator instance, and a function whose attestation chain breaks at any point is refused at deployment. The attestation chain is also the foundation for post-event audit.

Repository integrity. The synthesized-functions repository is the auditable record of every function ever generated by the facility. It is treated as broadcast-critical infrastructure: write-only history, off-site replication, access logged independently of the authoring layer itself, and recovery procedures rehearsed on the same cadence as other production systems.

5.4 Learning-loop integrity

The corpus-promotion mechanism described in Section 3.2 — well-performing functions are added to the template corpus, failing ones are retained as encoded negative examples — is the most distinctive feedback loop in SABF. It is also the most subtle attack surface, because failures of this loop manifest slowly and are hard to attribute.

Corpus poisoning via single-broadcast luck. A function that performed well during a single broadcast may have done so for reasons that do not generalize: a benign data feed, a fortunate set of game states, an attentive operator who silently corrected the function's outputs without flagging anomalies. Promoting such a function biases future generation toward patterns that worked once and may not work again. The mitigation is to require a function to pass multiple production runs across diverse fixtures before promotion to the active corpus, and to track promoted functions' downstream performance — corpus entries that correlate with later failures are demoted.

Cost-model reward hacking. The library evaluator's routing decisions are made against a synthesis cost model that learns from prior runs. A subtle attack — or simply an artifact of generator behavior — could push the model toward systematic underestimation of synthesis cost in some function class, biasing the evaluator toward synthesis where library is the better choice.

The defense is twofold: cost estimates are stored with confidence intervals, and routing decisions are periodically replayed against actual measured costs to detect systematic bias.

Drift in generation patterns. As the corpus grows, the generator's outputs increasingly resemble its prior outputs. Beneficial drift (more reliable, more efficient code) is welcome; harmful drift (overfitting to past patterns at the expense of new requirements) is not. The defense is to maintain a holdout subset of the corpus that is never used for retrieval during generation but is used for measuring drift over time.

Audit and rollback of contaminated corpus. The corpus is versioned. A promoted function discovered to be harmful in retrospect can be removed; subsequent functions generated against the contaminated corpus can be flagged and re-validated. The cost of this is non-trivial — rolling back the corpus is more disruptive than rolling back a single function — and the discipline to do it cleanly must be established before it is needed.

5.5 Runtime and fallback

Even when generation, validation, and the supply chain are clean, the live broadcast environment introduces conditions that staging cannot fully reproduce. SABF's runtime defenses must address what happens when a deployed function misbehaves under conditions no validator anticipated.

Emergent behavior under unanticipated inputs. Generated code is most likely to misbehave on inputs that lie outside the distribution it was trained or templated against. A trajectory ribbon that handles a 60-game prior season cleanly may misbehave when a player's record contains a single game with a NaN scoring value, or when the game-clock feed pauses for an unusually long delay.

The runtime monitor watches for value-range and structural anomalies in inputs and outputs, and alerts before a misbehaving frame reaches the program signal whenever the anomaly pattern is recognized.

Cascading failures in the composition graph. In a composition graph, a misbehaving downstream function can stall an upstream one through backpressure, or vice versa. The mitigation is to design the runtime so that any function in a composition can be quarantined without halting the broadcast: the orchestrator reroutes signal around the quarantined function, optionally substituting a fallback (a library equivalent, a pass-through, or a configured failsafe). The quarantine itself takes a measurable fraction of a second and is visible at the program output as a single-frame artifact, but the broadcast continues.

AI-induced single points of failure. If the authoring layer is the only path to certain capabilities, its unavailability becomes a broadcast risk. The mitigation is the graceful-degradation property described in Section 3.3: the facility must remain operable as a conventional DMF facility against its existing function library if the authoring layer is unavailable. A SABF deployment that fails this test — that depends on the authoring layer for any production-critical capability — has been mis-architected.

Limits of fallback. Fallback to a library equivalent only works if a library equivalent exists. For genuinely novel synthesized functions, the fallback may be a pass-through (the function's contribution to the program output is simply removed for the duration of the incident).

Operators must be aware of which functions in a composition are fallback-clean (a library substitute exists) and which are fallback-degraded (only pass-through is available); this is recorded in the function's registry entry and surfaced in operator dashboards.

5.6 The human in the loop

SABF's autonomy is bounded. The authoring layer makes many decisions automatically, but several decisions remain explicitly with the human operator. The boundary between automated and operator-mediated decisions is not arbitrary, and is itself an object of policy that the facility must articulate explicitly rather than allowing it to drift over time.

Decisions that always require operator approval. Spec sign-off (the formal specification approved by the producer); preview approval (the visual ground truth for functional validation); deployment authorization (the operator confirms the function may enter the live signal chain); and recovery action during runtime (any quarantine, fallback, or cutaway that affects the program output is operator-initiated unless explicitly pre-authorized). These are the decisions whose consequences the operator must own by name.

Decisions that automate by default but escalate on signal. Cost-routing is automated normally and escalates to the operator when the cost model's confidence is low or when synthesis is unprecedented for the function class. Validation outcomes are automated for clean passes and escalate for any persistent failure across repair cycles. Security findings are automated for non-blocking advisories and escalate for any blocking finding. The escalation thresholds are tunable but the policy is explicit.

Skill atrophy. If operators routinely accept the authoring layer's recommendations without scrutiny, their ability to evaluate those recommendations decays. The mitigation is operational: a fraction of automated routings are flagged for review even when they pass; the dialogue history is accessible for audit; operator training programs include review of authoring-layer decisions as a deliberate exercise; and senior operators rotate through the authoring-layer review role on a defined cadence.

Accountability. When a synthesized function fails on air, accountability follows the chain of authorizations: the producer who approved the spec, the operator who approved deployment, the facility that maintains the authoring layer, and the agentic system whose outputs are signed. The provenance metadata makes this chain explicit. SABF does not eliminate human accountability; it documents it in a way that pre-SABF facilities did not need to.

Audit trails. The authoring layer produces a signed, immutable audit record for every action: the intent it received, the clarifications it asked, the configurations it produced, the validation results, the deployment metadata, the runtime metrics, and any post-event review outcomes. Audit data retention follows the facility's standard policy for production records, typically several years; tampering is detectable through the same attestation chain that secures the supply chain.

5.7 Standards, certification, and the broadcast community

SABF is a research direction, not a standard. The deployment patterns described in this paper depend on coordination across the broadcast community on several fronts that fall outside any single facility's control. The questions raised below are not blockers for early prototype work, but they are the work the community will need to undertake before SABF can be trusted at scale.

DMF specification extensions. The DMF specification today does not address authoring-layer outputs.

Specification work is needed to define how synthesized functions are declared and registered, what attestation metadata they carry, and how the signing and audit chains interface with the existing registry semantics. This is a JT-DMF working-group conversation, and one that will benefit from early input from facilities running SABF prototypes.

Conformance harness extensions. The current conformance harness assumes vendor-supplied functions tested individually. SABF's lifecycle requires harnesses that exercise generated code against held-out fixtures, that resist gaming through corpus separation, and that compose with functional validation rather than substituting for it. Extending conformance to cover this is non-trivial; it touches both the harness implementation and the conformance test fixture catalog.

Signing and attestation standards. Signed artifacts in the broadcast supply chain are not yet standardized in the way they are in the cloud-native software supply chain (Sigstore, in-toto, SLSA). Adapting equivalent practices to broadcast — signing functions, configurations, and registry entries with verifiable chains rooted in identifiable facility credentials — is open work. Cross-facility verifiability (the ability for one broadcaster to verify another's synthesized function before accepting it as a content contribution) is a longer-term aspiration.

Insurance, contracts, and legal liability. Broadcast insurance and content-licensing contracts assume failures attributable to either equipment or human action.

AI-generated code occupies an awkward middle ground that is not yet treated explicitly in standard contract language. Several insurance carriers and licensing bodies are beginning to engage with this question; facilities considering early SABF deployment should expect to negotiate bespoke language with both insurers and major rights-holders.

Vendor relationships. SABF's hybrid model preserves a substantial role for vendor-supplied functions, but it introduces a new commercial pattern — facilities synthesizing functions that, in a pre-SABF era, they would have licensed. The community will need to find sustainable arrangements that recognize both the cost-reduction case for synthesis and the risk-reduction case for vendor-supplied, certified components. Several plausible patterns exist (vendor-supplied templates and primitives; certified vendor-curated corpora; vendor-operated authoring layers); none is yet dominant. The vendor ecosystem is a stakeholder in the SABF conversation, not an obstacle to it.

5.8 Limits and open questions

Several questions are deliberately left open because the broadcast community has not yet had occasion to answer them at scale. They are flagged here so that early SABF deployments can collect the data needed to answer them.

— How often will human escalation be required in production?

The patterns described in 5.6 are designed to escalate freely; the engineering question is whether this escalation rate is workable for facility operations or whether it overwhelms the operator. Early SABF deployments will produce the data.

— How does the cost model perform on function classes with no precedent? The synthesis cost model relies on historical data; the first synthesis of any function class is necessarily a guess. The defense is conservative routing, but the long-term answer is operational experience and cross-facility data sharing.

— What attacks emerge in production? Most of the threats above are anticipatory. A live SABF deployment will surface attack patterns no threat model anticipated. The security model must therefore be operationally adaptive, not statically specified, and the broadcast community will benefit from sharing observed attacks much as the cloud-native community does today.

— What is the right interface between SABF and content production? The intake's clarification dialogue is one model; structured production-management integration is another; spec-by-template is a third. Each has different ergonomics, different risk profiles, and different demands on operator skill. A canonical answer will emerge from operational experience rather than from analysis alone.

— How does the trust model scale across facilities? The defenses described above protect a single facility.

Cross-facility trust — accepting another broadcaster's synthesized function in a multi-network production, or in a content-syndication arrangement — is a harder problem that the community has not yet addressed.

These are open questions, not open objections. They are the work the broadcast and AI communities will undertake as SABF moves from prototype to production. Sections 6 and 7 turn to the broader implications: for the broadcast technology industry and the production workforce in Section 6, and for the standards-and-research agenda the community will need to organize itself around in Section 7.

6. Implications for the Broadcast Industry and Workforce

This section steps back from architecture and asks how the SABF concept, if adopted, would reshape the broadcast industry's commercial structure and the work people do inside broadcast facilities. The treatment here is necessarily more speculative than the earlier sections: it forecasts rather than describes. Several of the dynamics outlined below depend on how quickly broadcasters adopt SABF, what shape the standards agenda in Section 7 takes, and how vendors choose to position their products in response. The aim is not to predict precisely, but to identify the directions that are coherent with the architecture, and the trade-offs that are likely to matter most.

6.1 The vendor ecosystem

Broadcast technology has long been organized around licensed products from a small number of incumbent vendors. A graphics suite, a switcher control surface, a playout server, an automation system — each is sold as a complete product, integrated by a systems integrator, and licensed for the facility's expected lifetime. SABF disrupts the most direct version of this commercial relationship: a synthesized function paired with an open-source primitive can replace a substantial fraction of what a monolithic licensed product was sold to do, particularly for one-off or bespoke requirements.

The implication is not that vendors disappear. Several roles open up where vendors are well-positioned to compete, and where their broadcast-domain expertise is especially valuable.

Curated, certified components. The generator depends on a curated allowlist of dependencies and a corpus of validated primitives. Vendors that ship high-quality, certified building blocks — broadcast-domain libraries with strong conformance, performance, and security guarantees — become inputs to the authoring layer rather than its competitors. The commercial relationship shifts from "buy our complete product" to "build against our certified components."

Authoring-layer products. Some facilities will build their own authoring layer; many will not.

There is room for vendors to offer authoring-layer products with broadcast-specific tuning, templates, and operational tooling. The commercial pattern resembles the cloud-platform market more than the traditional broadcast-product market: a smaller number of vendors offering integrated platforms that broadcasters configure and govern.

Domain-specific corpora. A facility that synthesizes graphics functions benefits from a corpus rich in broadcast-graphics precedents. Vendors with deep vertical expertise — sports graphics, news graphics, language-specific subtitle styling, regulated-content workflows — can offer curated corpora as a differentiated product.

Consulting and operational expertise. SABF deployment requires governance design, allowlist curation, security gating policies, and corpus stewardship. These are services rather than products, and vendors with operational broadcast experience are well-suited to provide them.

New entrants from adjacent markets. AI infrastructure companies, cloud platforms, and machine-learning toolchain vendors are all credible new entrants to the broadcast market through the authoring-layer entry point. Some will partner with incumbents; some will enter directly. The competitive landscape over the next several years is likely to be more fluid than the broadcast industry has experienced in some time.

6.2 The integrator and the broadcaster

The systems integrator's role in broadcast has historically combined deep product expertise across many vendors with the engineering judgment required to make heterogeneous equipment work as a coherent whole. SABF redistributes both halves of this role.

Some traditional integration work becomes simpler. The deployment pipeline for a synthesized function is the same regardless of what the function does; the integrator does not need bespoke knowledge of each new vendor's product to onboard new capabilities. Composition graphs, configurations, and monitoring are uniform across modes. For routine deployment, the integrator's role becomes thinner.

Other work becomes substantially more demanding. Designing the governance layer for a SABF deployment — escalation thresholds, allowlist policy, signing infrastructure, post-event review processes, operator training — requires expertise that integrators do not traditionally hold and that the broadcast industry has not historically needed. Integrators with AI-systems backgrounds, or that invest in building such expertise, are well-positioned for this work; those that focus only on traditional product integration are not.

For broadcasters themselves, the operational posture shifts. The cost structure changes from product licensing toward infrastructure, governance, and a smaller number of higher-skilled roles.

Capabilities expand: smaller broadcasters can produce graphics treatments that previously required licensing decisions and lead times; larger broadcasters can iterate on creative direction at a pace that was previously unrealistic. The risk profile changes too — less exposure to vendor-update incompatibility and more exposure to authoring-layer governance failures, as Section 5 outlined.

Two broader shifts are worth naming explicitly. First, SABF is likely to be quietly democratizing for smaller broadcasters and producers who could not previously afford the licensed graphics, audio, and compositing capabilities of large facilities. The same authoring layer that lets a regional sports network synthesize a custom lower-third lets a local-news operation produce treatments that were previously the preserve of network-scale productions. Second, differentiation among large broadcasters shifts from "we have the best vendor relationships" toward "we have the best authoring-layer governance and the best corpus." The competitive advantage moves from procurement to operations.

6.3 The workforce

SABF affects different roles differently. Some shift in emphasis; some shrink in scope; a few are likely to grow. The treatment below is specific about which is which, because vague reassurance does the people doing this work no favors.

Broadcast and IT systems engineers. The deepest impact is on the engineering roles that today integrate, maintain, and troubleshoot vendor stacks. Less of that work is needed in a SABF deployment; more is needed elsewhere. The engineers who thrive will move toward authoring-layer architecture, supply-chain integrity, validation harness design, signing infrastructure, and the difficult technical discipline of corpus stewardship. These are growth areas, not shrinking ones, but they require investment in skills the role does not traditionally develop.

Technical directors and master control operators. Live operation does not disappear; it shifts character. The routine configuration work — selecting templates, parameterizing functions, managing manual overrides — is increasingly handled by the authoring layer. What remains is the higher-leverage work: scrutinizing the layer's recommendations, deciding when to escalate, owning recovery actions during incidents, and exercising the kind of broadcast-trained judgment that is the ultimate safeguard against AI-generated defects on air. The role does not get easier; it gets more decision-dense.

Graphics designers and creatives. The role expands rather than contracts. Manual template construction and parameter twiddling — the unloved part of graphics work — diminishes. Spec curation, preview review, and creative direction across many synthesized variants — the part of the work designers usually wish they had more time for — grows.

A designer who could produce one custom treatment per week now reasonably produces several per day, and is asked to make creative judgments at a higher rate. The skill set shifts toward design language and toward understanding what an authoring layer can be asked to do.

Producers. The producer's role is least affected in shape but substantially affected in tempo. The same brief that previously triggered a license decision and a multi-day production cycle now triggers a clarification dialogue and a preview within minutes. Producers iterate more, see results faster, and make creative decisions on a tighter loop.

Systems integrators. Covered in 6.2.

6.4 New roles, new skills

Several roles emerge in a SABF deployment that did not exist in pre-SABF facilities. None is exotic; all are recognizable from analogous practices in cloud-native software and AI-systems operations.

Authoring-layer governance specialist. Owns the policy surface of the authoring layer: allowlist curation,

escalation thresholds, signing-credential lifecycle, security-audit pipeline configuration. Sits at the intersection of broadcast operations, software supply-chain security, and AI-systems risk.

Synthesis output reviewer. Provides the deliberate human scrutiny of the layer's outputs that the threat model in Section 5 depends on. The role rotates to prevent skill atrophy and is treated as a senior responsibility rather than a junior one.

Corpus curator. Stewards the template corpus: monitors drift, identifies promotion candidates, makes demotion decisions when corpus entries correlate with downstream failures. Combines broadcast-domain judgment with the data discipline of an analytics team.

AI-broadcast risk officer. Owns the operational risk of the authoring layer at the facility level. Carries the kinds of responsibilities a risk officer carries elsewhere — incident review, regulatory liaison, cross-functional escalation — translated into the broadcast context.

The skill set across these roles overlaps with conventional broadcast engineering in some places and with cloud-native software, machine-learning operations, and AI safety practice in others. The hybrid is unfamiliar to both fields, and a pipeline for training people into it does not yet exist at scale. Universities, professional bodies, and broadcaster training programs will need to adapt; some early movers in each are doing so already, and the broadcast industry's conferences and trade publications are an obvious channel for disseminating practice as it matures.

6.5 Transition: an honest accounting

Some roles will shrink. The trajectory for routine vendor-product integration, manual template configuration, and basic graphics operation work points downward over the years that SABF takes hold. Pretending otherwise would be condescending; people in those roles can read the architecture as well as anyone. The relevant questions are about pace, mitigation, and what the industry collectively does to support workforce transition.

Several observations bear on those questions. The transition will be slow rather than sudden. Broadcast facilities replace systems on year-to-decade cycles, and SABF deployment is constrained by standards work, governance maturity, and operational confidence. The earliest large-scale deployments are not imminent. The skills that grow in value are reachable from the skills that shrink: a master control operator with deep broadcast judgment is a strong candidate to become a synthesis output reviewer; a systems engineer who built vendor integrations is a strong candidate to design a signing infrastructure. The transition is one of role evolution as much as displacement, and the industry's history of similar transitions suggests that careful re-skilling is both possible and effective when invested in.

Mitigation is not automatic. Employers, industry bodies, and educational institutions all have a part to play in providing re-skilling pathways, accessible training, and

recognition of the new role categories. The broadcast industry has navigated transitions before — the SDI-to-IP move, the cloud transition, the shift from tape to file-based workflows — and has done well in some cases and badly in others. The variable is not whether change happens but whether the workforce is given the time and resources to move with it. The case for proactive investment in workforce transition is straightforward and worth making explicitly: it costs less than the alternative, and it preserves capabilities the industry will continue to need.

The next section turns from these implications to the standards-and-research agenda the broadcast and AI communities will need to organize themselves around if SABF is to mature beyond the prototype stage.

7. A Research and Standards Agenda

The earlier sections describe what SABF is, how it would be built, what could go wrong with it, and how the broadcast industry and workforce reshape if it is adopted. This section addresses the question implicit in all of those: what work, by whom, must happen for SABF to mature from prototype to production-ready? The agenda is large enough that no single organization can address it. It is also achievable, provided the broadcast and AI communities organize themselves around it deliberately rather than waiting for a vendor or a single broadcaster to drive it.

The agenda is organized below into four categories — research, standards, infrastructure, and governance — followed by a discussion of how the community might coordinate the effort and a phased roadmap for sequencing it. The section closes with brief reflections on the SABF concept's broader significance.

7.1 Research questions

A set of empirical and scientific questions need answering before SABF can be deployed at scale with confidence. Most of them require live deployment data; some can be addressed in research settings. The questions below pick up the open issues raised throughout the paper, particularly in Section 5.8, and propose how the community might begin to make progress on each.

7.2 Standards work

Several standards extensions are required to support production SABF deployment. These are conventional broadcast-standards-body work in the JT-DMF, AMWA, and SMPTE traditions, with significant new content driven by the authoring-layer's needs. Section 5.7 introduced these informally; the table below organizes them as actionable standards items.

7.3 Infrastructure and reference implementations

Some of the agenda falls between research and standards — it is implementation rather than specification, but foundational enough that the community as a whole benefits when it is open and shared rather than each facility building it independently.

Open-source authoring-layer reference implementation. A reference implementation of the authoring-layer components — intake, library evaluator, code generator, configurator, validation harnesses, packager, runtime monitor — provides a foundation for vendor and broadcaster deployments. The reference need not be production-ready out of the box; it must be understandable, extensible, and exercised through the conformance test suite.

Open-source MXL extensions for SABF. The MXL data plane already has an open-source reference. Extensions specific to SABF — function registration with provenance, attestation hooks, runtime monitor interfaces — should be developed in the same project rather than as proprietary forks.

Conformance test corpora that resist gaming. The held-out test fixtures discussed in Section 5.2 require a curated corpus that is itself a community asset. Stewardship, rotation policy, and access control for the held-out corpus are infrastructure-level concerns that no single facility should own alone.

Provenance tooling. Generating, signing, verifying, and auditing the provenance metadata that runs through the entire SABF lifecycle is non-trivial tooling. A common open-source toolchain — analogous to the cloud-native software supply-chain tooling — would benefit every facility and would harden the cross-facility trust story considerably.

Interoperability test harnesses. Cross-facility trust depends on the ability to verify another facility's synthesized function against a common test surface. Reference harnesses, including representative inputs and expected behaviors, are required before cross-facility patterns can mature.

7.4 Operational and governance work

Some of the agenda is neither research nor specification but coordination among broadcasters, vendors, and adjacent communities. The work is no less important for being non-technical, and in several cases it is the harder kind of work because it requires collective action where individual incentives may pull in different directions.

Cross-broadcaster attack-pattern sharing. Threats observed in production cannot remain proprietary information; the community is collectively safer when they are shared, in much the way that cloud-native and financial-services communities share threat intelligence today. A neutral coordinating body, perhaps under EBU or SMPTE auspices, is the obvious vehicle and should be stood up early rather than after the first significant incident.

Insurance and contract framework development. AI-generated content failures occupy an awkward middle ground between equipment failure and human action. Insurance carriers and content-licensing bodies are beginning to engage; the broadcast community needs a coherent voice in those conversations rather than each broadcaster negotiating bespoke terms in isolation. The contract reference language tabled in 7.2 is the technical artifact; the broader negotiation is a governance task.

Vendor-broadcaster commercial pattern negotiation. The hybrid model preserves a substantial vendor role but shifts the commercial relationship significantly. Sustainable arrangements that recognize both the cost-reduction case for synthesis and the risk-reduction case for vendor-supplied components are not yet settled. This conversation will play out partly in industry forums and partly in commercial negotiation; both should be informed by community-level analysis rather than left to bilateral bargaining alone.

Workforce transition programs. The honest accounting in Section 6.5 implies real obligations on employers, industry bodies, and educational institutions. Coordinated re-skilling programs, recognized credentials for the new role categories, and accessible training are infrastructure for the workforce transition. The cost of doing this work is dwarfed by the cost of not doing it.

Cross-facility audit and trust frameworks. As multi-network productions and content syndication encounter SABF, there will be a need for trust frameworks that allow one

broadcaster's signed, validated synthesized function to be accepted by another broadcaster's pipeline. This is partly standards work, covered in 7.2, and partly governance work — defining who issues trust assertions, who verifies them, and who is liable when trust is misplaced.

7.5 How the community should organize the agenda

The agenda is too large for any single organization. It is also too coherent to be parceled out without coordination. The model that has worked elsewhere — most notably for cloud-native software in the CNCF and for software supply-chain security in the OpenSSF — suggests several patterns the broadcast community might adopt.

Working groups under existing bodies. The natural homes for most of the standards work already exist: JT-DMF for DMF extensions, EBU and AMWA for specific specifications, SMPTE for cross-vendor coordination. These bodies need to add SABF-specific working groups rather than absorb the work into existing ones, because the topic spans broadcast and AI in a way the existing groups are not staffed for.

A new coordination forum. Some of the agenda — particularly cross-broadcaster threat sharing, attestation standards, and infrastructure stewardship — does not fit neatly under any existing body. A dedicated coordination forum, modeled on the OpenSSF, with members drawn from broadcasters, vendors, AI infrastructure companies, and academic groups, is a plausible structure.

Such a forum would not displace existing standards bodies but would coordinate across them and host the work that falls between them.

Vendor and broadcaster roles. The agenda should not be vendor-led, because the commercial pattern is in flux and vendor-led standards work would naturally privilege incumbents' positions. It should not be broadcaster-led alone either, because broadcasters lack the AI-systems expertise that several agenda items require. The healthy pattern is broadcaster-led on operational and governance items, vendor-led on product and component standards, AI-community-led on the safety and security agenda, and joint coordination on the harder integrative items.

Open source as the default. Reference implementations, conformance test corpora, provenance tooling, and audit harnesses should be open-source by default. The supply-chain integrity arguments in Section 5.3 apply at the community level too: closed implementations of foundational tooling concentrate trust in their owners and create choke points the broadcast community has not historically tolerated.

7.6 A phased roadmap

The agenda above is achievable on a credible timeframe, but only if the work is sequenced. The roadmap below is a plausible sequencing rather than a definitive one; it is offered as a starting point for community discussion.

7.7 Closing reflections

This paper has argued that the SABF concept is a coherent extension of the Dynamic Media Facility, that it is achievable with technologies that exist today, and that it raises a set of engineering, operational, and community questions that the broadcast industry has not yet had to answer collectively. The questions are non-trivial; the answers are not yet clear; and the agenda outlined above is the work the community will need to undertake to answer them.

It is worth being honest about the broader stakes. Live broadcast occupies a particular place in public life. Live sports, live news, live cultural events — these are moments when large numbers of people share a common experience in real time, and the technology that produces those moments has historically been constructed with a deliberate margin of conservatism. SABF asks the community to admit a substantially more dynamic class of system into that environment, and the case for doing so rests on real benefits — democratization of capability for smaller broadcasters, faster creative iteration for larger ones, a more flexible response to the production demands of an increasingly diverse media landscape — but those benefits do not come for free. The discipline required to deploy SABF responsibly is substantial.

The cost of getting it wrong, in a domain where defects are visible to millions in real time, is not abstract.

The paper has tried to be clear about both sides of that ledger. SABF is worth doing; it is not casual to do well. The agenda above is the path the community will need to walk together. There is no organization that can do this alone, and there is no need to wait for one. The research, the standards work, the reference implementations, and the governance frameworks can begin in parallel as soon as the community organizes itself to begin them. Several of the relevant working groups already exist; several of the relevant communities already overlap. The broadcast and AI communities have the people, the institutions, and the technical foundation to do this work.

The remaining question is whether the will to do it crystallizes around a shared sense that the work is worth doing. We believe it is. We invite the community to join the conversation.

— end of draft —

References and Resources

This paper is a conceptual draft and does not carry inline citations to specific publications. The list below collects the real-world frameworks, standards, open-source projects, and industry bodies the paper engages with by name, organized as a starting point for follow-up reading. URLs are provided where the project or organization maintains a stable canonical reference.

Broadcast Standards and Specifications

SMPTE ST 2110 — Suite of standards for professional media over managed IP networks. Includes ST 2110-10 (system, timing, and definitions), ST 2110-20 (uncompressed video), ST 2110-21 (traffic shaping), ST 2110-30 (uncompressed audio), and ST 2110-40 (ancillary data). Published by the Society of Motion Picture and Television Engineers. smpte.org

SMPTE ST 2059 — Profile of IEEE 1588 Precision Time Protocol for use in professional broadcast applications. Provides the timing reference that ST 2110 streams synchronize to. smpte.org

AMWA NMOS — Networked Media Open Specifications, a family of open specifications for IP-based broadcast media management. Key specifications include IS-04 (Discovery and Registration), IS-05 (Connection Management), IS-07 (Event and Tally), and IS-08 (Audio Channel Mapping). amwa.tv/nmos

EBU Dynamic Media Facility and Related Work

EBU Dynamic Media Facility (DMF) — European Broadcasting Union reference architecture for software-defined live production. Defines a layered model with containerized media functions, a standardized data plane, and orchestration over Kubernetes. Published as a series of technical reports through the EBU. tech.ebu.ch

Media eXchange Layer (MXL) — Open-source data-plane library and runtime for the DMF architecture. Allows containerized media functions to exchange uncompressed video, audio, ancillary data, and timing in a standardized form. github.com/ebu / tech.ebu.ch/mxl

JT-DMF Working Group — Joint EBU – AMWA working group coordinating standards and specification work for the Dynamic Media Facility. The natural home for many of the DMF specification extensions discussed in Sections 5 and 7 of this paper. tech.ebu.ch and amwa.tv

EBU Technology and Innovation publications — Ongoing series of technical reports, recommendations, and white papers from the EBU's technology arm. Primary venue for DMF documentation, MXL reference materials, and broadcast-systems guidance. tech.ebu.ch

Software Supply-Chain Security and Integrity

SLSA (Supply-chain Levels for Software Artifacts) — Framework for software supply-chain integrity, defining graduated levels of provenance, build integrity, and source integrity. Section 5.3 and 7.2 of this paper draw on SLSA's framing for the broadcast supply chain. slsa.dev

Sigstore — Open-source code-signing infrastructure for the software supply chain. Provides keyless signing, transparency logs, and verifiable build provenance. The signing-and-attestation model proposed in Section 5.3 is informed by Sigstore's approach. sigstore.dev

in-toto — Framework for end-to-end software supply-chain integrity. Defines a metadata format and verification model for tracking each step from source to deployment. Hosted as a CNCF project. in-toto.io

Open Source Security Foundation (OpenSSF) — Linux Foundation initiative coordinating cross-industry work on software supply-chain security, vulnerability disclosure, and developer security practice. Cited in Section 7.5 as a model for the kind of cross-industry coordination SABF will need. openssf.org

Cloud-Native and Container Infrastructure

Kubernetes — Container orchestration platform underlying the compute-fabric layer of the DMF architecture. Hosted by the CNCF; the de facto standard for container workload orchestration. kubernetes.io

Cloud Native Computing Foundation (CNCF) — Linux Foundation umbrella organization for cloud-native open-source projects. Cited in Section 7.5 as a model for community organization around shared infrastructure. cncf.io

Open Container Initiative (OCI) — Industry standards for container formats and runtime, providing the image and runtime specifications used by Kubernetes-based deployments. opencontainers.org

AI Systems, Agents, and Machine Learning

Large Language Models for Code Generation — Active area of AI research and product development. Code-generating LLMs are the technical foundation for the synthesis mode described in Section 3 of this paper. Capabilities and tooling continue to evolve rapidly across vendors including Anthropic, OpenAI, Google, and others.

Agentic AI Systems — Class of AI systems that execute multi-step workflows with tool use and decision-making, rather than operating purely as conversational interfaces. The authoring layer described in Section 3 is constructed as an agentic system in this sense.

MLCommons — Open engineering consortium working on benchmarks and best practices for machine learning.

Cited in Section 7.5 as part of the precedent for cross-industry AI coordination forums. mlcommons.org

AI Safety and Evaluation Practice — Body of work, in active development across academic and industry research, on evaluating and constraining AI systems for production deployment. The threat model in Section 5 draws on this practice generally rather than on any single source.

Industry Organizations

European Broadcasting Union (EBU) — Alliance of public-service media organizations across Europe. Custodian of the DMF reference architecture, MXL project, and the Tech Report series cited throughout this paper. ebu.ch

Advanced Media Workflow Association (AMWA) — Trade association developing open specifications for IP-based broadcast media, including the NMOS family. Co-host of the JT-DMF working group with EBU. amwa.tv

Society of Motion Picture and Television Engineers (SMPTE) — Standards body for the motion picture and television industries. Custodian of ST 2110, ST 2059, and many other foundational broadcast specifications. smpte.org

International Broadcasting Convention (IBC) — Annual industry conference and trade show held in Amsterdam, and an associated publishing and standards conversation venue. A natural forum for SABF-related industry discussion. ibc.org

National Association of Broadcasters (NAB) — United States broadcast industry trade association. Hosts the annual NAB Show, a parallel forum to IBC for industry discussion and standards conversation. nab.org

On the Use of This List

The references above are organized for follow-up reading rather than as evidentiary citations. Where the paper makes a specific claim about an existing standard or framework, the corresponding entry above is the canonical place to verify the claim against the current published version of that standard or framework. Where the paper makes an original argument or projects forward (Sections 5 through 7 in particular), the entries above provide context for the argument rather than evidence for it.

A future, citation-bearing version of this paper would benefit from inline references to specific EBU technical reports, SMPTE standards revisions, and academic publications on agentic AI systems and code-generating models. Such references should be added with care to avoid the common error of citing works whose specific titles or details cannot be precisely confirmed.