190 lines
9.4 KiB
Markdown
190 lines
9.4 KiB
Markdown
# National Museum of Ecuador — Pattern Language Counter-Proposal
|
|
|
|
## What this project is
|
|
|
|
A public-advocacy counter-proposal for the New Building of the National Museum
|
|
of Ecuador (Quito), written from scratch to be **100% committed to meeting the
|
|
human needs of the people who will use the museum** — visitors, staff, school
|
|
groups, and the communities whose heritage it holds — rather than to
|
|
"inhuman" architectural spectacle.
|
|
|
|
Background: the Government of Ecuador ran an open international call (Stage 1
|
|
deadline 17 Feb 2026) for the museum's architectural preliminary project. A
|
|
winner was selected, but the winning design has provoked considerable public
|
|
objection over its failure to serve human needs, and is currently on hold and
|
|
may be abandoned. This project is not a competition entry — it is an
|
|
independent alternative vision, intended to be published to influence the
|
|
public debate in Ecuador while the winning scheme's fate is undecided.
|
|
|
|
Team: a small informal group (not a single firm), of which Bruno is one
|
|
member.
|
|
|
|
## Method
|
|
|
|
This project directly applies the methodology described in:
|
|
|
|
> Postle, B.; Salingaros, N.A. "LLM and Pattern Language Synthesis: A Hybrid
|
|
> Tool for Human-Centered Architectural Design." *Buildings* 2025, 15, 2400.
|
|
> (`ref/buildings-15-02400-v2.txt`) — Bruno is the paper's first author.
|
|
|
|
Core idea of the method: Christopher Alexander's *A Pattern Language* (1977)
|
|
encodes 253 human-centered design patterns, but at 1166 pages it's too
|
|
unwieldy for direct practical use, and requires expert familiarity to select
|
|
and combine patterns. The paper's workaround:
|
|
|
|
1. A web tool ([APL-Companion](https://apl-companion.netlify.app/apl.html))
|
|
lets someone familiar with the patterns curate a **project-specific
|
|
subset** of the 253, then export it as a condensed PDF (titles +
|
|
paraphrased summaries only, no navigation chrome). We convert these PDF
|
|
exports to Markdown once received (see Conventions below).
|
|
2. That pattern subset is fed to an LLM as context, along with a prompt describing the
|
|
project (purpose, scale, local context) and a request for a **narrative
|
|
description of the human experience** of the building — look, feel, and
|
|
ornamental treatment — grounded only in the selected patterns.
|
|
3. The LLM's narrative is checked for fidelity against the pattern subset
|
|
(any element not traceable to a selected pattern is a hallucination to be
|
|
caught and regenerated away).
|
|
4. Optionally, the narrative can later be used as a prompt for AI image
|
|
synthesis to produce illustrative (not prescriptive) visuals — the paper
|
|
found this reliably reveals human-centered forms even with no style
|
|
imposed. **This step is out of scope for us**: image generation will be
|
|
done later by others, not as part of this work.
|
|
|
|
The output of the method is words, not drawings — the operational chain is
|
|
*pattern repository → project-specific pattern subset → LLM narrative
|
|
synthesis → evaluation*.
|
|
|
|
## Our process for this project
|
|
|
|
1. **Pattern subset** — a subset pattern language for a national museum,
|
|
built with the APL-Companion tool, prepared by Nikos Salingaros (not
|
|
Bruno) and added to `ref/`.
|
|
2. **Condense the brief** — work through the official brief (see Reference
|
|
material below) and extract only the aspects that serve genuine human
|
|
needs (programmatic requirements, collection scale, site, functional
|
|
spaces), discarding or flagging anything that pushes toward inhuman /
|
|
spectacle-driven architecture. The critique transcript
|
|
(`ref/youtube-transcript.txt`) of the winning proposal is used here as a
|
|
source of **specific, concrete failures to avoid** — we mine it for
|
|
named problems (e.g. illegibility, hostility to human scale, disregard for
|
|
how people actually move/gather/rest) so the condensed brief and later
|
|
narratives explicitly steer clear of them.
|
|
3. **Write narratives** — using the pattern subset + condensed brief, write
|
|
one or more experiential narratives in the style of the paper's Section
|
|
4.2, from these viewpoints (at minimum):
|
|
- Visitor (general public)
|
|
- Museum staff (curators, conservators, educators)
|
|
- School group / children
|
|
- Indigenous / community stakeholders whose heritage is represented
|
|
Note that it is important that the narratives are mutually consistent,
|
|
features described in a narrative from the point of view of one stakeholder
|
|
must not contradict those perceived by another stakeholder.
|
|
|
|
## Deliverable
|
|
|
|
Written narratives in Markdown. No architectural drawings, plans, or images
|
|
are to be produced as part of this work — AI image synthesis from the
|
|
narratives is a separate, later step to be done by others.
|
|
|
|
Output format, filenames, and directory layout are not yet finalized — decide
|
|
and record here once the narrative-writing step actually begins.
|
|
|
|
## Reference material (`ref/`)
|
|
|
|
- `buildings-15-02400-v2.txt` — the Postle & Salingaros paper this project's
|
|
method is based on.
|
|
- `A Pattern Language Ecuador National Museum.md` — the project-specific
|
|
pattern subset (55 patterns from Alexander/Ishikawa/Silverstein, numbered
|
|
and paraphrased by the APL-Companion tool), prepared by Nikos Salingaros
|
|
for this museum project. This is the core design-constraint input for
|
|
narrative writing.
|
|
- `Ecuadorian_Form_Language_Grammar.md` — "Ecuadorian Form Language — Quito
|
|
Grammar", a companion design-grammar module (generated by Kimi.ai, source
|
|
unclear beyond that) covering Quito's climate response rules, a vocabulary
|
|
of regional/historical form elements (indigenous, pre-Columbian, colonial,
|
|
baroque, regional), composition syntax, and color/ornament systems. Written
|
|
as a prompt module for an LLM. Relevant to us for the "look, feel, and
|
|
ornamental treatment" part of narrative-writing (per the paper's Section
|
|
4.2 approach) grounded in authentic Ecuadorian vernacular character, and
|
|
for glossary terms (zaguán, corredor, zócalo, alero, etc.) worth reusing
|
|
verbatim in our narratives. Its final output-template step ("camera-ready
|
|
visual summary" for image generation) is not relevant to us since we are
|
|
not producing images.
|
|
- `Muna Technical Bases for Stage 1.txt` — the official Stage 1 open call
|
|
document: scope, site (Av. Eloy Alfaro / Av. de la República, Iñaquito,
|
|
Quito, 13,004.65 m² plot, min. 25,000 m² building), schedule, selection
|
|
process, and background on the National Museum of Ecuador.
|
|
- `Muna ANNEX-1_RulesMuseum_ENG.md`, `Muna ANNEX-2_RulesMuseum_ENG.md` —
|
|
participation rules annexes (mostly administrative/legal boilerplate;
|
|
ANNEX-2 is longer, worth checking for programmatic requirements).
|
|
- `MUNA Guide-for-the-submission-of-the-enabling-documentation.txt` —
|
|
administrative submission guidance (procedural, low relevance to design
|
|
content).
|
|
- `Muna.md` — template email for Stage 1 document submission (administrative
|
|
only).
|
|
- `youtube-transcript.txt` — transcript of a critique (Nikos Salingaros and
|
|
others) of the winning proposal, analysing it against human-centered
|
|
design/pattern-language principles. Use per "Condense the brief" above.
|
|
|
|
## Conventions
|
|
|
|
- Reference documents received as PDF are converted to Markdown (or plain
|
|
text, for documents like the academic paper where reflowing into headed
|
|
sections isn't worth the effort) and the PDF is then deleted — keeps
|
|
everything in `ref/` greppable and quotable rather than needing repeated
|
|
page-range PDF reads. Check conversions carefully: PDF text extraction can
|
|
silently mis-join hyphenated compounds and drop ligatures/symbols.
|
|
|
|
## Status
|
|
|
|
Pattern subset and the Ecuadorian Form Language Grammar have been received.
|
|
Next: condense the brief (step 2), then draft narratives (step 3).
|
|
|
|
|
|
<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:7510c1e2 -->
|
|
## Beads Issue Tracker
|
|
|
|
This project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.
|
|
|
|
### Quick Reference
|
|
|
|
```bash
|
|
bd ready # Find available work
|
|
bd show <id> # View issue details
|
|
bd update <id> --claim # Claim work
|
|
bd close <id> # Complete work
|
|
```
|
|
|
|
### Rules
|
|
|
|
- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
|
|
- Run `bd prime` for detailed command reference and session close protocol
|
|
- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files
|
|
|
|
**Architecture in one line:** issues live in a local Dolt DB; sync uses `refs/dolt/data` on your git remote; `.beads/issues.jsonl` is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/SYNC_CONCEPTS.md for details and anti-patterns.
|
|
|
|
## Session Completion
|
|
|
|
**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.
|
|
|
|
**MANDATORY WORKFLOW:**
|
|
|
|
1. **File issues for remaining work** - Create issues for anything that needs follow-up
|
|
2. **Run quality gates** (if code changed) - Tests, linters, builds
|
|
3. **Update issue status** - Close finished work, update in-progress items
|
|
4. **PUSH TO REMOTE** - This is MANDATORY:
|
|
```bash
|
|
git pull --rebase
|
|
git push
|
|
git status # MUST show "up to date with origin"
|
|
```
|
|
5. **Clean up** - Clear stashes, prune remote branches
|
|
6. **Verify** - All changes committed AND pushed
|
|
7. **Hand off** - Provide context for next session
|
|
|
|
**CRITICAL RULES:**
|
|
- Work is NOT complete until `git push` succeeds
|
|
- NEVER stop before pushing - that leaves work stranded locally
|
|
- NEVER say "ready to push when you are" - YOU must push
|
|
- If push fails, resolve and retry until it succeeds
|
|
<!-- END BEADS INTEGRATION -->
|