In my last journal entry, after five months inside a complex coordination environment, I wrote one sentence that I have not been able to put down since:
The coordinator’s brain should not become the database of the project.
At the time it was an observation. I had become the place where the project’s history lived. Which asset had which issue. Which comments were actually resolved and which were only administratively closed. Which decision was based on approved information and which was an inherited assumption. Who owed the next response.
It worked, in the sense that I could usually answer the question. It failed in a more important sense: if the answer only existed in my head, the project had a single point of failure. It was me.
This entry is about what I did about it. I built a tool called b1m.solutions.
The Problem I Kept Running Into
Projects are not short of places to put information. There are issue platforms, common data environments, Aconex threads, email, meeting minutes, WhatsApp groups and site walks. The problem is not storage. The problem is that none of these places keep the thread.
An issue platform records a status. It can tell you an item was closed. It usually cannot tell you who confirmed it, on what basis, or what it was waiting on before that.
Meeting minutes record a decision. Nobody reopens them three months later, when the same decision quietly needs to apply to twenty other assets.
Requests go out to contractors and consultants. When nobody answers, nothing comes back to remind you. The silence just becomes part of the project.
In my previous entry I described the shift from seeing a clash as the problem to seeing it as an observation:
The durable thing is not necessarily the clash. It is the coordination thread surrounding it.
That thread is exactly what gets lost. So I started building something to hold it.
Read from the bottom up, that is one issue’s thread: an observation on site, a measurement, a request to the MEP team, their answer, my check that the answer met the request, their claim that it was fixed, and the client’s walk-through. In most projects those pieces live in five different places.
What b1m Is, and What It Is Not
b1m.solutions is a coordination memory.
It is not a modelling tool. It is not a common data environment, and it does not replace the issue platforms a project already uses. It sits beside them and keeps what they tend to lose: what happened around an issue, in order, with the reasons attached.
I built it for myself first. One coordinator, many assets, and most of the work done away from a desk: on site, between meetings, on a phone.
A few principles shaped almost every decision in it.
- Nothing in the record is overwritten. When something changes, the earlier version stays in the history, with who changed it and when. When something is recorded later than it happened, the record says so.
- A claim is not a confirmation. These are different events, and the tool treats them differently.
- A decision carries its basis. Who decided, when, where it was recorded, and how far it reaches.
- What you are waiting for comes back. Silence is surfaced, not absorbed.
The screenshots below use a fictional project. The real one belongs to a client.
Claimed Is Not Confirmed
In When Coordination Moves Ahead of Clarity I argued that administrative closure and technical resolution are not the same event. A model update, an upload and a closed issue do not, by themselves, prove that anything was resolved.
So in b1m, “reported fixed” is its own state. When a contractor says an issue is fixed, that is recorded as what it is: a claim, by someone, on a date. The issue stays visibly unconfirmed until the confirmation actually arrives.
Resolving an issue asks one question that most trackers never ask: how do we know? Confirmed by the BIM Manager, the site team or the design team, or through an approved model, a meeting decision or an approved submission, with the reference beside it where there is one: the email, the minutes item, the model revision.
A resolved issue should always be able to answer the question: how do we know?
Decisions Carry Their Basis, and Their Reach
Most coordination decisions are made in meetings, workshops and calls. Most of them are later reconstructed from memory.
In b1m a decision is recorded with why it was made, who made it, when, where it was recorded (the minutes, the email, the RFI), and which earlier decision it replaces, if any. The previous decision does not disappear. It is marked as replaced, and both stay readable.
Working across many repeated assets also taught me a second lesson, which I described as the difference between what should be solved once and what must remain instance-specific. A decision made on one issue often turns out to apply everywhere. So a decision can be marked as applying to the whole project, and a specific asset can be recorded as an exception, with the reason.
The point is not bureaucracy. The point is that six months later, someone can open the record and understand why the model looks the way it does, without having to find the person who remembers.
What You Are Waiting For Comes Back
A large part of coordination is waiting. Waiting for a revised route, a clarification, an approval, a site check.
In b1m, every request records who owes what, and since when. b1m does not send anything itself; it remembers what I asked, and of whom. If nobody answers, the briefing raises it in plain words, for example that there has been no reply in ten weeks. When an answer depends on a meeting, b1m reminds me once the meeting has passed to record what was settled.
That meeting reminder has become one of the features I rely on most. It is usually the nudge to write up the meeting notes before they fade.
Every item on the briefing says why it is there. Nothing is ranked by a score I cannot explain. If something needs attention, the reason is written next to it.
Finding the Fragment
Memory does not come back as a record number. It comes back as a fragment: someone confirmed the clearance on site, a few weeks ago, I think.
So b1m searches everything that was said, including the history. Updates, responses, decisions, notes and observations. A result shows the words as they were written, who said them and when, and opens them in their place in the thread.
Built for the Phone, and for Judgement
Most of my coordination happens away from a desk, so the phone was never an afterthought.
Observations can be captured on site in a few seconds, with photos, and triaged later. Unfinished writing survives the phone closing the app halfway through a sentence. Correspondence that is not an issue (a call, a message, a conversation on site) can be kept as a note and linked to the assets and issues it concerns.
And there is one thing I deliberately kept out of the records: my own judgement of what matters today. A meeting can reshuffle a day in an hour. What matters is usually how critical something is and how hard the client is pushing for it. So I can flag an issue or a to-do as mattering now, with a reason if it helps (the client is pushing, it blocks work, a submission is due), and it leads the home screen. The flag shows how long ago it was set, so a stale priority is easy to see. It never becomes part of the history, because a priority is not a fact about the project.
What It Deliberately Does Not Do
It does not decide anything. It does not close issues for me. It does not infer that something was approved. It does not turn a claim into a resolution.
That last point connects to an argument I made in The Next Layer of BIM Maturity. As AI assistants start taking part in coordination, the record they work from matters more, not less. An assistant can read b1m’s records through a connector I authorise. If I allow it, it can add one thing: an observation, which it asks me about first and which I then triage myself. It cannot resolve, close, edit or delete anything, and it cannot quietly rewrite the history it reads. If a project’s rationale is going to be read by machines, it had better be written down properly first.
For a project to evolve safely, its rationale must be as permanent as its structure.
Closing Thought
b1m did not start as a product idea. It started as an uncomfortable realisation that I had become the project’s memory, and that a project depending on one person’s memory is fragile, however good that memory is.
The model shows what exists. Issue platforms show what is open. What I wanted was something that keeps why: why something changed, who confirmed it, what it was waiting for, and what was decided along the way.
A project should not depend on any one person remembering why. It should be able to tell you itself.