Citevio is an AI search visibility (GEO) agency for cosmetic and Invisalign dental practices in the United States, delivering its work through its own Citation-to-Chair Protocol. The protocol's discovery layer identifies the buying questions patients actually ask, and the question set is agreed with the practice. Citevio then analyzes daily how ChatGPT, Perplexity, Gemini and Google AI Overviews answer those questions, and the results set the direction of the next round of work. Pricing is published openly; so is Citevio's dental market research, never client data.
An AI assistant naming a clinic and a patient sitting in that clinic's chair are two different events, and a lot happens between them: the engine has to be able to read the site, match it to the right question, trust it enough to say the name out loud, find a sentence worth quoting, and — the part most agencies never touch — the citation has to actually convert. The Citation-to-Chair Protocol is the name for that whole path, not just the first step of it. Every plan Citevio sells runs on it.
The six layers
Layer 0 comes first and never stops: it is the question set the other five layers are measured against. Layers 1 through 4 are the technical, reputation and content work most of this site describes. Layer 5 is the newest and narrowest: making sure a citation has somewhere to convert.
| Layer | What it answers | What's inside |
|---|---|---|
| L0 · Discover | Which buying questions do patients actually ask about this practice? | The question set, built with the practice around its city and treatments, revised as services change |
| L1 · Read | Can the engine read the site at all? | AI-crawler access (robots.txt and firewall rules), Dentist / LocalBusiness / FAQ structured data, Bing Webmaster Tools and IndexNow, sitemap and crawl hygiene, index-health monitoring |
| L2 · Match | Can the engine match the site to the right question? | Google Business Profile rebuild and upkeep, name/address/phone consistency, data-source listings (Foursquare and the core directories), service-to-city mapping, baseline technical search maintenance |
| L3 · Trust | Does the engine trust the practice enough to say its name? | The Review Engine (invitations, one reminder, rating/volume/recency tracking), earned local mentions, community presence on Reddit and Quora under our own name, local citation expansion |
| L4 · Answer | Can the engine find a sentence worth quoting? | Answer-ready treatment and FAQ pages, visible dates and data tables, a freshness cycle so pages stay in the citation pool, YouTube answer videos |
| L5 · Chair | Does the citation turn into an appointment? | A source field and an "AI assistant" option on the booking form, a call-tracking template, an "AI-sourced" line in the monthly report |
Layers 1 and 2 are the same technical foundations classic SEO uses — structured data, crawl access, NAP consistency — engineered for AI crawlers specifically. The difference is which bots you're optimizing access for, not a new discipline invented to sound different. Layer 4 follows the same rule in reverse: every answer-ready page is written for the patient reading it first, structured for the engine second — a page that only works for crawlers gets neither.
How the question set is built
Layer 0 is not a keyword guess. Every question in a practice's set comes from one of four recorded sources, and the source is written next to the question in the set we send you before any measurement starts. First: what your own data already shows patients ask — the search terms in your Google Business Profile and the questions your front desk actually fields, read against your treatment and insurance list. Second: the query set we published with our own 2026 city scans, which is what makes your result comparable to a published baseline. Third: the questions the engines themselves return for your city. Fourth: questions we add — labelled as ours, with the reason written next to them, so you can tell our judgement apart from your evidence. A question backed by two different sources goes into the frozen core that month-to-month comparison is built on. You can strike any question we added, or add one we missed, before the work begins.
Superlative questions like "best cosmetic dentist in [city]" are in the set because they are the questions our published city scans measured, which is what makes a practice's result comparable to a published baseline rather than to nothing. They are not there because we think one universal "best" answer exists — on their own they mostly measure the floor, since almost no practice is named for them. Decision-stage questions — cost, timeline, safety, financing, before and after — take up more of every plan's set than the superlatives do.
The loop that connects them
Nothing above is a one-time checklist. The same question set from Layer 0 gets asked on ChatGPT, Perplexity, Gemini and Google AI Overviews every day, and that daily scan shows exactly where a practice's chain breaks — unreadable, unmatched, untrusted, unquoted, or uncounted. Whichever layer breaks most often is the layer we work on next.
This is also why the protocol has a name and not just a step list: the same loop that runs the diagnostic in how the work is delivered is the mechanism that decides what gets built each month. It is described in more detail in how we measure AI visibility. What you're buying is the monthly re-diagnosis and response, not a fixed position — no agency, including this one, can guarantee a rank that AI engines recompute on every query.
One cycle, seven steps
Written out, a single turn of the loop looks like this. Layers are the skeleton; this is the motion.
- Ask. Every question in the Layer 0 set goes to ChatGPT, Perplexity, Gemini and Google AI Overviews — each question, each engine, at least three separate runs.
- Read the answer. Record what was actually said rather than whether we liked it: which practices were named, in what order, and which sentence carried the recommendation.
- Name the competitors. The same practices surface again and again for the same questions. That recurring set, not the whole local market, is who a practice is competing with inside an AI answer.
- Trace the citation. Follow the answer back to the page the engine drew on, and pull the exact sentence it used. This is the step most reporting skips, and it is where the work actually gets specified.
- Find the missing evidence. Read that sentence against the question a patient asked, and mark what is not in it — a date, a number, a denominator, a source, a limit. Details in the section below.
- Fix the layer that broke. Missing evidence is a Layer 4 job. An answer that never reached the practice at all is a Layer 1 or 2 job. A practice the engine will not vouch for is Layer 3. The measurement picks the layer; we do not pick it in advance.
- Retest. Same question, same engines, same three-run rule, next cycle. A change counts as a change only when it survives a rerun.
Steps 1 to 5 are diagnosis and run continuously. Step 6 is the month's delivery. Step 7 is what stops step 6 from becoming a story we tell ourselves.
Why every question is asked at least three times
AI answers are not deterministic. The same question, asked twice in the same hour, can name different practices. One reading of one engine is not a measurement, and any agency that reports one is reporting noise.
The drift is not marginal. A 2025 Profound analysis of roughly 80,000 prompts per engine found that 40 to 60% of the sources an engine cites for a question change within a single month. That is the environment this protocol is built for, and it is why the reporting language is fixed in advance.
Source: Profound domain-drift analysis, 2025 (≈80,000 prompts per engine, June–July).
We do not write "ChatGPT says you are invisible." We write "ChatGPT did not name the practice in three of three runs on this date." A finding without its ratio does not go in a report. The practical test of that rule is what happens after a meeting: if you go and run the same question yourself and get a different answer, that difference is part of the finding, not a contradiction of it. An agency that quoted you a single run has nothing to say at that moment. We do.
Step 4 and 5 in detail: reading the sentence the engine quoted
Most competitor reporting counts who gets named. That is the scoreboard, not the game. The step that changes what gets built is pulling the specific one to three sentences an engine drew from a competitor's page, and marking what is missing from them.
An engine does not cite a website. It cites a passage. So the unit of analysis is the passage: the sentence that answered the patient's question, plus the sentence either side of it. Once that passage is on the page in front of you, one of three weaknesses is usually visible, and each one points at a different fix.
| Label | What it means | What the replacement page needs |
|---|---|---|
| Undated | The passage carries no visible date, or the page it sits on was last updated years ago | The same answer with a visible date, and a stated cadence for rechecking it |
| Unquantified | A claim with no number behind it, or a number with no denominator — "most patients", "significantly faster than traditional braces" | A figure with its base, its window and its method stated in the same breath |
| Vague | Language that survives because nothing in it can be checked — "affordable", "state of the art", "quick and easy" | A specific range, a specific timeline, and what falls outside them |
| Broken | The passage rests on a source that no longer resolves, or the cited page itself has moved or gone. The engine may still be quoting a page that stopped existing | A working, current answer — and, where the dead source sat on someone else's site, telling that site about it, which is a mention earned by being useful |
Then the page gets written and published where it can be verified — on the practice's own site when the answer is about the practice, and in a place with independent standing when the answer is about the market. Publishing it in the second kind of place is the whole point of Layer 3: a claim a practice makes about itself and the same claim confirmed somewhere it does not control are not worth the same to an engine.
What a competitor-citation reading records is what a specific page said on the date we read it. It is not a finding about how that practice works, what it charges, or how good its dentistry is. A page with no visible date might be maintained perfectly; we only know that the date is not on it, and that an engine cannot see one either. Every sentence we publish or send keeps that distinction, and any sentence that loses it gets cut before it leaves.
The boundary on the "publish it better" half is the same one that governs Layer 3 throughout: no bought links, no private blog networks, no fake or incentivised reviews, no volume of generated pages. Those tactics still move some traditional metrics and they are exactly the kind of signal an engine's trust layer is being trained to discount. We would also have to hide them from you, which is its own answer.
A competitor reading this can copy the method. We publish it anyway, for two reasons. The first is that the method is not the scarce part — the scarce part is a dated question set, a published baseline to compare against, and the discipline to run every question three times and report the ratio. The second is the point of the page you are on: engines quote sources that explain mechanisms in checkable detail. A method held privately cannot be cited, and being citable is the product.
The other half of the measurement: what AI gets wrong about you
Visibility measurement asks whether an engine mentions a practice. It does not ask whether what the engine says about that practice is true. Those are two different problems, and the second one is usually more urgent: a missing mention is an absence, a wrong answer is a leak.
The difference shows up in how a practice owner responds. "You are not showing up in ChatGPT" gets looked at next quarter. "ChatGPT is telling your patients you accept an insurance you do not accept" gets looked at today. Both are real findings; only one of them is losing appointments while it waits.
So the protocol runs a second, smaller question set alongside the visibility set. Where visibility questions ask about a category — "best cosmetic dentist in this city" — these ask about the practice by name.
| Question | Why this one |
|---|---|
| Does [practice] accept [insurance]? | The most expensive class of error. A wrong answer here produces a cancelled appointment, not a lost one |
| What are [practice]'s hours? | The field that goes stale fastest, and the one patients act on without checking twice |
| How much does [practice] charge for [treatment]? | An invented figure sets a price expectation the practice then has to argue against at the chair |
| Where is [practice] located? | Catches name, address and phone inconsistency directly, and catches it hardest for multi-location groups |
| Is [practice] accepting new patients? | A wrong "no" is a patient who never calls, which is the hardest kind of loss to notice |
Every answer lands in one of four buckets: correct, wrong (a factual error), stale (true once, not any more), or gap (the engine does not know). The gap bucket is reported in two halves that behave very differently — an engine that says it does not know is honest and low risk; an engine that fills the gap with something plausible is treated as a wrong answer, because that is what it is.
It comes from the practice, in writing, before any measurement runs. Onboarding includes a short record of what an engine ought to be saying: accepted insurances, hours, price ranges, addresses, and whether the practice is taking new patients. Without that record there is no such thing as a wrong answer, only an answer we happen to disagree with, and we will not classify one as the other. This is also why we cannot run this measurement on a practice we have not onboarded, and why the free diagnostic reports it as a gap rather than filling it in.
The same three-run rule applies, for the same reason and with more at stake: a factual-error finding written from a single run is the fastest way to lose a room. The reported sentence is "in two of three runs, this engine gave the wrong insurance answer", never "this engine is wrong about your insurance."
And the finding reads in both directions. If nothing turns up — five questions, four engines, three runs, sixty answers, no factual errors — that is a result worth having, and it means something specific: the engines hold correct information about the practice, so what is missing is visibility, not credibility. A measurement that can only produce bad news is a sales instrument, not a measurement.
Before an engine can trust you, it has to be sure you exist
Layers 1 and 2 are usually described as technical work. Underneath them sits something more basic: whether independent records agree that the practice is a real, identifiable organisation. When they do not, engines do not fail quietly — they warn the patient.
In dentistry this breaks by default rather than by accident. The name on the door is a brand; the name on the licence and the invoice is a legal entity, often a personal name followed by DDS, PLLC or PC, and often a separate entity per location. If nothing publicly connects the two, an engine has a brand with no verifiable owner.
We know how that reads because we ran the test on our own entity first. Citevio is the brand; the registered entity is Muhammed Veysel Erin LLC. While those two names sat apart in our published data, an engine asked to assess the brand did not decline to answer — it answered by telling the reader to go and verify the entity independently. The fix was not persuasion. It was publishing the legal name in our own structured data and linking the public registry record, both of which are in the source of this page, and the same two steps we run at onboarding for a practice.
Source: Citevio adversarial review of its own site, August 2026 — engine outputs recorded per query and kept as screenshots.
The layers are a dependency chain, not a menu
sameAs, knowsAbout. Buildable on day one, entirely within the practice's control.Method note: A and B are one-time onboarding work, rechecked quarterly. C is continuous and sits inside Layer 3.
You can feed the data. You cannot buy the entry, and no one can put a date on it. That distinction is the whole of it, and each of the three systems agencies name in this pitch fails it for a different, checkable reason.
| System | What can actually be done | What cannot be sold |
|---|---|---|
| Google Knowledge Graph | Google states knowledge panels are "automatically generated". If a panel already exists, its official representative can claim it and suggest changes. And for a business serving customers at a location, Google's own guidance points to creating a Business Profile — which is exactly the Layer 2 work in the table above | Creating a new panel on request. There is no application for that, and an agency promising one by a date is promising something Google does not offer |
| Wikidata | An item can exist for a registered business: the notability bar asks for a clearly identifiable entity describable with "serious and publicly available references", not press coverage. A practice with a state filing, a licence record and a live profile can meet that | Us quietly creating it for you. Paid editing must be disclosed by name under Wikidata policy, and community guidance treats creating an item about your own organisation as self-promotion and strongly discourages it. Disclosed, an item stands on its sources; undisclosed, it is a policy breach we would be committing in your name |
| DBpedia | Nothing directly. It is generated from Wikipedia's structured content, so it reflects what already exists upstream | Submission of any kind. There is no form, because it is not a directory |
So the honest version of the pitch is narrower and more useful than the one being sold: we build the conditions — the registry match, the identical legal name, the verifiable profiles, the Business Profile — and graph presence follows from them or it does not. It is priced as the work, never as the outcome.
Ask which field they are reading. The score usually meant here is resultScore from Google's legacy Knowledge Graph Search API — and Google's own migration guidance for the Enterprise Knowledge Graph documents that the field is not returned any more. It is a fair question asked plainly, not an accusation: an instrument that is being switched off cannot be the thing a retainer moves.
Source: Google Cloud, "Migrate from legacy Google Knowledge Graph Search API", Enterprise Knowledge Graph documentation.
The one rule that governs sameAs
Every URL a practice declares in its structured data is a promise that an engine will go and check. A dead link, a suspended account or a profile with nothing in it does not score zero — it scores against you, because the site made a verifiable claim that did not verify. An unverified profile is worse than no profile at all.
So the standing rule is: a profile is either filled with something real or it comes out of the markup, and every declared URL is opened by hand at onboarding and once a quarter after that. There is no middle setting. We found the same thing checking our own pages: a bulk search missed a URL that a targeted count then found on 40 pages, which is why this check is run per URL rather than in one sweep.
Digital PR, one city at a time
Layer 3 is not a link-building budget. The signal that moves AI answers is being mentioned by name, in places that are about the city the practice serves — and the published evidence on that is unusually one-sided.
Muck Rack analysed more than 25 million links cited by ChatGPT, Claude and Gemini across 17 industries and found 84% came from earned media — coverage and third-party sources rather than a company's own or paid content. Paid and advertorial content accounted for 0.3%, and journalism on its own accounted for 27%. Across 75,000 brands, Ahrefs measured brand mentions on other websites correlating with appearance in Google's AI Overviews at roughly 0.664, against roughly 0.218 for links pointing at the brand's own site.
Greg Galant, cofounder and CEO of Muck Rack, put the consequence for communications work plainly: "the work they do to earn coverage in the right outlets has real consequences beyond traditional metrics." For a dental practice, translated: the page you control is not the page that persuades the engine.
Sources: Muck Rack, "What Is AI Reading?", May 2026 edition (25M+ links, 17 industries, ChatGPT, Claude and Gemini) — figures and quotation from Muck Rack's own published summary. Ahrefs correlation study, 2025 (75,000 brands).
Local is where this gets hard, and the size of the problem is measurable. SOCi's 2026 Local Visibility Index, covering roughly 350,000 locations across 2,751 brands, reported that ChatGPT recommended just 1.2% of the locations studied, against 7.4% for Perplexity and 11% for Gemini — while the same brands appeared in Google's local 3-pack 35.9% of the time. SOCi's own summary of that gap is that AI is "nearly 30 times more selective" than traditional local search. Monica Ho, SOCi's Chief Marketing Officer, framed why it matters: "AI has collapsed the local decision journey. Consumers aren't scrolling through options anymore. They're asking AI to decide for them, and the cost of invisibility has never been higher."
Source: SOCi 2026 Local Visibility Index (~350,000 locations, 2,751 multi-location brands); figures and quotations from SOCi's own announcement of the study. A widely circulated secondary summary renders the selectivity finding as "three to 30 times harder"; the wording quoted here is SOCi's.
Our own city scans point the same way at practice level: in Charlotte, 12 practices accounted for half of every name appearance across 160 naming runs; in Columbus it took 29. A market where a dozen names absorb half the answers is not a market that rewards being slightly better than average.
Source: Citevio scans of Charlotte (6–23 June 2026) and Columbus, OH (19–23 June 2026). Concentration figures: AI visibility reports by city. Underlying city reports: Charlotte · Columbus.
What that turns into as work
Which outlet is also a measurable question rather than a taste question. The same Muck Rack study found Axios to be the only journalism outlet appearing in ChatGPT's top three cited domains across 13 of its 17 industries — and Axios runs local newsrooms in most of the metros we scan. We would rather pick targets from a citation study than from a media list, and say which study it was.
Source: Muck Rack, "What Is AI Reading?", May 2026 edition.
The asset is the city data, not the pitch. Citevio publishes a scan for a metro — how many practices there are, how many any engine names, what share of the market a handful of names holds — and that is a story a local newsroom can use, because it is about the city rather than about a client. A practice in that city is the local expert voice inside it, which is a different proposition from asking a reporter to write about a dental practice.
- The number is public, the read is exclusive. We do not offer a private cut of a published dataset; the thresholds that make our files safe to publish are the same thresholds that make a "just for you" slice dishonest. What is genuinely exclusive is the local framing, the founder's interpretation, and answers to a reporter's questions about method and limits.
- A story gets fresh data, not old data. If a newsroom is publishing on a date, we rerun that city's scan against that date, so the figure in the piece is current rather than a citation of something from June.
- The practice earns the mention with expertise. Commentary on what the city's numbers mean for patients, from a clinician in that city. Not a paid placement, not a press release with a practice bolted onto it.
What we do not do: buy placements, write or incentivise reviews, or pitch a practice as the subject of a story it has no part in. Local earned coverage is effort under Layer 3 from the Authority plan upward — it is worked at every month and it is not a guaranteed placement, because no one can guarantee an editor.
The evidence this protocol is built on
Each layer exists because something measurable breaks there. The three datasets below are Citevio's own scans, published as downloadable CSV with their scan windows attached, and they are what the layer order is derived from — not an industry framework we adopted.
| Dataset | What it found | Which layer it explains |
|---|---|---|
| 527 US dental practice websites read field by field, 6–26 June 2026 | 53.9% carried no LocalBusiness or Dentist schema at all, and only 3.4% had both LocalBusiness and FAQPage. Meanwhile 96.7% of those with a Google rating already sat at or above 4.3 stars | L1 and L4. The reputation bar is already cleared across the market; the machine-readable layer is not. That gap is the opportunity, and it is why L1 comes before L3 |
| 6,497 robots.txt files read on 22 July 2026 | 11.4% block at least one of 13 AI and data crawlers; 7.6% counting only crawlers run by OpenAI, Anthropic and Perplexity. OAI-SearchBot, which surfaces sites inside ChatGPT search, is blocked by 0.4% | L1. Also a correction: robots.txt is a real but small cause. An agency selling "we will unblock the AI crawlers" is selling a fix for a problem most practices do not have |
| 499 homepages requested with seven crawler identities 22 July 2026 | Of sites whose robots.txt welcomes AI crawlers, 14.4% were refused by their own server anyway. Googlebot was refused by 1.2% in the same run | L1. The rule a site publishes and the rule its server enforces are two different rules, and the gap falls on the crawlers that feed AI answers. Only a live request finds it |
One correction that follows from the second dataset is worth stating on its own, because it is sold the other way round constantly. A site with no robots.txt file is not blocking anything. RFC 9309, the standard that defines the file, is explicit: "if a server status code indicates that the robots.txt file is unavailable to the crawler, then the crawler MAY access any resources on the server." What a missing file costs a practice is control, not access — and an agency quoting a scary blocking number without separating those two cases is quoting the wrong number.
Source: RFC 9309, Robots Exclusion Protocol, IETF, 2022.
These are dated snapshots of samples, not a census, and the data library states each limit in full: seven metros rather than a national frame, a partial base for the speed readings, and two crawler instruments a month apart that give two different blocking rates — 2.8% and 11.4% — which we publish side by side with the reason rather than quoting whichever reads better.
Which plan includes which layers
Layer 0 runs underneath every plan — there is no version of this work without a question set. What changes between plans is how many of the delivery layers, 1 through 5, are included.
| Plan | Layers included | What that buys |
|---|---|---|
| Visibility | 1–2 (Read, Match) | Getting read correctly by all four engines |
| Authority | 1–4 (Read → Answer) | Getting recommended, repeatedly |
| Dominance | 1–5 (Read → Chair) | Holding the answer in one metro, competitors locked out |
What Layer 5 does not do
Layer 5 measures whether a citation converted. It does not give Citevio access to patient information, and it is built specifically so that it can't.
Where a plan includes booking-source measurement, Citevio builds the source field on the booking form, the "AI assistant" option, and the line in the monthly report. The data stays inside the practice's own systems. Citevio does not receive patient names, phone numbers, appointment times or treatment details, and does not want them. What reaches Citevio is a monthly total the practice reports. If call tracking is used for this, the account is opened in the practice's own name; Citevio only reads the count. The full commitment is written into Citevio's terms of service.
AI answers increasingly resolve without a click — that's exactly why the protocol measures what happens after the answer, not the click itself. Layer 5 gets installed with a practice's actual booking form; until then, this is a design commitment, not a delivered number. The protocol gets a practice into the conversation an AI assistant is having with a patient. It does not replace financing conversations, chairside trust, or the consultation itself — those still happen at the chair, not before it.
The one part of this plan that will not change
Everything in this protocol has an expiry date except the protocol itself. The engines change models, change what they cite, and change their minds inside a month. So the fixed point is not a tactic. It is that the method is versioned, dated and rewritten whenever measurement says it should be — and that we publish the rewrite.
The evidence for treating it that way is not a prediction. It is already in the numbers on this page: 40 to 60% of the sources an engine cites for a question turn over within a month, and our own two crawler instruments, run four weeks apart, produced two different blocking rates for what looks like the same question. A method that is not built to be rewritten will quietly describe last quarter's engines while claiming to describe this quarter's.
What that means in practice, and what a practice can hold us to:
- The layers stay; the contents move. Discover, Read, Match, Trust, Answer and Chair describe a path that exists because of how these systems work, not because of how any one of them is built this year. What sits inside each layer is a working list, and it is expected to change.
- A tactic that stops measuring is retired in public. We already do this with our own instruments: the data library publicly withholds two measurements that did not clear our accuracy bar — a listing check whose matcher returned businesses outside dentistry, and a name-extraction study whose precision is not yet high enough to publish as counts. Both are listed with the exact condition that would release them. That is the standard the tactics are held to as well.
- Every number carries its date. Figures on this site are snapshots with a scan window attached, never a live feed described as one. Where a rerun changes a number, the number changes and the date changes with it.
- Nothing on this page is a guarantee of position. Positions are recomputed on every query, by systems no agency controls. What is committed to is the loop: the measurement, the reporting ratio, the response, and the retest.
Read that as the warning it is meant to be, in both directions. If a competitor's method page says exactly the same thing a year from now, that is a sign it is not being measured. The same test applies to this page, which is why it carries a last-updated date at the top and at the bottom.
What this protocol does not claim yet
Layers 1 through 4 are built and running today, inside every active plan. Layer 5 is defined at the template level, exactly as described above; it gets installed with a practice's actual booking form and call setup at onboarding, not before.
Two of the newer sections on this page carry their own limits, and they are stated here rather than left for you to discover:
- The factual-error measurement runs at onboarding, not before it. The question set, the four buckets, the three-run rule and the reporting language are written and fixed, which is what you have just read. The measurement itself needs a practice's own written record of what an engine should be saying, and we will not manufacture one to produce a demonstration. It runs at onboarding and the result goes into that practice's first monthly report.
- Local earned coverage is effort, not inventory. The city datasets exist and are published. The route from a city dataset to a placement has been opened for Citevio's own research and is worked per client under Layer 3 from Authority upward. No agency can commit an editor to publishing, and we do not price it as though it can.
We are saying that plainly so the protocol's name never outruns what has actually been built for a given practice. If a claim about Layer 5, about factual-error measurement, or about placement ever shows up somewhere without a delivered engagement behind it, that claim is wrong — write to contact@citevio.com and we will correct it.