A Preview Must Use the Same Pipeline as the Commit

Disclosure: this article was drafted with the help of an AI assistant and reviewed by the Orivox team. All facts come from Orivox's own description of its system.

A preview that looks right is not the same as a commit that is right. In an AI website editor, the owner sees a proposed change, decides whether to keep it, and only then should the live site move. If the preview is built by a different path than the commit — a cheaper renderer, a slightly older snapshot, a client-side guess — the owner can approve one thing and ship another.

In Orivox we treat that as a defect, not a convenience. The preview must be produced by the same pipeline that will apply the edit if the owner confirms it. This article explains why the two paths diverge in practice, how we keep them together, and the tests that catch a split before a customer does.

Why two paths appear in the first place

Building a preview feels like a display problem. The commit feels like a write problem. It is tempting to optimize them separately.

A preview wants to be fast. It may be rendered from a summary of the page, from the model's proposed operations alone, or from a cached copy that is cheaper to fetch than the live document. A commit wants to be careful. It re-reads the current HTML, checks the page fingerprint, applies the operations, and writes a new revision.

Those incentives pull the code apart. The preview path drops a CSS class the commit path keeps. The commit path resolves a relative URL against a different base than the preview. The preview uses yesterday's footer include; the commit reads today's. None of these differences are obvious in a typo fix. They show up when the owner is looking at a button, a form, or a layout shift, and they approve what they were shown.

The damage is quiet. The owner did not approve the live result. They approved a picture of a result. Support then has to explain why "what I clicked" and "what went live" are not the same file.

One pipeline, two exits

The rule in Orivox is simple to state. There is one function that takes the current page, the approved operations, and the project lock, and produces a new document. The preview is that document, shown before the write. The commit is that same document, written after the owner confirms.

We do not build a second, looser renderer "just for preview." We do not let the model describe the after-state in prose and display that description as if it were the page. We do not apply the operations to a stripped-down copy and hope the real file behaves the same way.

The working copy used for the preview is the same snapshot the commit will patch, held under the project lock so it cannot go stale while the owner is looking. If the snapshot cannot be held, we do not show a preview that pretends to be current. We refuse the turn or we refresh and start again.

There is still a last check at commit time: the page fingerprint must still match, and the operations must still be legal. That check is not a second pipeline. It is a gate on the same output. If the gate fails, nothing is written, and the preview is discarded with it.

What we still allow to differ

A preview is allowed to be labeled as a preview. It may have a banner, a disabled publish button, or a watermark. It may omit third-party scripts that would fire analytics on a draft. Those are decorations around the document, not a different document.

What it may not do is change the HTML that the owner is being asked to approve: the text, the attributes, the order of nodes, the hrefs, the form actions, the language and accessibility attributes. If a preview strips hreflang or rewrites a mailto because a simpler sanitizer ran only on that path, the owner is approving a lie.

The same rule applies to media. If the commit will keep a relative image path, the preview must not replace it with a placeholder that happens to look fine in the draft view. If the commit will leave a script in place, the preview may choose not to execute it, but it must still represent that the script is there.

Tests that actually catch a split

A heading typo will look the same in almost any renderer. These cases will not:

1. Make a legal text change, then compare the preview HTML to the HTML written on commit, ignoring only the preview banner. They must be identical.

2. Change a button label on a page that also has a form, a hidden field, and a lang attribute. After commit, the form action, the hidden field, and the language tag must be unchanged, and they must have been visible or inspectable in the preview.

3. Expire or replace the snapshot after the preview is shown, then confirm. The commit must refuse. It must not apply the operations to a newer page that the owner never saw.

4. Force the preview path to use a cached include and the commit path to use a live include. The test should fail until both paths read the same include.

5. Run a normal typo fix on a simple page and confirm it still previews and commits quickly. A single pipeline that is too slow to use is not a solution.

If test 1 ever produces two different documents, the preview was not the commit path.

The lesson

Speed and safety should not be split across two renderers. Build the new page once, show that page as the preview, and write that same page if the owner confirms. Decorate the draft if you must. Do not invent a second, simpler document and ask the owner to trust it. The click they make is a decision about a file. The file they are shown has to be the file that will go live.

Orivox is a free AI website builder for Hebrew- and English-speaking small businesses. If you want a broader look at the kinds of tools this problem appears in, see the article below:

https://www.orivox.pro/blog/ai-tools-to-build-a-website-without-coding