Plan import is easy to overpromise: give an AI a floor plan and it automatically recognizes a complete model.

For developers, that framing is not precise enough. The stronger architecture question is: how do you turn a DWG, DXF, PDF, image, scan, or photo into editable working truth while preserving enough evidence to repair mistakes locally?

SAH’s import direction is not “perfect recognition.” It is repairable import.

Autonomous-first does not mean evidence-free

Designers should not have to confirm every wall, door, and intermediate candidate before getting a useful model. That creates a low-signal approval workflow.

Import should quickly create an editable first-pass working model.

But autonomous-first does not mean evidence-free. The system still needs to retain source manifests, format information, previews, evidence artifacts, extracted interpretation, scale assumptions, confidence, quality flags, and generated model references.

Those artifacts are not final truth, but they are repair context.

imports/ is not project truth by itself

imports/<import_id>/ should store source material, previews, evidence, and extracted interpretation. It answers: where did this working truth come from, what assumptions were made, and where is uncertainty?

The active agent workflow uses accepted working truth in design_model.json:

  • import sessions;
  • walls;
  • openings;
  • space footprints;
  • source provenance;
  • quality flags.

Source evidence gives traceability. Working truth gives editability. They should not collapse into the same layer.

A first-pass model is not a verified survey

The first imported model should become editable quickly, but it should not be described as survey-grade truth.

It is a working model with provenance. It can be validated, versioned, executed, reviewed visually, and repaired, but it still needs to expose uncertainty:

  • scale may be inferred;
  • openings may be low confidence;
  • raster sources may include outside blank regions;
  • room labels may conflict with detected boundaries;
  • negative regions should not become rooms or walls.

That uncertainty should not be hidden. It should appear in quality summaries or source interpretation.

Source fidelity and SketchUp execution are separate gates

A successful SketchUp execution does not prove the imported truth matches the source.

These are separate gates:

  • bridge execution gate: can current design_model.json generate and execute in SketchUp?
  • source fidelity gate: does the working truth still respect the source evidence?

A model may cleanly replay into SketchUp while a balcony expands into blank outside space, an opening is hosted on the wrong wall, or a room footprint conflicts with a source label. That is not a bridge problem. It is a source fidelity problem.

The import pipeline therefore needs source-scoped constraints, negative regions, dimension chains, room candidates, opening constraints, and boundary checks.

Repair should be local

When the user says a wall is wrong or the imported width should change, the system should not automatically restart the whole import.

A better flow is:

  1. identify the affected model entity and provenance;
  2. retrieve the relevant source evidence;
  3. reinterpret the local region or entity class;
  4. patch design_model.json;
  5. regenerate the bridge trace;
  6. clean replay or execute locally;
  7. report the specific change.

That is the point of working truth. It lets the agent turn natural-language correction into structured local repair instead of starting over.

Dynamic runtime memory belongs in the project

An import may create source-specific memory: a symbol legend from one drawing, designer-corrected room naming, or a known scale interpretation.

That memory may be useful for the current project, but it should not automatically enter product runtime skills or the central knowledge base.

It can live as project/session dynamic runtime skills inside the active design project. Only after a pattern is generalized, repeatedly validated, and tested should it enter product baseline behavior or central abstract knowledge.

Why this belongs in the developer series

Import is not a single “recognition” feature. It is a combination of source management, evidence retention, truth generation, validation, repair, runtime memory, and host execution.

If developers only optimize for the first visual result, the product becomes hard to repair. The durable value is this: even when the first version is imperfect, the system knows where it came from, what is uncertain, and how to repair it locally.

That is the architecture value of moving from source evidence to working truth.

Source trace