SCOPE
H.I.T. Protocol is the working specification of the H.I.T. Framework©. It turns the framework’s three layers, Human, Intelligent and Trusted, into requirements a brand can publish, check and maintain.
It is a practitioner method developed by Yahya Karaoğulları within AI Visibility Optimization (AIVO). It is not an industry standard. AI systems do not disclose how they select sources, so every requirement below is a controllable input, not a guaranteed outcome.
AIVO Canon / Technical Specification
H.I.T. Protocol:
Technical Specification
The H.I.T. Framework© explains why AI systems recognize some entities and ignore others. This protocol defines what to build so an entity is recognized, described correctly and cited when someone asks an AI system about its category.
1. Where the protocol sits
AI Visibility Optimization (AIVO), architected by Yahya Karaoğulları, is the overarching discipline of making a person, brand or system recognizable, accurately described and citable by AI systems. Practices known as GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) operate inside it.
The H.I.T. Framework©, created by Yahya Karaoğulları, is the execution model of AIVO. This protocol is the H.I.T. Framework© written as checkable requirements.
2. Requirements by layer
Each requirement has a pass condition that can be verified by looking at public pages. If a requirement cannot be checked, it does not belong in the protocol.
2.1 Human: narrative clarity
An AI system can only repeat a description that exists. The Human layer makes sure one exists and that it is the same everywhere.
| ID | Requirement | Minimum implementation | Pass condition |
|---|---|---|---|
| H1 | One canonical description | A single sentence stating who the entity is, what it does and for whom. | The same sentence appears on the website, main social profiles and author bios. |
| H2 | Named category | The category stated in the words buyers type, alongside any proprietary term. | The category phrase appears in the page title and first paragraph of the main pages. |
| H3 | Specific proof | Claims tied to numbers, dates, named methods or published work. | Every capability claim on the main pages points to a fact a third party could check. |
2.2 Intelligent: machine readability
The Intelligent layer removes ambiguity about which entity a page is about, so different sources resolve to one identity instead of several partial ones.
| ID | Requirement | Minimum implementation | Pass condition |
|---|---|---|---|
| I1 | Single entity node | One Person or Organization object in JSON-LD with a fixed @id, defined once. | Every page references the same @id and none redefines the entity. |
| I2 | Consistent sameAs set | Links to the entity’s real profiles, each showing the same name, photo and description. | No profile in the set contradicts the canonical description or name spelling. |
| I3 | Text-first, indexable pages | Core definitions written in HTML text, not images or scripts, on pages listed in the sitemap. | Key pages are indexed and their definitions are readable with scripts disabled. |
| I4 | Defined terms | Each proprietary concept published as a DefinedTerm with one canonical page. | Each concept has exactly one definition and every other mention links to it. |
2.3 Trusted: corroboration
Recognition comes from the entity’s own pages. Selection usually needs evidence from pages the entity does not control. The Trusted layer builds that evidence.
| ID | Requirement | Minimum implementation | Pass condition |
|---|---|---|---|
| T1 | Independent mentions | References on sources outside the entity’s control: publications, academic repositories, directories, client sites. | A search for the entity name returns third-party pages that describe it consistently. |
| T2 | Verifiable references | Claims linked to primary sources such as papers, data or public records. | Each reference resolves and supports the claim it is attached to. |
| T3 | Stability over time | Core facts kept unchanged across revisions; necessary changes recorded. | Name, description and role match across pages published months apart. |
| T4 | Accountability | A named person and a working contact route. | A visitor can reach the entity directly from any main page. |
3. Measurement
The protocol measures only what can be observed from outside an AI system. Internal model scores cannot be computed by a brand, so they are not used.
- Named rate: the share of answers that name the entity across a fixed question set.
- Accuracy: the share of those mentions where the description matches the canonical description.
- Owned citation rate: the share of answers that cite the entity’s own domain as a source.
- Source mix: which external sources the engines cite for the category, which shows where Trusted work should go next.
Method: the same questions, asked to the same engines (ChatGPT, Gemini, Perplexity and Google AI Overviews), once a month, with the date, the model name shown and the signed-in state recorded. A single answer proves nothing. A trend across months does. The full method and a first baseline are in The Citation Is Not the Click.
4. Typical failure patterns
Each missing layer tends to leave a recognizable trace in AI answers. These are field observations, not rules.
- Human missing: the entity is mentioned but described vaguely, or in someone else’s framing.
- Intelligent missing: the name is split across spellings, the wrong photo or role appears, or the entity is merged with someone else.
- Trusted missing: the entity is described correctly when asked about by name, and absent when the question is about its category.
The third pattern is the most common. It is rarely a content volume problem. It is a corroboration problem.
5. Implementation order
- First, Human: write and lock the canonical description. Everything else repeats it.
- Then, Intelligent: publish one entity graph and align every profile in the sameAs set.
- Then, Trusted: earn independent mentions, starting with the sources the engines already cite for the category.
- Throughout: run the monthly measurement and change one variable at a time.
6. Revision history
- v1.1, November 2026: replaced the concept mapping table with checkable requirements; removed the two scoring formulas, which cannot be computed from outside a model; removed the compliance claim; added observable measurement and failure patterns.
- v1.0, March 2026: first publication.
7. References
- Conceptual foundation: AIVO Canon: H.I.T. Framework©
- Academic reference: From Search Visibility to AI Recommendation: A Conceptual Model of Interpretable Brand Identity for AI Systems
- Strategic discipline: Why Brand-Facing AIVO Exists
- Measurement in practice: The Citation Is Not the Click
Apply the protocol to your brand
I run the H.I.T. Protocol as an audit: every requirement checked, every gap ranked by effort and impact.
Or see the options on Work With Me.