functional-choosing-types-or-plain-datalisted

# Choosing Types or Plain Data ## Overview There are two coherent schools of functional design, and this pack is built on one of them. **Type-first** says: name every concept, give it a type, and make illegal values unbuildable. The rest of this pack teaches it. **Data-first** says: keep data as generic maps and lists, keep code separate from data, and put the schema outside the data as a separate value you can compose, store, and generate. Nothing in the data is hidden behind a constructor, so every generic operation — project, diff, merge, serialise, audit — works on everything. Both are real positions held by serious people. They disagree, and the disagreement is not resolvable in general. It is resolvable per value, on facts you can observe about that value, and that is what this skill is for. **The default in this pack is type-first.** This skill says when to leave it, not that it is optional. ## When to use - Choosing between a domain type and a plain map for a shape - The field set is defined outside the code - Wrapper types are multiplying and each one feels like paperwork - A generic operation must work across many shapes - Reviewing a design that models everything, or nothing Not for: choosing **which** type once you have decided to model something. That is [functional-modeling-with-algebraic-types](../functional-modeling-with-algebraic-types/SKILL.md). ## The default: model it Model the shape. Do not weigh this up each time; the cases below are the whole