GateTrue

What each generator documents about marking its output

Scope as written: not generalising past a sentence

Scope as written means recording the boundary a vendor put on a statement. A mark described on downloads from one surface is recorded that way, not generalised to everything the model produces. As of 2026-09-22.

What generalising past a boundary would produceA statement about one route says nothing about another. One entry in this register documents two routes into the same models with opposite defaults, which shows that extending either statement would have been wrong about half the files the product produces.The vendor's sentence names a route. What nowRecord the scope as writtenNarrow and trueThe cell names the route; the reading sayswhich routes the sentence does not cover.Generalise to the modelBroad and unsupportedOne entry here documents two routes withopposite defaults, so this fails outright.The proof that the inference is unsafe is inside the register
Fig. 1 Where a second route exists and is undocumented, the register records the silence rather than assuming it matches the first.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termScope as written
What it namesThe discipline of keeping a vendor's own boundary on a statement
What it is notA refusal to record anything general
Where the register uses itSeveral visible-mark and control values

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 sentence with an edge in it

Vendors often qualify a marking statement without drawing attention to it: videos downloaded from our website and app, videos generated on the console's own page, content generated under these plans. Each of those is a boundary, and dropping it would turn a narrow true statement into a broad unsupported one.

So the register keeps the phrase. The cell says what the statement covers and the reading says what it does not, which is usually the more actionable half for anybody integrating a model through a route the sentence did not mention.

2Why the restraint is not excessive caution

One entry here documents two surfaces into the same models with opposite defaults. A register that had generalised either statement would have recorded a contradiction or picked a winner, and both would have been wrong about half the files the product produces.

That is the proof that the inference is not safe. Where a second route exists and is undocumented, the register says so rather than assuming it matches the first, because the one vendor that documents both shows the assumption can fail.

3What it looks like in a cell

Values name the surface or route where the vendor named one: the console, the documented interface, downloads from the vendor's own properties. Where a vendor attached a plan group rather than a surface, the group is named instead.

The cost is cells that read less crisply than a yes or no. The benefit is that a reader can tell whether a statement covers the way they actually use the product, which a crisper cell would hide.

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 protocol page, what earns a row. Nearby terms: re-reading, register row, inclusion rule.