01must proveProposed | Keys consist of three dot-separated segments beginning with lowercase letters; subsequent digits and underscores are allowed; the first segment identifies the registering application; registration rejects another application's key and repeated keys. ✓ accounting.batch.posting_failed from accounting✗ crm.batch.posting_failed declared by accounting no proof recorded yet | validation | service, database | test |
02must proveProposed | Category, severity, preference mode, delivery requirement, replacement scope and audience types use fixed enumerations; a declaration includes at least one audience type. no proof recorded yet | validation | service, database | test |
03must proveProposed | Console support is compulsory; default channels form a subset of supported channels, and mandatory definitions default to the console plus e-mail whenever e-mail is supported. no proof recorded yet | validation | service | test |
04must proveProposed | The request-data schema is valid JSON Schema with a closed root; its fields cannot use Platform's organization, recipient, record or destination variable names; Between one and ten examples satisfy that schema. no proof recorded yet | validation | service | test |
05must proveProposed | Templates use safe syntax, declared data and Platform's supplied objects; All examples render a nonempty console title of at most 140 characters, a console body of at most 2,000, a text message of at most 306 and a nonempty e-mail subject; English wording is present, together with templates for supported e-mail and text channels. no proof recorded yet | validation | service | test |
06must proveProposed | Route placeholders correspond to declared destination parameters; Up to ten open, route or operation actions are allowed; operation actions reference the application's own console API operations and retain their required permissions. no proof recorded yet | validation | service | test |
07Proposed | An unavailable API registry produces a warning instead of blocking registration; Permissions supplied without an application permission catalog are retained as unverified. | policy | service | test |
08must proveProposed | An existing key retains its category and preference mode across releases; changing either requires a different key. no proof recorded yet | invariant | service | test |
09must proveProposed | Invalid manifests leave the registry unchanged; the registration response identifies the definition and offending field so deployment can report the refusal. no proof recorded yet | validation | service | test |
10must proveProposed | Registration leaves identical definitions untouched, increments the version of changed definitions and records their release; Omitted definitions become retired rather than deleted; a subsequent declaration reactivates them. no proof recorded yet | lifecycle | service, database | test |
11must proveProposed | Retirement commits before Platform tries to cancel accepted, unsettled requests across operational workspaces; Settled requests and settings survive; cancellation errors are logged without reversing registration. no proof recorded yet | lifecycle | service | observed |
12Proposed | Platform registers its test notice, four responsibility notices and two provisioning alerts using the application registration interface. | policy | service | test |
13must proveProposed | The global definition list requires the HQ notification-read permission; Staff can filter by application and status; entries exclude template content and data schemas. no proof recorded yet | permission | api, service | test |
14must proveProposed | Manifest validation accepts format one, no more than two hundred definitions and twenty locales per definition, and bounded labels, descriptions and templates; Extra fields, duplicate declaration values and invalid locale or duration values are rejected. no proof recorded yet | validation | service | observed |