Every RAXXO product page names the exact AI tool behind a feature instead of a vague "powered by AI" line, a rule that started after one support email in March
I only disclose where the answer changes what a customer expects from the result, not every step, so a page stays readable instead of turning into a changelog
Naming names invites a "just AI" dismissal, and the fix was pairing every disclosure with what I still check by hand, not hiding the tool
The changelog is what keeps a disclosure honest over time, because a claim that goes stale is worse than no claim at all
The Email That Started It
A customer wrote in about a product description on one of the merch listings and asked a plain question. Did a person write this, or did a bot. Not hostile, just curious. I answered honestly: a language model drafted it, I edited it, and I approved the final copy before it went live. The reply back was short. "Cool, thanks for saying so."
That exchange stuck with me longer than it should have, because it exposed a gap between what I believed about my own pages and what was actually on them. I thought of RAXXO as an AI studio in the open, no secret about it, the name is on the tin. But nothing on the actual product pages said which AI did what. A customer had to email me to find out something I would have told them without hesitation if asked. That is not transparency, that is transparency on request, and those are different things.
So I made a rule. Every RAXXO product page states which AI tool or model actually built the feature it is describing, in plain language, not as a badge or a footnote buried at the bottom. If a tool's core function runs on a specific model, the page says so. If a feature was hand-coded with AI assistance rather than generated by a model at runtime, the page says that instead, because those are different claims and customers can tell the difference even when the marketing language tries to blur it.
The first pass at this was rough. I went through five live product pages and rewrote the sections that touched AI functionality, and it was slower than I expected, because writing an honest sentence about what a tool actually does is harder than writing a confident one. "Powered by advanced AI" takes ten seconds to write and says nothing. "This runs a language model to generate the output, and you can regenerate it as many times as you want before you commit to one" takes longer to get right and actually tells someone what they are buying. I kept the second kind and cut every instance of the first kind I found.
It also forced a smaller, more useful habit. Before I write disclosure copy for a new feature, I have to be able to state in one sentence what the AI part actually does and what happens without it. If I cannot write that sentence cleanly, the feature is not clear enough in my own head yet, and that is worth knowing before launch, not after a confused support ticket.
This connects to a decision I made early on about how the studio presents itself at all. Lexxa exists instead of a personal creator brand precisely so the studio's voice stays consistent and separate from any one person's identity, and the same logic applies here. Disclosure is not about putting a face on the AI, it is about putting an honest sentence next to the feature. The studio can be transparent about its tools without turning that transparency into a personality performance.
What Gets Named and What Doesn't
The rule sounds simple until you try to apply it to five products with different levels of AI involvement, and then it gets a lot more specific. Not everything gets a disclosure line. Only the parts where knowing changes what a customer reasonably expects from the result.
If a tool uses a model to generate the primary output a customer sees and keeps, that gets named. Someone paying for generated output has a right to know it is generated, and roughly what generated it, because that shapes what a reasonable person expects in terms of consistency and occasional misses. If AI assisted somewhere upstream in a way that does not change what the customer receives or how it behaves, I leave it out of the page copy. A build tool that helped me write the underlying code is not something a buyer needs to weigh when deciding whether the product does what they need, any more than they need to know which text editor I used.
I use one test before adding a disclosure line: would a reasonable buyer's expectation of the result change if they knew this. If yes, it goes on the page, plainly, near the feature it describes. If the honest answer is "no, this is implementation detail," it stays out, because burying a page in every tool that touched a feature does not inform anyone, it just turns a product page into a changelog nobody asked to read. Four of my products are AI-adjacent tools themselves, and if I disclosed every internal step, the page would be longer than the documentation. That serves nobody. Specificity beats completeness here every time.
This also means the disclosure has to stay tied to the actual feature, not float at the top of the page as a general statement. "This product uses AI" at the header and nothing else is close to the vague badge I was trying to get away from. Putting the sentence right next to the feature it describes, where the customer is already reading about what that feature does, is what makes it useful instead of decorative.
The "Just AI" Problem
Naming the tool has a real cost, and I want to be honest about that instead of pretending disclosure is free. Some people read "built with a language model" and immediately downgrade their expectations, assume the work is thin, assume nobody was actually paying attention. That reaction is understandable given how much low-effort AI output is floating around right now, and pretending it will not happen is naive.
The fix was not to soften the disclosure or bury it further. It was to pair every disclosure with a sentence about what I still check by hand. If a feature generates something, the page also says what I review before it ships or before it reaches the customer, when that review exists. That second sentence is doing real work. It tells the customer the AI generated a first pass and a person, not a pipeline, decided it was good enough to sell. That is a true statement I can make about most of what RAXXO ships, and saying it plainly turned out to matter more than the disclosure line itself.
I noticed the pattern in the handful of replies I got after adding this. Nobody complained that a tool used AI. A few people specifically thanked me for saying which one and for saying what I still checked. The complaint I was bracing for never showed up, and the trust I got in its place was worth more than the vague confidence a generic AI badge might have bought me. People are not allergic to AI. They are allergic to being talked around instead of talked to.
There is a version of this that would have been worse: disclosing the tool but hiding my own role, letting the copy imply the model did everything unsupervised. That reads as either overclaiming what the AI can do or underclaiming my own involvement, and either way it is not accurate. The honest version, tool named, my review named, has held up better than either extreme would have.
I also learned to expect a small, vocal minority who will never be satisfied by any disclosure, who read "AI" anywhere on a page and move on regardless of what follows it. I stopped writing for that group. The sentence is not there to win over someone who has already decided AI-built means low quality no matter what. It is there for the much larger group of people who just want an honest answer to a fair question, the same question that started this whole rule in the first place.
Keeping Disclosure Current
A disclosure is a claim, and claims go stale the moment the thing they describe changes. I already run a changelog habit that keeps five RAXXO tools honest about what shipped when, and product-page disclosure now rides on the same discipline. Any time a feature's underlying model or approach changes, the product page disclosure updates in the same pass as the changelog entry, not as an afterthought weeks later.
This matters more than it sounds like it should, because an out-of-date disclosure is arguably worse than no disclosure. If a page still says a feature runs on a model I swapped out months ago, that is not a small documentation gap, it is an inaccurate claim sitting on a page people are paying against. I would rather say less and have it be current than say more and let it drift out of true.
The same design system that keeps five RAXXO tools feeling like one studio also keeps the disclosure language consistent across products, so a customer reading two different product pages sees the same style of honesty rather than five different tones depending on which page they landed on. That consistency is part of why the practice works. A one-off disclosure on a single page would read like a legal footnote. The same plain sentence style repeated across every product reads like a studio policy, because it is one.
Bottom Line
None of this started as a strategy. It started as an honest answer to one customer's email, and the gap between that answer and what my pages actually said bothered me enough to fix it everywhere. The rule that came out of it is narrow on purpose: name the AI where the answer changes what someone expects, skip it where it doesn't, and always say what I still check by hand. That third part turned out to matter the most. People do not need every product to be AI-free to trust it. They need to know a person is still in the loop, and they need that to be true, not just written. RAXXO is a studio of one working with AI in the open. The least I can do is put that on the page instead of waiting for someone to ask.
Top comments (0)