Quick answer
Your company may already hold the answer, yet employees may not find the approved version, internal AI may not retrieve it within existing permissions, and no cleared public page may exist for answer engines to cite. When those failures occur, the problem is knowledge visibility, not document volume.
A public answer system cannot cite an approved first-party page that does not exist. It may cite a third-party source instead, which is why the distinction matters.
Generative Engine Optimization (GEO) is the work of making approved public evidence clear, attributable, current, and technically eligible for generative answer systems to discover and reference. GEO applies to public evidence, not confidential operational knowledge, and eligibility is not a citation promise.
Executive decision brief
Before buying another content or AI platform, sponsor a 30-day audit of ten recurring questions. For each question, identify the approved answer or confirm that none exists. Then test three separate conditions: whether authorized employees can find it, whether an approved AI system can retrieve it while respecting existing permissions, and whether a cleared nonconfidential public version exists.
Fix access-control failures first. Assign an owner and review date to every answer. Keep three remediation backlogs because success in one layer does not repair or authorize another.
Personal opinions: The views expressed are Fernando Angulo's own and do not represent Semrush or Adobe.
When marketing knowledge falls out of usable view
An answer falls out of usable view when a current decision sits beside an obsolete version, an analysis has no clear owner, or a policy depends on asking one expert. The file still exists. The approved answer is simply difficult to identify and retrieve through a documented route.
Two workplace studies provide bounded examples of these mechanisms. They are useful signals, not evidence of market-wide prevalence.
In a 2024 case study at one biotechnology company, a SharePoint feature classified 171,523 of 288,363 enterprise-search queries over four months as people searches, or 59.5%. The study involved 5,854 searchers, 98 completed questionnaires from 226 invitations (a 43.4% response rate), and eight interviews. The eight interviewees described using people searches to find contact information, documents, and expertise, and as shortcuts or steppingstones in complex exploratory searches. Top Management was excluded from the interview sample due to time constraints.
The 59.5% figure is the software feature's classification, not a manually verified measure of intent. One company, one system, and four months do not establish a benchmark for another organization.
A 2025 qualitative study of one large international IT company reported multiple unsynchronized tools, duplicated information, unclear ownership, and scattered sources. The study involved 50 employees in 22 group interviews, drawn from cross-functional teams distributed globally. Its findings are context-specific, but the failure signals are concrete enough to test: competing versions, missing owners, expert dependency, and no documented route to the approved answer.
If those signals appear across ten real questions, the team has evidence from its own environment. That is more useful than importing a universal productivity estimate.
Fragmentation creates three visibility failures
The first failure is human retrieval. An authorized employee may find several plausible documents but still miss the current approved answer, its owner, or its effective date. Retrieval succeeds only when the employee can reach the approved source and verify its provenance through a documented route.
The second failure concerns permissioned AI access. Retrieval-augmented generation (RAG) gives an AI model selected material from an external collection before it produces an answer. In the original RAG architecture described by Lewis and colleagues, a retriever selected documents from a dense index and supplied them to a generator alongside the model's existing parametric memory.
A retrieval stage can provide context only from material available to its retriever and index. That is an architectural inference from the original design. It does not mean every AI answer uses RAG, that a model has no other knowledge, or that an available document will be selected. A missing connection or stale index can still prevent permission-respecting retrieval of an approved answer.
Access remains a separate test. NIST's Zero Trust Architecture guidance calls for per-session access with the least privileges required and rejects automatic access to one resource merely because another was authorized. Its scope is general enterprise zero trust architecture, not AI retrieval or validation of this audit. Microsoft documents connector options that either respect source-system access-control lists or expose connected content more broadly, warning that incorrect settings can overshare sensitive material. Google documents identity-aware filtering for Agent Search. That Google feature is Preview under Pre-GA terms, may have limited support, and may change incompatibly. These product pages describe specific controls, not universal performance.
The third failure concerns public evidence. Public answer products describe web sourcing, but the accepted sources do not promise selection. OpenAI says ChatGPT Search can use web sources and show citations or a Sources panel, while warning that results and citations can be incomplete, outdated, or incorrect. It also says allowing OAI-SearchBot can create eligibility, not guaranteed placement. Google says AI Overviews provide supporting web links and can make mistakes. Perplexity's own product overview says it searches the web and links to original sources. These are first-party product descriptions, not independent evaluations of source quality, completeness, or citation accuracy. Publication therefore creates an opportunity for discovery and citation. It never guarantees selection, accuracy, ranking, traffic, or endorsement.
The Three-Layer Knowledge Visibility Audit
I propose a three-layer audit built around three questions: Can people find it? Can approved AI use it under the same permissions? Is there a cleared public version to cite?
The layers are independent. Use this master confidentiality boundary throughout the audit: confidential operational knowledge stays internal; internal AI access is permissioned and governed; only approved nonconfidential expertise may become public. A pass in one layer does not grant access or publication in another.
Use the following thresholds, tester count, and aggregation rules as a proposed starting rubric, not a validated benchmark or externally validated standard. Before testing, define the target, planned repeat count, and acceptance threshold for each question and layer. Record the intended actor, approved source and effective date, expected access result, retrieval-time target where relevant, and evidence required to pass. Do not adjust the target after seeing the results.
- Pass: The predefined target is met with a current approved source, required provenance, and no access or confidentiality failure.
- Partial: The result is usable, but a predefined requirement for consistency, timeliness, provenance, or route quality is missing. An access or confidentiality failure is never partial.
- Fail: The answer is missing, wrong, stale, conflicting, unsupported, or outside the expected access boundary.
- Not applicable: The layer was excluded before testing, with the reason, decision owner, and date recorded. Missing tooling or approval does not qualify by itself.
Layer 1: Human retrieval
Give each question to three to five authorized testers who did not prepare the source list. Score each tester separately. Aggregate pass only when every tester passes. Aggregate partial when at least half pass and no tester reaches a materially wrong answer presented as approved. Aggregate fail when fewer than half pass or any tester reaches that critical wrong answer.
Score a documented route to a particular expert as partial unless expert judgment is inherently required. It may pass when the expert role and escalation route are approved and the response meets the predefined target. An undocumented or unavailable expert dependency fails. A missing approved answer also fails because there is no validated target to retrieve.
Layer 2: Permissioned AI access
Permissioned AI access asks a narrower question: can an approved system return a supported answer while respecting the source permissions attached to the test identity? Passing this layer does not certify the system as safe or compliant overall.
Use only an organization-approved system and approved connections. Prefer approved, non-sensitive canary content with representative access controls. Test denial against that canary instead of probing for real restricted material merely to prove that denial works.
Obtain written security-owner and system-owner approval before negative identity testing. Use a sanctioned test account or a legitimately distinct identity that already has the intended access difference. Never change production permissions or impersonate a user for a test. Predefine the number of runs for every question and identity. Pass only when all authorized runs return the supported answer and all approved negative runs respect the expected denial. Partial applies only to incomplete authorized retrieval with no unauthorized exposure.
Record the minimum evidence needed to reproduce the result: system and version, connector or index timestamp, exact question, identity or role, expected source, expected access result, run number, and observed source. If oversharing occurs, stop the test, preserve only the evidence required by policy, and follow the organization's incident process before continuing. If this layer is intended but no approved system exists, record fail. Use not applicable only for a prior, recorded scope decision.
Layer 3: Approved public citability
This formal layer asks the plain-language question: Is there a cleared public version to cite? Pass only when publication approval, evidence, authorship, freshness, canonical URL, ordinary web access, and technical-eligibility checks all succeed. Partial means an approved page has remediable readiness gaps. Fail means public use is intended but no approved current evidence exists. Not applicable means the owner and publication reviewer intentionally kept a public version out of scope.
A Layer 3 pass measures publication readiness and technical eligibility only. Apply the citation limitation stated above. It does not record or predict actual citation occurrence.
For public evidence, keep actual citations separate from mentions. How to measure citation authority
A platform cannot fix an ownership problem
A repository or AI interface can improve a retrieval route. It does not decide which conflicting document is authoritative, approve an answer that does not exist, name its business owner, or clear a public version. Those are management decisions.
The accountable business role validates the answer. A knowledge or operations role maintains the documented route. Security and system owners authorize permission tests. A publication reviewer clears any public version. Marketing can sponsor the audit and coordinate remediation without inheriting another function's authority.
Protect the audit register as sensitive operational metadata. Classify it, restrict access, set retention rules, and minimize or redact question wording, source locations, identities, classifications, and approval references in broader reports. Store full details only in the access-controlled system of record when they are necessary and permitted.
Run the audit in 30 days
The 30-day schedule, ten-question scope, tester count, repeat plan, and scoring thresholds are proposed pilot parameters, not validated benchmarks. Adapt them through the organization's approved governance and security processes before use.
Select ten questions that recur in executive, sales, customer, product, policy, or market conversations. Use only questions for which a responsible owner can validate the approved answer or confirm its absence.
Days 1 to 5: choose and classify. Ask five to eight functions for recurring questions, then select ten by frequency, consequence, and cross-functional reuse. Assign an answer owner, confidentiality class, approved source, effective date, and review date. Predefine each layer's target, repeat count, and acceptance threshold. Classify and access-control the register before adding sensitive details.
Days 6 to 12: test human retrieval. Use three to five authorized employees who did not prepare the source list. Record each result, route, elapsed time, conflicting version, and provenance. Aggregate with the proposed starting rubric.
Days 13 to 19: test permissioned AI access. Use approved systems, approved connections, sanctioned identities, and non-sensitive canary content. Run the predefined repeats. Record only the evidence needed to reproduce the result. Address any access-control failure first and use the incident process when required.
Days 20 to 24: assess public evidence. Where a nonconfidential public version has a legitimate approved audience, check its answer, authorship, public evidence, freshness, stable canonical URL, ordinary web access, and crawl eligibility. The audit does not grant publication approval.
Days 25 to 30: prioritize fixes. Create three separate remediation backlogs: internal knowledge hygiene, permissioned retrieval, and approved public evidence. Rank work by business consequence, question frequency, confidentiality risk, and effort. Report each layer as four counts out of ten: Pass, Partial, Fail, and Not applicable. Do not blend the layer baselines.
Use a compact, access-controlled audit record:
| Field | Minimum record |
|---|---|
| Question and target | Question ID, exact question, approved answer or confirmed absence, expected source, effective date, and acceptance threshold |
| Test context | Layer, system and version where relevant, connector or index timestamp, identity or role, and planned repeat count |
| Expected result | Expected access result, expected source, and run number |
| Observed result | Observed source, Pass, Partial, Fail, or Not applicable, plus minimum redacted evidence |
| Remediation | Accountable role, target date, review date, and coded approval reference when publication is proposed |
The result is a management view of ten recurring questions, approved answers or recorded gaps, owners, review dates, three independent baselines, and three remediation backlogs.
Start with the knowledge you already own
The audit does not assume that more content is the answer. It shows where approved knowledge stops: with an employee, at a permission-respecting retrieval layer, or before a cleared public page exists.
Begin the 30-day audit with ten recurring questions, three to five authorized testers, predefined repeat counts, and three separate remediation backlogs.
FAQ
1. Should internal company knowledge be made public?
No. Confidential operational knowledge should stay internal. Only nonconfidential expertise that passes a separate publication review may become public evidence. Human access or permissioned AI access does not authorize publication. A public version needs its own evidence, authorship, freshness, stable URL, and technical checks before the third layer can pass.
2. What is the difference between internal retrieval and public citability?
Internal retrieval helps authorized employees or approved systems find supported answers within existing access controls. Public citability concerns a cleared, nonconfidential page that answer systems can discover and potentially reference. The first supports governed work inside the organization. The second creates an external evidence surface, but it does not guarantee citation or accurate use.
3. Who should own knowledge visibility?
Marketing can sponsor the audit, but authority stays distributed. A business owner validates each answer, a knowledge or operations role maintains the retrieval route, security and system owners govern permission tests, and a publication reviewer clears a public version. One coordinator can manage remediation without taking over those separate decisions.
4. How does knowledge management relate to GEO and AI citations?
Knowledge management makes approved answers findable and maintainable inside the organization. Generative Engine Optimization, or GEO, applies to cleared public evidence that generative systems can discover and potentially reference. Governance connects them: only approved nonconfidential expertise moves outward. Publication creates technical eligibility and a citation opportunity, not a promise of selection.
5. Is a new knowledge management platform required?
Not necessarily. Test ten recurring questions against existing sources, owners, permissions, and public evidence first. A platform may improve a documented retrieval route, but ownership, approval, access, and publication decisions remain management work. Let the three remediation backlogs show whether the priority is process repair, permissioned retrieval, public evidence, or new technology.
Do not start with another content calendar. Start with the knowledge your company already owns but cannot consistently retrieve, use, or publish.
FA