The structured half of applicability: does the definition's subject entry
(isSubjectEntry — the subject kind, workflow scope, at most one
by deploy invariant) accept documentType? The kind is the discriminator,
so a definition surfaces from its SUBJECT's document picker and nowhere
else; the start dialog collects the remaining required entries (their
fail-hard validation backstops). A definition with no subject entry takes no
subject and never matches. A subject without types accepts any type that is
not a system document (isSystemDocumentType). Naming a reserved
sanity. or system. type in types accepts it, but naming a type the engine
owns and writes for itself never does.
Cheap and indexable — no GROQ evaluation — so a consumer can pre-filter
before loading document content.
The structured half of applicability: does the definition's subject entry (isSubjectEntry — the
subjectkind, workflow scope, at most one by deploy invariant) acceptdocumentType? The kind is the discriminator, so a definition surfaces from its SUBJECT's document picker and nowhere else; the start dialog collects the remaining required entries (their fail-hard validation backstops). A definition with no subject entry takes no subject and never matches. A subject withouttypesaccepts any type that is not a system document (isSystemDocumentType). Naming a reservedsanity.orsystem.type intypesaccepts it, but naming a type the engine owns and writes for itself never does. Cheap and indexable — no GROQ evaluation — so a consumer can pre-filter before loading document content.