Common Building LanguageRead and sign
Manifesto for a Common Building Language · first public draft · Version of 24 October 2026

Every building, every stakeholder, one open language.

The Common Building Language (CBL) is an open description of buildings. Geometry, quantities, prices, carbon and exchange files follow from it, the same in every tool. Written for people and AI models alike, it works alongside existing BIM, CAD and CAM tools, and adoption proceeds project by project.

Your role

Choose your role, or several, and the page puts first what concerns you.

Lineage

Nearly every part has a precedent. The combination is new.

Architects have described buildings by modules, orders, types, patterns, grammars and models for two thousand years. The foundations review eleven strands of that work, from Vitruvius to the language models of 2026, trace each to the fields from which its concepts came, and find a precedent for nearly every component of the Common Building Language (CBL); what remains its own is their combination. The language and Cascading Style Profiles (CSP) are defined together. What multiplies afterwards is the heuristics that every party writes in them, from the regulator to the project, each level multiplying the combinations one description admits.

30 BC10001500180019001950200020262regulator48163264projectTreatisesNon-Western codesType and elementStyle and placeIndustrialisationOpen buildingDesign methodsFormal languagesInformationAI and generationBIM and ontologiesCBLCSPHeuristics30 BC10001500180019001950200020262regulator48163264projectTreatisesNon-Western codesType and elementStyle and placeIndustrialisationOpen buildingDesign methodsFormal languagesInformationAI and generationBIM and ontologiesCBLCSPHeuristics
The eleven strands of the foundations, each drawn firm from its first milestone to its last, on a time scale compressed toward the present; point to a milestone for its work and date. With two sets of heuristics at each of six levels, one description admits 64 combinations, and each further level doubles them.
Contents
  1. Language and style
  2. Models and tools
  3. The manifesto
  4. Challenges
  5. Signatories
Language and style

The web already works this way, brilliantly, on billions of pages and in any browser.

Every page on the web is written in HTML, which says what is on the page, and styled with CSS, which says how it looks. Both are open and kept apart: every browser implements the same two standards, and one style sheet can change the look of a whole site without touching its pages. The Common Building Language (CBL) and Cascading Style Profiles (CSP) bring the same arrangement to buildings.

The webA building
What is thereHTML<h1>Pavilion</h1>What is on the page: a heading, a paragraph, a picture.CBLroof · rests on the columnsWhat is in the building: each element, where it is and what it relates to.
How it looksCSSh1 { font-family: serif; }Fonts, colours and layout, set apart from the page.CSPcolumn: steel, I-sectionThe selection of each party, from regulation to project, set apart from the description.
Who reads itAny browseron any deviceBillions of pages, each written once.Any toolin any officeEvery building, each described once.

This site carries a second style of its own. The switch Aa at the top sets every page in it, with other faces and colours and every size and space kept, as a style sheet changes a site without touching its pages.

In the Common Building Language (CBL) each element is named by its type and related to the others: the terrace hosts the hall and the columns, the columns carry the roof, the hall encloses 2,540 m². The requirements descend to each element. The drawing sets the elements on the grid only to show them; nothing yet says what form they take or how they are made.

In Cascading Style Profiles (CSP) each party writes its selection within the language. A practice profile selects an orthogonal order, steel sections, a deep roof grid and glass between vertical mullions; the project profile, more specific, sets the granite of the terrace.

A profile may govern form as well as material. Another practice profile sets the hall on a rounded plan with its walls leaning outward, tapers and inclines the columns, and bends the roof into one shell. Every relation of the description holds: the roof rests on the same eight columns, and the hall encloses the same area under it.

A third practice profile makes the roof of curved sheets that meet at folds, sets the hall in inclined facets and leans each column its own way. The description and the project profile are unchanged, so the same building takes a third form.

ElementThe description CBLThe style CSPPractice profile: orthogonal steel and glass. Project profile: granite terrace.Practice profile: continuous curves. Project profile: granite terrace.Practice profile: folds. Project profile: granite terrace.
1Terraceterrace · surface · grid 3.6 m · hosts the hall and the columns
granite, jointed on the gridprojectgranite, jointed on the gridprojectgranite, jointed on the gridproject
2Hallenclosure · 4 surfaces · 2,540 m² · transparent
glass in steel frames on a square plan, vertical mullions every 3.6 m, one transompracticeglass on a rounded plan, walls leaning outward, mullions following the curvepracticeglass in inclined planar facets, in horizontal bandspractice
3Columnscolumn × 8 · carry the roof
steel, I-section, verticalpracticewhite concrete, tapered, inclined toward the edge of the roofpracticesteel tubes, each at its own inclinationpractice
4Roofroof · surface · covers the hall · rests on the columns
steel grid, 1.8 m deep, dark fasciapracticewhite shell, doubly curved, 0.4 mpracticecurved metal sheets meeting at folds, 0.7 mpractice
Models and tools

Every model can write it. Every tool can read it.

Language models already generate scripts, drawings and models of buildings, each in the format of one tool, and each answer starts again from nothing. The same models can write in the Common Building Language (CBL): what they write is checked as it is written, expands to the same building in every tool, and can be edited, merged and priced by every party. Each difference below is tested by a hypothesis of the whitepaper.

A model on its ownThe same model writing CBLTested as
TranslationEvery tool and every model needs a translation to every other, so the work grows with the product of their numbers.Every tool, model and product line maps once to one language, so the work grows with their sum.H6
CollaborationA generated model is a file, replaced whole at each round, and the changes of two parties cannot be merged.A description is text, versioned and merged element by element, as code is.Collaboration and versioning, Interface independence
CustomisationA practice's standards and style are restated in each prompt, differently by each person.Standards and style are written once as profiles and applied by every tool and every model.Company standards as profiles, Signature models
Size and costGeometry and exchange files are long, and a model pays for every token it reads and writes.A description states the decisions and derives the geometry by expansion; its length in bytes and tokens is measured against IFC.H1
ValidityOutput can break the rules of the products it names, and the errors are found after it is written.Output is checked against the schema and the manufacturers' rules as it is written.Reliability, H5
Each jointA model gets the overall design largely right and single joints wrong, and one wrong joint passes into everything built on it.Each joint is checked against the rules that govern it before anything depends on it.H5
ReproducibilityThe same request gives a different building on each run.The same description expands to the same elements in every tool and on every run.Reproducibility
KnowledgeInvented details look the same as known ones.Every element records whether it was given, fixed, inferred, proposed or confirmed.Epistemic calibration
InspectionNo one can see which rule produced an element.Every element shows the rules that shaped it, the rule that prevailed and who wrote it.Calculation traceability
ProductsProducts are known as they were in the training data, without current price or lead time.Mapped products carry their limits, price, lead time and carbon at the moment of design.Supply-aware design, Marketplace search

Your tools stay. Revit, Archicad, Rhino, Grasshopper and the fabricators' software each implement one expansion engine or one mapping and from then on read and write the same description, and IFC and drawings are produced from it, so the language can be adopted one project at a time. Free software lowers the cost of tools. A common language lowers the hours lost between them.

The manifesto

Ten statements. Read them, then sign.

The manifesto sets out ten statements, each with the belief it rests on, in about twenty-five minutes of reading. The signature follows the last of them, so that every name below stands under the text it supports.

  1. ConditionAn industry the size of the world, working as one team.
  2. OpportunityKeep your tools. Gain everyone's work.
  3. LanguageOne description, read the same way by everyone.
  4. StyleOne language, every style.
  5. AIPeople draft, decide and sign. Machines compute.
  6. CreativityUnique by design, predictable by construction.
  7. MarketEvery price known while it can still change the design.
  8. KnowledgeYour next project begins where every other one ended.
  9. OwnershipYours to use, nobody's to own.
  10. OutlookFrom one facade to the built world.
Challenges

Agreement is signed. Improvement is measured.

Every signature is welcome, and each one widens the community in which the language can be adopted. A signature records agreement with the manifesto; an improvement is shown only by measuring the work of a domain with and without the language. The whitepaper states such claims as hypotheses, each with its measure and the baseline it must beat: six chosen as first tests, and one hundred suggested as open challenges that any organisation may take up, modify or replace. Every organisation that has signed is invited to take one up on a real project, and a hypothesis receives its number when it is taken up.

A challenge taken up carries a responsibility. The pioneer records its own baseline before the work begins, repeats the work with the language, and publishes both results with the project, whatever they show. The list shows who is at work on each challenge, so that organisations on the same one can join their efforts, and every result once it is published. Organisations that complete a pilot and publish its measures are invited to become founding members of the neutral body that will steward the language, with seats balanced across the domains.

Of the 106 challenges, 6 are chosen as first tests and 100 are suggestions, open to take up, modify or replace. Until the first pilots begin, the list shows the six first tests.

ChallengeDomainWhere it stands
H1 CompressionEducators and researchers

Open

H2 CoverageEducators and researchers

Open

H3 Early-design speedArchitects

Open

H4 Design to quoteManufacturers

Open

H5 Validity by constructionSoftware developers

Open

H6 Mapping and integration effortSoftware developers

Open

Signatories

Those who have signed, and where they work.

Every pioneer, advocate and supporter is placed at the city they gave, or else in their country, with a line from each signatory to the signatory whose invitation brought them. Choose a domain and a country to find the advocates there; everyone who has taken part is listed below the map.

Map: Natural Earth. Places: © OpenStreetMap contributors.

Pioneers

The first pioneers will be listed here once their pilots are agreed.

Supporters

The first supporters will be listed here once their signatures are confirmed.

Advocates

The first advocates will be listed here once their signatures are confirmed.

Contributors

The first contributors will be listed here once their signatures are confirmed.