A city wants models for permitting: business concepts first, then normalized attributes and keys, then tables and indexes. Which sequencing of model levels is correct?

Sound municipal modeling sequences meaning before storage. For permitting, start with a conceptual model of business entities and relationships, refine into a logical model with detailed attributes and keys, then implement a physical model of tables, indexes, and storage. That order keeps business intent visible when engineers choose physical optimizations and prevents column names from becoming the only “definition” of a civic concept. Building physical tables first and inventing business terms afterward reverses the sequence and embeds accidental structure into language. Treating logical and physical models as interchangeable labels erases the distinction between technology-neutral design and platform-specific implementation. Claiming conceptual models exist only after production hotfixes abandons upfront clarity and invites uncontrolled drift. Exam items test sequencing: conceptual → logical → physical. Caveat: agile delivery may iterate these levels, but skipping conceptual alignment for shared civic entities still creates cross-department conflict. Operationally, before new permit tables are created, confirm an approved conceptual entity list and a logical attribute model exist, then verify the physical DDL traces to those artifacts rather than to ad hoc hotfix names.