01must proveConfirmed | Applications register complete condition and purpose declarations during deployment, and Platform rejects an invalid declaration set with its problems without persisting any part. | validation | service | test |
02must proveConfirmed | Condition declarations must use compatible operators, their application’s registered datasets and functions, valid subject fields and registered choice sources. | validation | service | test |
03must proveConfirmed | Changed declarations require a higher version; an equal or lower version is rejected, while an identical redeployment performs no write. | validation | service | test |
04must proveConfirmed | Omitted declarations are withdrawn unless a published rule uses the condition or a binding uses the purpose anywhere, in which case registration fails with the affected workspace and rule identified. | policy | service | test |
05must proveConfirmed | Deprecated conditions continue to evaluate and appear only when explicitly requested; withdrawn conditions never appear in the authoring catalogue. | lifecycle | service | test |
06must proveConfirmed | Renamed conditions preserve their former keys as aliases for existing published expressions. | invariant | service | test |
07must proveConfirmed | Authoring catalogues include only licensed application conditions and purposes, support subject-kind filtering and omit internal queries and provider functions. | permission | service | test |
08must proveConfirmed | Each process retains its evaluation catalogue for 60 seconds and invalidates that snapshot after its own successful registration. | policy | service | test |
09Confirmed | Condition and purpose declarations have no staff-facing mutation route and change through application deployments. | permission | api | test |
10Confirmed | Platform declares testing, population, simulation and decision purposes plus date and portal-role conditions; portal-role evaluation awaits a user-to-contact relationship. | policy | service | documented |