AI systems for the built environment
Same method.
Different medium.
A puzzle-solver who maps known vs unknown, finds leverage points, tests with real variables, and wires AI into the gaps.
See the workBackground
Twenty years building things that have to work.
Industrial designer by trade. Twenty years in joinery fabrication and commercial fit-out - reception desks for Okta, lobby joinery for BNP Paribas at 60 Castlereagh, bespoke furniture for Koskela. Work that goes from drawing to CNC to site, with tolerances that don't forgive mistakes.
The method was always the same: map what is known, identify what is not, find where the leverage is, test with real constraints, and build the thing. Repeat until it works.
That method transfers. The problems in built environment firms - tribal knowledge locked in people's heads, onboarding that takes six months, repetitive comms overhead that nobody has time to fix - are the same class of problem. AI is the medium. The thinking is the same.
Work
Four things that show the method.
The feature ceiling at St Paul's University - geometric timber panels, triangulated facets, perforated sections installed across a double-height atrium. Then the BNP Paribas Centre lobby at 60 Castlereagh Street - timber ring ceiling, wall cladding, all joinery throughout. Both came from an architect's design. The job was to figure out how to build them.
That means taking a set of drawings and working out how every panel gets made, how it gets supported, how it goes up in sequence, and how it meets the tolerances that the finished space demands. Structure, fabrication constraints, site conditions - all at once.
That gap between a design that looks right and a building that holds together is where the real work happens. Twenty years of commercial projects across hospitality, healthcare, and corporate fit-out. Same problem every time: take what exists on paper and make it real.
ASOR (A State of Ride) is a performance indoor cycling studio in Sydney. The production rig - DMX lighting, show file control, live stream output - was built from scratch and has run reliably across every live session since.
It works because every decision got made once, tested against real constraints, and locked in. The lighting cues, the sequencing logic, the show file structure - all of it lives in the person who built it.
That is the next problem. A system that only runs when the right person is in the room is not really a system. Extracting that embedded knowledge - the decisions, the sequencing, the cue logic - into something another operator can pick up and run is exactly the class of problem AI is well suited to solve.
The production rig is the proof the method works. The packaging of it is what comes next.
R38 Breathe — page 1 of 14
The problem
A State of Ride runs on instructor quality. When a new release drops - eight tracks, around 50 minutes, a specific physical and emotional arc - every instructor needs to walk in knowing what they are working with.
The official release guide covers the basics. What it does not cover is the read: why this track at this point in the ride, what the musical palette is doing to the room, where the psychological pressure builds and where it releases. Matty Clarke creates every ASOR release. That authorial intent moved from Matty to the team through conversation. One instructor at a time. Whatever he remembered to say.
That is not a knowledge problem. That is a distribution problem.
The approach
Every release arrives with hard data - cadence targets, BPM, RPM, perceived effort ratings, phase structure. That tells you what the ride does physically.
The Spotify API fills the rest. Legacy accounts surface audio features beyond public endpoints: danceability, energy, valence, acousticness. Cross-referenced against the ride data, those metrics describe the emotional texture of each track - not as a guess, but as a structured reading.
The task was to identify those two data sources, connect them, define what a useful instructor briefing actually contains, and direct the system to produce it - every release, without manual effort.
The output
Each release produces a 10 to 14 page intelligence document.
- –Physicality - a plain-language summary of what the ride demands, broken into front and back half arcs
- –Feel - the emotional and sonic character of each track, and how the musical palette moves across the full ride
- –Key and mood analysis - per-track tonal character mapped against the effort phase it sits in
- –Effort and position distribution - time in zone, broken down by effort level and riding position
- –Coaching integration - specific hooks where the music and the physical demand align, ready to use in cues
The result
“While the release booklet is the what to do when... the analysis becomes the why as well as the where.”
Matty Clarke, ASOR creator
Matty pulls from the document every release cycle - not because he has to, but because it gives him material he would otherwise have to assemble from memory or skip entirely. What he chooses to share with instructors is still his call. The system just makes sure the material is there.
What this is
The analysis in this document is AI reasoning applied to structured data. The judgment about what data mattered, what an instructor actually needs, and what format makes that usable - that is the work.
Tribal knowledge does not disappear when the person who holds it is not in the room. It becomes inaccessible. The job is to make it accessible - reliably, at scale, without depending on the right conversation happening at the right time.
That is the problem this solves. It is also the problem Revision is built to solve.
A tool for the built environment currently in development. Details to follow.
Writing
Thinking out loud.
The Brief Was Right. The Build Wasn't Wrong Because of the Brief.
I gave Claude Code a precise, dimensioned brief for a live gauge build. It still failed six different ways, using six different techniques, all from the same bad input data underneath.
AI doesn't close the gap. It widens it.
Everyone walks into the AI conversation with the same assumption: this is the great equaliser. That is not what I am seeing.
89 commits for a chili plant.
All I wanted was a reminder not to let my chilis die over winter. 89 commits later I have a full stack web app with shared gardens, seasonal planting guides, and a cohort who uses it more than I do.
I don't know what I know.
Someone told the Mrs and I that we are not normal. That we do not use AI like normal people do. I have been turning that over ever since.