How AI Verifies You're Real

The claim

A validator checks whether your schema parses. It doesn't check whether anyone should believe it.

That's the gap this piece is built to close. Clarion's own 130-firm audit of independent RIAs found a specific, buildable architecture underneath the handful of firms an AI system actually trusts: seven layers, each with a name, each checkable from outside the firm, each present or absent in a way that has nothing to do with which regulated profession you practice. An RIA needs it. So does an attorney, a physician, a general contractor, a dog breeder. The mechanism doesn't check your license type. It checks whether the license is linked.

This piece teaches those seven layers from first principles, with a paired example running through each one: an independent RIA and an independent attorney, two professions in different regulatory worlds, built to the identical spec. Then it hands you a tool that scores your own site against that spec, right now, and shows you exactly what's missing and why it matters. It will not show you how to fix it. That refusal is the point, not an oversight, and the rest of this piece explains why.

What AI search actually checks — and what the existing tools check instead

Search "schema markup checklist" and you'll find dozens of tools that all check the same thing: does your JSON-LD parse, which schema.org types have you declared, does the page qualify for a rich snippet in Google. Google's own Rich Results Test does this. So does validator.schema.org. So does the current crop of AEO tools: one scores a "Schema Health Score" and hands you ready-to-paste code to fix what it finds in the same breath; another scores schema as one signal among roughly forty in a free "AEO analyzer." All of them answer a syntax question: does this parse, does this exist.

That is not the question an AI system is actually asking when it answers a client's question. When someone asks an assistant to recommend an adviser, a lawyer, a physician, a breeder, the model isn't checking whether your Organization block is well-formed. It's trying to answer a harder, more specific question: is this claim true, and can I verify it against something I don't have to take the page's word for. Valid syntax and verifiable authority are different questions, and every tool in the category above answers the first one.

Clarion's own 130-firm audit of independent RIAs is what surfaced the distinction, because it measured both at once. Eighty-nine percent of the firms audited surface in AI search — visible, findable, recognized as belonging to the category. But that visibility is borrowed. It comes from third-party directories that scraped a public regulatory filing, not from anything the firm itself built. Ask what those same firms have built to let a machine verify their own claims, and the numbers collapse: fifty-nine percent have no structured organization entity at all, and not one of the hundred and thirty links its own regulatory record in a form a machine can check. The firms are recognized as a category. They are not verified as individuals.

That's the seven-layer architecture this piece walks through, and it's worth being direct about how it differs from a validator before going further: a validator checks syntax. This piece, and the tool below, check authority: whether a claim on the page is backed by something outside the page that a machine can go confirm. Nothing below tells you how to fix what it finds. Every validator on the market already does that, usually badly. This does the harder, narrower thing none of them do.

Score your own site

Before the deep-dive, run the check on your own site.

The tool below fetches a URL you give it (server-side, so it isn't blocked by the cross-origin restrictions that stop a browser from reading another site directly), extracts whatever structured data it finds, and scores it against the same seven-layer rubric this piece walks through below, weighted the way the research report weighted them. If you'd rather not have anything fetch your site, paste the page's HTML directly instead; that path runs entirely in your browser and sends nothing anywhere. Either way you'll get a number, a band, and a plain-language account of what each layer found and why it matters. Never an instruction to add a property or change a line of code.

Run it now, then read the seven layers below with your own result in mind. Each section calls back to the layer it just scored.

The seven layers, walked

The Organization layer

An entity graph starts with a name that resolves to one specific thing, not a website's worth of pages that might or might not be about the same business.

In schema terms, that means an Organization-family entity, typed as specifically as schema.org allows, anchored by a stable @id (a canonical URL with a fragment, like https://example-advisors.com/#organization) that gets referenced, not redeclared, everywhere else on the site. An RIA declares FinancialService, not the generic Organization or LocalBusiness type most firms default to if they declare anything at all. An independent attorney declares LegalService, or the more specific Attorney type schema.org provides, with the identical @id discipline. Either way the entity carries name, url, a logo or image, and an address or telephone: the baseline properties that let a machine say "this is a real, locatable thing," not just a string of text.

Clarion's audit found this layer thin across the industry: forty-one percent of the hundred and thirty firms audited declare any Organization-family entity at all, and of that forty-one percent, only 15.4 percent of the full sample use the correct, field-specific type rather than a generic one. Fifty-nine percent, the majority, have no organization entity anywhere. From a machine's perspective, that firm is a stack of unsigned documents. The prose might say who wrote them. Nothing in the page's structure does.

This is the cheapest layer to build and the one most sites skip, usually because nobody told them it existed rather than because it's hard. A stable @id and a correctly typed entity are a few lines of JSON-LD, not a redesign. It's also the layer every other layer depends on: the Person entity below references the Organization's @id, the regulatory links attach to it, the content layer's articles eventually trace back to it. Skip this one and the rest of the graph has nothing to anchor to.

The regulatory verification layer

This is the layer Clarion's research calls the most striking finding in the study, and it's the one this piece leans on hardest, because it's simultaneously the cheapest layer to build and the one nearly nobody has bothered to.

Every RIA in the audited sample is registered with the SEC. That registration lives at a stable, public URL on the IAPD database (adviserinfo.sec.gov, keyed to the firm's CRD number) that anyone, including an AI system, can dereference and check. The same is true, structurally, for an attorney: a state bar's public member-lookup record, keyed to a bar number, sits at an equally stable URL. Schema.org's sameAs property exists specifically to hold links like these. An Organization entity's sameAs array should include the regulatory record, not just the firm's LinkedIn and Facebook pages. A social profile and a regulatory filing are not the same kind of link, and treating them identically is exactly the confusion that leaves this layer empty.

Not one firm in Clarion's hundred-and-thirty-firm sample links its IAPD record in schema. Zero link NAPFA, the fee-only membership body most of those same firms cite prominently in their own marketing copy. Zero link FINRA BrokerCheck, a link FINRA Rule 2210 already requires be visible on the page, meaning the schema version of that link would extend an obligation the firm already has, not create a new one. Eighty-two percent of the sample carries no authoritative external link in schema at all.

The most expensive thing to fake and the cheapest thing to verify — and almost nobody has built it. That's the report's own framing for this finding, and it holds exactly as well for a lawyer's state bar record, a physician's board certification, or a breeder's AKC registration as it does for an SEC filing. The regulatory body differs by profession. The mechanism (a public, stable, checkable link from a claimed credential to the authority that issues it) does not.

One honest caveat, worth stating before the tool below states it too: this layer's scoring depends on a maintained list of recognized authorities, and that list is a starting point, not a ruling. An unrecognized regulatory link isn't the same as no regulatory link. It just means Clarion's lookup table hasn't caught up to your profession yet.

The Person layer

A bio paragraph is prose. A Person entity is a claim a machine can trace.

The distinction matters most for owner-operated and principal-led practices, where the person is functionally the brand: a solo RIA, a boutique litigation firm, an independent physician's practice. Schema.org's Person type, declared with its own stable @id, a jobTitle, and a worksFor property that references the Organization's @id specifically (not a bare string repeating the firm's name), turns "I am the founder of this firm" from an assertion into a graph edge a machine can follow: Person, linked to Organization, both independently checkable.

worksFor is the property that does the actual work here, and it's worth being precise about what a real link looks like versus what most sites do instead. A worksFor value that's just the firm's name as a text string tells a machine nothing it can verify. It's the same unstructured claim as the bio paragraph, dressed in JSON-LD. A worksFor value that's an object carrying the Organization's own @id is a real reference: two independently declared, independently checkable entities, connected. The difference is a few characters of markup and the entire difference in what the graph can prove.

Clarion's audit found this layer nearly untouched: 3.1 percent of the audited firms (four firms out of a hundred and thirty) have a Person entity for their principal advisor at all. An independent attorney's site needs the identical entity: name, jobTitle ("Attorney," or a more specific title), an @id, and a worksFor link back to the LegalService entity above it. The vocabulary changes. The graph shape doesn't.

The credential layer

Years of earned licensure, stated only in prose, are a claim a reader has to take on faith. The same credential declared as a structured hasCredential property is a claim with an address: somewhere a machine can go check it, rather than trust the page that made it.

Schema.org's EducationalOccupationalCredential type is built for exactly this: a credentialCategory describing what was earned, and (the property that actually does the verifying) a recognizedBy field naming the body that issued it. An RIA's principal declares hasCredential for a CFP or CFA designation, recognizedBy the CFP Board or CFA Institute. An independent attorney declares the JD and bar admission the same way, recognizedBy the issuing law school and the state bar respectively. Both live on the Person entity from the layer above, which is why the layers build in this order: you need a Person to attach a credential to before the credential means anything.

Zero of the hundred and thirty firms in Clarion's audit make any hasCredential declaration in schema. Not one. This is a profession where the credential is close to the entire value proposition: a CFP or CFA represents years of study and a governing body willing to revoke it for cause, and none of that authority exists anywhere a machine can read it. The advisor's CFA and the article they wrote about portfolio construction are, in the model's reading, unconnected facts, because nothing in the data links them.

This is also the layer where "thin but present" beats "absent." A single, correctly structured hasCredential declaration (even one credential, even without every designation a principal holds) moves an entity from having no verifiable expertise at all to having some. The gap between zero and one credential is bigger, structurally, than the gap between one and five.

The content layer

Published work is the primary evidence most professionals have of their own expertise, and it's routinely orphaned from the person who wrote it.

An Article or BlogPosting schema block on a published piece does the binding: the author property should reference the writer's Person @id, the same entity built two layers up, not a bare name string repeating the byline. That link is what lets a machine connect the credential to the content: an attorney's essay on a specific area of contract law becomes evidence of the JD and bar admission declared on the Person entity, rather than an anonymous opinion with a name attached to the top.

A third example is worth introducing here, because the point of this piece is that the mechanism doesn't care what you're licensed to do. A specialist physician publishing patient-education content on a specific condition needs the identical structure: Article schema, author referencing the physician's Person @id, that Person entity carrying a board-certification credential recognized by the relevant specialty board. The vocabulary is medical instead of financial or legal. The graph shape (content, bound to author, bound to credential, bound to organization) is the same shape this piece has now walked through three times, on purpose.

Clarion's audit didn't produce a clean percentage to cite here, and that's itself informative: the base rate of firms even attempting this binding sits low enough across the sample that a precise number would overstate how developed the practice is anywhere in the industry. The firms that publish substantively and the firms that bind that content to a credentialed author are, functionally, two different, mostly non-overlapping groups.

This layer only applies to pages that are actually content: an about page or a homepage isn't scored on it, and the tool below auto-detects the difference rather than penalizing a page for not being something it was never trying to be.

The discovery file layer

Everything above this line is invisible if the discovery layer doesn't let a crawler read it in the first place.

robots.txt determines which crawlers are allowed to request pages at all, and the AI-specific crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and a growing list of others) need to be named explicitly, not covered by a wildcard rule written before any of them existed. sitemap.xml gives a crawler the canonical list of pages worth reading, referenced from robots.txt so a crawler finds it without guessing. llms.txt, a newer and less standardized convention, gives AI systems a structured summary of what the site is and where its primary content lives.

Clarion's own site had this layer wrong for most of its own existence: a Cloudflare setting that blocks AI bots by default was quietly left on, silently blocking the exact crawlers the studio's entire practice is built around being legible to, until I found and fixed it during the same audit that produced the research report this piece cites throughout. That's not a flattering detail to include, and I'm including it anyway, because the discipline this piece is arguing for only means something if it holds against the person making the argument.

The fully-worked instance in Clarion's own corpus belongs to a different project entirely: Northwest Lagotto, a one-person dog-breeding program audited as a case study at the opposite extreme from the hundred-and-thirty-firm sample: one entity, zero marketing budget, the same seven layers applied once, by hand, outside financial services. Its robots.txt names more than twenty crawlers explicitly, its sitemap and llms.txt stay in sync with each other, and all three were checked, not assumed, before that case study published. None of that required a redesign. It required someone deciding the crawlers were worth naming.

The propagation layer

A single page can tell you a lot. It cannot tell you whether the rest of your site agrees with it.

Every layer above needs to hold consistently across every page type a firm publishes, homepage, about page, service pages, article pages, not just the one page a visitor happens to land on first. The same Organization @id, referenced rather than redeclared, on every page. The same Person @id for the same principal, wherever they're mentioned. Schema declared on the homepage and nowhere else isn't a smaller version of a complete entity graph. It's a different, weaker thing: a claim made once, in one place, that a machine has no way to confirm the rest of the site still stands behind.

Clarion's audit measured this directly: 17.7 percent of the audited firms maintain a stable @id that actually propagates across the pages sampled. The rest either don't propagate at all or redeclare a slightly different version of the entity on each page: the kind of drift that looks fine to a human skimming the site and reads, to a machine trying to resolve one entity from several inconsistent descriptions of it, as several different, unreliable claims instead of one verified one.

This is also the layer a single-URL scan structurally cannot verify, and it's worth being honest about that here rather than only in the tool's own disclosure. If you ran the Inspector above against one page, it told you the propagation layer wasn't assessable, not that it scored zero. Those are different statements, and the difference matters: a one-page tool that silently scored this layer as failing would be making a claim about your whole site from evidence about one page of it. The tool doesn't do that. It says plainly that it can't see this layer from what you gave it. If you're willing to paste in a second or third page, the tool's multi-page mode is the way to actually check whether your @id holds across them.

What a one-page scan can't see

The tool above is honest about its limits, and this piece should be too, before a skeptical reader finds the gaps unassisted.

It reads server-rendered HTML only. It does not execute JavaScript, which means a site that injects its schema through a client-side framework after the page loads will show up here as having no schema at all, even though a browser-executing crawler might see something different. That's a materially different method than the hundred-and-thirty-firm audit itself used, which ran live browser execution specifically to catch schema injected this way. Worth naming directly, rather than letting the discrepancy sit unexplained if your own site scores lower here than you expected.

It checks a finite, maintained list of regulatory and credentialing domains, seeded at launch across the professions this piece names: SEC and IAPD, FINRA, NAPFA, and the CFP Board for financial advisers; a set of state bar associations for attorneys; the AKC, OFA, and the Lagotto Romagnolo Club of America for the profession Clarion happens to have tested this mechanism on personally; the AIA for architects; the ADA and the American Board of Medical Specialties for dentists and physicians. That list will miss legitimate authorities it hasn't been taught yet, and an unrecognized link scores as an absent one even when the authority behind it is entirely real. The fix for that isn't pretending the list is complete. It's saying so, in the tool's own output, every time.

And, as the propagation section above already said directly: it cannot tell you whether the rest of your site agrees with the one page you gave it. A high single-page score is real evidence of a well-built page. It is not evidence of a well-built site, and this piece won't let the tool imply otherwise by omission.

What this replicates — who this is for

None of the seven layers above are specific to financial advice, and the paired examples running through this piece were chosen to make that hard to miss rather than easy to skim past.

An RIA and an independent attorney appear in every layer, deliberately, because they sit in genuinely different regulatory worlds: one under SEC and FINRA oversight, the other under a state bar. The graph shape is identical anyway: Organization, typed specifically; a regulatory sameAs link; a Person entity for the principal; a credential bound to that person; content bound to that credential; discovery files that let a crawler find any of it; the same structure propagated across every page. A specialist physician's patient-education content made the same case a third time, in the content layer, with a board certification standing in for a bar admission. Swap in a general contractor's license board, a CPA's state licensing body, an architect's AIA and NCARB registration, an AKC-registered dog breeder's club membership and health-testing records, and nothing about the mechanism changes. Only the vocabulary does.

That's the actual claim underneath the phrase "entity graph," stated plainly instead of left implicit: the seven layers don't care what you're licensed to do. They care whether the license is linked. A firm's specific value (the fifteen years in a narrow specialization, the specific credential, the specific published expertise) is exactly what makes a client choose one professional over an interchangeable field of them. None of that is visible to an AI system unless it's built in a form the system can check. Most of it, across most professions, currently isn't.

This piece and the tool above exist to make that gap visible before you take Clarion's word for how it applies to your own practice. Run the Inspector. Read your own score against the layer that explains it. Then decide whether the gap is worth closing.

Close

A machine-legible identity is not a mystery, and it is not a matter of taste. It is a specific, buildable architecture: seven layers, a hundred points, weighted toward the layer that turns out to matter most. The fastest way to know where your own site stands against it is to have run the Inspector above rather than take this piece's word for any of it.

Restated plainly, one more time: a validator checks whether your schema parses. It doesn't check whether anyone should believe it. This piece, and the tool built alongside it, check the harder question instead: not because the syntax question doesn't matter, but because every other tool already answers it, and none of them answer this one.

This tool will tell you what's missing and why it matters. It will not tell you how to fix it. That part is the paid engagement, on purpose. The same discipline the research report and the Northwest Lagotto case study both practice, for the same reason. A diagnosis you can verify yourself is worth more than a fix you have to take on faith, and it's the only kind of claim this piece is interested in making.

FAQ