Where the standard stops, where the platform stops

1ST-Bridge — what Japan's structural data standard carries

Japan has a structural data exchange standard called ST-Bridge. It is an XML format maintained by buildingSMART Japan that carries 通り芯 (grids), member placement and section marks together with rebar placement information. It is a Japan-specific standard that grew out of the judgement that IFC alone made integration with integrated structural calculation software difficult.

What matters is how it carries that information. The specification defines the principle of rebar representation as follows — “representation of rebar placement by grade, diameter and number of bars or pitch, as in the section table (断面表) of a structural design drawing”. In other words, a table, not the three-dimensional geometry of an individual bar.

Opening the schema and checking it, the following information does not exist.

And this is not an oversight but a gap the specification itself acknowledges. For the element concerned, the specification states that it “assumes giving the fabrication and assembly of rebar, development lengths and so on”, and explicitly notes that “detailed definitions will be made in a later version, reflecting actual practice”.

2A standard exists — how much actually crosses is another matter

The second fact is not about the standard but about its implementations. “Supports ST-Bridge” on a datasheet does not mean every product exchanges the same information.

And the body that wrote the standard measures this itself and publishes it. buildingSMART Japan’s Information Interchange Map rates each listed application’s import and export support attribute by attribute on a ◯△× scale, then expresses the degree of interoperability for each pairing as a percentage. For RC alone there are 1,201 evaluation items.

Those figures vary widely by pairing. Two products can both claim the same standard, and how much information actually survives the trip still depends on which one is sending to which. That a standard exists and that it is implemented uniformly are separate questions — and the authors of the standard have quantified the gap themselves.

But both of these are questions of how well something is carried across.

The fact from the previous section — that the geometry of an individual bar is not in the payload to begin with — survives any improvement in implementation.

3Revit — why things get heavy once rebar goes in

Rebar is the object for which the element count per member explodes. A single column holds dozens of main bars, hoops and reinforcing bars; across a whole building it runs into the hundreds of thousands. So most practitioners have experienced that handling rebar on a BIM platform makes things heavy.

Whether that is a matter of how it is used or a matter of architecture can be checked against Autodesk's own official documentation.

• The CPU recommendations in the official Help put the performance gain from multiple cores at “up to 20%”
• The same document recommends a CPU with a large L3 cache — because model regeneration runs single-threaded
• There is a dedicated support article on rebar elements being slow to copy, move and edit, and its first recommended action is to lower the detail level of the view — that is, to draw rebar as lines rather than solids

The workaround is the same everywhere in the world: split the model and reference it by link. Move the rebar into a separate file, link it in, show it only in the views that need it, and lower the detail level. Autodesk's own guidance for large projects likewise recommends splitting, linking and managing model states.

A “open it whole, handle it whole” answer does not appear in the official documentation either.

This is not a jab at any particular product. It is a question of what a code base over twenty years old can carry, and it is something the vendor states in its own documents.

One important implication follows. An add-in that computes inside Revit inherits that same ceiling. However well optimised the add-in is, model regeneration and element creation still happen under the platform's rules.

4The conclusion that remains

In summary, the situation in 2026 is this. Integrated structural calculation has been standardised (a data exchange standard exists, if unevenly implemented), BIM authoring has been standardised (mature platforms and template ecosystems), and the legal deliverable has been standardised too (2D drawings).

Only the layer in between — the physical reality of each individual bar and its coordination at joints — has no standard, and no platform fills it directly.