Submissions Responsibilities
How the Product Area Is Divided
The product area currently contains a standalone application and review engine. Its definitions, intake, review, outcomes and reporting parts share a schema, allowing a lifecycle command to commit the local application, review and decision changes together. The recorded migration places review in Platform and separates form collection into its own Platform module.
Submissions, Intake, Review and Outcomes
Definitions owns process configuration and its published versions. Intake owns application content, participation, revisions, files, clarification requests and outside contributions. Review owns runs, reviewer pools, assessments, conflicts and configured follow-up state. Outcomes owns decisions, delivery pointers and application events; reporting supplies reads over these owned records.
The engine freezes published configuration, pins applications and serializes completing commands with database uniqueness as a second safeguard. Blind review withholds marked identifying content through server projection; unmarked content can still identify an applicant. Event history covers the events implemented by each command. Externally owned decisions use duplicate-tolerant delivery and acknowledgement reconciliation rather than a promise that the owner has already performed its effect.
Staff operations, applicant-side APIs and contributor links expose different authority boundaries. Trusted functions support owner intake and status reads. None of the engine operations is published as an owning-domain Submission Form binding. The operation inventory and object ownership agree with the service contracts.
What Is Delegated to Platform and Other Areas
Platform supplies identity and authorization, console hosting, communication delivery, prepared files, number allocation, query execution, business calendars and the shared action library. CRM retains person and organization records and owns tasks affected by follow-ups. The registered subject owner applies decision effects and reports their handling.
Attention publishing is disabled by default, and the scanner currently substitutes a clean result without inspecting content. Unexpected inline follow-up errors can abort their triggering transaction. These implementation limitations remain findings rather than approved product guarantees. Engine records have no custom fields, and the current history surface uses application events rather than Platform row-change history.