The reversibility promise

Decolla classifies every build item before deployment — auto, reverse, or irreversible — with one-way changes flagged in advance on the plan you approve. Here is how the doctrine works, and exactly where it stops.

Undocumented change is the real risk

The changes that hurt an estate are rarely the ones that break something on day one. Those get noticed, escalated and fixed. The expensive ones surface months later: a setting nobody remembers applying, on devices nobody can list, with no record of what it replaced. Removing it becomes research. Sometimes it becomes a re-image.

Most provisioning tooling treats this as normal. Things get applied, the record is a log line if you are lucky, and undoing anything is your problem. If you are the person who carries the risk when a build goes wrong, that arrangement should bother you — every deployment quietly adds to a pile of changes you cannot confidently reverse.

Decolla's position is simple: a tool drawing on a catalogue of 260+ build items owes you an equally precise account of how each change it applies is undone. That account is the reversibility promise.

Every item is classified before anything runs

Decolla's library holds 260+ build items across 21 sections — pre-built, industry-tested policies, scripts, hardening steps and the recurring fixes every helpdesk knows by heart. When you assemble a build, the itemised plan you approve lists every selected item with its delivery method and one of three reversibility classes: auto, reverse, and irreversible.

Two of the three classes are reversible; the label on the plan tells you which applies to each item. The practical guarantee is the same for both: a rollback path exists, per item or for the whole build. The third class is different in kind — and it is treated differently, as the next section explains.

The classification is not buried in documentation you would have to go looking for. It is printed on the plan itself, next to each item, before deployment. You read the plan; nothing runs until you approve it.

Irreversible means a flag up front, not a footnote

Some changes are genuinely one-way, and pretending otherwise is how tooling loses trust. So Decolla does not pretend. Where an item cannot be undone, the plan says so in plain terms — next to the item, in advance, on the same document you read before approving. Not buried in a general disclaimer accepted once at sign-up: named, per item, on the plan.

The reasoning is deliberate: the person who owns the risk should see every one-way door named before it opens — knowingly, in advance, with the item on the plan in front of them. Nobody on your team should discover that a change was permanent after it has happened. And because nothing runs until you approve the plan, an item you are not prepared to make permanent is an item you can simply leave out of the build.

Rollback: per item, or the whole build

Rollback in Decolla is concrete and scoped: it covers the changes Decolla itself made. For items in the reversible classes, you can roll back a single item that turned out to be unwanted, or roll back the whole build. Reversibility is offered per item and in full — not as a vague restore button whose actual coverage you have to guess at.

It also answers the question every IT manager eventually gets asked: what exactly did that build change? With Decolla, the answer is written down before anything runs — the itemised plan you approved, listing every item, its delivery method and its reversibility class. No archaeology, no folklore, no asking the person who left.

What rollback does not cover

A reversibility promise is only credible if its boundary is drawn honestly, so here is the boundary: rollback covers Decolla's own changes — precisely and only.

• It will not rescue a failed Microsoft installation. Application and update installs run at Microsoft's pace, through Microsoft's mechanisms, and Decolla does not claim to speed them up or unwind them.
• It will not unstick a stuck Enrollment Status Page. If ESP hangs, that is a Microsoft-side condition to diagnose — not something a third-party rollback can wave away.
• It will not undo changes made by other tools, other admins, or policies that already existed in your tenant. Your tenant remains yours; Decolla accounts for what Decolla did, nothing more.

You have probably read vendor pages that imply their rollback fixes everything short of hardware failure. We would rather you knew exactly where ours stops. It is the same instinct behind publishing the full list of Graph scopes before you connect Decolla to your tenant: narrow, explicit claims you can verify beat broad ones you have to take on faith.

A standard you can hold us to

Decolla is built by The Cloud Platform, a working UK IT consultancy. This doctrine exists because we have been the people cleaning up after undocumented changes — not because a whiteboard said "trust" on it. The product is in private build, so there are no customer quotes to show you, and we will not invent any. What we can show you is the standard itself: every item classified before deploy, every one-way door flagged on the plan before you approve it, and a rollback — per item or whole build — whose scope is stated narrowly enough to be true.

If that is the standard you want your provisioning tooling held to, join the early-access waitlist — and when your invitation arrives, read a plan for yourself before anything runs.