Skip to content

Data Invariants

Capture non-negotiable model constraints that must hold across schema, APIs, sync, and integrations.

These invariants are implementation requirements, not optional guidelines.

  1. Person identity durability A person identity must not be destroyed when affiliations, memberships, or roles change.

  2. Person history continuity Learning history remains linked to the same person across institutions and role transitions.

  3. Multi-role compatibility A person may hold multiple active roles in overlapping time windows.

  4. External identity traceability Every external identity binding must include provider, external subject, and validity period.

  1. Time-bounded participation Membership and role grants must support effective windows.

  2. No hidden overwrites State transitions must preserve previous state in audit/event logs.

  3. Event ordering semantics For a single aggregate, state transitions must be orderable and replay-safe.

  1. Unified participation model Learner and teacher participation use the same membership abstraction.

  2. Scoped visibility Access is granted through explicit membership/affiliation, never inferred from profile fields alone.

  3. Contextual administration Organization context governs authorization but does not redefine person identity.

  1. Attempt integrity An attempt belongs to exactly one person and one assessment definition.

  2. Score traceability Final scores must reference attempt version and evaluation source.

  3. Qualification provenance Every qualification award must reference definition, issuer context, and grant basis.

  1. Versioned competency stability Published competency framework versions are immutable.

  2. Evidence provenance completeness Competency evidence must include source, actor/provenance, and timestamp metadata.

  3. Derived-state integrity Person competency state is derived from evidence and policy rules, not ad hoc overwrite. Current state attaches to the durable competency node and spans framework editions (ADR-0018); contributing editions live in the evidence rows and derivation metadata.

  4. Node/revision framework coherence A competency node revision’s framework version must belong to its node’s framework. This is not FK-enforceable (the two FKs land on different parents); writers assert it and seeds/imports must uphold it.

  1. Learner exportability Person-linked learning evidence must be exportable in standards-aligned formats.

  2. Full attempt and feedback portability by default Person-portable exports include full attempt-level and feedback-level history unless explicitly redacted by policy.

  3. Import reconciliation Imported records must preserve source provenance and avoid destructive merge semantics.

  1. Core stability first Core entities should not accumulate specialization fields without review.

  2. Typed extension for critical data High-value domain extensions must use typed extension tables/contracts.

  3. Extension namespace ownership Every extension must declare namespace, owner, and versioning policy.

  1. Offline-safe identity keys IDs must support deterministic reconciliation across Postgres and PGlite contexts.

  2. Conflict visibility Conflict outcomes must be auditable and observable, not silent.

  3. Convergence requirement Sync strategy must guarantee eventual convergence for supported mutation classes.

  • Domain-level types and validators in packages/domain
  • Relational constraints and indexes in packages/db
  • Sync conflict policies and merge rules in packages/offline-data
  • Authorization and mutation orchestration in apps/api

Use this checklist whenever changing model semantics:

  1. Does the change preserve person history continuity?
  2. Does it introduce an unbounded role or membership without temporal fields?
  3. Does it break unified participation semantics?
  4. Does it weaken full attempt-level or feedback-level export portability?
  5. Does it violate competency framework versioning or evidence provenance rules?
  6. Does it create a non-portable learner-critical record?
  7. Does it bypass typed extension governance for critical data?
  8. Does it weaken deterministic sync convergence?

If any answer is yes, document the exception and add compensating controls.