Your AI Visibility Data Is Part of Your Company, Not Your Vendor

My rule for software is simple: if I cannot inspect the work, move it, or rebuild it without the person who made it, I do not own it.
I am dependent on it.
Founders are about to repeat that mistake with AI visibility data. They will spend months building a baseline inside a polished dashboard, change vendors, and discover that the history they thought belonged to the company was only a view inside someone else's system.
The dashboard is useful. The dependency is not.
AI visibility data ownership starts with the raw evidence
AI visibility data ownership means your company can preserve and reconstruct the measurement after the software changes.
That requires more than a CSV with a date and a score.
A defensible export should preserve at least these fields:
- The exact prompt, including every variation.
- The engine, model, product surface, and mode used for the answer.
- The date, time, locale, and relevant session settings.
- Whether retrieval or web search occurred, when that state is available.
- The full answer text, not a cropped screenshot.
- Every cited URL and domain, in the order shown.
- Every brand mention, its context, and its position in the answer.
- The denominator, deduplication rule, exclusions, and formula behind every score.
This is not administrative detail. It is the measurement.
The answer surfaces themselves make the distinction visible. OpenAI documents that ChatGPT search responses can include citations and source links. Claude documents that web-search responses include citations. Google's Gemini grounding documentation exposes grounding metadata and source links. These products do not expose identical objects in identical ways. Your export has to preserve the conditions that produced the answer instead of pretending every answer row is interchangeable.
The current Machine Relations source-layer baseline separates five objects before it permits a composite view: the query universe, answer presence, brand mention rate, share of citation, and retrieval state. Collapse those into one exported score and the history becomes impossible to interrogate.
You can see that a number changed. You cannot prove why.
A score without lineage is rented certainty
Founders love a clean number because it makes a messy market feel controllable.
I understand the attraction. A single score is easier to put in a board deck than hundreds of answers, citations, and query settings. It is easier to compare 61 to 54 than to explain that one platform counted all responses, another counted only branded responses, and a third weighted the score by estimated impressions.
Easy is not the same as true.
Machine Relations Research reviewed the public measurement contracts of 16 AI visibility platforms. The review found that headline scores can use different denominators, sampling rules, retrieval disclosures, uncertainty treatments, and deduplication methods. Different numbers can be valid inside their own contracts and still be useless as a continuous trend line.
That is the trap.
You leave one platform at 42 and enter another at 31. The team reports an 11-point decline. Nothing may have declined. The instruments may be measuring different objects.
A score is an interface.
Lineage is the asset.
Use the handover test before you sign or switch
Do not wait until the contract ends to learn what can leave the platform.
Run the handover test before you buy.
| Ask for | A useful handover contains | The failure it prevents |
|---|---|---|
| Query export | Exact prompts, variants, groups, and active dates | Rebuilding a different baseline by accident |
| Answer export | Full text, engine, model, timestamp, locale, and mode | Losing the evidence behind the score |
| Citation export | URL, domain, answer association, position, and source type | Confusing mentions with cited support |
| Measurement contract | Denominator, formula, deduplication, exclusions, and confidence rules | Comparing unlike scores as one trend |
| Change log | Query edits, engine changes, model changes, and scoring revisions | Mistaking instrument drift for market movement |
| Portable format | Documented CSV, JSON, or API output with stable field definitions | Turning a vendor change into a forensic project |
A vendor does not need to use your preferred schema. It does need to tell you what the fields mean.
Undisclosed does not automatically mean wrong. It means you cannot reconstruct the claim independently. That boundary matters because serious operators do not accuse a system of failure when the real problem is an unknown contract.
They label the unknown.
Then they decide whether the dependency is acceptable.
Run a parallel window before cutting over
Never splice two dashboards together on the day you switch.
Run both systems against the same declared query set for a parallel window. Freeze the prompts. Match the engines as closely as the products allow. Record differences in retrieval mode, model identity, locale, frequency, and scoring.
The research case for repetition is direct. The 2026 paper "Don't Measure Once: Measuring Visibility in AI Search" argues that answer variance across runs, prompts, and time makes one-off observations unreliable and that visibility should be treated as a distribution rather than a single point.
Here is a hypothetical example:
| Field | Existing platform | New platform |
|---|---|---|
| Declared prompts | 100 | 100 |
| Runs per prompt and engine | 1 | 5 |
| Brand mention denominator | All answers | Answers naming any tracked brand |
| Citation counting | Every cited URL | One count per cited domain per answer |
| Headline score | 42 | 31 |
The two headline scores are not a before-and-after result. They are different calculations.
The parallel window has one job: build a translation map. Which fields are equivalent? Which are close enough for directional comparison? Which must begin a new series?
If the answer is "we cannot tell," start the new series honestly. A broken trend line with a clear boundary is better than a smooth lie.
Your baseline should survive the dashboard
A company-owned baseline is not a screenshot folder.
It is a dated evidence set with enough context to answer four questions:
- What exactly did we ask?
- What exactly did each engine return?
- Which sources did the answer use?
- How did the system convert those observations into the reported number?
The public Machine Relations Index offers a useful scale reference. Its September 2026 release contains 119,397 source events across 21,372 domains. That scale is not impressive because the number is large. It is useful because every aggregate depends on a source layer beneath it.
The same rule applies to a 20-query startup baseline.
Preserve the rows.
Preserve the settings.
Preserve the definitions.
Then preserve the report.
That sequence matters. The report is the conclusion. The rows are the evidence that lets the next operator challenge it.
This is a founder problem hiding inside software procurement
The software question is which platform fits the team.
The founder question is whether the company is building knowledge or renting confidence.
I do not need to hold every technical skill in the company. Companies require expertise. I do need an independent way to inspect the work rather than depend on a conclusion I cannot evaluate.
AI visibility can create the same psychological dependency in a cleaner package. The dashboard feels objective, so nobody asks what would survive if the interface disappeared tomorrow.
Ask now.
The NIST AI Risk Management Framework Playbook organizes voluntary actions around Govern, Map, Measure, and Manage. The useful founder translation is straightforward: measurement belongs inside an operating system with ownership and oversight. It is not a magic number floating above the company.
Export one month. Reconstruct one metric. Trace one score back to the exact answers and citations that produced it. Give the export to someone who did not configure the tool and see whether they can explain the result.
If they cannot, you have a presentation layer, not institutional knowledge.
Machine Relations makes measurement answer to evidence
AI visibility records where a brand appears, whether it is cited, and how it is described across a declared set of observations. It does not prove revenue, preference, or causation by itself.
That is why measurement sits inside Machine Relations, not above it. Earned authority, entity clarity, citation architecture, distribution, and measurement have to remain connected. A dashboard can observe the system. It cannot become the system.
The founder move is simple:
Own the evidence layer.
Let vendors compete on how well they help you read it.
Before you sign the next platform contract, run the AuthorityTech AI visibility audit and preserve the baseline outside the interface. Then make one decision you can trace back to the raw answer, the source, and the declared denominator.
You can rent software.
Do not rent your company's memory.
FAQ
What is AI visibility data ownership?
AI visibility data ownership is the ability to export, understand, and reconstruct a company's measurement without depending on the original dashboard. The minimum evidence includes prompts, engine and model context, timestamps, raw answers, citations, brand mentions, retrieval state when available, and score definitions.
What should an AI visibility platform export?
An AI visibility platform should provide enough data to reproduce its reported metrics: exact prompts, answer text, engine and model identifiers, dates, locales, cited URLs, brand mentions, denominators, formulas, exclusions, and change history. The format matters less than documented field definitions.
Can AI visibility scores be compared across tools?
Only when the tools use compatible query sets, engines, sampling rules, denominators, retrieval treatment, and deduplication logic. If those contracts differ, the scores should be treated as separate series unless a parallel run establishes a defensible translation.
How long should an AI visibility vendor transition run in parallel?
There is no universal duration. The parallel window must capture enough repeated observations to expose differences in prompts, engines, retrieval modes, scoring, and answer variance. The decision rule should be set before the run instead of chosen after the scores appear.
Who coined Machine Relations?
Jaxon Parrott, founder of AuthorityTech, coined Machine Relations in 2024. The discipline connects earned authority, entity clarity, citation architecture, distribution, and measurement so AI visibility remains grounded in an inspectable source system.
About Jaxon Parrott
Jaxon Parrott is founder of AuthorityTech and creator of Machine Relations — the discipline of using high-authority earned media to influence AI training data and LLM citations. He built the 5-layer Machine Relations stack to move brands from un-indexed to definitive AI answers.
Read his Entrepreneur profile, and follow on LinkedIn and X.
Jaxon Parrott