# Anatomy of a model repository

*Building a meta-model · lesson 1 of 6 · ~15 min*

## What you will learn

The canonical shape of a conformant model repository: every reserved location, what belongs in it, and why the shape itself is a contract.

## The canonical tree

```text
meta-model/
├── README.md               # human landing
├── BOOTSTRAP.md            # operating instructions: how to read this model (read first)
├── LICENSE
├── CHANGELOG.md
├── manifest.yaml           # walk declaration: bundle order, classification, exclusions
├── sources.yaml            # Data Mastership Register: who masters each dataset
│
├── bundles/                # the model data: bundles → layers → records
├── canon/                  # source texts this model treats as ground truth
├── raw/                    # unprocessed harvested captures (never hand-edited)
├── artifacts/              # generated, regenerable outputs (never authored)
├── imports/  ├── mappings/ # external standards and alignments to them
├── schemas/  ├── examples/ ├── diagrams/ ├── docs/ └── tools/
```

Each location carries a fixed meaning, so a reader (human or agent) never guesses what a file is from vibes.

## The two entry points

**`BOOTSTRAP.md`** is for minds: how to read this model, in what order, what the local conventions are, what you must not touch. **`manifest.yaml`** is for machines: identity, bundle order, file classification rules, exclusions. Everything else is reachable from these two. If your ecosystem already has an entry file (a `CLAUDE.md`, an `AGENTS.md`), keep it, but make it point to BOOTSTRAP: one structural source of truth.

## The four content temperaments

Everything in a model has one of four temperaments, and they never mix:

1. **Authored** content (bundles, policies, docs): written by people or agents-as-authors, edited in place, reviewed like code.
2. **Canonical** texts (`canon/`): documents the model is *about* or *bound by*: a doctrine, an adopted decision, the meta-model spec you conform to. Layers reference canon; they never paraphrase it. If a record and a canon text conflict, canon wins.
3. **Harvested** evidence (`raw/`): captures from external systems: exports, dumps, crawls. Organized `raw/<system>/<dataset>/`, each with a provenance sidecar (source, scope, extraction time, tool). Hand-editing a capture destroys its evidentiary value: corrections happen at the source (then re-harvest) or as annotated model records.
4. **Generated** outputs (`artifacts/`): computed views, reports, walk results. The test of a healthy `artifacts/`: delete it entirely, regenerate, nothing of value lost.

## Real example: a platform model

The DevTeam.Games model shows the shape absorbing a messy reality: its `_raw/` (a legacy name, mapped in the manifest) holds a ClickUp export frozen at the tracker's retirement, competitor research and design captures; `00-meta/` holds a vendored mirror of the AISMM canon with provenance sidecars; the platform's actual source code is attached as external git clones, present on disk but declared as mirrors mastered elsewhere. 2613 files, every one classified. Legacy layouts did not need renaming: the manifest maps old names to reserved meanings.

## Key takeaways

- Two entry points: BOOTSTRAP.md for minds, manifest.yaml for machines.
- Four temperaments (authored, canon, harvested, generated) with reserved homes; they never mix.
- Legacy layouts survive: mapping beats renaming.

## Go deeper

- [MMAS-Package: repository and package structure](/spec/#02-architecture/MMAS-Package.md)
- [Model traversal and well-known locations](/spec/#02-architecture/Model-Traversal-and-Layout.md)

Next: [Bundles, layers, records](02-records.md)