The Platform Approach to Building Product Information

The Platform, Not the Pipeline

Most teams treat drawing-to-code conversion as a pipeline problem: feed in a DWG, pray for a clean IFC or JSON out the other end. That framing fails the moment a real file shows up—exploded blocks, missing layers, mixed units—because a pipeline has no memory and no shared muscle. The durable win is treating conversion as a product platform problem: the conversion engine is the shared module, and every derivative deliverable (IFC, JSON, code) is just another product off the same assembly line.

This guide walks the decision tree for that platform approach: what counts as minimum viable input, how to build a classification layer that survives legacy drawings, which output formats matter and why, and how to measure whether your platform is actually getting cheaper to run. Recent tooling—ezdxf’s active maintenance, the free ODA File Converter bridge, and manufacturer data libraries—makes the build-vs-buy question more tractable than it was five years ago, but only if you start with the canonical rule: platform beats pipeline.

Minimum Viable Input Rules

The minimum viable input for any drawing-to-code platform is not a DWG file — it is a DWG file with declared units, named layers, and un-exploded blocks. According to the ezdxf documentation, a clean file with consistent units and layer naming is the baseline; missing layers or exploded blocks force pre-processing normalization before any automation can proceed. The decision rule is blunt: if your drawing has more than three layers named "Layer 1" or "0", stop and normalize before you spend a single compute credit on classification. That rule saves more hours than any model tuning you will do later.

The normalization step is where most teams bleed time, because they treat it as an exception rather than a gate. Enforce a pre-flight checklist — units declared, layers named, blocks intact, no proxy objects — and reject drawings that fail. A firm converting 50 legacy floor plans per year typically spends 30 hours per plan on cleanup and bespoke export scripts; the platform approach spends 200 hours once on the shared core, then 10 hours per plan. The gate is what makes the math hold.

The tooling for this gate is more accessible than most architects assume. The ezdxf library, actively maintained as of August 2026, provides the odafc add-on that interfaces with the ODA File Converter to read and write DWG files. That is the free bridge for non-native DWG workflows — no paid SDK required to get files into a DXF-based pipeline. One Stack Overflow thread on DWG handling recommends the ODA File Converter as the free standard for DWG-to-DXF conversion, but warns that text encoding and block attribute fidelity vary by ODA version. Pin your converter version. Do not let a silent update change how your blocks parse mid-project; version pinning is a one-line config that prevents a class of bugs that are miserable to trace.

The edge case that most guides miss is HPGL/2 plot files from legacy plotters. These are not dead. The ezdxf hpgl2 add-on converts them to DXF, SVG, and PDF, which means scanned-era drawings can enter the platform without manual redrawing. If you have a drawer full of 1990s plots, that add-on is the difference between a digitization project and a redrawing project. The conversion quality is not perfect — line weights and text placement often need review — but the alternative is hours of tracing that no one bills accurately.

The common practitioner mistake is skipping the gate for a "quick test" on a single file. That one file passes, so the team assumes the rest of the corpus is clean, and the platform's classification layer silently degrades on the second batch. The gate is not a formality; it is the contract between the drawing corpus and every downstream product. If you are building a platform, the input rules are the first product you ship. Set the pre-flight checklist today, reject the first dirty file, and watch how fast the normalization module becomes the most-used component in your stack.

Classification: Rules vs. Learning

Classification is where the platform approach either pays for itself or quietly dies, and the decision rule is simpler than most vendors admit: if your legacy drawings have consistent layer naming, rule-based classification on layer names and hatch patterns beats machine learning on cost, speed, and explainability. Reserve ML for scanned or hand-drawn input where layers are meaningless. That split is the difference between a classifier you can debug in an afternoon and a model you will be re-training forever.

The standard metrics are precision and recall — precision is the fraction of relevant instances among retrieved instances, recall is the fraction of relevant instances retrieved from the total. For wall and door detection, those are the only two numbers that matter. A rule-based classifier that hits 0.95 precision and 0.90 recall on clean DWGs is production-ready. The same classifier on scanned blueprints will collapse, and the failure mode is not the model architecture — it is the distribution shift between clean CAD data and scanned input. That drop is the real cost, not the choice of framework.

A typical automated conversion pipeline involves geometry extraction via libraries like ezdxf or shapely, topology cleanup, element classification, and export to formats such as JSON, IFC, or parametric modeling commands. Classification is one stage, not the whole game, but it is the stage where most pipelines fail because teams try to solve every input type with one approach. The concrete scenario: a firm with 200 clean DWGs and 10 scanned blueprints should build a rule-based classifier for the DWGs and treat the scans as a separate ML project with its own budget. Mixing them in one model degrades both — the clean data teaches the model shortcuts that fail on scans, and the scans add noise that hurts precision on the clean data you actually bill for.

The edge case that kills rule-based systems is hatch patterns. A wall represented as a double line with a hatch fill is trivial for rules — the layer name and hatch pattern give it away. A wall represented as a single polyline with no fill requires geometric heuristics: parallel line detection, thickness thresholds, and adjacency checks. Rules handle those poorly because the thresholds are drawing-specific. A 200mm wall in one project is a 150mm wall in another, and your thickness threshold either over-matches or under-matches. One r/bim thread notes that practitioners report the most debugging time — not on the obvious double-line walls, but on the single-polyline walls that require geometric inference. The fix is to keep those heuristics in a separate module with its own test drawings, not to bolt them onto the layer-name rules.

The platform implication is that your classification layer must be shared across every derivative product, as noted in the earlier section on the shared core. If the wall classifier lives in one script and the door classifier lives in another, you have two bespoke scripts, not a platform. The rule-based classifier should be a single module with a documented schema, versioned test drawings, and a clear interface for the export stage. When a new project arrives with a layer naming convention you have not seen, you extend the rule table — you do not fork the script.

One caveat: rule-based classification fails silently on drawings with inconsistent drafting standards. If your legacy stock is a mix of 1990s plots and modern CAD exports, run a layer-name audit before committing to rules. If it is the latter, budget for the ML project on the scans and accept that the clean DWGs will carry the platform's early returns. The action today: take your ten messiest drawings, run a layer-name audit, and count how many wall entities would be caught by a simple double-line-plus-hatch rule. That number tells you which classification path to build first.

Output Formats: IFC, JSON, or Code

The export format is a product decision, not a technical one, and the rule is simple: structural engineers and contractors get IFC, software applications get JSON, and parametric models get command scripts. Never write one export that tries to serve all three, because the semantics each consumer needs are mutually incompatible. IFC carries geometry plus meaning — wall types, fire ratings, material properties — which is exactly what a contractor checking a fire-rated partition needs. JSON is lightweight and schema-flexible, but you define the semantics yourself, which means your schema becomes a contract you must version and document. Parametric commands like Dynamo or Grasshopper graphs are executable, but they are version-locked to the host application; a Dynamo graph written for Revit 2025 will not run cleanly in Revit 2026 without a migration pass.

The trade-off is measurable in file size and fidelity. That spread is the argument for the platform approach: the extraction cost is paid once, and each output format is a thin adapter on top of the shared classification layer. The IFC path is heavy and lossy on complex curves, so if your source drawings contain spline-heavy organic forms, expect the IFC end-to-end to degrade them. JSON has no such geometry problem, but it has no built-in semantics either, so you will spend the time you saved on file size defining and maintaining your own schema.

The edge case that trips most teams is that IFC is not a single format. IFC2x3 and IFC4 have different entity coverage, and a wall classified as IfcWallStandardCase in IFC2x3 may not end-to-end through IFC4 without reclassification. If your downstream consumer is still on IFC2x3 — which is common in legacy infrastructure projects — exporting IFC4 and assuming compatibility will fail silently. Verify the consumer's schema version before you commit, not after the file lands in their model. One r/bim thread notes that clients ask for IFC but what they actually open is the DWG export, so confirm the actual downstream tool before you invest in an IFC adapter at all. The cheapest way to do this is a single phone call to the engineer or contractor asking which software version they run and what they will do with the file.

One caveat: the version-lock problem is not limited to Dynamo. Any parametric command export ties you to the host application's API, and those APIs change on release cycles you do not control. If you need longevity, JSON with a documented schema is the most durable output because it has no runtime dependency. The concrete action today is to audit your three most common downstream consumers and write down which format each actually opens — not which format they request in the contract. That list is your export adapter roadmap, and it will tell you which of the three formats to build first.

Case Study: Two Firms, One Platform Decision

Firm A and Firm B start from the same DWG set, and the divergence is measurable before the first export runs. Firm A writes a bespoke Python script per client, hardcoding a layer-name mapping that dies with the project. Each engagement costs 40 hours of engineering time and produces a one-off JSON output that no future project can reuse. Firm B invests 200 hours once in a shared core: ezdxf geometry extraction, a configurable layer-mapping table, and three export modules for IFC, JSON, and Dynamo. Each new project then costs 8 hours of configuration and validation, not 40 hours of re-discovery.

The math over ten projects settles the argument. Firm A spends 400 hours total and owns zero reusable assets. Firm B spends 200 hours on the core plus 80 hours on configuration, for 280 hours total, and the eleventh project costs 8 hours instead of 40. The breakeven lands at project six, which is the threshold most firms never calculate because they are too deep in the bespoke-script cycle to see the cumulative cost. According to a 2021 definition from Salonen's "Building on Bedrock," a product platform is a set of common components from which a stream of derivative products can be efficiently created, making subsequent products cheaper, faster, and more consistent to build. That is exactly what Firm B has done, and the 120-hour savings over ten projects is the price of admission for treating conversion as a platform rather than a pipeline.

The failure mode is maintenance, not construction. When ezdxf ships a new release, Firm B has to update their odafc wrapper, which interfaces with the ODA File Converter to read and write DWG files. That is a half-day of work, and it is the cost of owning a living asset. Firm A's bespoke scripts were unaffected by the release, but they were also useless for the next project, which is the quieter erosion. One r/bim thread notes that clients ask for IFC but what they actually open is the DWG export, so Firm B's three-module approach lets them confirm the actual downstream consumer before committing to a format. Firm A has no such option because their output is welded to the script that produced it.

The field decision is not about engineering elegance. For firms converting more than five drawings per year, the platform approach is the only rational choice, and the 280-hour total over ten projects is the evidence. For one-off conversions, the pipeline approach is cheaper, and that threshold is real and measurable. The trap is the middle ground: a firm that converts six drawings a year, builds a half-platform, and then abandons it because the maintenance feels optional. As one industry analyst notes, treating the platform like a shortcut will have you writing a post lamenting its erosion. The platform is a strategic commitment, not a script you run once.

Validation is where the platform earns its keep. Cross-checking the generated BIM model against the original drawing using geometric overlay, comparing room areas and wall lengths, is standard practice to catch missing elements before downstream use. Firm B builds that check into the shared core once, and every project inherits it. Firm A rebuilds the check from scratch each time, or skips it entirely, which is how missing walls end up in a contractor's coordination model. The action today: take your last three completed conversion projects and count the hours spent on cleanup and bespoke export logic. If that number exceeds 120 hours, you have already paid for a platform core you do not own yet.

Measure What Survives

Precision and recall are the only metrics that tell you whether your conversion platform is actually working, and most teams quote the wrong one. The platform approach fixes the classifier once in the shared core; the pipeline approach patches it per project, forever.

The decision rule is to track precision and recall separately for each element type — walls, doors, windows, structural grids — and never aggregate them into a single accuracy score. Code compliance review fails on a missing door, not on a slightly misplaced wall. One r/computervision thread on floor plan segmentation puts it bluntly: everyone quotes accuracy, nobody quotes per-class IoU. The per-class breakdown is where the real failures live, and it is the only place where you can decide whether a fix belongs in the classifier or in the input rules.

Precision and recall are not symmetric in their cost, and this asymmetry drives the measurement discipline. A false positive wall — a precision error — can trigger a structural conflict that costs thousands in rework when the extracted geometry feeds an analysis model. A false negative door — a recall error — fails code compliance review and stops the permit process entirely. Both are expensive, but they fail at different stages and different stakeholders catch them. Structural conflicts surface during coordination; missing doors surface during review. If you only track one number, you will optimize for the wrong failure mode.

The measurement discipline that separates a platform from a script collection is logging every false positive and false negative with the source drawing and the classification confidence. This log becomes the training data for the next platform iteration. Without this log, every failure is a one-off debugging session. With it, failures compound into a better shared core — the platform approach turns errors into compound interest, while the pipeline approach pays the same debugging tax on every project.

Start today by exporting the per-class precision and recall for your last three conversion projects, broken out by element type. If you do not have that breakdown, you do not know whether your platform works — you only know that it ran.

What to do next

Also worth reading: BIM Building Information Modeling The Essentials · How Building Information Modeling Transforms Design and Construction · Building Smarter The Essential Guide to Information Modeling

Sources: wikipedia, medium, linkedin, saastr, barcinno