PRISMA 2020 Specification & Data Model Constraints¶
Overview¶
This directory contains the binding specification documents produced by Phase 2 of the SyRF Platform Evolution. These documents constrain ALL data model decisions in Phases 3-16 across three releases.
The specification ensures that every data model choice -- from field names and entity relationships to lifecycle state machines and screening outcome structures -- is PRISMA 2020 compatible. Without these constraints, implementation phases would risk introducing structures that silently break PRISMA flow diagram generation.
Core principle: Data model decisions are irreversible once data exists. These specifications prevent mistakes that would require painful migrations.
Document Index¶
| Document | Purpose | Key Contents |
|---|---|---|
| prisma-flow-diagram-mapping.md | PRISMA box-to-field mapping | 17 boxes, 34 fields, derivation rules, gap analysis |
| three-level-data-model.md | Publication/Citation/Study entities | Entity specs, relationships, migration strategy |
| deduplication-service-specification.md | Dedup service interface | ASySD integration, confidence model, enrichment rules, merge scenarios |
| study-lifecycle-and-source-taxonomy.md | Lifecycle status & source types | 9 lifecycle states, 6 source types, PRISMA count derivation |
| prisma-constraint-annotations.md | Per-phase constraints & release checklists | 14 phase annotations, 3 release checklists, validation procedures |
How This Specification Package Is Used¶
Phase Executors¶
Before implementing any phase (3-16), read the relevant section in prisma-constraint-annotations.md and comply with all MUST constraints. Cross-references in the constraint annotations point to the specific specification document and section that defines the requirement.
Migration Authors¶
Before each release migration, run ALL items in the release's validation checklist (found in prisma-constraint-annotations.md Section 4). The validation procedures section provides exact MongoDB queries and code grep patterns.
Feature Spec Authors¶
When designing new features, cross-reference the three-level-data-model.md and study-lifecycle-and-source-taxonomy.md to ensure compatibility. In particular:
- New Study fields must not conflict with reserved PRISMA field names
- Screening-related data must use the per-profile screeningOutcomes[] pattern, never a single study-level status
- Any entity that touches deduplication must preserve Citation immutability
PRISMA Report Implementers (Phase 16)¶
Use the derivation rules in prisma-flow-diagram-mapping.md Section 3 as the authoritative source for PRISMA box population. Every box's field, entity path, and aggregation query is documented there.
Requirements Covered¶
| Requirement | Status | Covered In |
|---|---|---|
| PRISMA-01 | Specified | prisma-flow-diagram-mapping.md |
| PRISMA-02 | Specified | study-lifecycle-and-source-taxonomy.md |
| PRISMA-03 | Specified | three-level-data-model.md |
| PRISMA-04 | Specified | study-lifecycle-and-source-taxonomy.md |
| PRISMA-05 | Specified | deduplication-service-specification.md, study-lifecycle-and-source-taxonomy.md |
| ARCH-07 | Specified | three-level-data-model.md |
| DEDUP-01 | Specified (design) | deduplication-service-specification.md |
All 7 requirements mapped to Phase 2 in the REQUIREMENTS.md traceability table are covered by this specification package.
Relationship to Other Feature Specs¶
These specifications inform (but do not replace) the following feature-level specs:
docs/features/screening-annotations/-- Implements theFinalScreeningOutcomeand structured exclusion reasons referenced by this specificationdocs/features/screening-profiles/-- Implements the screening profiles that produce per-profile screening outcomesdocs/features/stage-filtering/-- Implements stage study pools referenced in PRISMA count derivationdocs/features/annotation-management-reconciliation/design-decisions.md-- Contains the authoritative design decisions (D1-D50) that informed this specification
Change Policy¶
These specifications are AUTHORITATIVE. Changes require:
- Identification of which PRISMA box or entity is affected
- Impact analysis on downstream phases (use the PRISMA Impact column in prisma-constraint-annotations.md summary table)
- Update to all affected specification documents (changes often cascade across multiple specs)
- Update to release validation checklists if the change affects checklist items
Changes to MUST constraints require re-evaluation of all phases at or above the affected phase's PRISMA impact level.
Created: 2026-02-17 Phase: 02-prisma-specification-data-model-constraints