Barefoot BIM - Print All

1

Building by Building Information Modelling

How do we eat?
Why do we eat?
Where shall we have lunch?

Barefoot BIM and the RIBA API

toward non-scalable, convivial tools

a 3 part presentation:

1. "Computervision's INTERACT - GRAPHIC Presently under development, this terminal combines several low-cost facilities into one configuration that will allow a high level of interaction. The unit is designed as a transition between present methods and future computer graphics. With this device the operator can even use his own pencil." source - The Architecture Machine - 1970

2

Consider for a moment a society of designers built upon machine aides that cannot evolve, self-improve, and most importantly, cannot discern shifts in context.

These machines would do only the dull ignoble tasks, and they would do these tasks employing only the procedures and the information designers explicitly give them.

Furthermore, since no learning is permitted in our not-so-hypothetical situation, these machines would have the built-in prejudices and 'default options' of their creators.

These would be unethical robots.

— The Architecture Machine - Nicholas Negroponte 1970

> part 1: how do we eat? 

3

axisdesignarchitects.com

practitioners and
hopeful technologists

ArchiCAD users since 1995...
sharing projects at BIM events

writing, building, teaching

language model optimists and methodological experimentalists...

> part 1: how do we eat? 

4

fieldsection.co.uk

We work on stuckness at the seams – where technical systems, regulation, and real use collide. Close enough to read the situation; clear enough to help it move.

One step to the left of delivery, while options are still live.

Dr Justin Pickard - Anthropologist

Rob Annable - Architect

> part 1: how do we eat? 

1. source credit: Toni Frissell, 1954, public domain / Library of Congress

5

Scalability is possible only if project elements do not form transformative relationships that might change the project as elements are added.

But transformative relationships are the medium for the emergence of diversity.

Scalability projects banish meaningful diversity.

Nonscalability theory allows scales to arise from the relationships that inform particular projects, scenes, or events.

— Anna Lowenhaupt Tsing, "On Nonscalability: The Living World Is Not Amenable to Precision-Nested Scales,"

what is nonscalability?

> part 1: how do we eat? 

1. also "Nonscalability theory requires attention to historical contingency, unexpected conjuncture, and the ways that contact across difference can produce new agendas."

6

what are barefoot developers?

> part 1: how do we eat? 

We get powerful, flexible tools that let barefoot developers make lots and lots of local, home-cooked software. They solve all kinds of specific, local problems for the people around them.

Their communities love it. They become dependent on what they’ve built.

But the software and the data behind it are all held in the cloud. And you have to keep paying a monthly subscription fee to access it.

And then suddenly the terms of service change. And there’s a giant advertisement in the middle of every homepage. And the subscription fee doubles.

And it turns out what they’ve built was never actually theirs all along.

— Maggie Appleton - Home Cooked Software 2024

[Ed: You mean vibecoding??]

1. In this article we propose “local-first software”: a set of principles for software that enables both collaboration and ownership for users. Local-first ideals include the ability to work offline and collaborate across multiple devices, while also improving the security, privacy, long-term preservation, and user control of data. - https://www.inkandswitch.com/essay/local-first/

2. Slides from https://maggieappleton.com/home-cooked-software

7

> part 1: how do we eat? 

- Do standardised interfaces, library parts and tools in BIM risk being a barrier to architectural diversity?

questions...

....What does non-scalable barefoot development look like? > > >

- What can we learn from nonscalability theories to foster digital tools that are contextual, relational and particular?

- Can Large Language Models allow the profession to 'barefoot develop' its own nonscalable, convivial tools?

1. "Scalability projects banish meaningful diversity, which is to say, diversity that might change things." — Tsing (2012)

2. The question inverts the standard BIM question: not "how do we standardise?" but "what would tools look like if they started from the particular?"

3. - How can a diverse profession of multiple scales ensure their BIM methodology is responsive to and contingent on each building's needs?

4. How can 'local first' computing support user agency & ownership of data and software?

8

single file html tools

for large dataset analysis

> part 2: why do we eat? 

1. Generates LLM prompt carrying the data and queries: "HEAT PUMP ANALYSIS REPORT Generated: 2026-02-02 Analysis Tool: Heat Pump Analysis Tool by Axis Design Architects System: Plot 04.xlsx === LLM ANALYSIS PROMPT === You are analyzing heat pump system performance data from a single residential system. Please provide insights on:..."

9

turning space analysis

> part 2: why do we eat? 

F.A.F.O

mistake strewn iterations as knowledge building!

...whilst a LLM holds your hand

1. Ivan Illich, Tools for Conviviality (New York: Harper & Row, 1973), Chapter 2: "Convivial Reconstruction", p.22

10

using LLMs to import material info into ArchiCAD

using LLMs to create bespoke software to analyse whole BIM

> part 2: why do we eat? 

1. Embodied carbon calculator querying ICE database (Circular Ecology / University of Bath)

2. ICE database = 300-page PDF + spreadsheets. Tool makes carbon visible during sketch design, not post-rationalised in LCA

3. Not replacing professional LCA — making embodied carbon legible when material choices are still live

11

talk to your building...?

> part 2: why do we eat? 

"Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user."

— Ivan Illich

12

bespoke, rapid, single file tools

> part 2: why do we eat? 

13

> part 2: why do we eat? 

1. PDF as the scalable document: fixed layout, non-interactive, designed for print, assumed as universal output

2. HTML as alternative: interactive, queryable, embeddable, forkable, version-controllable

3. Planning submissions, client reports, building manuals — all could be living documents rather than frozen snapshots

14

> part 2: why do we eat? 

- AI assisted 'barefoot development' of practice specific tools is now possible and affordable for everyone.

- The tool's purpose and design can be particular to each project and client.

- The collaborative iteration reinforces the relationship between architect and machine.

- Expensive software subscriptions may be over!

- The value of this process increases as more tools are built and shared.

BUT ... how do we secure user agency and ownership of data? >>>

summary..

15

architecture barefoot developer clubs??

a network of groups making and sharing software under Creative Commons licenses - sharealike, attribution etc?

> part 3: where shall we have lunch?

proposition...

"Seize back the power of computation!"

"Make ethical robots!"

"PDFs are dead!"

"Local first!"

1. "Nonscalability theory requires attention to historical contingency, unexpected conjuncture, and the ways that contact across difference can produce new agendas." — Tsing (2012)

2. Regional practice cohorts sharing tool seeds — not products, but starting points adapted to local context

3. Creative Commons licensing: forkable, attributable, non-commercial. Code is yours to modify.

16

> part 3: where shall we have lunch?

questions...

- Who owns the barefoot development language models / tools?

- How is it stored and what resources does it consume?

- Who bears the compute cost?

- What dataset is it trained on?

- Who decides what questions it can answer? (who shapes its boundaries?)

- Can a user modify it for their specific context, or is it one-size-fits-all?

- Can I export my contribution if I leave?

...and are they
a landlord, a librarian, or a gatekeeper?

1. "Machines would have the built-in prejudices and default options of their creators" — Negroponte (1970)

2. Training data: who contributed? Who profits? What biases are embedded?

3. RIBA AI Report 2025: ethical concerns rising — clients 86%, wider community 85%, fellow professionals 80%

4. Local LLMs (Ollama, llama.cpp) as alternative: runs on a laptop, no subscription, no data extraction

17

LARGE
LANGUAGE
MODEL

LLM stewardship on behalf of profession, responsible for dataset ethics, licensing and hosting and offering an accessible API (Application Programming Interface) to its data

> part 3: where shall we have lunch?

proposition...

"promoting and facilitating the acquirement of the knowledge of the various arts and sciences connected therewith"

— RIBA Charter 1837

Precedents:

The Library (since 1834)

190 years stewarding the profession's accumulated knowledge, free to access, open to all.

Education Validation (since 1924)

RIBA determines what constitutes professional knowledge.

Technical Resources

Plan of Work, Uniclass, (formerly) NBS. The profession has created shared infrastructure before.

BUT ... landlord, librarian, or gatekeeper?...

- If RIBA hosts centrally, is it still "local-first"?

- Can practitioners fork their own version?

- What happens when RIBA loses interest, or goes down?

...what is the nonscalable version? >>>

1. "RIBA's role is clear. We need to make sure AI serves the profession, not the opposite." — Muyiwa Oki, RIBA AI Report 2025

2. Regional LLMs trained on local planning policy, building stock, climate, precedents — West Midlands model knows Birmingham Article 4 directions

3. RIBA API: planning policy queries, Building Regs compliance, embodied carbon data, anonymised performance benchmarks

4. Constitutional Precedent... The 1837 charter already covers this:the "arts and sciences" have evolved from drawing → photography → CAD → BIM → now computational intelligence.

18

Public Commons Partnerships

> part 3: where shall we have lunch?

1.  Workers, who manage the day-to-day running of the workplace.
‍
2.  A Public Body, such as a city council or agency, which provides resources and support.
‍
3.  The Common Association, made up of local residents who decide how profits are reinvested.

A PCP is built around a Joint Enterprise co-owned and co-governed by three groups:

This model is different from charities, community land trusts, and community consultation exercises. Its uniqueness lies in combining worker control, community decision-making, and public support into one institution. The goal isn’t just to make workplaces fairer, but to steadily grow the commons — the shared wealth and resources that belong to all of us.

— Radical Abundance

1. Kai Heron, Keir Milburn & Bertie Russell, Radical Abundance: How to Win a Green Democratic Future (Pluto Press, 2025)

2. PCP vs PPP: where PPPs transfer public assets to private profit, PCPs transfer control to workers and communities

3. Three elements: public body (assets, legitimacy), joint enterprise (workers, expertise), commons association (surplus governance)

4. Crucial move: surplus from one PCP must support another PCP elsewhere — self-expanding circuit of the commons

5. https://www.in-abundance.org/what-is-a-public-commons-parntership

19

Radical Abundance British Architects

> part 3: where shall we have lunch?

RABA

"Seize back the power of computation!"

"Regional Barefoot Clubs"

CREATIVE SURPLUS?

????

1. "Scalable projects are everywhere linked with nonscalable worlds." — Tsing (2012)

2. Public body = regional RIBA chapters. Joint enterprise = cohorts of barefoot developer practices. Commons association = practitioners + educators + community reps.

3. Surplus is knowledge: training data, anonymised performance data, validated workflows, tool seeds, pedagogical material

4. Practices build tools → tools generate knowledge → knowledge improves regional LLM → better LLM enables more practices → surplus seeds new regional PCPs

20

10 PRINT Building by Building Information Modelling
20 GOTO 10

> part 3: where shall we have lunch?

> particular and responsive tools over scalable platforms

> tool-making capacity distributed across small practices

> a computation commons and regional RIBA stewardship

Barefoot BIM and the RIBA API

an ethical future of computational tool-making

1. "Unlearning is as important as learning… Information can assume less significance over time and eventually disappear — exponential forgetting." — Negroponte (1970)

2. Not "Building Information Modeling" (universal methodology) but building-by-building — each model specific to this site, this community, this authority, this building's actual users

3. Negroponte's ethical machine + Tsing's nonscalability + Illich's conviviality + Appleton's barefoot development

4. Software for this building, not every building — but with knowledge that circulates

21

</END>

Slide Away  - sharing the software that made this talk...

https://www.fieldsection.co.uk/work/barefoot-bim/leicester-2026/

https://codeberg.org/fieldsection/slide-away

Barefoot BIM - HTML, browser friendly slides and footnotes

> part 3: where shall we have lunch?

1. "Nonscalability theory shows us the architecture of nonnesting, which is key to the (re)making of cultural diversity." — Tsing (2012)

2. slide-away: single-file HTML presentation tool. No PowerPoint, no Keynote. JSON data, static HTML output.

3. Recursive proof: a barefoot tool presenting the case for barefoot tools