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 subject without types accepts any
type; a definition with NO subject entry takes no subject and never
matches. 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 subject withouttypesaccepts any type; a definition with NO subject entry takes no subject and never matches. Cheap and indexable — no GROQ evaluation — so a consumer can pre-filter before loading document content.