Back to Lab
Digital courtyard-building cutaway showing rooms, openings and wireframe enclosure edges.
Concept image (AI): architectural visualization for this research question.

Architectural Context Library

What must an AI assistant know about a drawing before it changes one line?

Design Knowledge & Workflows04 - BUILDINGExperiment design
Study period
2026
Note updated

The research question

A line carries more than coordinates. It may be a wall, an overhead edge or a discarded option. Units, drawing conventions and revision history determine how it should be read. This study asks how that architectural context can travel with a bounded editing task.

The proposed experiment uses the same doorway edit under three conditions: geometry alone; geometry with office conventions; and both with explicit task constraints. We will also introduce missing units and conflicting instructions. The assistant should expose these conflicts before altering the drawing.

Success means that the requested change is made while protected elements and relationships remain intact. A valid file is only one check. A reviewer must also inspect whether the edit respects the brief, and record the work needed to correct it.

One drawing, three levels of context

Geometry x, y?
Geometry. Coordinates show where the objects are. They do not establish units, revision or which objects the task must preserve.
Office information mmA-WALLR02
Office information. Units, layer convention and revision make the drawing easier to interpret. They still do not define the requested change.
Task context mmA-WALLR02Keep
Task context. The doorway is identified as the target and reference geometry is marked for preservation. Conflicts would need clarification before an edit.

Illustrative context package. The annotations are authored examples; no AI model runs here. The proposed schema and its effect on editing still need evaluation.

Ideas and methods

Negroponte’s Architecture Machine frames computation as a dialogue with the designer. Today, an information requirement such as IDS can make part of that dialogue explicit. We use the historical question of design intent to distinguish a geometric operation from an architectural decision.

Read the sources ↓

Current work and the next experiment

On this page
An illustrative plan and three context states: geometry, office information and task constraints.
Planned output
A versioned schema, permission-cleared test drawings, expected changes and independent architectural review.

How we will test it

Distinguish validity from meaning
Check that the package is readable, then check whether the requested change was understood. Score changed dimensions, protected objects and requested clarification separately.
Hold out an office convention
Develop examples with one naming system, then test unfamiliar conventions without rewriting the expected answer. Retain cases where more context creates a new error.
Inspect the saved model
Reopen the result in the target application and compare object identities, units and relationships. A persuasive explanation is not a substitute for the model that was actually saved.
What remains open
  • A useful schema in one office may encode that office's habits. Transfer between practices and design stages remains an unanswered question.
  • Geometric checks do not establish architectural quality, accessibility or regulatory compliance. Those assessments require their own criteria and expertise.
  • Context can be incomplete or contradictory. Treating a retrieved example as an instruction would create a different failure from missing it.
  • Evaluation cases and software versions still need to be selected. Release permissions also need clarification. No performance target has been validated.

Next output

The next deliverable is a versioned context schema with purpose-made drawings, expected edits and a failure catalogue. A published task instruction could explain how an agent should read the package and verify a bounded operation. The experiment will establish which information is necessary for an accepted edit before the library is integrated into a product.

Sources and method notes