For a long time the construction industry followed LOD — but everyone had the same question: does it really need this much information?

Things changed with LOIN. People started asking "which data do we need to build?" and "what do we need this data point for?"

Concepts evolve, software innovates. The move from an LOD to a LOIN baseline finally landed.

But ultimately, has the effort on modeling, takeoffs, and estimates improved?

Did the complexity in software actually come down?

Read more: https://bimsta.com/docs/lod-vs-loin/

#Bimsta #BIM #CAD

"LOD" and "LOIN" get used interchangeably all the time — and it quietly causes confusion on real projects. They aren't the same thing. LOD (Level of Development) is a fixed ladder you climb, 100 to 500, with geometry and data advancing together. LOIN (Level of Information Need, from ISO 19650) flips the question entirely: not "how developed is this element?" but "what do we actually need to know about it, for what purpose, and by when?" — with geometry, data, and documentation each specified on their own. The takeaway holds either way: model to the level the decision in front of you needs, and don't pay for detail nobody will use.

Put together a breakdown of what each LOD stage actually means for a model's geometry and data, and how much you can rely on it at each point. The framing is reliability, not visual detail: higher LOD means you can use the element for more decisions (cost, coordination, fabrication), not that it just looks busier on screen. Also covers why AIA added 350 between 300 and 400, and where most architectural vs structural/MEP work actually lands.

We’re just starting out here. I want r/Bimsta to be more than just "how to use Revit." I think we stand for:

1. Data over Drawings.
2. Collaboration over Silos.
3. Integration as a Phase, not an Afterthought.
4. Open Standards (IFC, BCF) as the backbone. Does this resonate? What else should define our community?

A core "Bimsta" principle: Automation. Whether it’s Dynamo, Grasshopper, or a Python script, we should automate repetitive tasks (renaming, sheet creation, parameter syncing).

What is the one task in your BIM workflow that you wish you could automate today? Let's brainstorm some solutions.

In software, "Technical Debt" is the cost of choosing an easy solution now instead of a better approach that takes longer. BIM has this too:

• Exploding CAD imports instead of modeling properly.
• Generic models instead of specific families.
• Overriding graphics instead of fixing the underlying data. Eventually, the debt comes due during the coordination or construction phase. How do you keep your "model debt" low?

Think of the IFC file as the API (Application Programming Interface) of your building. It’s the way different systems talk to each other.

When we export an IFC, we aren't just "printing a 3D PDF." We are exposing a data schema for MEP, Structural, and FM teams to consume.

If your "API" is broken (bad exports, missing property sets), the whole "integration" fails. Tip: Test your IFC exports in a third-party viewer before you send them. Don't assume the export worked just because the progress bar finished.

We all say the BIM model is the "Single Source of Truth," but then we have 5 different Excel sheets, 3 PDFs, and a WhatsApp group for coordination. If it’s not in the model (or the linked database), it doesn't exist. For our "Bimsta" workflow, let's commit: If a coordination decision is made in a meeting, it must be reflected in the model metadata within 24 hours. No data silos!

In software, no one pushes code to production without a peer review. Why do we treat BIM models differently? In our "Integration" phase, we should be doing Model Reviews not just for clashes, but for "data cleanliness."

• Are the naming conventions followed?
• Is the metadata populated?
• Is the "logic" of the family/object sound? If we treat our models like code, we catch the "bugs" before they become expensive site errors. Who’s doing formal peer reviews on their teams?

Do you have a dedicated "integration" phase in your BIM design workflow?

I’ve been thinking about this a lot lately. When we share models with MEP or Structural teams, we shouldn't just send the native files and hope for the best. Always include the IFC file.

Why?

• Reduces Rework: It catches discrepancies early in the other disciplines' environments.
• Streamlines Workflow: It ensures the data "speaks the same language" across different software.
• Quality First: You solve conflicts long before a single brick is laid on-site.

In the software engineering world, we call this Integration Testing. We don’t treat a "bug" found during testing as a professional failure; it’s just part of the collaboration.

Think of it like this: My perfectly designed model meets your perfectly designed model, but they don’t speak the same language yet. The integration phase is where they learn to communicate.

How are you handling your handoffs? Are you using IFCs as a standard, or is it still a "send and pray" situation?

Hey everyone! I'm u/tuning101, a founding moderator of r/bimsta. This is our new home for all things related to Bimsta. We're excited to have you join us!

What to Post Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about Bimsta, BIM modeling, IFC.

Community Vibe We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started 1) Introduce yourself in the comments below. 2) Post something today! Even a simple question can spark a great conversation. 3) If you know someone who would love this community, invite them to join. 4) Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/bimsta amazing.