§ Continuity and Rollback

Nothing is overwritten. Going back is a read.

Every application in Frames Studio keeps every version it has ever had, because a save is an insert and never an overwrite. That single decision is what makes reverting cheap: there is no earlier state to reconstruct, because the earlier state was never removed. The same decision answers the harder question a procurement reviewer asks, which is not how you undo a bad afternoon but what happens to the estate if something happens to us.

Two different readers want this page. A developer wants to know how quickly a mistake can be undone. Someone signing a contract wants to know what they own and what survives. The mechanism underneath both answers is the same, so this page states it once and then answers each question in turn.

I

Why Going Back Is Cheap Here

In a conventional stack, rolling back is a forward operation wearing a disguise. You find the previous commit, check it out, build it again, wait for the pipeline, and deploy the result. The old version does not exist anywhere as a running thing. It exists as instructions for producing a running thing, and you have to follow them again under pressure, which is the worst possible time to be running a build you have not run in weeks.

Frames Studio does not have that shape, because it does not have those steps. An application is rows, and a save writes a new row rather than replacing the old one. The version you replaced is still sitting there, complete, in the same table it always lived in. Reverting means resolving the earlier row instead of the later one.

(1) History Is Not A Feature You Can Forget

There is no code path that overwrites. Version history is not something a developer has to remember to create, and it is not a setting an administrator can switch off to save space. It is a consequence of how writing works, which means it is as reliable as the write itself.

(2) Rollback Is A Read, Not A Rebuild

Going back does not run a build, because there is no build to run. It does not check anything out, because there is no checkout. It does not wait for a deploy, because nothing deploys. The previous version is served the same way the current one is, by resolving a row at request time.

(3) The Change Was Shown Before It Landed

Reverting is the second line of defence rather than the first. Every edit runs as a dry run and returns the exact byte delta before anything is written, so the common case is catching the change before it exists. History is what covers the case where the delta looked correct and the behaviour was not.

(4) The Estate Is One Thing To Protect

Application code, schema, desktop placement and users are records in one database. Protecting the estate is protecting a database, so it inherits the backup and recovery model your organisation already has opinions about, rather than requiring a separate story for source control, another for configuration, and another for state.

“A rollback that has to rebuild the old version is a deployment. A rollback that reads the old version is a lookup. Only one of those is something you are willing to do at four in the afternoon.”

II

What A Reviewer Should Ask

These are the continuity questions we would put to a vendor in your position, with the answers we can give today.

Can we get our applications out?

Yes. Application code and schema are readable text, and they can be exported. There is no opaque artifact and no proprietary binary in the path, so what you export is the same thing the runtime reads.

What does an export need in order to run?

The Frames Studio runtime. The code is real Python, HTML, CSS and JavaScript, but it is resolved and dispatched by the runtime at request time, so an export is not a standalone application you drop into an unrelated stack. The runtime is self-hostable, which is the part that matters: you can run it yourself. The three modes.

How far back can we go?

To any version that has been saved, because none of them were removed. Beyond application history, the database itself supports backup, restore and point-in-time recovery, which is the layer that covers accidents larger than one bad edit.

What happens if you stop existing?

The estate is a database you can export and a runtime you can host. That is the honest shape of the answer, and it is deliberately not a promise about our longevity. For teams whose process requires it, the same architecture supports a source-code escrow arrangement with defined release conditions.

III

What We Have Not Published Yet

Everything above is a property of the architecture, which means it is true now rather than planned. What is missing is the evidence that turns an architectural claim into something a reviewer can check, and we would rather name the gap than let you find it.

We have not published a written export procedure, and we have not published the result of a restore exercise performed against it. Until both exist, the correct way to read this page is as an accurate description of how the system is built, not as a tested runbook you can hand to an auditor. If continuity is a gating requirement for you, say so and it moves up the queue, because the work is documentation and demonstration rather than engineering.

We also have not published an escrow arrangement. The architecture supports one and we will enter into one where a review requires it, but no agreement is in place today and we are not going to imply otherwise.

Ask what happens
when you need to go back.

The question worth asking a platform vendor is not whether they have a rollback button. It is what the rollback actually does, what it depends on, and who has to be available for it to work. Ask us those three and we will answer them directly.

Evaluating for a team?

Ask about the exit.

Tell us what your process requires for continuity and exit. We will tell you what exists today, what is architectural, and what we have not published yet.

Request Access