A roadmap is not a promise. It is a record of thinking.

When we first put together a public roadmap for Queensland Foundation, we made a decision that felt obvious to us but turned out to be uncommon in practice: we decided we would update it honestly. Not just when things went well. Not just when we had something exciting to announce. We decided we would update it when things moved, when things were cut, when our thinking shifted, and when something we said we would do turned out to be wrong — and we would tell people what changed and why.

That decision sounds simple. It is not. It turns out that keeping a roadmap honest is one of the hardest disciplines in a project like ours, not because the changes themselves are hard to make, but because telling people about them requires a kind of ongoing courage that is easy to underestimate at the start.

This post is about that practice — where it came from, what it costs, what it produces, and why we think it is inseparable from the thing we are actually building.

What a roadmap is supposed to do

A roadmap exists to answer a question that every person who cares about a project is quietly asking: what are you doing next, and can I trust that you will actually do it?

That question has two parts. The first part is practical. People want to know what is coming, so they can make decisions — whether to get involved, whether to wait, whether to invest time or attention or money into something that might not be ready yet. This is the surface function of a roadmap, and it is the one that most project teams design for.

The second part is harder. Trust is not established by a list of features with estimated delivery windows. Trust is established by watching how a team behaves over time, especially when things do not go to plan. The roadmap, updated honestly, is one of the clearest possible windows into how a team behaves.

When a roadmap never changes, it is not because the project never changes. Projects always change. What it means is that the team has decided not to tell you about the changes. That is a choice, and it is a revealing one.

We made a different choice. We decided the roadmap should do both jobs at once — communicate what we plan to build, and document how our thinking has evolved. Those two jobs together are what make it a genuine instrument of accountability rather than a polished piece of marketing.

The difference between updating and announcing

There is a version of roadmap transparency that most projects practice, and it looks like this: new things get announced with enthusiasm. Old things that did not happen quietly disappear. The roadmap is refreshed periodically, always forward-looking, always framed as progress. If you were to read the history of such a roadmap, you would find only momentum. You would never find a moment where the team said: we got this wrong.

This is not transparency. This is selective disclosure dressed up as openness. It is the kind of communication that optimises for a particular emotional response — confidence, excitement, forward motion — while carefully managing away anything that might produce a different response, like doubt or disappointment or the reasonable conclusion that the team does not always know what it is doing.

We are not interested in that version. Not because it is dishonest in the most obvious sense — nobody is lying — but because it treats the people who care about this project as an audience to be managed rather than a community to be trusted with the truth.

When we update the roadmap, we try to do something different. We try to make the change legible. What moved, and why. What was cut, and what led us to cut it. What was added, and what we learned that made us think it was worth adding. This is harder than announcing. Announcing is exciting. Explaining why something moved is more like doing your homework in public — it requires you to articulate thinking that is often still in progress, and to do it in a way that a person who was not in the room can follow.

We do it anyway. We do it because we think the people who have committed to this project — who have decided that permanent onchain addresses for Queensland are worth caring about — deserve to understand the reasoning behind the decisions that shape it, not just the decisions themselves.

Why change is inevitable and why pretending otherwise is corrosive

Every project that is doing real work changes its roadmap. This is not a sign of poor planning. It is a sign of genuine engagement with the world as it actually is, as opposed to the world as it appeared to be when the roadmap was first written.

We built Queensland Foundation on blockchain infrastructure that is itself evolving. The technical environment we operate in is not static. The community we are building for has ideas we did not anticipate. Our own understanding of what we are making deepens as we make it. Each of these things produces changes — sometimes small adjustments, sometimes significant reconceptions of what we thought we were doing.

The question is not whether to change. The question is whether to acknowledge it.

Projects that do not acknowledge change tend to accumulate a particular kind of debt. It is not financial debt, and it is not quite reputational debt either — it is something more like cognitive debt, a growing gap between what the team actually believes and what they are saying publicly. Over time, that gap becomes expensive to maintain. It requires ongoing effort to avoid questions that would expose it. It shapes communication in ways that gradually become distorting. And it means that when something genuinely goes wrong — something big enough that it cannot be quietly disappeared from the roadmap — the team has no established language for talking about difficulty. They have only the language of enthusiasm, which is exactly the wrong tool.

We decided early that we did not want to accumulate that debt. The practice of honest roadmap updates is in some ways a debt-management practice. Each time we explain a change, we are spending a little honesty upfront rather than storing up a larger reckoning later. It is not always comfortable. It is always worth it.

The specific discipline of telling people what was cut

Additions are easy to communicate. When we add something to the roadmap — a new feature, a new capability, a new idea we have decided is worth pursuing — that is essentially good news, and good news is easy to deliver. People tend to receive additions warmly. They feel like progress.

Cuts are different. When something comes off the roadmap, there is a version of that conversation that we could have that would be almost invisible. We could simply stop mentioning it. We could let it fade from the documentation while foregrounding other things. Nobody would necessarily notice immediately, and those who did might be willing to assume it was deprioritised rather than abandoned.

We do not do this.

When something is cut, we say it is cut. We try to explain why. Sometimes the reason is that we overestimated the value of a thing relative to the effort it would require. Sometimes the reason is that the technical landscape shifted and the thing we planned to build is now either unnecessary or better served by a different approach. Sometimes the reason is simply that we learned something — from building, from the community, from paying attention — that changed our view of what this project most needs to be.

None of these reasons are shameful. But they do require a kind of intellectual honesty that is not always comfortable to perform publicly, because they all involve some version of admitting that we thought something was a good idea and then decided it was not.

We think that is fine. We think it is more than fine — we think it is one of the most reliable signals of a team that is doing genuine thinking rather than protecting a narrative. The willingness to cut something publicly, and to explain why, is evidence that the roadmap is a working document rather than a trophy cabinet.

Why the reasoning matters as much as the decision

It would be possible to update a roadmap with full transparency about what changed without ever explaining why. A changelog is not the same as an explanation. You can document change without illuminating it.

We try to illuminate it.

This is harder than it sounds. The reasons behind a roadmap decision are often messy. They involve partial information, competing considerations, conversations that happened in contexts we cannot fully reproduce in a public post. They involve judgment calls that a different reasonable team might have made differently. Explaining them publicly means exposing that messiness — not concealing it behind the clean language of a decision already made, but actually showing, as best we can, the thinking that led there.

We do this for a few reasons.

The first is that it is more useful. If you understand not just what changed but why, you have a much richer picture of the project. You can evaluate the reasoning. You can notice if our priorities are shifting in ways that matter to you. You can hold us to account — not just for whether we did what we said, but for whether the logic behind our decisions is consistent and coherent over time. That kind of accountability is only possible when the reasoning is visible.

The second reason is that it builds a different kind of trust. There is a thin version of trust that is built on track record alone — you said you would do this, you did it, therefore I trust you. This is real trust, but it is fragile. It cannot survive a genuine miss, because the entire basis of the relationship is perfect execution. The thicker version of trust is built on understanding — I understand how you think, I understand why you make the decisions you make, and even when I would have made a different decision I can follow the reasoning and believe you are operating in good faith. This kind of trust survives difficulty. It can accommodate a miss because the relationship is not premised on perfection.

We are trying to build the thicker version. That requires showing our reasoning, not just our results.

The third reason is that explaining our reasoning keeps us honest with ourselves. There is a discipline involved in articulating why you made a decision that is separate from the discipline of making the decision. When you have to write down your reasoning in terms that someone outside your own head can follow, you find out quickly whether the reasoning is actually sound. Sometimes it is. Sometimes the act of writing reveals a gap or a contradiction that the decision itself managed to conceal. Either way, the discipline of explanation makes us better at thinking — not just better at communicating.

Roadmap transparency as an expression of what we believe about ownership

Queensland Foundation is building something that is, at its core, about a specific kind of permanence. Permanent onchain addresses. One price, once, for life. No renewals, no expiry, no ongoing relationship with a central authority that can change the terms. The whole premise of what we are offering is that ownership means something — that when you hold a .queensland address or a .brisbane2032 address, it is genuinely yours, unconditionally, without the fine print that normally accompanies the word “yours” in the digital world.

That belief — that ownership should mean what it says — is not something we can quarantine to the product. It bleeds into how we operate. If we believe that people who hold our addresses deserve unconditional clarity about what they own, then we also have to believe that people who follow our project deserve unconditional clarity about what we are building and how our thinking evolves.

You cannot say, with integrity, “this is yours forever, no hidden clauses” and then manage your public communication in a way that conceals the things that would be inconvenient to share. Those two things do not fit together. The trust required to mean the first thing requires that you also mean the second thing.

Our practice of transparent roadmap updates is not separate from the thing we are building. It is an expression of it.

What we have learned from doing this

We have been doing this long enough to have learned some things about it.

The first thing we learned is that honesty about change does not erode confidence — it builds it. The fear, when you first start updating a roadmap publicly and explaining what was cut or moved, is that people will interpret the changes as signs of dysfunction. That they will see a missed milestone and conclude the team is unreliable. That they will see a cut feature and feel misled. In practice, we have found the opposite. People who follow projects carefully are not looking for perfection. They are looking for integrity. When they see a team that updates its roadmap honestly — that says this moved because of this, that was cut because of that — they tend to conclude that the team can be trusted, not that the team is struggling.

The second thing we learned is that the discipline of explanation makes us more deliberate about changes. When you know you will have to explain a change publicly, you think harder before making it. Not to avoid making it — necessary changes should be made — but to make sure you can actually articulate why. Sometimes that process of pre-explanation reveals that your reason for making the change is thinner than you thought. Sometimes it firms up the reasoning in ways that make you more confident. Either way, the accountability of public explanation produces better decisions.

The third thing we learned is that the cadence matters. A roadmap updated once and then left alone is not a living document. It is a photograph of a moment. For the roadmap to function as a genuine instrument of accountability, it needs to be updated with enough regularity that it reflects the actual pace of the project’s evolution. This does not mean updating it constantly for the sake of activity. It means updating it whenever something real has changed, and being honest with yourself about what counts as real.

The fourth thing we learned is that the language of roadmap updates requires its own care. There is a temptation, when explaining why something moved or was cut, to reach for the most positive framing. To describe a delay as a strategic reprioritisation. To describe a cut as a decision to focus. These framings are not necessarily wrong, but they need to be earned. If you reprioritised strategically, say what the strategic reasoning was. If you decided to focus, say what you are focusing on and why that focus required cutting the other thing. The framing should follow from the substance, not substitute for it.

The accountability this creates, and why we welcome it

Honest roadmap updates create accountability. We want to say that plainly, because some teams treat accountability as something to be managed — a risk to be minimised, a pressure to be navigated. We do not experience it that way.

Accountability to the people who care about Queensland Foundation is not a constraint on our work. It is part of the structure that makes the work meaningful. When we know that the community can see not just what we planned but how our thinking has evolved, it creates a kind of external coherence that we value. It means we are not just accountable to ourselves — to our own internal sense of whether we are making good decisions — but to a broader view that includes people who are watching the project from the outside, who see things we might miss, who have interests that are not identical to ours.

This kind of accountability has made the project better. When we explain our reasoning and people push back on it — when someone in the community points out something we had not considered — that feedback is more productive than it would be if we had only announced a decision without explaining it. The explanation creates a surface for engagement. The engagement produces better outcomes.

We also welcome accountability because we think it is the honest consequence of asking people to trust us. When we say that a .qld address is yours permanently, that we will not change the terms, that the infrastructure will persist — we are asking for a very significant level of trust. That level of trust is not free. It needs to be earned, continuously, through behaviour that is consistent with the claims. Honest roadmap updates are one of the behaviours that earn it.

On the difference between a working document and a marketing document

We have used the phrase “working document” a few times, and we want to be more specific about what we mean.

A marketing document is designed to produce a particular response. Its truth content is real but selective — it contains nothing false, but it is shaped and curated to create a specific impression. A good marketing document is effective precisely because it controls the narrative. It shows you what you should see. It is, in the best sense of the word, persuasive.

A working document is designed to be accurate. Its truth content is not curated for effect — it reflects the actual state of things, including the parts that do not produce a flattering impression. A good working document is useful precisely because you can rely on it to show you what is actually there. It is, in the best sense of the word, trustworthy.

A roadmap that is never updated is a marketing document. It shows you what the team wanted you to see at the moment of publication, and it never revises that picture regardless of how reality has moved. A roadmap that is updated only with additions — with new exciting things, but never with cuts or delays or changes — is also a marketing document. It has the appearance of transparency, because things do change, but it has been curated to produce a specific response: confidence, enthusiasm, the feeling that things are always moving forward.

Our roadmap is a working document. It changes in all directions — things are added, things are cut, things move. It does not always tell a flattering story. Sometimes it tells the story of a team that overestimated how quickly something could be done, or that learned something which required a significant rethink. We prefer this. We prefer it because it is accurate, and because accuracy is the only foundation on which genuine trust can be built.

Why this is harder than it looks

We want to be honest about the difficulty of this practice, because we think it is important not to make it sound easy.

The hardest part is not the mechanics. Writing an update to a roadmap and explaining what changed is not technically difficult. The hardest part is the psychological cost of sustained exposure. Every time you update a roadmap honestly — every time you say, this thing we said we were going to do, we are not going to do — you are choosing to be visible in a way that most organisations are trained to avoid. You are choosing to show a gap between what you said and what happened. You are inviting scrutiny of your reasoning rather than just your results.

That kind of exposure becomes cumulative. It is not especially difficult the first time. By the hundredth time, you have built a practice and a muscle. But in the middle, there are moments when the easier path — the quiet update, the dropped feature, the forward-only announcement — is genuinely tempting. We have felt that temptation. We have chosen, each time, to explain anyway.

The other difficulty is audience diversity. The people following Queensland Foundation come with different expectations, different levels of technical understanding, different emotional relationships to the project. An explanation that is adequate for a deeply engaged community member may be insufficient for someone who is coming to the project fresh. An explanation calibrated for someone with technical context may be opaque to someone without it. Writing roadmap updates that work across this range of people is a genuine craft challenge, and we do not always get it right.

What we try to do is aim for a level of explanation that assumes the reader is intelligent and genuinely curious, but does not assume they have been following every previous update in detail. We try to make each update self-contained enough to be understood on its own, while also being part of a coherent narrative for those who have been following all along.

What it means to build something permanent while being honest about impermanence

There is a tension at the heart of what we do that we think about a lot.

The product we are building is premised on permanence. Permanent addresses. Permanent ownership. Something that will exist as long as the blockchain exists, regardless of what happens to us as a team or as an organisation. This is one of the things we believe most strongly about what Queensland Foundation offers — the value of genuine permanence in a digital world where almost everything is contingent, revocable, or subject to terms that can change.

And yet the process of building that permanent thing is irreducibly impermanent. Our roadmap changes. Our thinking evolves. Things we were certain about turn out to be more complicated. The journey from here to the finished thing is not a straight line and never will be.

This tension could be uncomfortable. It could feel like a contradiction — how can you offer permanence if your path to it keeps changing? We have come to see it differently. We think the honest acknowledgement of an impermanent process is actually what makes the claim of a permanent product credible. If we were a team that never updated its roadmap, never admitted to changes, never showed you the evolution of our thinking, you would have no basis for trusting that our commitment to permanence in the product is genuine rather than rhetorical. The willingness to be honest about the uncertainty of the journey is evidence that our certainty about the destination is real.

We are uncertain about many things. We are certain that the addresses we are issuing — the .qld addresses, the .brisbane addresses, the .gold-coast addresses and all the others — are permanent. That certainty is not in tension with our honest acknowledgement of everything else we are still figuring out. It is supported by it.

The commitment going forward

We will keep updating the roadmap. We will keep explaining what changed and why. We will keep choosing the harder path of transparent reasoning over the easier path of selective announcement.

Not because we are required to. Not because it is the most comfortable way to operate. But because we think it is the only version of this project that is worth building.

Queensland Foundation is, at its root, a project about giving people something they can trust unconditionally. An address that is theirs without clauses. A piece of digital Queensland that does not expire, does not require renewal, does not live at the pleasure of an intermediary who can change the rules. That is what we are building, and every decision we make about how we communicate should be consistent with it.

An honest roadmap is one of the ways we try to be consistent with it. Not the most dramatic way. Not the most visible way. But one of the most sustained and most tested ways, because it requires us to make the same choice over and over again — to be transparent even when it is inconvenient, to explain even when announcing would be easier, to show our reasoning even when the reasoning is still being worked out.

That repeated choice, made consistently over time, is what trust actually looks like. Not a declaration. Not a marketing document. A practice.

We intend to keep practicing.