Geotechnical design and interior design look worlds apart. One deals with effective stress and settlement; the other with the materials and experience of a space. Yet from a data management perspective they are strikingly alike. Both have objects and properties, calculations and standards, provenance and change, approval and construction status. The expertise differs by discipline, but the operating principles can be shared.
The Same Questions Recur, Whatever the Discipline
A geotechnical engineer must explain which stratum, which test, and which design judgment produced a friction angle of 30 degrees. A structural engineer must show which load combination and member forces determined a 400×700 beam section. A steelwork engineer checks which design force and which detail drawing the bolt count and plate thickness at a connection are tied to. A finishes lead manages how the wall finish in a given space connects to its substrate, thickness, material, sample approval, and quantities.
The wording of the question differs; its structure does not. “What is this object?”, “What properties does it carry?”, “Where did the value come from?”, “Which calculation and which standard were applied?”, “What changed, and who approved it?” That shared structure becomes the kernel of the platform.
The Common Kernel Must Be Thin and Strict
Making the common data model large feels like a way to accommodate every discipline, but in practice it mostly multiplies abstract attributes. The kernel should carry only the concepts every discipline needs: project and document, object, property, unit, formula, rule, source, revision, issue, and approval. Each Domain Pack then takes responsibility for the specialist vocabulary and calculation logic.
`Property`, for example, is a shared concept, but it materializes as N-value and cohesion in geotechnics, as concrete strength and member forces in structures, and as thickness and waste rate in finishes. `Formula` is shared too, yet bearing capacity equations, steel connection checks, and plastering quantity calculations each need their own verification suite. The purpose of commonality is not to collapse the equations into one, but to trace, in the same way, which objects, inputs, evidence, and versions each equation is connected to.
Geotechnical Domain Pack: The Context of Judgment, Not Just the Value
Geotechnical data carries high uncertainty and spatial variability. An N-value from a single borehole is never adopted directly as a design parameter; it passes through stratum classification, test quality, sample disturbance, groundwater conditions, continuity with adjacent boreholes, and the designer's conservative judgment. The Geotechnical Pack must therefore express not only the number in the table but also its range of applicability and its confidence status.
A friction angle of 30 degrees for weathered soil, for instance, has to carry links to the boreholes and tests behind it, to whether it came from a direct shear test or an empirical correlation, to the excavation zone it applies to, to which anomalous strata were excluded, and to which KDS or project standard was used. Only then can you catch the case where the earth retaining calculation sheet and the foundation calculation sheet use different values under the same name.
Structural Domain Pack: The Contract Between Model, Analysis, and Drawing
In structural work, the BIM element, the analysis model element, the Excel check sheet, the structural drawing, and the quantity take-off all call the same thing by different identifiers. Beam B3-214 may exist as a GUID in BIM, as Element 4821 in the analysis model, and as `Beam_3F!B17` in the calculation sheet. Without that linkage, a section change leaves stale calculations or rebar schedules behind.
The Structural Pack must connect members and segments, sections, materials, boundary conditions, load combinations, analysis results, design checks, and details. Not every analysis result needs to be copied into a central database. It is enough to make explicit the reference to the results you need, the analysis run version, the extraction rules, and the units and combinations.
Steelwork Domain Pack: From Design to Fabrication
Steelwork has clear object relationships and feeds directly into fabrication data, so linkage pays off strongly here. Members and connections, plates, bolts, welds, assemblies, and piece marks can all be tied to analysis results, detail drawings, the BOM, and fabrication and inspection status.
When the design force at connection C-442 changes, the bolt count, plate thickness, weld length, and detail drawing all have to be re-checked. If the change touches members already ordered or in fabrication, a design review alone is not the end of it. Material inventory, CNC data, shop work orders, and even the site erection sequence must be checked for status. This is where `Change Event` and `Effective Date` become critical.
Finishes and Plastering Domain Pack: The Myth of a Discipline Without Calculation
Finishes and plastering are often pushed down the digitization queue because they have no complex numerical model like structural analysis. Yet the actual work involves areas, layer build-ups, thicknesses, waste allowances, mix designs, material requirements, labor productivity, curing times, procurement lead times, and quality tolerances. That is engineering data, and it is entirely calculable.
The object that matters is not only the space but the surface. Within a single room, walls, floors, ceilings, skirtings, and the areas around openings each carry different substrates and finish layers. Surface area can be pulled from BIM, but installed quantity shifts with opening deductions, corners, loss rates, patterns, small residual areas, and site conditions.
Interiors Domain Pack: Connecting Design Intent to Procurement
Interiors handle room types and design intent, products and colors, FF&E, sample and mock-up approvals, and supplier and lead-time information together. When one specified product is discontinued or its lead time no longer fits, an equivalence review, a color adjustment, a detail change, a re-quote, and a new order all follow.
In this area the combination of text, image, and drawing matters. AI can extract candidate products, colors, and model numbers from finish boards, spec books, and detail drawings. But the final equivalence judgment has to weigh performance, dimensions, certifications, tactile quality, and design intent together. The system must therefore never auto-substitute on image similarity alone; it must present a difference table and an approval workflow.
How to Build a Common Platform and Specialist Products at Once
Product strategy has to strike a balance between “one general-purpose app that supports every discipline” and “a completely separate product for each discipline.” Foundations such as data capture, document parsing, version control, calculation execution, evidence display, issues, and approvals can be built once and shared. Object schemas, terminology dictionaries, equations, rules, review UI, and evaluation data, by contrast, must be developed in depth per discipline.
Implemented as Common Platform + Domain Pack, the foundation built in one field becomes reusable in the next. Excel formula dependency analysis and regression verification of results, for example, are common to every discipline. But stratum correlation in geotechnics, load combinations in structures, and opening-deduction rules in finishes each belong to their own specialist Pack.
One general-purpose AI handling every discipline
Domain Packs layered on a common platform
Sequence Development by Verifiable Work Units, Not by Data Volume
Which discipline to start with should be decided by verifiability and the customer's recurring cost, not by data volume. Geotechnics and structures have relatively clear inputs, formulas, and results, which favors calculation reproduction and error detection. Steelwork carries strong commercial value because it runs all the way through to the BOM and fabrication status. Finishes and interiors involve high quantity, procurement, and change frequency, which makes them a good place to demonstrate site and cost impact.
Rather than launching every discipline at once, it is better to pick one customer's real calculation sheets, drawings, and change cases and complete them end to end. Work with a clear beginning and end serves best — for example, “groundwater level change → re-check of earth retaining and uplift calculations → impact on the report and sections,” or “room-type finish change → impact on area, ordering, schedule, and sample approval.”
The Same Philosophy, Different Depths
Geotechnics, structures, steelwork, finishes, and interiors are specialist fields that cannot be flattened into a single app screen. Yet the way objects and properties, calculations and standards, provenance and change, approval and evidence are managed can be shared. This is the critical balance point in building an industry-specific AI platform.
The next article looks at how this data philosophy behaves in a real change situation. It covers Engineering Change Intelligence: tracing the blast radius when a single groundwater level, structural member, or finish material changes — through drawings and calculations, quantities, cost, schedule, and approval.
doAZ Point of View
doAZ's long-term advantage comes not from a general-purpose LLM but from what accumulates on top of the common kernel: discipline-specific object schemas, calculation sheet libraries, formula semantic mappings, rules, review cases, and change graphs.