Code Review Data Model Skill

When you must assess a component's data model — its domain types, entity models, schemas, and kernel data structures — against the data-oriented design criteria: layout, value semantics, hot/cold split, batch access. Use before major data-model refactors, when onboarding to a component, or periodically to track data-model debt. It is the single-lens complement to the broad compass-code-review-component audit. For PR-delta reviews, use compass-code-review-pr.

1. Identify the component(s). Components live under projects/ores.<component>. To see all known components:

   ./projects/ores.compass/compass.sh list --type component
   

2. Classify the regimes. For each component, map its parts onto the three regimes in Data-Oriented Design in ORE Studio: numerical kernels (Regime 1), persisted domain data (Regime 2), wire and messaging (Regime 3). A component spans regimes; state which part is which and why. Document-shaped payloads sit outside the three regimes — the knowledge doc states the boundary.

3. Gather the data-model artefacts. Regime 2 review walks two surfaces, and the checklist states which surface each check applies to:

   • The decision surface: the modeling/*.org entity, junction, and field-group models. The lookup_entity metatype is reserved but has no authored instances; do not hunt for lookup models.
   • The invariant surface: the domain C++ types codegen generates from those models, and hand-written domain headers in the core facet.

   Also gather, per regime: the SQL schema the entities map to (the CREATE TABLE statements under projects/ores.sql/create/<component>/); repository and service signatures; and kernel entry points with their inner loops.

4. Apply the matching checklists. The checklists live under * Review criteria in the knowledge doc. Walk the Regime 1, 2, or 3 checklist for each classified part; on Regime 2, walk the decision checks per entity model and spot-check the invariant checks once per component. Mark checks outside a part's regime as not-applicable — never demand SoA of a CRUD entity, never accept a pointer graph inside a simulation kernel, and never force table-shaped or flat-message checks onto document-shaped payloads.
5. Apply the evidence rule. Hot-path claims need the loop structure, a profile, or a benchmark as evidence. Without evidence, record a layout risk as an opportunity, not a defect.
6. Score and report. Per component: a 1-5 score per applicable regime using the scoring anchors in the knowledge doc, a findings table (severity, effort, mapped criterion), an overall data-model verdict, and a debt level of Low / Medium / High. Follow the report conventions in the knowledge doc.
7. Summarise. Conclude with the per-component score table, the top 3-5 recommendations, and the overall debt level. This skill only reviews — filing remediation stories is a separate decision made through the backlog.

• How do I show a doc by UUID? — to inspect the component's component_overview.org and its modeling docs.
• How do I find docs matching a pattern? — to enumerate a component's modeling files, tasks, and stories.

• Data-Oriented Design in ORE Studio — the criteria, regimes, and report conventions this skill applies.
• Code Review Checklist — the sibling criteria set for general component and PR review.
• compass-code-review-component — the broad whole-component audit this lens complements.