Codex 0 · Chapter 07 — The Data Model

This chapter specifies every canonical entity, ENT-01 through ENT-19 and its derived datasets: purpose, key fields, identity and ownership, lifecycle, relationships, and retention.

07.0 Purpose

The institution holds one true record of every person, organization, and produced work, so that a claim made about a member in one division is the same claim in every other. This chapter fixes what each canonical entity is, who owns it, how it is born and how it ends, so that no division invents a second definition of something already defined here (Codex 0 §01.2.3, Codex 5).

07.1 Scope and non-scope

07.1.1 This chapter governs the field-level shape, identity rule, lifecycle, relationships, and retention of every entity in the Registry's Entity section (Appendix 99, Part 5), plus the derived and anonymized datasets built on top of them.

07.1.2 This chapter does not govern which role may read or write a given entity (Chapter 08), the engines that produce and consume entities (Chapter 05), or the graph's node/edge representation of a subset of this data (Chapter 06). It states the record; those chapters state who may touch it and how it is reasoned over.

07.1.3 A change to an entity's shape that alters its meaning follows Codex 5's contract rules: a version, a migration window, and a decision record. This chapter does not restate that procedure; it names where each entity is bound by it.

07.2 The four categories, and normalization

The four categories

07.2.0 Every entity in this chapter belongs to exactly one of four top-level categories. The categories are the institution's organizing frame for data and never change:

People           who they are, what they have demonstrated, what they hold
Organizations    the bodies the institution serves, partners with, and builds
Knowledge        capabilities, curriculum, sources, publications, indexes
Capital          money, ventures, investments, and the institution's own means

Every table, boundary, dataset, and report ultimately supports one or more of these. A proposed entity that belongs to none of the four is misconceived and is redesigned rather than added. A proposed entity that appears to belong to two is split, or one category is named as its owner and the other as a reference.

Normalization rules

07.2.1 One canonical row per real-world thing. Every entity in this chapter has exactly one authoritative record. Other systems reference it by ID; they never hold a second copy of its fields for convenience.

07.2.2 No duplicate people. A human being has exactly one Person row for life (§07.4). No workflow, onboarding path, or division-specific intake may create a second Person row for someone already known to the institution. Where an intake process cannot yet resolve whether a person already exists, it blocks on identity resolution before writing, rather than writing speculatively.

07.2.3 No denormalized role storage. A role grant is never a column on Person, Membership, or any profile-shaped table. Roles live exclusively in the Role entity (§07.7) keyed to person and scope, per Chapter 08.

07.2.4 History is additive. Assessments, credentials, index values, decisions, and progress state are versioned or appended, never overwritten in place, when the change would alter what was previously asserted (§07.4's AuditRecord doctrine, mirrored per-entity below).

07.2.5 Derivation over duplication. A value obtainable by joining or computing from canonical entities is never stored redundantly as if it were itself canonical, except where materialized for performance and explicitly marked as a cache with a rebuild path.

07.2.6 Anonymized data is derived, never primary. Any dataset used for research, reporting, or model training that has had identifying fields removed or aggregated is a derived dataset with its own record of the transformation that produced it (§07.20); it is never treated as, or promoted to, a primary record.

07.2.7 Every public table ships grants and RLS in the same migration that creates it. No table holding member data reaches built status without row-level security policy and explicit grants defined alongside its schema, in the same change (Codex 5, Chapter 08 §08.2).

07.3 Time, money, and identifiers

07.3.1 All timestamps are stored in UTC with timezone information preserved at the point of capture; display localization happens at the surface, never by altering the stored value.

07.3.2 A date without a time (a birth date, a target date) is stored as a date, not coerced into a timestamp with an arbitrary time component.

07.3.3 Monetary amounts are stored as an integer minor-unit value (cents, or the smallest unit of the recorded currency) paired with an explicit currency code. No monetary value is stored as a floating-point number.

07.3.4 Every entity's primary identifier is a stable, non-reused, institution-scoped ID assigned at creation. Human-readable slugs or display codes are a separate field and may change; the ID never does.

07.3.5 A reference from one entity to another is always by ID. No entity embeds another entity's mutable fields as a snapshot unless the snapshot is explicitly a historical record (for example, a Credential recording the exact Capability version it certifies, per Chapter 06 §06.6.3).

07.4 Deletion, severance, and retention — the general rule

07.4.1 Two distinct operations exist and are never conflated:

• Soft delete marks a record inactive while preserving it fully, reversible by an authorised role, used for records a person or the institution may need to restore (a withdrawn enrolment, a retracted draft).
• Severance is the person-initiated or legally required removal of personal content under §04.8.4: it removes identifying and personal fields, retains anonymized aggregates, and preserves the fact and validity of anything third parties rely on (issued credentials, audit records of consequential actions).

07.4.2 Severance is never reversible in the way soft delete is; a severed person's record cannot be reconstructed from the institution's stores. This is the tradeoff that makes the deletion right meaningful (Chapter 04 §04.8.4) without destroying what the institution owes to others (a verifier of a credential, an audit of a past decision).

07.4.3 Retention periods below are defaults; a longer period applies wherever a legal, contractual, or credential-verification obligation requires it, and that obligation always wins over a shorter default.

07.5 ENT-01 — Person

Purpose. The single record of a human being known to the institution, for life (Chapter 04 §04.2).

Key fields. Institution-assigned ID; display name; contact channel(s), each independently verifiable; date of birth where collected for a specific lawful purpose; locale and accessibility preferences; standing (active, dormant, departed, deceased).

Identity and ownership. Owned by Technology (DIV-05). One row per human being, enforced by identity-resolution at every intake path (§07.2.2). A Person owns no role, no organization membership detail, and no profile-shaped duplicate of data that belongs on Membership or Role.

Lifecycle. Created on first verified contact (application, enrolment, employment, investment, or partner-referred intake). Standing transitions (active → dormant → returning → active, active → departed) are Events (§07.19); a standing change that affects rights or visibility is also an AuditRecord (§07.20). Severance transitions standing to departed and removes personal fields per §07.4.2; deceased is a standing pending the open question in Chapter 04 §04.13.4.

Relationships. 1—n Identity; 1—n Membership; 1—n Role (scoped); 1—n Enrolment; 1—n Engagement (as advisor or client contact); 1—n Venture (as founder); 1—n Credential; 1—n Event.

Retention. Retained for the institution's operating life. On severance, personal fields are removed; the row persists as an anonymized reference anchor so that credentials, audit records, and aggregates that reference it remain resolvable (§07.4.2, Chapter 06 §06.2.8).

07.6 ENT-02 — Identity

Purpose. An authentication method bound to exactly one Person (Chapter 04 §04.2.1, Codex 4 "Identity").

Key fields. Identity ID; provider type (email/password, institutional SSO, social provider); provider-specific subject identifier; verification state; created and last-used timestamps.

Identity and ownership. Owned by Technology. Authentication is separate from identity in the human sense: a Person may bind several Identity rows, and an Identity binds to exactly one Person, never shared.

Lifecycle. Created on sign-up or SSO binding; deactivated (soft delete) when a credential is revoked or a sign-in method is removed by the person; all Identity rows for a Person are removed on severance.

Relationships. n—1 Person.

Retention. Active for the life of the bound Person's active standing; removed on severance; deactivation events retained as Event history for security review.

07.7 ENT-03 — Organization

Purpose. A company, university, government body, or partner the institution has a relationship with (Codex 4, Codex 5).

Key fields. Organization ID; legal name; type (enterprise client, partner institution, venture-affiliated, vendor); primary contact Person reference; agreed reporting scope where applicable.

Identity and ownership. Owned by Technology. One canonical row per real-world organization; a subsidiary or campus is a related Organization row with an explicit parent reference, never a duplicate of the parent's fields.

Lifecycle. Created on first formal relationship (contract, MOU, or venture affiliation); archived (soft delete) when the relationship ends; never hard-deleted while any Membership, Engagement, or Investment references it.

Relationships. 1—n Membership (its members' relationship to it); 1—n Engagement (as client); 1—n Investment (as investor); 1—n Cohort (as sponsoring organization).

Retention. Retained for as long as any relationship record references it; aggregate and financial history retained per Chapter 15's financial record obligations.

07.8 ENT-04 — Membership

Purpose. A Person's relationship to the institution itself or to an Organization — the entity that makes "one person, many simultaneous relationships" concrete without duplicating the person (Chapter 04 §04.2.2).

Key fields. Membership ID; Person reference; Organization reference (nullable for direct institutional membership); membership type (institutional member, employee-of-client, partner-affiliated); start and end dates; standing.

Identity and ownership. Owned by Technology. A Membership never carries role grants (§07.2.3); it states only the relationship, not the authority it might imply.

Lifecycle. Created when a relationship begins; ended (soft delete, with end date set) when it lapses or is terminated; a person may hold many concurrent Membership rows against different organizations and against the institution directly.

Relationships. n—1 Person; n—1 Organization (nullable).

Retention. Retained as history for the life of the Person row; end dates are never deleted, since a person's institutional history is part of their lifetime record (Chapter 04 §04.3).

07.9 ENT-05 — Role

Purpose. A scoped grant of authority to a Person — the sole mechanism by which access is derived (Chapter 08).

Key fields. Role ID; Person reference; role name (from the controlled vocabulary of Chapter 04 §04.4); scope type (individual, cohort, organization, division, institution); scope reference (the specific cohort, organization, division, or none for institution-wide); granted-by, granted-at, reason; expiry (nullable, required for any elevated or delegated grant).

Identity and ownership. Owned by Technology. Chapter 08 governs enforcement in full; this entity governs only the record's shape and lifecycle.

Lifecycle. Created by a grant action, itself an AuditRecord (§07.20); modified only by a new grant or an explicit revocation, never by editing the original grant's meaning in place; expires automatically where an expiry is set (Chapter 08 §08.6).

Relationships. n—1 Person; scope reference resolves to Cohort, Organization, division, or nothing (institution-wide).

Retention. Retained indefinitely as history, including revoked and expired grants, so that "who could see what, and when" is always reconstructable for audit (Chapter 08 §08.9).

07.10 ENT-06 — Capability

Purpose. A named, describable human capability at a specific taxonomy level, authored by Research Institute (Chapter 06 §06.2.1, §06.3).

Key fields. Capability ID; plain-language capability statement; taxonomy level (domain, strand, capability, sub-skill); status (draft, published, deprecated); named reviewer of record; localized labels.

Identity and ownership. Owned by Research Institute (DIV-03). One canonical row per capability; the Knowledge Graph references this entity's ID rather than duplicating its fields (Chapter 06 §06.12.5).

Lifecycle. Authored in the editorial pipeline (ENG-09); published after named review; a meaning-changing revision creates a new versioned row linked by supersedes, never an in-place edit (Chapter 06 §06.6.1); deprecated rather than deleted while referenced.

Relationships. n—n CapabilityAssessment; n—n Credential; n—n Curriculum unit (via teaches); referenced by Knowledge Graph nodes (Chapter 06 §06.2.1).

Retention. Retained permanently once published; a deprecated capability remains resolvable by ID for as long as any CapabilityAssessment, Credential, or Publication references it (Chapter 06 §06.6.4).

07.11 ENT-07 — CapabilityAssessment

Purpose. Evidence that a Person demonstrated a Capability at a stated level, at a stated time, through a stated instrument (Codex 5).

Key fields. Assessment ID; Person reference; Capability reference (exact version); instrument or method; result and level achieved; assessor (Person or role) reference; timestamp; supporting Artifact reference where applicable.

Identity and ownership. Owned by Academy (DIV-01). One row per assessment event; a re-attempt produces a new row, never an overwrite (§07.2.4).

Lifecycle. Created by the assessment or review workflow (WF-01); immutable once finalized, mirroring AuditRecord doctrine (§07.20.2); a correction to a finalized assessment is a new, linked record through the recorded appeals or correction procedure (Chapter 04 §04.8.3), never a silent edit.

Relationships. n—1 Person; n—1 Capability; 0..1 Artifact; feeds Credential issuance eligibility.

Retention. Retained permanently; assessment history is part of the person's lifetime capability record and survives severance in anonymized form (§07.4.2), while the identifiable link is removed.

07.12 ENT-08 — Credential

Purpose. An issued, verifiable institutional statement that specific capabilities were demonstrated (Chapter 06 §06.2.7).

Key fields. Credential ID; Person reference; certified Capability references (exact versions, per Chapter 06 §06.6.3); issuing authority (role and division); issue date; status (active, revoked); public verification token.

Identity and ownership. Owned by Academy. Issuance and revocation are separated by role (Codex 4, "separation of duties" — the author of a credential standard is not the sole issuer against it, Chapter 08 §08.5).

Lifecycle. Created at successful completion of WF-01's credentialing stage; revoked (never hard-deleted) only through a documented procedure with a stated reason, itself an AuditRecord.

Relationships. n—1 Person; n—n Capability (exact versions); read via the permanent public verification boundary (API-05, Codex 5).

Retention. Retained permanently, without exception. A Credential's existence and validity outlive the deletion of the person's other data (Chapter 04 §04.11.5); verification must resolve for at least twenty years (Codex 5, "Contract rules").

07.13 ENT-09 — Curriculum

Purpose. The school, program, course, module, and lesson hierarchy that structures learning (Codex 5).

Key fields. Unit ID; unit type (school, program, course, module, lesson); parent unit reference; title; body or reference to content storage; prerequisite unit references; authoring status (draft, published, deprecated).

Identity and ownership. Owned by Academy. One canonical hierarchy; a unit is never duplicated across schools — shared content is referenced, not copied.

Lifecycle. Authored and versioned in TOOL-01; a meaning-changing revision to a published unit that scholars have completed against is versioned, not silently altered, so existing Enrolment and Progress records still resolve to what was actually completed.

Relationships. Self-referential hierarchy (parent/child); n—n Capability (via teaches, Chapter 06 §06.4); 1—n Enrolment; referenced by Knowledge Graph CurriculumUnit nodes.

Retention. Retained permanently once published, following the same deprecate-don't-delete rule as Capability (§07.10).

07.14 ENT-10 — Enrolment

Purpose. A Person's participation in a curriculum unit or cohort (Codex 5).

Key fields. Enrolment ID; Person reference; Curriculum unit reference; Cohort reference (nullable for self-paced); start date; status (active, completed, withdrawn, dormant).

Identity and ownership. Owned by Academy. One row per person per unit-or-cohort participation; re-enrolment after withdrawal creates a new row rather than resurrecting the old one, preserving an honest history.

Lifecycle. Created at WF-01 intake; status changes are Events; withdrawal is a soft delete (status change), never a row removal.

Relationships. n—1 Person; n—1 Curriculum unit; n—0..1 Cohort; 1—n Progress records (§07.15).

Retention. Retained permanently as part of the person's lifetime learning record; survives severance in anonymized aggregate form only.

07.15 ENT-10a — Progress

Purpose. The additive record of what a Person has attempted and completed within an Enrolment (Chapter 05 §05.6.2's Learning engine state, formalized here as canonical record).

Key fields. Progress record ID; Enrolment reference; Curriculum unit reference (lesson-level); state (unlocked, attempted, completed); timestamp.

Identity and ownership. Owned by Academy, written exclusively by the Learning engine (ENG-02, Chapter 05 §05.2.2).

Lifecycle. Appended on each state change; never overwritten (§07.2.4); a completion is recorded only when the required action was actually performed (Chapter 05 §05.6.2.1).

Relationships. n—1 Enrolment; n—1 Curriculum unit.

Retention. Retained as part of the lifetime learning record, identical retention to Enrolment.

07.16 ENT-11 — Cohort

Purpose. A time-bound group moving through curriculum together (Codex 5).

Key fields. Cohort ID; name; curriculum scope; start and end dates; sponsoring Organization reference (nullable); faculty assignment.

Identity and ownership. Owned by Academy.

Lifecycle. Created at scheduling; closed (soft delete) after its end date; historical cohorts are never deleted while any Enrolment references them.

Relationships. 1—n Enrolment; n—0..1 Organization.

Retention. Retained permanently as part of institutional and organizational history (Chapter 15, Chapter 16 reporting).

07.17 ENT-12 — Engagement

Purpose. An advisory relationship with an Organization or an executive (Codex 5).

Key fields. Engagement ID; Organization reference; assigned advisor Person reference(s); scope and commitments; status (active, closed); start and end dates.

Identity and ownership. Owned by Advisory (DIV-02).

Lifecycle. Created at engagement staffing (WF-02); closed at completion; commitments and risks recorded within it are append-only history, never overwritten (§07.2.4).

Relationships. n—1 Organization; n—n Person (advisors); feeds anonymized case material into Research (§07.20's derivation rule, Chapter 06 §06.9.3).

Retention. Retained for the institution's standard commercial record period; anonymized outcome material may be retained permanently as a derived dataset.

07.18 ENT-13 — Publication

Purpose. A research output with methodology and sources (Codex 5, Chapter 06 §06.2.4).

Key fields. Publication ID; title; authors (Person references); methodology summary; status (draft, published, retracted); linked Source references.

Identity and ownership. Owned by Research Institute.

Lifecycle. Authored in TOOL-05; published after editorial review; a retraction is recorded as a status change with a stated reason, never a deletion (mirrors §07.10's capability doctrine).

Relationships. n—n Capability (via discusses); n—n Source (via cites); referenced by Knowledge Graph Publication nodes.

Retention. Retained permanently once published, including retracted publications, since the retraction itself is part of the scholarly record.

07.19 ENT-14 — Index

Purpose. A published, versioned measurement series (Codex 5).

Key fields. Index ID; name; methodology reference; IndexValue history (period, value, methodology version at time of computation).

Identity and ownership. Owned by Research Institute. IndexValue rows are append-only; a methodology change produces new values under the new methodology version rather than restating history under a different method.

Lifecycle. Created at first publication; each period's value is appended, never revised in place — a correction is a new, annotated value with the original retained and marked superseded.

Relationships. 1—n IndexValue; consumed by WF-07 annual accounting and Chapter 16 reporting.

Retention. Retained permanently; this is the institution's own long-horizon measurement record (Chapter 16).

07.20 ENT-15 / ENT-16 — Venture and Investment

Purpose. Venture: a company in the incubator, accelerator, or studio. Investment: a capital relationship between a Person or Organization and a Venture (Codex 5).

Key fields (Venture). Venture ID; founder Person reference(s); program stage; milestones; status. Key fields (Investment). Investment ID; Venture reference; investor Person or Organization reference; instrument and terms; date.

Identity and ownership. Both owned by Ventures (DIV-04).

Lifecycle. Venture created at intake (WF-04); milestone history is append-only. Investment is created at close and is never edited after execution; a subsequent round is a new Investment row.

Relationships. Venture n—n Person (founders); Venture 1—n Investment; Investment n—1 Person/Organization.

Retention. Retained permanently as part of the institution's capital and venture history (Chapter 15).

07.21 ENT-17 — Artifact

Purpose. Any produced work: submission, memo, model, paper — the shared substrate that assessment, review, and credentialing act on (Codex 5).

Key fields. Artifact ID; producing Person reference; type; storage reference; version; visibility (private, shared-for-review, published).

Identity and ownership. Shared entity; the producing Person owns the artifact's content rights within institutional policy (Chapter 04 §04.4.3).

Lifecycle. Created on submission; new versions are new rows linked to the prior version, never overwrites, so review history remains attached to what was actually reviewed.

Relationships. n—1 Person; referenced by CapabilityAssessment, Engagement, Publication drafts.

Retention. Retained per the retention of the workflow that produced it; personal, unpublished artifacts are removed on severance except where retained as evidence behind an issued Credential in anonymized form.

07.22 ENT-18 — Event

Purpose. A record that something happened, with actor, subject, and time — the general-purpose occurrence log every other entity's lifecycle transitions are expressed through (Codex 5).

Key fields. Event ID; actor reference (Person, service identity, or agent); subject entity reference; event type; timestamp; payload summary.

Identity and ownership. Owned by Technology. Written by every engine and workflow as a side effect of a state change (Chapter 05 §05.5.4).

Lifecycle. Append-only; never edited or deleted; high-volume, expected to be the largest table in the system by row count.

Relationships. References any entity as its subject; 1—0..1 AuditRecord where the event is consequential (§07.23).

Retention. Retained per the institution's operational log retention policy; a subset promoted to AuditRecord is retained permanently regardless of the general log policy.

07.23 ENT-19 — AuditRecord

Purpose. An immutable record of a consequential action: any grant, elevation, revocation, deletion, credential issuance or revocation, or standing change (Chapter 04 §04.2.4, Chapter 08 §08.7).

Key fields. AuditRecord ID; source Event reference; actor; subject; action; stated reason (required for any elevated access); timestamp.

Identity and ownership. Owned by Technology. Never editable after creation; a correction is a new, linked AuditRecord, never an edit to the original (§07.4, mirroring Decision doctrine in Chapter 05 §05.6.6.1).

Lifecycle. Created synchronously with the consequential action it records; a consequential action that completes without a corresponding AuditRecord is a defect, not an acceptable gap.

Relationships. n—1 Event; readable by the subject Person (Chapter 04 §04.8.5) and by governance and security review roles (API-11).

Retention. Retained permanently, without exception, including through the severance of the subject Person (the fact of the access is retained; the subject reference is anonymized rather than removed, so the record of "an elevation occurred" survives even though "of whom" is severed where required).

07.24 Derived and anonymized datasets

07.24.1 A derived dataset (a research corpus, a reporting aggregate, a training set) is itself recorded: what canonical entities it was built from, the transformation applied, the anonymization or aggregation threshold used, and the date generated.

07.24.2 Anonymization is irreversible in practice, not merely policy: identifying fields are removed or the aggregation threshold is high enough that re-identification is not practically feasible (Chapter 04 §04.4.2, Chapter 16's reporting threshold).

07.24.3 A derived dataset is regenerated, not patched, when its source entities change materially, including when a source Person is severed; a revocation of consent is honoured at the dataset's next generation (Chapter 04 §04.7.3).

07.24.4 A derived dataset never becomes the system of record for anything; if a derived value is needed operationally, the operational system reads the canonical entity, not the derived copy.

07.25 Interfaces

API-01 through API-11 (Codex 5) each read or write a defined subset of the entities in this chapter · Chapter 05 engines hold private state that is not itself a canonical entity except where explicitly named here (for example, Progress, §07.15) · Chapter 06's Knowledge Graph references ENT-06, ENT-09, ENT-13 by ID · Chapter 08 governs access to every entity named here.

07.26 Invariants

1. 1Exactly one Person row per human being, for life (§07.2.2).
2. 2No role is ever stored on a profile-shaped table (§07.2.3, §07.9).
3. 3History-bearing entities are append-only or versioned, never overwritten in meaning (§07.2.4).
4. 4Every table carrying member data ships grants and row-level security in the same migration that creates it (§07.2.7).
5. 5Credential and AuditRecord outlive the severance of the Person they reference (§07.12, §07.23).
6. 6Monetary values are integer minor units with an explicit currency; no floating-point money (§07.3.3).

07.27 Prohibitions

1. 1A second Person row for a human already known to the institution, for any reason.
2. 2Storing a role, permission, or scope as a field on any entity other than Role.
3. 3Overwriting an assessment, credential, index value, or audit record in place.
4. 4Treating a derived or anonymized dataset as a canonical or operational source of truth (§07.24.4).
5. 5Shipping a member-data table without grants and RLS in the same migration.
6. 6Hard-deleting an entity referenced by an issued Credential, an AuditRecord, or an active Investment.

07.28 Open questions

1. 1Deceased standing. How Person.standing = deceased interacts with credential verification and memorial treatment is undecided (Chapter 04 §04.13.4).
2. 2Cross-border data residency. Where canonical entities must be stored to satisfy jurisdiction-specific law as the institution operates internationally is not yet specified (Chapter 18).
3. 3Artifact storage boundary. Whether large binary artifacts are stored inline or in a separate content store referenced by ID is an implementation choice not yet made; this chapter is agnostic but the reference-by-ID rule (§07.3.5) applies regardless.
4. 4Index correction disclosure. Whether a superseded IndexValue is shown by default alongside the current value, or only on request, is undecided (Chapter 16).

07.29 Governing Codices

Codex 5 (canonical entities, normalization, contract rules); Codex 4 (the canonical person); Codex 1 Article V, VI (measurement honesty, member rights); Chapter 04 (people and lifecycle); Chapter 05 (engine state that produces entities); Chapter 06 (graph references into this chapter); Chapter 08 (access to every entity named here).