Comparison

BIM software comparison: authoring, coordination, data and decision infrastructure

Most BIM tool comparisons compare features. This one compares categories, because the useful question is which job a tool is built to finish.

8 min read · Updated 2026-09-15

Buying teams often compare BIM tools that are not actually competing. An authoring tool and a decision layer are no more interchangeable than a word processor and a contract register. The useful comparison is by category: what job does this class of software finish, and what does it deliberately leave to something else?

The four categories

CategoryCore jobTypical examplesWhere it stops
AuthoringCreate and modify the model: geometry, types, documentationRevit, Archicad, Vectorworks, AllplanHolds descriptions, not governed commitments or priced decisions
Coordination and reviewFederate models, find clashes, run issue workflowsNavisworks, Solibri, BIMcollab, BIM TrackAnswers 'does it fit and comply with checks', not 'what should we choose'
Common data environment / data platformStore, version, share and query project informationACC, Trimble Connect, Speckle, Bimsync-style platformsMoves and exposes data; does not own deterministic decision authority
Decision infrastructureResolve elements to governed systems, products, cost and carbon with receiptsLITHIC CoreDoes not author geometry; consumes model evidence from the layers above

Questions each category can actually answer

  • Authoring: what is modelled, where, and in what nominal build-up?
  • Coordination: do the models agree with each other and with rule-based checks?
  • Data platform: where is the current information, which version is it, and who can see it?
  • Decision infrastructure: which system, product, price and carbon figure does this population resolve to — and can we prove why?

Notice that only the last question needs an answer that survives argument. That is why decision infrastructure is defined by receipts rather than by views.

Where teams usually feel the gap

The gap shows up as spreadsheets. Quantities exported and re-counted. Product choices tracked in a side document. Carbon calculated in a separate tool from a separate material list. Prices pasted from a supplier email. None of those artefacts are versioned against the model surface they came from, so by the third design iteration they disagree with each other and nobody can say which is right.

Adding another dashboard does not fix this, because the problem is not visualisation. The problem is that no system owns the commitment, so every consumer re-derives it.

How to evaluate a decision layer

  1. Ask it to show the evidence behind a single number, down to the model version and viewable it came from.
  2. Change one input and check that the output changes deterministically, and that the previous result is still readable.
  3. Remove a piece of evidence and confirm the tool refuses rather than substituting a default.
  4. Check that partial coverage is stated as partial, not presented as a whole-building total.
  5. Check that product and price data carry versions and sources, not just values.
  6. Check that AI suggestions are clearly separated from committed decisions.

Does it replace your existing stack?

No — and a vendor claiming otherwise should worry you. Decision infrastructure sits downstream of authoring and alongside the common data environment. It reads published model evidence, applies governed rules, and writes commitments. Your architects keep authoring where they author; your coordinators keep coordinating; the decisions stop living in spreadsheets.

LITHIC Core is built for that position specifically: model evidence in, governed classification, products, price and carbon out, with a replayable receipt behind each result.