Aliases: Zachman; ontology; what; how; where; who; when; why; reification; architecture.
Use six interrogatives across six transformations to locate a missing description or an inconsistent representation. Questions: What (things/relationships), How (transformations), Where (distribution/connections), Who (responsibility), When (events/timing), Why (motivation). Transformations: identification, definition, representation, specification, configuration, instantiation. These are neither runtime stages nor levels of detail. Telescoping is reading access to relevant detail; reification changes the kind of representation.
For a Rust change, distinguish: the owner's meaning; a technology-independent relationship model; the Rust/storage realization; configured artifacts; observations from actual work. Do not let a type selection stand in for the owner's mandate or current runtime evidence. A source module is not a complete deployment/distribution description.
Example: requiring confirmation changes the entry policy's business meaning and the relevant How/When conditions. The entry model, selected ConfirmedOnly realization, configured instance and initial/later visit outcomes must agree. It does not thereby change registration password policy or make delivery depend on entry. A claim of process durability is unsupported by an in-memory realization even if every static composition compiles.
The doctrine's worked workshop map covers all 36 intersections as a bounded example. It does not require 36 documents per task. Use existing code, decisions, schemas, configuration and observations when they supply the relevant descriptions. Unknown facts and external boundaries remain explicit; an occupied cell is not proof of truth or completeness of the whole enterprise.