Generated Content Should Have Ancestry: What We Learned Building ReviewProof Studio

Early in building ReviewProof Studio, I asked a general-purpose AI tool to write a testimonial post for a business. It produced something polished, warm and completely invented. A customer who did not exist praised a result that never happened. It was a beautiful output. It was also exactly the thing our product must never do.

That moment shaped the whole architecture. ReviewProof Studio turns real customer reviews from Google Business Profile and Trustpilot into branded marketing content. The entire value of the product depends on one promise: the content is real. If a single generated asset invents a quote, attributes a sentence to the wrong person, or loses track of which review it came from, the product has failed at its only job.

The principle we arrived at is that generated content should have ancestry. Every asset the product produces must have a traceable line back to the proof that made it possible. This article is about what that means in practice, what it cost us, and what I think it teaches about any AI product that works with evidence.

A beautiful output that invents evidence is a failed output.

What ancestry actually means

Ancestry is a simple idea with a lot of consequences. It means that for any asset in the product, you can walk backwards and answer a chain of questions. Which design version is this? Which generated text is it based on? Which generation job produced that text, with which brand context and which owner context? Which proof record was the input? Which original review, from which source, said by which customer, on which date?

In ReviewProof Studio that chain is explicit in the data model. The original review is a canonical proof record. Generation produces a derivative linked to it. Refinement produces a version linked to the generation. Design produces an asset linked to the version. Nothing is a loose file. Nothing floats free of its source.

The reason this matters is not academic. When a business owner looks at a social post and asks "where did this come from?", the product can answer precisely. When a customer asks for their review to be removed, the product can find every asset that depends on it. When an agency manages twenty brands, no asset can quietly end up under the wrong one. Ancestry is what makes the product trustworthy, and trust is the whole product.

Why generic AI writing fails for proof

General AI writing tools are optimised to produce good text. That is a fine goal for a blog post. It is the wrong goal for evidence.

When the input is a short review like "Great service, very fast", a model asked to write a compelling testimonial will do what it was built to do. It will add detail. It will invent a context, a problem the customer had, a specific outcome. The result reads well and is fiction. Nobody told the model to lie. It simply filled the gap, because filling gaps is what fluent generation does.

Our rule became: give AI creative freedom over expression without giving it creative freedom over facts. The model can rephrase, adapt tone to the brand, fit the format of a channel and propose variants. It cannot add a fact the proof does not contain. Direct quotes are preserved as quotes. Anything the model wants to say beyond the review must come from somewhere real, which brings us to context.

Three contexts, kept separate

Short reviews often lack story. The business owner usually knows the story. They remember the customer, the problem, what they did. That context is valuable and legitimate. The question is how to add it without the model blending it into the customer's words.

Our answer is Owner Voice. The owner can add their own context, by typing or by speaking, and it is stored as owner context, separate from the customer's review. When generation runs, the model receives three distinct inputs: the customer's words, the owner's context and the brand context from the Brand Kit. It is told what each one is and what it may do with each.

The customer's words are evidence. They can be quoted and lightly adapted but not expanded. The owner's context is background. It can inform the framing but is attributed to the business, not the customer. The brand context is style. It shapes tone, vocabulary and format, and never adds facts.

Keeping these separate in the data model, and separate in what the model is told, is what lets the product add richness without inventing it. Know what was said, and know who said it. Those two things sound obvious until you watch a model merge them in one fluent paragraph.

Know what was said and know who said it. Those two things sound obvious until you watch a model merge them into one fluent paragraph.

Structure before intelligence

One of the clearest lessons from this product is that the proof had to be structured as product data before it ever became AI context.

Reviews arrive from different sources in different shapes. A Google review, a Trustpilot review, a screenshot of a text message and a manually typed testimonial are all proof, but they look nothing alike. The temptation is to hand whatever arrived straight to the model and let it cope. We did not do that. Every source goes through normalisation into one canonical proof record with consistent fields: the text, the author, the rating where one exists, the source, the date, the permission state and the link back to the original.

That decision made everything downstream simpler and safer. Generation works from one shape. Filtering and selection work from one shape. Ancestry works because there is a single record to point at. Deduplication is possible because records can be compared. Normalise external complexity at the product boundary, and the rest of the product does not have to carry it.

It also meant treating the Google and Trustpilot imports as core infrastructure rather than as integrations bolted on at the end. When external proof is the starting point of your workflow, import reliability is part of the core experience. An import that silently misses reviews or duplicates them is not a minor bug. It corrupts the evidence the entire product is built on.

Human confirmation after extraction

A lot of real proof lives in screenshots. A customer's message, a review on a platform we do not integrate with, a comment on a post. We wanted the product to read those, because typing them out by hand is exactly the manual work the product should remove.

AI reads screenshots well. It also, sometimes, reads them slightly wrong. A name misspelled, a rating misread, a date off by a year. In a product built on proof, slightly wrong is wrong.

So the flow is: the screenshot goes to the model, the model proposes a candidate record, and the user confirms it before it becomes proof. The model does the reading. The person does the verifying. Accurate capture and factual verification are two separate responsibilities, and giving both to the model would have put uncertainty straight into the evidence layer.

We also let uncertainty be represented. If extraction was not confident about a field, the record can say so. A product that works with evidence should be comfortable saying "we are not sure about this part" rather than presenting a guess with full confidence.

Generated is not approved. Approved is not permitted.

Ancestry is about where content came from. The other half of trust is about where it is allowed to go.

We separated three states that are usually collapsed into one. A generated asset exists but nobody has looked at it. An approved asset has been reviewed by someone with the right to approve creative work for that brand. A permitted asset is one whose underlying proof has a recorded consent or permission state that allows publication in that context.

Those are three different questions answered by three different kinds of people. Approval is a creative and brand decision. Permission is about the customer whose words are being used. Collapsing them means a nicely designed post could be published without anyone checking whether the customer agreed to be quoted. Keeping them apart means the workflow itself enforces the responsibility.

We were also careful not to overclaim. Permission state in the product proves that governance happened. It does not claim to be universal legal clearance, because the product cannot know every rule in every jurisdiction. Being honest about what the software can and cannot guarantee is part of trust architecture too.

What ancestry cost us

I do not want to pretend this was free. Building lineage into the core of the product had real costs, and anyone considering the same approach should know them.

• A more complex data model. Proof, generation, version, design and permission are distinct entities with relationships, instead of one content table.
• Slower generation flows. Confirmation steps and approval states add friction compared to a one-click generate-and-post button.
• Harder deletion. Removing a review means finding every derivative. Deletion has to be lineage-aware, which is more engineering than a single delete.
• More careful bulk operations. Bulk generation across many reviews needs item-level state and retry so one failure does not hide inside a batch and break the chain.
• A smaller feature surface at launch. Depth around proof came before breadth across marketing channels, which meant saying no to things that would have demoed well.

Lessons for any AI product that touches evidence

ReviewProof Studio is about customer reviews, but the lessons are not specific to reviews. They apply to any product where AI generates something from information that is supposed to be true: contracts, medical notes, financial summaries, compliance reports, research.

Store truth with the application and use AI to transform the representation of that truth. Structure the evidence as data before it becomes model context. Keep different kinds of context separate so the model cannot blend them. Give the model freedom over expression and no freedom over facts. Put a human confirmation step between extraction and the evidence layer. Separate generation from approval, and approval from permission. Make every output traceable to its source, and make deletion follow the same lineage.

None of this is about limiting what AI can do. It is about building the product so that AI can be used confidently, at scale, without the trust of the people who depend on it becoming collateral damage. The proof has to stay stronger than the automation around it.

AI works from the proof. The proof does not become whatever the AI says it is.