GateTrue

What each generator documents about marking its output

Two-route product: where the door decides the file

A two-route product reaches the same models more than one way: a console and an interface, or plans and an interface. The route can decide what the output carries, and one entry here documents both sides. As of 2026-09-22.

Three ways of documenting more than one doorBoth routes documented, with statements that disagree, lets an integrator plan around the split. One route documented leaves the other an open question. A statement scoped to one route neither includes nor excludes the rest, and the register records the scope as written.Both documentedA console that stamps, a fielddefaulting to falseTwo statements, disagreeingA split that can be plannedaroundOne documentedPlans remove the mark; interfacepages silentOne statementAn open question about theother routeScoped to a routeDownloads from the vendor's ownpropertiesA statement with an edge onitOther routes neither in noroutSame commercial shape, three documentation practicesNo file from any of them records which door it came through
Fig. 1 The entry that documents both routes proves that assuming the second matches the first can be exactly wrong.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termTwo-route product
What it namesA product whose models are reachable by more than one route
What it is notTwo products, or two models
Where the register uses itThree entries, with different amounts documented

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.

1Three degrees of documentation

One entry publishes a marking statement for each route and the two disagree: a console that always stamps and an interface that defaults to not stamping. One publishes a line on its consumer plans and does not repeat it on its interface pages. One scopes its statement to downloads from its own properties and does not address anything else.

Only the first lets an integrator plan. The register records the consumer statement where it exists and does not extend it across a boundary the vendor did not extend it across, because the entry that documents both shows that the inference can be exactly wrong.

2What a documented disagreement is worth

More than agreement would be. Knowing that two routes differ by default means a pipeline can be labelled, a door chosen, and stamped files expected from the other one. Knowing nothing about a second route leaves an open question that no published page closes.

The vendor that documents both also gives a reason for one of them, attributing its console restriction to compliance requirements. That makes the asymmetry legible rather than arbitrary: the surface a regulator would look at is the one without a switch.

3What a recipient can tell afterwards

Very little. A stamped file at least proves the stamping route on the entry that documents both. A clean file proves nothing, because it could come from a caller who set a field or one who never knew the field existed.

And none of the three entries names a provenance standard, so no file from any of them records the route it came through. The door matters and the file does not remember it, which is the ceiling on this whole distinction.

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 user toggle column, source documents. Nearby terms: download route, burned-in mark, corner stamp.