1. Agree what the exchange is for
Start by describing the next task. Is the structural engineer establishing the first analytical model, reviewing a particular part of the building, or comparing an architectural revision? The answer determines which source version and scope should accompany the handoff.
Record the project, building or zone, revision identifier, and expected destination. Include a short note explaining any intentional exclusions. This small record makes it easier to distinguish a missing element from a deliberate boundary around the work.
- Identify the person who owns the source model and the person receiving it.
- State whether the exchange covers the whole project or a defined subset.
- List open questions that could affect interpretation of the model.
2. Understand what the format represents
SAF is a spreadsheet-based exchange schema focused on structural analytical information. IFC is a broader open standard for built-environment objects, properties, and relationships. They serve related exchange needs, but they do not describe an identical package of information.
Graphisoft documents SAF export from ArchiCAD’s analytical model and separate IFC export translators. Confirm the appropriate format, version, and settings for your actual receiving workflow. A filename ending in the expected extension is not enough to establish that the contents are suitable.
3. Make the export choices visible
For a SAF export, note the translator and the selected export scope. Graphisoft’s export documentation distinguishes the entire project, visible elements, and selected elements. A review of the scope can explain why the receiving model contains fewer members than expected.
For IFC, record the translator, schema, and intended exchange purpose. Graphisoft’s translators determine which elements are converted and how information is interpreted. Keep any adjustments to these settings with the handoff record so a later revision can use a comparable setup.
- Check which elements the export includes.
- Review the intended material and section mappings where relevant.
- Note the units and coordinate conventions the team expects.
4. Inspect what was actually exported
Use the exported result as the object of the check. Looking only at the authoring model can miss a filter, mapping, or view choice that affected the exchange. Start with a few recognisable references: the building extent, a typical floor, an unusual junction, and a known opening.
Then check representative element information. Can the receiving workflow identify the intended member, section, and material? If something differs, record the source element and the observed result. A specific example is more actionable than a general report that the file looks wrong.
5. Send a model with a useful history
Keep the original export together with its source revision and a short handoff note. Choose a naming convention that makes the issue identifiable without relying on a message thread. Retain the previous agreed issue when the new file is a revision.
Make unresolved points easy to find. A changed core wall, an excluded area, or an uncertain material assignment deserves a precise reference. The goal is to give the engineer enough context to begin review without reconstructing the history of the export.
Where NodeSnap fits
NodeSnap’s workflow takes ArchiCAD SAF or IFC exports into conversion, builds the analytical skeleton, and checks converted elements against their source before the result moves into LIRA-SAPR. A clear handoff gives those checks the right context.
For a first conversation, describe your ArchiCAD version, preferred exchange format, typical model, and current handoff problem. Discuss the export details with the team rather than assuming that every schema, translator, or unusual geometry behaves identically.