Ask what the object represents
Infrastructure models include more than proposed construction. A model may contain existing assets, restrictions, design geometry, survey observations, derived surfaces, and setting-out data. These object types serve different purposes and should not be treated as interchangeable. A line can represent a surveyed edge, a proposed alignment, or a calculation output.
Give each object a meaningful class or role, stable identity, and source so users understand whether it is measured, designed, or derived.
Distinguish source data from result data
A terrain surface may be calculated from contours or point observations. The surface is a result, not a raw measurement. Keep the relationship to its inputs and method. For a hypothetical drainage design, a catchment boundary derived from terrain should be traceable to the terrain version and hydrological assumptions used.
If source data changes, teams can identify which results may need recalculation. Without that link, derived geometry may persist long after its basis has changed.
Choose geometry that matches the role
Points, lines, surfaces, and solids each communicate different information. A survey control point needs a location and reference; an alignment needs linear geometry and stationing; a pavement course may need a surface or volume for quantity work. A 3D solid is not inherently better if the underlying evidence supports only a line or approximate envelope.
Define geometry requirements based on downstream tasks and disclose simplifications. This reduces oversized models and prevents visual detail from suggesting unsupported precision.
Read diagram notes
- Identity
- Stable asset or object key
- Meaning
- Measured, designed or derived
- Provenance
- Origin, method and revision
Make identifiers stable
A unique identifier lets people relate an object across revisions, reports, and external systems. Names alone can be duplicated or changed. Define how identifiers are created, who maintains them, and whether an object retains its identity when geometry changes.
For a road drainage system, a chamber ID should correspond to the asset register or delivery package where required. If objects are split or merged during design, record the relationship so quantities and issues can be reconciled.
Attach properties with a defined meaning
Properties should be selected because they support a decision or exchange. A 'status' field may mean design phase, existing/new, or review state; one overloaded property invites inconsistent values. Define field name, type, units, controlled values, and authoring responsibility. For example, an existing utility's verification status should not be confused with its operating condition.
Keep the data dictionary short enough for model authors to apply consistently and recipients to understand.
Use the object register for review
Group model objects by semantic type and inspect outliers. A large share of generic proxies may reveal weak classification; objects without identifiers may be impossible to track; a derived result without source links may need review. Such signals guide investigation rather than prove a defect.
Compare a sample against the project's object requirements and consult the relevant engineer or surveyor. A disciplined review looks at meaning and evidence, not only appearance.
Manage cross-domain objects
Some objects sit between disciplines: an embankment near a structure, a utility within a road corridor, or an environmental exclusion zone affecting construction. Define the authoritative author and reference relationships. Avoid duplicated copies that diverge. If multiple teams need the same geometry, establish which model owns it and how other models reference or consume it.
This makes design responsibility clearer and helps avoid incompatible updates.
Carry semantics through exchange
When exporting to IFC or another format, check that class, identifier, properties, and spatial relationships survive. Open the result in a receiver tool and test queries that the next participant will perform. A visually correct object with lost semantics may be unusable for scheduling, quantities, or asset data.
Record known export limitations and an agreed workaround. The goal is to preserve enough meaning for the next task while keeping the exchange honest about its boundaries. A useful object review samples both common and unusual components. Inspect a typical chamber, a boundary crossing, a temporary diversion, and one derived surface.
Ask the author to explain each object origin, meaning, and intended use without relying on undocumented personal knowledge. If another team cannot interpret the object consistently, improve its classification or delivery note before the exchange. This check is especially valuable when models pass through multiple companies.