TIM is mandatory: expertise vs financial models

TIM mandatory status in construction answers only one question: whether the developer has an information model and in what form it is submitted. After that comes a fork that the regulation does not describe. The model for approvals proves compliance with the design solutions and passes review. The model used to calculate costs must provide volumes linked to the classifier, units of measure, and rates. These are different requirements for model content, not two levels of detail of the same thing. Anyone who assembled the first and a year later tried to get the second from it ends up populating the model twice: once for the designer for review, and once for themselves - manually, in Excel.

The difference is not in geometry. A highly detailed consolidated residential model may still produce no lines in the bill of quantities if the elements are not classified, the units of measure are not set, and the identifiers change with every reissue. Below we break down what the model must contain for each of the two tasks, what the developer should do when the working documentation is issued in 2D and there is effectively no usable model, why the government systems need machine-readable formats, and which minimum requirements for the designer pay back from the first project.

The level of geometric detail and the richness of attributes are two different axes, and they grow independently. A model can be detailed down to fastening nodes and still produce no bill lines because the elements differ only by family name. Conversely, a modest geometric model with correctly assigned codes and units of measure is converted into volumes normally.

Three things make the jump from model to money. The classifier provides a common language: as long as one designer says "monolithic wall" and another says "reinforced concrete load-bearing structure," they are different lines, automatic calculation is impossible, and the project summary must be assembled manually. Units of measure define what is actually summed: concrete volume, formwork area, and reinforcement mass for the same element are calculated by different rules, and without an explicit unit the export produces numbers that cannot be compared with anything. Linking to the work item and rate closes the final step: the rate applies to the work item, not to the geometric body, so there is always a counting rule between the model element and the estimate line.

These rules are maintained by the client. The designer is responsible for the design solution and its composition, while the coefficients for consumption, cutting, reinforcement, and complicating factors are reference data on the client side, reused from project to project and not meant to be rebuilt each time. The division of responsibility here matters more than any platform: if the counting rules live inside the design organization, then when the contractor changes, the developer loses the ability to calculate its own cost price.

This is the reality on a significant share of projects, and it does not cancel reporting or the need to calculate cost price. There is no need to wait for the design organization to move to full TIM: volumes are assembled from what is actually issued.

The source becomes the designer's specification for the project section. It lists products and materials according to the design solution, but it contains no work items and no consumption coefficients, and you cannot turn it into a bill of quantities by renaming columns. A specification line becomes work and materials through the client's reference data: consumption beyond the design quantity, cutting and waste, conversion of structural volume into reinforcement weight, complicating factors, and building height. We explain the mechanics of this transition in full in the article bill of quantities.

Non-modelable elements live separately - cable, terminal fittings, installation consumables. They will not appear in any model, no matter how well it is populated, because they are not design solutions. They require their own list and their own norms, and that is needed regardless of whether you use TIM or not.

Controlling transfer completeness is easier than it sounds. Specification lines that do not become work and materials are highlighted and sent to the queue for reference-data completion - this lets the catalog grow from project to project instead of being built 100% in advance. There is no need to retrain the designer: missing attributes are captured through a reference form filled out together with the issue.

You do not choose state systems - you connect to them. ISUP receives project progress data for publicly funded projects, GISOGD manages urban planning data and permit documentation, and EGRZ stores expert review conclusions together with the set of submitted documents. Each of these systems expects data in a defined format and on a defined schedule, not an export done however it happens.

This is pure integration work: match internal reference data with external sources, ensure machine-readable export, comply with the transfer rules, and be able to show where every number came from. It is done once and reused across all projects - but only if the data in the model and in the accounting system is structured. From an unstructured model, every export to a government system has to be assembled manually again.

Practical takeaway for developers: the government systems side is another argument for attribute discipline, not for buying another platform. Which systems must be integrated and which products cover adjacent areas are explained in a review of construction and BIM software in CIS.