Define the exchange purpose
An in-house IFC standard should begin with the information use it must support. Coordination, quantity review, fabrication, and asset handover do not necessarily require the same object detail or properties. If one export configuration is expected to serve every use, teams may deliver unnecessary data while omitting critical fields.
State the receiving application or process, expected IFC schema and exchange view where applicable, and acceptance test. That makes the standard a practical contract between authoring and receiving tools rather than a collection of preferences.
Set units and coordinate rules
Unit and location errors can make a geometrically plausible model unusable. Define project units, coordinate reference, rotation, elevation datum, and any transformation procedure. For a hypothetical bridge package, coordinate verification might use the alignment start point and two survey control locations checked independently after export.
Do not rely on a viewer's default display to prove the model's real-world position. Include a known-distance and known-elevation check. Require the exporter to document which coordinate basis was selected and the receiver to verify it.
Make object classes meaningful
IFC classes and types help recipients understand what an object represents. A structural column exported as a generic proxy may retain a shape yet lose useful meaning for filtering or downstream checking. Define mappings for the recurring object types in the project's scope and identify justified exceptions.
Do not force every element into a familiar class if that class misrepresents its function. When the schema lacks a suitable concept or the authoring software cannot map it reliably, record the limitation and agree a consistent fallback with recipients.
Read diagram notes
- Authoring rule
- Objects, units and properties
- Exchange mapping
- Schema, class and configuration
- Receiving check
- Known sample and exceptions
Agree property names and values
Property information should answer a downstream question in a stable way. Define whether a property is required, its data type, allowed units or values, and which party authors it. A field called 'Material' may contain a specification grade in one model and a generic family name in another.
For a sample reinforced concrete package, the exchange may need a consistent material designation and element identifier, but it should not imply that a model property is the approved structural specification unless governance says so. Avoid duplicating a native parameter under competing names.
Specify representation boundaries
A coordination model needs enough geometry to reveal relevant interfaces, while excessive detail can slow review and create false precision. Agree which components are included, how openings and embedded items are represented, and whether analytical objects are included or separate. Define treatment of temporary works and objects hidden in authoring views.
An export should not accidentally omit items because a view filter was active. Use a known sample containing typical members, openings, connections, and annotations to test expected inclusion and exclusion.
Write responsibility into the procedure
A standard needs owners. Identify who maintains the mapping tables, who configures each authoring tool, who exports, who validates, and who accepts deviations. If several disciplines use different software, keep a shared test model that exposes their common exchange requirements. A change to the standard should include a version, reason, affected workflows, and migration date.
This avoids silent divergence when a project template evolves. The process should also state when a deviation requires approval and how it is recorded in the delivery.
Validate both content and behavior
Validation should examine more than whether the IFC file opens. Check units, coordinate placement, object classes, required properties, relationships, quantities, and critical geometry against known reference cases. Compare the export to the native model and, where practical, inspect it in a second application. A report should distinguish a software limitation from a model-authoring omission.
Re-run the same checks after exporter or template changes. Passing a test suite shows conformance to the agreed exchange criteria; it does not establish that the underlying structural design is adequate.
Keep the standard lean and useful
A standard that is too long will be ignored; one that is too thin leaves critical choices to chance. Start with recurring exchanges and expand only when evidence shows a need. Put stable project rules in the main document and tool-specific settings in maintained appendices.
Include examples of a good file, a failing file, and the acceptance report. Review the standard after a real exchange failure or a new use case, not merely because a software release appeared. Its value is measured by fewer ambiguous handoffs and more predictable receiving behavior.