Editing QC Items (data model 2026-04)
QC Items are being republished so that they follow the EBU QC data model 2026-04. This page explains what that changes in the Item editor.
Two data models, two API generations
Every version of an Item records the data model it was made under. The Item page shows it as a label next to the version number:
- Legacy (pre-2026-04): all versions that existed before the switch. API v1 and v2 serve these versions only.
- EBU QC data model 2026-04: every version created since. API v3 serves these versions only.
A new version of an older Item is always a 2026-04 version. The label is set once and never changes.
Republishing an Item for the 2026-04 data model counts as a substantial change, so it gets a new MAJOR version number (see Versioning).
Colour key
Some fields exist in only one of the two API generations. The edit and show pages tint them, with a small text label, and show a colour key above the Inputs and Outputs:
- Light blue, label "v3": only in API v3 (data model 2026-04). These are the CheckResult definition, the Analysis method and the four positioning flags (Has locator (temporal), Has locator (spatial), Has track, Has wrapper location).
- Grey, label "v1/v2 only": only for API v1/v2. This is the old Locator. It is derived from the flags and cannot be edited.
- No tint: used by both.
On a legacy version, the v3-only fields read "not in this version".
These tints are permanent. The red and yellow outlines that the Item checks put on a field are different: they appear only while a check has something to say. A mandatory field has no tint of its own; it is red while it is empty.
Usable as: Check and Report
Usable as (UsableAs in the data model and in all API versions: v1, v2 and v3) says whether an Item can be used as a check, in reports, or both. It is not a field you fill in: it follows from the In Checks and In Reports settings of the Inputs and Outputs.
- Check: at least one Input or Output has In Checks set to something other than "not applicable".
- Report: at least one Input or Output has In Reports set to something other than "not applicable".
- Neither: every row is "not applicable" in both columns.
The edit page shows the result at the top of the basic values, with the same Check and Report badges as the Item page. It updates while you edit: when you change In Checks or In Reports, and when you add or delete an Input or Output. A new row starts as "optional" in both columns, so adding one turns on both badges until you change it.
To change what an Item is usable as, change those columns. When the Item becomes usable as a check, the CheckResult definition becomes required; the form marks it as required straight away, and saving checks it.
CheckResult definition
The CheckResult definition describes what a check reports when it finds a problem. It is needed for every Item that is usable as a check.
When such an Item has no CheckResult definition yet, the edit form pre-fills a suggestion that starts with [TO BE VERIFIED]. The suggestion is the Description of the Item's old "CheckResult" Output when there is one, otherwise a generic sentence. Only the form is pre-filled; published versions are not changed.
Read the suggestion, correct it where needed, and remove "[TO BE VERIFIED]". As long as the text still starts with that marker, the version cannot move to Publication ready or Published.
An Item that is not usable as a check has no CheckResult definition in the data model. If you remove the last check setting, an old text stays saved but is hidden, and API v3 leaves it out.
Analysis method
The optional Analysis method says how the test is meant to be implemented: readout, measurement, or readout and measurement (see What is implicit for all QC Items). It is only in API v3. Leave it empty when it is not known or not prescribed.
When it is empty, the edit form pre-fills it from the Layer: wrapper and bitstream give readout, baseband gives measurement, crosscheck gives readout and measurement. Other layers get no suggestion. Only the form is pre-filled; published versions are not changed.
A pre-filled value is marked [TO BE VERIFIED] below the field, and Item checks lists it under To review. Check it, then click Confirm there, or choose another value. A value other than the suggestion counts as checked.
Positioning flags (replacing Locator)
API v1/v2 had one Locator flag per Input or Output. The 2026-04 data model replaces it with four independent flags:
- Has locator (temporal): the value refers to a time position or segment in the content.
- Has locator (spatial): the value refers to a position in the picture.
- Has track: the value refers to a specific track.
- Has wrapper location: the value refers to a location in the file wrapper.
The old Locator is now derived: it is on when Has locator (temporal) or Has locator (spatial) is ticked. A child no longer inherits it from its parent; each row has its own flags.
For a row that had Locator on but none of the new flags, the edit form pre-ticks Has locator (temporal), because most old Locators are time segments, and shows the hint "Pre-ticked from the old Locator: verify." Check it, and tick Has locator (spatial) instead (or as well) for a position in the picture. If you untick both locator flags, the old Locator is cleared when you save.
Item checks
The Item checks tell you what still needs attention under the 2026-04 data model, before you save. They show in three places, always with the same words:
- On the field. A field with a finding gets a coloured outline, its title takes the colour, and the message appears below it. Red is a blocking finding, yellow is a finding to review. If a field has both, red wins. A finding about an Input or Output colours that cell of the row. A finding about a whole part of the page colours that part: the Usable as box, or the Inputs, Outputs, References or Examples card. A message that says "Name is empty." replaces the browser's own "Please fill in this field" bubble, which the edit form does not use.
- In the Item checks panel. The Item checks button at the bottom right has three counters: red for blocking findings, orange for findings to review, green for checks that pass. Open it to read them. It updates as you type, and lists the findings top-down in the order of the page.
- In the "Not saved" list. When a save is rejected, the page reloads with a red list at the top, one line per problem, each linking to its field. Every problem is listed once. The list follows your edits: a line you have changed is struck through, and one whose row you deleted disappears. The server still decides on the next save.
The panel has three tabs:
- Blocking (red): must be fixed. What it stops depends on the check; the table below says which.
- To review (yellow): worth a look. Fix the finding, or click Confirm if it is intended. Confirmations are saved with the version and carried to later versions. A confirmed finding moves to OK and is no longer coloured; Undo takes the confirmation back.
- OK: the checks that pass, and the findings you confirmed.
A check only runs when it applies. Until then it is listed nowhere, not even as OK.
What each check does
"Stops every save" means the Item cannot be saved at all, in any status, until the finding is fixed. "Stops tech review and later" means you can still save in Drafting, but the Item cannot move to Tech review, Group review, Publication ready or Published. "Publication ready and Published only" leaves Drafting, Tech review and Group review free and stops only those last two. Findings of the last two kinds appear in the "Not saved" list when you try that move. The words in the last column are what the panel, the field and the list say.
Blocking checks (red)
| Check | Stops | Colours | Says |
|---|---|---|---|
| EBU QC ID is present, valid and unique | every save | the EBU QC ID field | "The EBU QC ID is empty." / "The EBU QC ID has more than 6 characters." / "The EBU QC ID may only contain the characters 0-9, a-z, A-Z and “-”." / "The EBU QC ID “X” is already used by another Item." |
| Layer, Category and Card style template are chosen | every save | the field | "Layer is not chosen." |
| Name is filled | every save | Name | "Name is empty." |
| Definition, Card title, Card lines 1 to 4 and Card image are filled | tech review and later | the field | "Definition is empty." / "Card line 3 is empty." / "Card image is missing." |
| CheckResult definition is filled for a check | every save | the CheckResult definition | "The Item is usable as a check (an Input/Output is used in checks) but the CheckResult definition is empty." |
| CheckResult definition is no longer a suggestion | tech review and later | the CheckResult definition | "The CheckResult definition is a suggestion: verify it and remove “[TO BE VERIFIED]”." |
| The Item is usable as a check or a report | tech review and later | the Usable as box | "The Item is usable as neither a check nor a report: set In Checks or In Reports on an Input/Output, or fill the CheckResult definition." |
| Every Input and Output has a valid, unique data model name | tech review and later | the name cell of the row | "Output #1 has no data model name." and the variants for a reserved, invalid or duplicate name |
| Every Input and Output that needs a value has a Type | tech review and later | the Type cell | "Output #1 needs a value but has no Type." |
| Every Input and Output has a Description | tech review and later | the Description cell | "Output #1 has no Description." |
| In Checks and In Reports are consistent | tech review and later | the cell of the row, or the Outputs card | "Output #1: In Checks and In Reports cannot both be “not applicable” (Annex C.4)." |
| Inputs and Outputs are structured as Annex C.4 requires | tech review and later | the cell of the row | "Output #1 has no Value, so it needs a locator flag or a track (Annex C.4, Table 16)." |
An unnamed row is called "Input #1" or "Output #1" by its place among the rows that are left, so deleting the first row renumbers the rest.
Checks to review (yellow) never stop anything.
| Check | Colours | Says |
|---|---|---|
| The Item has a Description (optional in the data model) | Description | "The Item has no Description." |
| The card lines are all different | each field that holds the repeated text | "Card text “…” appears more than once." |
The text follows the catalogue style: Definition and Descriptions start with a capital letter, the Definition ends with a full stop, no double spaces, data model names in PascalCase (for example ProgrammeCount) |
the text field or row cell | "Definition should start with a capital letter." / "Name contains double spaces." |
| Ranges spell "infinity" in lower case | the Range cell | "Output #1 range “…”: write “infinity” (lower case)." |
| No placeholder Unit such as "-" | the Unit cell | "Output #1 uses “-” as Unit. That is a placeholder, not a unit…" |
| Type, Unit and Range are official parameters | the cell | "Output #1 uses the unofficial Type “…”." |
| The letter at the end of the EBU QC ID matches the Layer (W, F, B or X, see Layers), and the Layer is not a retired one | the EBU QC ID and the Layer, or the Layer alone when it is retired | "EBU QC ID ends in W but Layer is Bitstream (expected F)." |
| At least one Input or Output sets a positioning flag, or you confirmed that none applies | the Outputs card (the Inputs card when there are no Outputs) | "No Input/Output sets a v3 locator flag…" |
| The Analysis method suggested from the Layer was confirmed or changed. An empty one is listed too when the Layer suggests a value | Analysis method | "The Analysis method is empty; the Layer suggests “…”." |
| The Item has no open Editor discussions. Each open one is listed. A confirmation lapses when a discussion is opened, reopened or gets a new reply, as each may hold new information | the checklist only (not a field) | "Open Editor discussion “…”: read it, then confirm that it is handled, or close it." |
| The Item has References | the References card | "The Item has no References." / "A newer version of the reference “…” is in the list. Save the Item to take it over." |
| References are picked from the reference list | the References card | "The reference “…” is typed in, not picked from the reference list. Pick it from the list if it is there; otherwise add it to the list." |
| References are official (an Item uses a reference from the reference list) | the References card | "The reference “…” is not official yet. A workflow manager has to make it official." |
| The Item has Examples (text or image) | the Text examples and Image examples cards | "The Item has no Examples." |
The Item check rules page
Item check rules, under Items > Item Validators in the menu, lists every check above, in the same order, with where it applies, whether it stops a save or a status move, what it colours, and whether it is switched on. Every editor can read it. Workflow Managers can switch a check off and on again, for all editors, for example while the catalogue is being brought into line. A check marked "always on" repeats an error that the save raises anyway, so it cannot be switched off. Switching a rule off hides its findings, its colours and its place in the panel.
EBU QC ID and Layer
The letter at the end of an EBU QC ID follows the Item's Layer: W for Wrapper, F for Bitstream, B for Baseband and X for X-check. When you create an Item, the suggestion below the EBU QC ID field uses the letter of the Layer you chose. See Layers for the letters, and why Bitstream uses F.
The Layer list only offers the four Layers of the data model. An Item on a retired Layer ("Programme layout", "Not present") keeps it until you choose another one.
Rules for Inputs and Outputs
From Tech review onward, saving checks the Inputs and Outputs against Annex C.4 of the 2026-04 data model. An error is shown on the row concerned:
- The data model name is unique (ignoring upper and lower case) among all Inputs, children included, and separately among all Outputs.
- The data model name contains only letters, digits and "-", and does not start with "-" or "PRIVATE" (those are reserved for vendor-specific Inputs and Outputs).
- The data model name is not the name of an attribute of the data model, for example CheckResult.
- The Description is filled.
- In Checks and In Reports are not both "not applicable". A child is "not applicable" wherever its parent is.
- A top-level Input or Output without a Type sets at least one positioning flag. A top-level Input without a Type also has one or more children.
- A child Input has a Type. A child Output has a Type or sets a positioning flag.
- An Item usable in reports has at least one top-level Output with In Reports set to required or optional. If it has only one, that one is required.
These apply on every save, whatever the status:
- A row with children has no value of its own, and there is only one level of nesting.
- When Needs a value is unticked, the row's value fields are hidden, and its Default value and Alias are cleared on saving.
Unit, Representation and Range are optional
In the 2026-04 data model, Unit, Representation and Range are optional. The editor accepts them empty, also for publication; each picker has a clear button (for the Unit, "No unit"). A value you do enter must still be allowed by the Type, and a Range must be official from review onward.
A count has no unit: leave the Unit empty rather than choosing "-".
Definition and Description
Both are free text, and both are about what the test is, never about how to implement it. They do different jobs, so keep them apart: mixing them is what makes an Item hard to read. In the edit form, both fields have an info symbol: hover over it for a quick help, and click it to come to this section.
- Definition is a concise statement of what the test is and what it checks, including the key concepts. It is required from Tech review onward, and it is the text the test is judged against. Do not go into implementation details. How to word it is in the Editor guidelines. It ends with a full stop. Example: "Used in Checks, the system shall report the presence of black bars in the video essence with size and duration beyond the specified input thresholds."
- Description helps the reader understand what the test is about. It gives context, especially why the test is useful in practice, and explains the situation it applies to. It is optional, and it is not a second Definition: nothing the test depends on may only be written here, and it does not describe how to implement the test. Example: "Images that do not fill the intended screen (e.g. 4:3 or 16:9). A movie designed for a cinema screen will often have black bars at the top and bottom when shown on a 16:9 television."
Rule of thumb: if it changes what a conforming system must do, it belongs in the Definition. If it only helps a person understand why and when, it belongs in the Description. How a system should do it belongs in neither; the Analysis method says whether the test is a readout or a measurement, and References point to the specifications.
Further information that complements the Definition goes in the Remarks, which are published. Editor remarks are for editors only: they are not shown to the public and are not in the API. The Description of an Input or Output is a different field: it describes that one parameter, not the Item.
Both fields accept the reference syntax.
Card lines
The card shows, below the test name, four lines (Line 1 to Line 4). Together with the card title they summarise the test at a glance, so a reader can pick the right card from a set. Each line has its own purpose. In the edit form, the card title and each of the four lines have an info symbol: hover over it for a quick help, and click it to come to this section.
| Line | Says | Example |
|---|---|---|
| 1 | What is tested | Audio peak level |
| 2 | More details about the test; can be keywords or a related standard | EBU R 128 |
| 3 | What is considered a pass | True peak at or below -1 dBTP |
| 4 | What is reported | Time intervals of exceedance |
The examples only illustrate the idea.
Each line is one short line of plain text: there is little room, and text that is too long is cut off on the card (the full text is shown when you hover over it).
- Ideally the four lines all differ, so each says something new. If two are the same, the Item checks panel shows a finding to review; it never blocks saving, and you can confirm it when the repetition is intended.
- All four are required from Tech review onward, together with the card title and the card image.
- Type the card title in normal case, for example "Audio peak level". Do not write it in capitals: the card layout shows it in capitals by itself.
- Keep the lines short. Details belong in the Definition and Description.
See also
- Parameters: Types, Representations, Units and Ranges
- Parent field
- QC Item Status
- API and the API validators