YAML data model

simple-plm stores all PLM data as YAML files in a Git repository rooted at plm-data/. There are no database tables for parts, BOMs, or ECOs — only files. This is a hard design constraint, not a convention: the dashboard, CLI, and API read and write the same files.

On-disk layout

plm-data/
├── parts/
│   └── <PN>/
│       ├── part.yaml
│       └── attachments/        # datasheets, drawings, 3-D models
├── boms/
│   └── <PN>.yaml               # one BOM per parent part
├── ecos/
│   └── <ECO-ID>.yaml
├── manufacturers/
│   └── <name>.yaml
├── suppliers/
│   └── <name>.yaml
└── releases/
    └── <tag>.yaml              # generated manifest per release

Filenames are deterministic, derived from the entity’s primary key (PN, ECO ID, supplier name). Renaming requires a Git move plus a search-and-replace in any referencing files — the dashboard and CLI handle this for you on the rare occasions it’s needed.

Why YAML and not SQL?

YAML files in Git buy you three things:

1. Auditability — every change is a commit. git blame answers “who changed C12’s tolerance, and why?” in seconds.
2. Branchability — proposals are branches, not staging tables. Two ECOs can progress independently without elaborate locking.
3. Tool interoperability — anything that can read a file can read simple-plm data. Engineers can grep their PLM. CI pipelines can lint it. AI agents can stream entire orgs’ worth of YAML into a context window.

The cost is that some operations (cross-part aggregate queries, full-text search) need an index rebuilt on each push. simple-plm runs that index inside your tenant pod, transparently.

Schemas

Each top-level type has a JSON Schema enforced by the API. Editor integrations (VS Code, JetBrains) can resolve schemas via # yaml-language-server: $schema=... directives at the top of each file. Schema violations are rejected at write time, not silently persisted.