# M1 Technical Decisions

1. **Clean replacement.** No legacy database compatibility layer and no runtime connection to the old B360 database.
2. **Modular monolith.** CodeIgniter application modules share one relational database. OMR remains a separately deployable service.
3. **Shield authentication.** Passwords, login security and MFA readiness belong to Shield. Business authorization is additionally scoped by organization, competition or scoring event.
4. **Migrations are authoritative.** Database creation and changes are repeatable, reviewable and version controlled.
5. **Published definitions are immutable by service policy.** Structure and content are separate so Utah-style label changes create new content versions without changing bubbles or scoring.
6. **Evidence and result are separate.** Submissions preserve what entered the system; results identify the current accepted calculation; corrections append revisions.
7. **Zero is data.** `0` is an answered value. An unanswered field is represented by the explicit `unanswered` state and a null value.
8. **Ambiguity is not correction.** Multiple OMR marks create an ambiguous response/review flag; the darkest response is not silently selected.
9. **Idempotency is required.** Import and submission batches have competition-scoped idempotency keys; source documents have checksums.
10. **Customer-facing hostname is independent of the server's primary domain.** DNS can point a professional subdomain to the same server.
11. **Repositories are selective.** They encapsulate workflows requiring data-access isolation; simple CodeIgniter models need not be wrapped ceremonially.
12. **Mah Jongg rounds are scoring events.** Each round can have its own event entry and score while `mj_round_assignments` supplies table and seat.
13. **Preparation status is derived.** Competitor readiness, assignment generation and score-sheet generation are calculated from underlying records; administrators do not manually check off stages.
14. **Assignment locking is an approval.** B360 generates all configured rounds from supplied Round 1 positions. An MJ Organization Admin explicitly locks a validated assignment version before score sheets are generated. Any later change requires a reason and a new version.
15. **Rounds are configurable and independent.** Current MJ uses 12 rounds, but the schema and UI must render the configured count (supported foundation range 1–40). There is no round open/close dependency, and mixed-round OMR batches are valid.
16. **MJ print order is contractual.** Score sheets are generated player-major. For 12 rounds, each player's six 2-up pages pair R1/R7 through R6/R12 so that cutting the full stack yields two Player-ID-ordered piles.
17. **Acceptance is validation, not finalization.** Clean OMR/manual submissions become accepted authoritative records automatically after identity, round, response and duplicate checks. Ambiguity, including crossed-out plus replacement marks, creates review and never silently chooses a value.
18. **Workspace and report profiles are versioned.** Superadmin assigns a published workspace profile and report collection to a competition. Finalized competitions retain their assigned versions for reproducibility.
19. **Primary Organization Admin is protected.** Organization Admins may grant ordinary Organization Admin membership; only Superadmin may transfer or remove the single primary designation.
20. **MJ owns finalization.** An authorized MJ Organization Admin finalizes and locks competition results. Superadmin does not perform routine customer finalization.