architect-method-lens

Extract evidence-backed design methods from an architect's writings, interviews, drawings, and built works, then apply those methods critically to a current architectural project. Use when researching an architect or practice, analyzing precedents across projects, building a reusable architect-method profile, comparing several architects' approaches, translating design philosophy into project-specific questions or operations, or critiquing a scheme through a named architect's methodological lens without copying signature style.

Turn architectural references into a traceable method library and a project critique lens. Preserve the difference between documented fact, visual observation, interpretation, and speculation.

Select the operating mode

• Profile: Build or update one architect's method profile from sources.
• Apply: Test a current project through an existing or newly built profile.
• Compare: Compare two or more architects against the same project question.
• Audit: Check an existing profile or design claim for weak evidence, contradictions, or style mimicry.

State the selected mode and scope in one sentence. Do not expand into a general biography unless it helps explain a method.

Establish the inputs

Identify:

1. Architect or practice, including relevant office or collaborator when authorship is shared.
2. Career period, geography, building type, or design question in scope.
3. Available sources and whether browsing or document extraction is permitted.
4. Current project phase and the decision the user needs to make, for Apply or Compare mode.
5. Local constraints that can override a method: code, climate, accessibility, budget, structure, procurement, and cultural context.

Ask only for missing information that would materially change the result. If the user supplies a folder or source set, inspect it before searching elsewhere. If evidence is too thin, produce a research plan or provisional hypothesis instead of a definitive profile.

Build the evidence base

Read references/evidence-model.md before assigning evidence levels or confidence.

Create a source register before synthesis. Record creator, title or project, date, source type, locator, access path, relevance, and limitations. Prefer architect-authored material and primary project documentation. Use criticism to contextualize, not to impersonate the architect's intent.

For visual material, separate:

• Observation: what is visible in a drawing, photograph, model, or building record.
• Interpretation: what the spatial or tectonic relationship may mean.
• Attribution: what the architect or a named source explicitly says it means.

Never turn an interpretation into an attributed intention without evidence.

Extract recurring methods

Analyze across these dimensions when relevant:

• problem framing and values
• site, landscape, city, and existing fabric
• program and adjacency
• circulation, threshold, and spatial sequence
• geometry, order, scale, and proportion
• structure, construction, and detail
• material, surface, light, and atmosphere
• climate, resources, maintenance, and time
• representation and design process
• social use, institution, and public realm
• recurring tradeoffs, refusals, and failure conditions

Require evidence from at least three materially different projects before calling a pattern recurring. With one or two projects, label it a provisional method. When a practice changes over time, create period-specific cards instead of flattening the work into one timeless philosophy.

Actively search for:

• projects that contradict the proposed pattern
• differences between stated philosophy and built evidence
• adaptations caused by site, program, collaborator, budget, or regulation
• interpretations that critics disagree about

Produce method cards

Read references/output-schemas.md and use its Method Card schema.

Each card must contain:

• a verb-led principle, not a style label
• the design problem and trigger conditions
• observable operations across projects
• intended or observed spatial effect
• tradeoffs and failure conditions
• counterexample or limiting evidence
• evidence citations and confidence
• questions for the current project

Prefer cards such as “delay visual access to stage arrival” over labels such as “monumental,” “minimalist,” or “in the style of X.” Do not reproduce signature forms as a shortcut.

Keep direct quotations short and cite the exact page, timestamp, drawing, or project record when available. Paraphrase otherwise.

Apply the lens to a project

First summarize the current project without the architect lens:

• confirmed facts
• design goals
• constraints
• unresolved questions
• current project phase

Select only three to five method cards whose trigger conditions match the project. For each card:

1. Explain why it is relevant.
2. Translate it into two or three project operations or critique questions.
3. Identify what evidence or drawing would test the idea.
4. State conflicts with code, accessibility, climate, budget, structure, operations, or user needs.
5. State how the project could reject or transform the method while preserving its own authorship.

Do not generate a final form solely from the architect profile. Offer alternatives and evaluation criteria. The architect remains responsible for design judgment and professional coordination.

Run the counter-lens

Before concluding, ask:

• Where would this method fail in this project?
• Which current constraint has no meaningful precedent in the source set?
• Are we copying an appearance while losing the underlying problem logic?
• Would a different architect or non-architectural framework produce a better answer?
• What must be verified by the project architect, consultants, client, or authority?

Revise or reject cards that do not survive this check.

Deliver the result

Use the smallest output that answers the request. For a full study, deliver in this order:

1. Scope and evidence limitations
2. Source register
3. Concise architect method profile
4. Method cards
5. Project application matrix
6. Counter-lens findings
7. Decisions, open questions, and next research actions

Mark every substantive claim as one of: documented, observed, interpreted, or provisional. Include citations close to the claim.

For structured templates, use references/output-schemas.md. For source and confidence rules, use references/evidence-model.md.

Guardrails

• Do not fabricate quotations, intentions, project facts, drawings, or citations.
• Do not infer a complete philosophy from one iconic building or a mood board.
• Do not treat popularity, visual similarity, or search ranking as evidence.
• Do not erase collaborators, engineers, clients, craftspeople, or historical context.
• Do not present general precedent as proof of code compliance or buildability.
• Do not let the named architect's method override the current brief, users, site, or professional obligations.
• When evidence is unavailable, say what is missing and provide a bounded acquisition plan.