--- id: AREA-SUB title: Submissions product_area: submissions revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: rhythm-v2-docs: ec0b44d8b41c3c03a84b911844227e0cb53aa40a services-submissions: 64236c19be89579ef5897aad7de3925ed3ce03bf services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/MODULE.md#Purpose' modules: - MOD-SUB-SUB owns: - The shared review process and the evidence of how an application reaches an outcome. - 'Application content retained for review, reviewer participation, decisions and contributor evidence.' - Local follow-up records and the delivery state that connects a decision to its owning application. does_not_own: - >- Platform owns identity, access policy, workspace lifecycle, file storage and shared execution infrastructure. - 'CRM owns people, organizations and tasks.' - Owning applications keep their business records and apply the effects of review outcomes. - The console shell hosts staff navigation; applicant and contributor portal screens remain deferred. handoffs: - to: Platform Security what: 'Authenticated identity, scoped authority and controlled staff entry.' - to: CRM what: Applicant and reviewer identity references and requests for tasks. - to: Platform shared services what: >- Prepared file references, communication requests, operational attention, governed queries and workflow primitives. - to: Owning applications what: >- Registered subject kinds, submitted review work, versioned decisions and acknowledgement of owner handling. - to: Platform submissions and reviews what: The approved future homes for form collection and review after the standalone engine moves. invariants: - The area distinguishes review responsibility from the business responsibility of an owning application. - >- Records and access decisions remain bounded by the authorized workspace and the applicable process or participation. - >- Shared infrastructure keeps its own authority; Submissions describes its local work and the evidence available at each handoff. - The current standalone engine and the approved future Platform ownership remain distinguishable. intent_sources: - >- services-submissions:docs/milestones/README.md#SF-01 (Andrew, 2026-10-22); PLAT-M30 approved 2026-10-22 11:45 ET ownership_questions: - question: OQ-SUB-SUB-001 provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/FINDINGS.md#Open Questions' - question: OQ-SUB-SUB-004 provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/FINDINGS.md#Open Questions' - question: OQ-SUB-SUB-005 provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/FINDINGS.md#Open Questions' - question: OQ-SUB-SUB-006 provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/FINDINGS.md#Open Questions' - question: OQ-SUB-SUB-007 provenance: documented source: 'rhythm-v2-docs:specs/submissions/submissions/FINDINGS.md#Open Questions' evidence: - 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#MOD-SUB-SUB' - 'rhythm-v2-docs:specs/submissions/submissions/MODULE.md' - 'rhythm-v2-docs:specs/submissions/ACTORS.md' - 'rhythm-v2-docs:specs/submissions/RESPONSIBILITIES.md' - 'services-submissions:docs/milestones/README.md#Re-homed 2026-10-22' - 'services-submissions:docs/forge-handoff/submissions-and-reviews.md#A. Executive summary' --- # Submissions ## Purpose and Outcomes Submissions gives a customer one place to organize review work that otherwise spreads across application records, reviewer correspondence and staff decisions. It connects the people who supply evidence, the people who assess it and the application that acts on the result. A customer can use that shared arrangement for work such as awards, nominations or reports while keeping the underlying business record with its owning application. The area gives staff a common language for review responsibility and a retained account of the evidence behind an outcome. Administrators govern the review arrangement, coordinators oversee daily work, reviewers contribute judgment, and readers inspect progress. Applicants and contributors supply the material the review needs. Owning applications and scheduled work participate through service integrations rather than interactive staff screens. The intended outcome is a review that staff can explain and an outcome whose handling the owner can account for. Delivery evidence, outstanding work and ownership boundaries matter alongside the decision itself. The current area describes the standalone engine and its staff console. Applicant and contributor backends exist before their portal experiences. Product has approved moving form collection and review into Platform, so this overview keeps that future ownership visible without presenting the migration as completed. ## Scope and Boundaries Submissions owns the shared review arrangement and its local evidence: application content, reviewer work, contributor material, outcomes and follow-up records. It also keeps the delivery state needed to distinguish recording a decision from the owner handling it. Platform supplies identity and access policy, workspace lifecycle, prepared files, communication delivery, attention, governed queries and shared workflow primitives. CRM supplies contact and organization records and owns requested tasks. The console shell supplies navigation and hosts staff screens. Each owning application keeps its domain records and performs the business effects of a review outcome. Integration requests and acknowledgement cross these boundaries; the area does not establish that a requested external effect succeeded merely by recording local work. ## How the Area Is Divided The Submissions, Intake, Review and Outcomes module is the area's single corpus module. It brings the review arrangement, collected evidence, assessment work, outcomes and operational visibility together. Open it when a question concerns the meaning of a review record, responsibility for review work, the staff experience or a handoff to the application that owns the business record. Its design distinguishes configuration, intake, review, outcomes and reporting service responsibilities within that shared module. ## Area-Level Invariants Review responsibility and business ownership remain separate throughout the area. Workspace boundaries and the relevant process or participation constrain access across its records. Shared services retain their own responsibilities, and local records provide evidence of a handoff rather than an unconditional promise of external completion. The standalone engine remains the current implementation record until the Platform move is verified. ## Open Ownership Questions The module's existing ownership questions cover where staff configure review after the Platform move, where owner-hosted applications collect answers during the form transition, and when the corpus changes to the new homes. They also ask whether local action history remains sufficient and who compensates effects already performed when an application ends or reopens. Those decisions remain with Product; this overview preserves their existing home.