# ifc-element-type instructions
Purpose: authoring the 132 concrete `IfcTypeObject` subtypes, the type
definitions occurrences inherit their shared description from.
Follow `../AGENTS.md`. Read `PLAN.md` only when assigned implementation or
roadmap work; record progress, blockers, and evidence there, not here.
## Boundary
Allowed production dependencies: `ifc-model` only. This crate holds no
domain semantics: a pump type and a task type differ only in their slot
table row, so no HVAC or scheduling knowledge belongs here. Occurrence
entities stay in their domain crates.
## Why one crate for many domains
The catalogue spans HVAC, structure, furniture, resources and processes,
which looks like a boundary violation. It is not. These 132 entities are
one shape with one shared WHERE rule; splitting them across domain crates
would copy the same rule and the same slot table into a dozen places, and
each copy would drift.
## Generated code
`src/table.rs` is generated by `scripts/gen-element-types.py` from
`references/ifc-spec/ifc4x3-add2/IFC4X3_ADD2.exp`. Do not edit it by hand:
regenerate. `tests/authoring.rs` asserts the catalogue invariants a bad
regenerate would break, rather than restating 132 rows.
## Pitfalls
- Slots 6 and 7 mean different things per `Family`. Element types hold
`RepresentationMaps` and `Tag`; the nine resource and process types hold
`Identification` and `LongDescription`. Writing slot 7 blindly files a
tag as a description on those nine.
- `PredefinedType` is at slot 9 for most types, 10 for `IfcFurnitureType`,
and 11 for the six resource types. A hardcoded 9 writes a predefined
type into a cost list on those six.
- The `USERDEFINED` fallback is always slot 8, but its *name* differs:
`ElementType`, `ResourceType` or `ProcessType`.