Is BrandSwitch AI? No - and That's Exactly Why It's Fast

Is BrandSwitch AI?

No. BrandSwitch is not AI. It's a deterministic, rule-based document engine that reads your file's structure and applies your brand directly, so the same input always produces the same output. There is no language model reading, interpreting or rewriting your document content at any point in the process.

That's the direct answer. The rest of this post is why that's a deliberate design choice, not a missing feature.

It's also a fair question to ask about any tool that touches your documents right now. AI is being bolted onto every category of software, sometimes because it genuinely helps and sometimes because it's the current default assumption for anything new. Document rebranding is a case where it's worth asking the question explicitly, because the honest answer changes what the tool can safely be trusted with.

What BrandSwitch actually does instead of AI

Rather than asking a model to "understand" a document and regenerate it, BrandSwitch reads the actual structure of the file - the same structure Word itself uses - and applies a fixed set of rules to it:

• Find every color reference, whether it's a theme color or direct formatting, and replace it with the new brand color
• Find every font reference across headings and body text and replace it with the new brand font
• Find every instance of the logo - cover page, header, footer, watermark - and replace it with the new one
• Do this consistently across headers, footers, tables and body text, not just the parts that are easy to reach
• Leave every word of your actual content untouched - no organization name, heading text or wording is ever rewritten

Each of those is a fixed rule applied against the document's structure, not a judgment call a model makes about what "looks right." That's a meaningful difference: a rule either finds a match and applies the change, or it doesn't, and the same document always produces the same result.

None of that requires a model to "decide" anything about your content. It requires code that knows where colors, fonts and logos live inside a document, and updates them.

Concretely, that means walking the document's actual XML structure - the same underlying format Word itself reads and writes - rather than treating the file as an image or a block of plain text to be regenerated. A color reference is a color reference whether it's on page 1 or page 400, and the rule that replaces it is the same rule every time. That's what "deterministic" means in practice: not a marketing word, just a description of how the code actually behaves.

Why that means no hallucinated text, no rewritten content, no surprises

A language model summarising or rewriting a document can change wording, drop detail, or introduce an error that wasn't in the original - that's simply how generative models work, and it's a reasonable trade-off for some tasks. It's not one you want in a compliance document, a policy template or a client contract, where every word matters and needs to stay exactly as written.

Because BrandSwitch never generates new text, there's nothing to hallucinate. The same document processed today and processed again next month comes back with identical wording - only the brand elements have moved.

That matters most for the documents where accuracy actually carries risk: compliance frameworks, assessment tools, contracts, policy documents. Anyone who has watched a generative model quietly reword a sentence "for clarity" and change its meaning knows why that's not a risk worth taking on a document that has to say exactly what it originally said, just wearing a different brand.

Why it also means no per-page AI costs and no third-party model

Deterministic, rule-based processing doesn't need to call an external AI API for every page of every document. That has two direct effects: processing doesn't get slower or less predictable as document volume scales up, and your document content isn't sent through a third-party AI service to get the job done. It's processed directly and automatically deleted from the system within an hour.

This is also a cost-structure point as much as a security one. AI-based processing is typically metered per call or per page, so cost scales with usage in a way that has to be priced into the product. Deterministic processing doesn't carry that same per-page cost, which is part of why it can run as a straightforward batch process rather than something priced around AI token consumption.

It's also simply a different engineering discipline. A deterministic system can be tested the way any other software is tested: run it against a real document, check the exact output, and expect the same result every time you run it again. An AI-based process is harder to pin down that precisely, because the same input can legitimately produce a slightly different output from one run to the next. For a task where "identical every time" is the actual requirement, that's not a small difference.

What AI was used for (building the tool) vs what runs it (deterministic code)

AI helped build BrandSwitch - it's a genuinely useful tool for writing and iterating on code faster. But BrandSwitch itself doesn't use AI to process your documents. It's deterministic, rule-based code, and that distinction holds regardless of how the tool was built.

It's a distinction worth drawing clearly, because "built with AI assistance" and "runs on AI" get conflated constantly right now, and they're not the same claim. A tool can be built quickly with AI help and still run as ordinary, predictable, rule-based code with no model involved at inference time. That's the case here. The founder, a senior project manager in Australia, has written more on how that build process worked and why the same "AI to build it, not to run it" line applies more broadly than just this product. The build tool and the product are two separate questions, and conflating them is where a lot of "wait, is this an AI wrapper?" confusion comes from.

FAQ