GateTrue

What each generator documents about marking its output

Platform label: the mark the destination adds

A platform label is applied by the destination a file is published to, not by the tool that generated it. It is outside every column here, and it is the reason one vendor argues for switching its own mark off. As of 2026-09-22.

Two sources of marking, and where the register stopsA mark applied by the generating tool is decided before delivery, by a plan or a setting, and is documented on the vendor's own pages. A label applied by the destination is decided afterwards by another party's policy, and nothing in this register records one.The generating toolA plan, a setting or a parameterDecided before deliveryRecorded in this register, from vendorpagesThe destinationAn upload policy, elsewhereDecided after deliveryOutside every column hereWhat a viewer eventually sees on the frameTwo unknowns, and this register addresses one
Fig. 1 One vendor argues for switching its own mark off precisely because the second kind exists.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termPlatform label
What it namesA label applied by the site a file is published to
What it is notAnything the generating tool wrote or burned in
Where the register uses itAs the boundary of what the register records

Inclusion rule. Words this site uses in a narrow sense, where the ordinary sense would lead a reader to misread a cell. No vendor statement appears on this page. Order. Fixed order: what the word names, what it excludes, then where it is used here.

1A different actor, and therefore a different record

Everything in this register is read from the pages of companies that generate video. A destination that labels uploads is a separate actor with separate documentation, separate policies and a separate rate of change. Mixing the two into one table would produce rows whose values come from parties with no relationship to each other.

So the register stops at the point the file leaves the tool. That boundary is arbitrary in the sense that any boundary is, and it is the one that keeps every cell attributable to a single company's own published page, which is the site's only standard of evidence.

2Why it still appears in the reasoning

One vendor argues for allowing its own mark to be switched off precisely because a destination may add a label: two labels on one frame is the stated case. That is the only place in this register where a marking decision is justified by something happening after delivery, and it is an operational argument rather than a commercial one.

It also explains why a reader cannot infer disclosure from this register alone. A file delivered clean may still be labelled where it is published, and a file delivered marked may be labelled twice. What the register records is what the tool did, which is one input to that outcome and not the outcome.

3What a publisher should take from the distinction

Two sources of marking behave differently. A mark from the tool is decided before delivery, by a plan or a setting, and can be planned for. A label from a destination is decided after, by somebody else's policy, and can change between one upload and the next without anybody being told.

A workflow that depends on the appearance of a final frame therefore has two unknowns and this register addresses one of them. The readings say which vendors publish enough to plan around the first; nothing here can say anything about the second.

Nothing on this page is a vendor statement; the values it helps read are on the support table, with the page and the date each one was read from. See also the free tier column, metadata against watermark. Nearby terms: double label, detection signal, feature grid.