The three-layer external entity graph AI systems use to resolve organizations has been in place for over a decade. Wikidata is the open structured-data layer. Wikipedia is the human-readable public reference.
Google’s Knowledge Graph is the consolidated internal layer that produces the Knowledge Panels in Search results and feeds entity resolution across AI Mode, AI Overviews, and Google’s internal ranking systems.
Treatment centers benefit disproportionately from being in all three. Behavioral health has the collision-heaviest entity graph of any category we work in.
Facility names collide with unrelated healthcare organizations in different states. Portfolio operators run multiple facility brands that AI systems have to resolve to specific entities. Clinicians work at multiple facilities under multiple brands. Modality names (“PHP,” “IOP,” “TMS,” “MAT”) run across hundreds of centers.
Without external entity infrastructure grounding your facility to canonical identifiers on Wikidata, Wikipedia, and the Google Knowledge Graph, AI systems piece together an identity from review snippets, competitor pages, and aggregator directories. They usually get it wrong.
Google Knowledge Panels either populate with third-party data the facility does not control, or they do not populate at all.
This piece is the operational deep-dive on the three-layer external entity graph our AI Optimization practice deploys for treatment center clients. It walks how the three layers interact and what treatment centers specifically need to publish to each.
It also covers the BH-specific notability and compliance gotchas that undermine deployment, the specific implementation sequence that produces defensible external entity infrastructure, and the measurement approach that surfaces whether the work is producing Knowledge Panel population and AI citation lift.
This piece pairs with our full AI search stack, which covers the on-site AI-readability layer, and our entity SEO explainer and sameAs strategy piece, which cover the Schema.org layer this external infrastructure connects to. This is part of our broader work on behavioral health marketing.
Key Takeaways
- The three-layer external entity graph consists of Wikidata (open structured data), Wikipedia (human-readable reference), and the Google Knowledge Graph (Google’s internal consolidated layer). Treatment centers with presence in all three produce meaningfully stronger entity resolution in AI answer surfaces and populate Knowledge Panels with facility-controlled content.
- Wikidata is the highest-impact layer for most treatment centers because the notability bar is lower than Wikipedia, entries can be created and maintained directly, and Wikidata feeds downstream systems including Google Knowledge Graph, AI training corpora, and every major open-source knowledge project. Facilities without Wikidata entries leave the highest-return investment on the table.
- Wikipedia has a materially higher notability standard than Wikidata. Most single-facility treatment centers do not qualify for Wikipedia articles under current notability guidelines. Facilities with meaningful media coverage, academic citation, or public policy relevance may qualify. Facilities that do not qualify should skip Wikipedia rather than attempt an article that will get flagged for deletion.
- Google Knowledge Panels populate based on Google’s internal Knowledge Graph, which pulls from Wikidata, Wikipedia, Google Business Profile, Schema.org markup on the facility’s website, and Google’s own entity confidence signals. Facilities that deploy all four inputs consistently produce Knowledge Panel population with facility-controlled content.
- The BH-specific gotchas that undermine deployment: Wikipedia’s medical and health advertising guidelines prohibit facility-authored content, Wikidata entries require published sources for every claim, Google Knowledge Panels sometimes populate with negative or third-party content the facility does not control, and portfolio operators face specific entity-disambiguation challenges across multiple facility brands.
- The right implementation sequence starts with Wikidata entry creation (weeks 1-4), moves to Schema.org and Google Business Profile alignment (weeks 3-6), then Google Knowledge Panel claiming and correction (weeks 6-12), and only pursues Wikipedia if the facility has documentable notability (typically not applicable at single-facility scale).
DEFINITION
Knowledge Graph optimization. The discipline of establishing and maintaining a treatment center’s presence across the three external entity layers AI systems use to resolve organizations: Wikidata (open structured data with Q-numbers and cited claims), Wikipedia (human-readable reference with a higher notability standard), and the Google Knowledge Graph (Google’s internal consolidated layer that populates Knowledge Panels in Search).
Distinct from Schema.org optimization (on-site markup, feeds one input among many), distinct from entitymap.json publishing (on-site machine-readable graph proposal), and distinct from sameAs strategy (identifier grounding across sources). The external entity graph produces the canonical facility record AI answer surfaces and Google Search treat as authoritative — and it is where the collision-heaviest categories (behavioral health among them) either resolve cleanly or misresolve to competitors, aggregator directories, or unrelated organizations.
OPERATOR INSIGHT
Wikidata is the highest-impact layer for most treatment centers.
Notability bar is achievable. Entries can be created and maintained directly. Downstream propagation feeds Google Knowledge Graph, AI training corpora, and every open-source knowledge project. Facilities that skip Wikidata and go straight to attempting Wikipedia typically waste months on articles that get flagged for deletion while leaving the actual highest-impact investment on the table.
The three-layer external entity graph
The three layers work together but serve different purposes. Understanding what each layer does is the prerequisite to deciding where to invest.
Wikidata (wikidata.org)
The open structured-data layer that underlies Wikipedia and dozens of other Wikimedia projects. Each entity gets a Q-number (like Q17743 for a specific treatment facility) and a set of structured claims (founded date, headquarters location, accreditation status, sameAs external identifiers). Wikidata is directly editable by anyone with a Wikimedia account, subject to community review.
Notability requirements for Wikidata are lower than Wikipedia. A treatment center facility that has published sources verifying core facts (year founded, address, accreditation, ownership) can typically qualify for a Wikidata entry even without meaningful media coverage.
The specific standard is that each claim must have a citable source, not that the entity itself has passed a notability bar.
Wikipedia (en.wikipedia.org and language variants)
The human-readable public reference layer. Wikipedia articles are longer-form prose with citations, and the notability standard is materially higher than Wikidata. General notability requires significant coverage in reliable, independent sources. Medical and health-adjacent content has additional editorial standards under WikiProject Medicine.
Most single-facility treatment centers do not qualify for Wikipedia articles.
Facilities that do qualify typically have one or more of: meaningful media coverage in national publications, academic citation as a research site or clinical framework originator, historical significance (opened before a major regulatory milestone), or policy relevance (referenced in state or federal health policy documentation).
Google Knowledge Graph
Google’s internal consolidated entity graph. Not directly editable by external parties. Google populates the Knowledge Graph from multiple sources including Wikidata, Wikipedia, Google Business Profile, Schema.org markup, direct crawl of authoritative sites, and Google’s own entity-resolution logic.
The Knowledge Panel that appears in Google Search results for branded queries is the visible output of the Knowledge Graph.
Facilities with strong Wikidata and Wikipedia presence combined with clean Schema.org and Google Business Profile deployment tend to see Knowledge Panels populate with facility-controlled content. Facilities without external entity infrastructure often see either no Knowledge Panel or Knowledge Panels populated with third-party content.
Wikidata: the highest-impact layer for treatment centers
For most treatment centers, Wikidata is the specific layer where investment produces the strongest return relative to effort.
The notability bar is achievable, the entry can be created and maintained directly by facility representatives, and the downstream effects propagate through Google Knowledge Graph, Wikipedia (if the facility eventually qualifies), and every AI system that consumes Wikidata as training or grounding data.
Creating a Wikidata entry. The specific process runs through the Wikidata interface at wikidata.org. Create a Wikidata account. Search for the facility to confirm no entry exists. Create a new item with the facility’s canonical public-facing name. Populate the initial claims: instance of (typically “treatment center,” “medical clinic,” or “healthcare organization” depending on the operator), founded (date), headquarters location, official website, and any relevant identifiers.
Every claim requires at least one source. Wikidata accepts sources through the reference feature: URL of the source, publisher name, retrieved date, and stated in property when applicable. Sources should be independent of the facility where possible (news coverage, accreditation body directory listings, state license lookup portals, government registries). The facility’s own website can serve as a source for a limited set of self-describing claims but not for notability-adjacent claims.
The identifier layer. The specific Wikidata properties that ground the facility to external authorities: NPI (P8248 for US National Provider Identifier), Google Knowledge Graph ID (P2671, though this typically populates automatically once Google detects the Wikidata entry), Freebase ID (P646, if the facility had a Freebase entry historically), LinkedIn organization ID (P4264), Facebook page ID (P2013), and various accreditation-body-specific identifiers where they exist.
Facilities that carry accreditations should reference the accreditation body’s directory URL as a source for the accreditation claim. JCAHO Quality Check URLs, CARF directory URLs, LegitScript public database URLs all qualify as sources under Wikidata’s guidelines.
Ongoing maintenance. Wikidata entries need quarterly review to keep claims current. Accreditation cycles produce new sources. Facility changes (new locations, leadership changes, program additions) need to be reflected in the entry. Stale Wikidata entries produce weaker downstream entity resolution than accurate current entries.
The external entity graph at a glance
3
Layers: Wikidata, Wikipedia, Google Knowledge Graph
2-4 hrs
Wikidata entry creation once source docs are gathered
90-180 d
Knowledge Panel population window after full deployment
6-12 mo
Full deployment-to-brand-search-lift timeline
Wikipedia: only if the facility qualifies
Wikipedia articles about treatment centers are rare because the notability standard is higher than most facilities can defensibly meet.
Attempting a Wikipedia article for a facility that does not meet notability typically produces an article that gets nominated for deletion, sometimes with negative documentation of the deletion attempt that persists in Wikipedia’s history.
The notability standard. Wikipedia’s general notability guideline requires significant coverage in reliable sources that are independent of the subject. For treatment centers, “significant coverage” typically means substantive articles or book chapters that focus on the facility as a primary subject, not passing mentions or industry-directory listings.
Medical and health-specific standards. WikiProject Medicine guidelines add additional editorial standards for medical and health-adjacent content. Treatment center articles that make clinical claims need those claims sourced to peer-reviewed medical literature, not to the facility’s own marketing materials. Articles that read as promotional get flagged aggressively.
Who typically qualifies. Historical facilities (opened before major behavioral health legislation), research-affiliated facilities (formally connected to academic medical centers), facilities whose clinical framework has been documented in peer-reviewed literature, and facilities that have been the subject of major national media coverage.
Who typically does not qualify. Single-facility residential SUD operators without national media coverage, PHP or IOP programs without published research, facilities with only industry-directory listings or regional trade press coverage, and any facility whose Wikipedia article would rely primarily on the facility’s own website or marketing content.
If the facility does qualify, the article should be written by an independent contributor, not by facility staff or paid PR agencies. Wikipedia’s conflict-of-interest guidelines require disclosure when a paid or affiliated party creates or edits an article. Failure to disclose produces edit reversals and often gets the article flagged for deletion.
Google Knowledge Graph and Knowledge Panels
The Knowledge Panel is the visible surface of Google’s internal Knowledge Graph. When a user searches for a facility by name, Google may display a Knowledge Panel in the SERP that consolidates the facility’s core information: name, address, phone, website, hours, category, founder, related entities, and reviews.
How Knowledge Panels populate. Google’s Knowledge Graph pulls from multiple sources. Wikidata is one input. Wikipedia is another (when an article exists). Google Business Profile is a heavy input for local businesses including treatment centers. Schema.org markup on the facility’s website contributes. Direct crawl of authoritative sites (accreditation body directories, state license portals) contributes. Google’s own entity confidence signals weight the inputs.
Claiming the Knowledge Panel. Facilities that see a Knowledge Panel populate for their branded queries can claim it through Google’s official process. The facility signs in to a Google account associated with the business, uses the “Claim this knowledge panel” flow in Google Search, verifies through Google’s verification process (typically requires a matching Google Business Profile), and gains a suggested-edit workflow for corrections.
Claiming does not produce full editorial control. Google’s Knowledge Graph is not a directory that facilities directly edit. Claiming provides a channel to suggest corrections, which Google evaluates against its confidence signals. Some suggestions get accepted quickly. Others require additional source documentation.
What produces Knowledge Panel population. Facilities with clean Wikidata entries, complete Google Business Profiles, Organization schema markup on the website with all required properties (name, address, telephone, url, sameAs), consistent NAP citations across major directories, and defensible notability signals typically see Knowledge Panels populate within 90 to 180 days of full deployment.
What prevents Knowledge Panel population. Missing Wikidata entries, incomplete Google Business Profiles, Organization schema without sameAs values, inconsistent NAP citations across directories, entity confusion with similarly-named organizations, and insufficient entity-confidence signals. Facilities that deploy some inputs but not others typically produce partial Knowledge Panel population that presents third-party data in slots the facility does not control.
The BH-specific gotchas
Four specific patterns undermine treatment center Knowledge Graph optimization.
Gotcha 1: Wikipedia advertising violations. Facilities that attempt Wikipedia articles for marketing purposes produce content that gets flagged as promotional within days. The Wikipedia community’s advertising enforcement is aggressive on health-related content. A failed Wikipedia article attempt often persists in Wikipedia’s edit history and produces negative documentation. Skip Wikipedia entirely unless the facility documentably qualifies for notability.
Gotcha 2: Wikidata source insufficiency. Treatment center facilities without meaningful press coverage often have limited independent sources to cite in Wikidata claims. The facility’s own website does not qualify as an independent source. State license lookup portals, accreditation body directories, government registries, and news coverage do qualify. Build the source trail before creating the Wikidata entry — creating an entry without sources produces claims that get removed during community review.
Gotcha 3: Google Knowledge Panel content the facility does not control. Google’s Knowledge Graph sometimes populates Knowledge Panels with content from third-party sources including negative news coverage, competitor comparison content, or aggregator directory data. Facilities discovering unwanted content in their Knowledge Panel should claim the panel and submit corrections through the suggested-edit workflow. Persistent unwanted content may require formal legal request through Google’s content removal process.
Gotcha 4: Portfolio operator entity disambiguation. Portfolio operators with multiple facilities under one parent brand face specific challenges. Google’s Knowledge Graph may consolidate multiple facilities into one entity or split what should be one entity into multiple. The specific fix is careful Wikidata modeling: separate entries per facility with clear parent-subsidiary relationships (part of, owned by properties) and distinct sameAs identifier sets per facility, so downstream systems can resolve each facility to the correct entity.
The implementation sequence
The specific sequence that produces defensible external entity infrastructure runs through four phases.
Phase 1 (Weeks 1-4): Wikidata entry creation. Confirm no existing Wikidata entry. Gather independent source documentation for the core facts. Create the entry with initial claims. Add identifier claims (NPI, LinkedIn, Facebook, sameAs to accreditor directories). Publish and monitor for community feedback.
Phase 2 (Weeks 3-6): Schema.org and Google Business Profile alignment. Confirm Organization schema on the facility website includes all required properties. Confirm sameAs values in Organization schema match the identifiers on the Wikidata entry. Confirm Google Business Profile is claimed, complete, and consistent with Wikidata claims. This is the entity-alignment step our entity SEO explainer and entitymap.json piece both address from the on-site side.
Phase 3 (Weeks 6-12): Knowledge Panel monitoring and claiming. Monitor branded search queries for Knowledge Panel appearance. When the panel appears, initiate the claim process. Verify through the Google Business Profile flow. Once claimed, review the panel content for accuracy and submit corrections for any incorrect or missing information.
Phase 4 (Weeks 12-24+): Ongoing maintenance and Wikipedia evaluation. Quarterly Wikidata review to keep claims current. Quarterly Knowledge Panel review to confirm no third-party content has surfaced. If the facility has developed documentable notability through media coverage or academic citation over the intervening period, evaluate Wikipedia eligibility with an independent contributor.
Facilities that attempt to compress the phases into a single sprint typically produce partial deployment where some layers are in place and others are not.
The specific dependency is that Wikidata entry creation should precede Knowledge Panel claiming because Google’s Knowledge Graph consumes Wikidata data. Deploying in the wrong order produces avoidable rework.
DO
- Start with Wikidata — highest return per hour, achievable notability bar, and the layer that downstream feeds Google Knowledge Graph + AI training corpora.
- Gather independent published sources (accreditor directories, state license lookups, government registries, press coverage) BEFORE creating the Wikidata entry.
- Cross-link Schema.org sameAs on your Organization markup to the Wikidata Q-number as soon as the entry is stable — accelerates Google entity resolution.
- Claim your Google Knowledge Panel through the official Google flow once it populates — then use the suggested-edit workflow for corrections.
- Monitor branded queries monthly for third-party or negative content Google may pull into the panel from external sources.
DON’T
- Attempt a Wikipedia article without documentable notability — deletion produces persistent negative documentation and does not help entity resolution.
- Have facility staff or paid PR agencies author Wikipedia articles — conflict-of-interest disclosure rules will flag the edits regardless of quality.
- Publish Wikidata claims without independent sources — community review flags source-insufficient claims and removes them.
- Skip the Schema.org + GBP alignment step — Wikidata alone does not populate a Knowledge Panel; the four inputs work together.
- Compress the four phases into a single sprint — Wikidata must precede Knowledge Panel claiming because Google’s KG consumes Wikidata.
Measurement and monitoring
The specific measurement approach that surfaces whether the external entity work is producing lift runs across three signals.
Signal 1: Knowledge Panel appearance and content. Monitor branded search queries for Knowledge Panel appearance. The specific queries to track: facility name alone, facility name plus city, facility name plus service (“[Facility] residential rehab”), and facility name plus insurance (“[Facility] BCBS coverage”). Log whether the panel appears and what content it contains monthly.
Signal 2: AI answer surface citation frequency. Run a fixed query set (20 to 30 branded and category queries) through Google AI Mode, AI Overviews, ChatGPT search, Perplexity, and Claude at a monthly cadence. Log which queries cite the facility and which do not. Citation frequency increases over time typically follow Knowledge Panel population by 30 to 60 days. Our 12-Pattern SEO Failure Diagnostic covers the broader citation measurement rubric.
Signal 3: Wikidata entry health. Monitor the Wikidata entry for community edits, source challenges, or claim removals. Wikidata entries that stay stable indicate the source documentation held up under community review. Entries that see repeated edits or challenges indicate underlying issues that need attention.
The overall pattern: Knowledge Panel population precedes AI citation lift, which precedes measurable brand-search traffic improvement. The full effect typically materializes over 6 to 12 months from the completion of Phase 3.
Common failure modes
Four patterns produce most of the Knowledge Graph optimization failures we audit.
Failure mode 1: Attempting Wikipedia without notability. Facility marketing team creates a Wikipedia article. Article gets flagged for deletion within days. Deletion process produces negative documentation. Facility loses time and gains no external entity infrastructure. Fix: focus on Wikidata, skip Wikipedia unless documentable notability exists.
Failure mode 2: Wikidata without source documentation. Facility creates Wikidata entry with claims but weak or no sources. Community review flags claims for source insufficiency. Claims get removed. Entry becomes minimal and does not produce meaningful downstream entity resolution. Fix: build the source trail before creating the entry, not after.
Failure mode 3: Schema.org and Google Business Profile inconsistency. Facility has clean Wikidata entry but Schema.org identifiers differ from Google Business Profile listings. Google’s Knowledge Graph cannot reconcile the entity across sources. Knowledge Panel does not populate or populates inconsistently. Fix: audit all four inputs (Wikidata, Schema.org, GBP, Wikipedia if applicable) for consistency.
Failure mode 4: No monitoring of third-party Knowledge Panel content. Google’s Knowledge Graph populates the Knowledge Panel with content from third-party sources including news coverage, competitor comparisons, or aggregator directories. Facility does not notice until a family member arrives at the facility referencing content the facility does not control. Fix: monthly Knowledge Panel monitoring for branded queries with escalation workflow for unwanted content.
Frequently Asked Questions
Do we need a Wikidata entry if we already have Schema.org markup on our website?
Yes. Schema.org markup on the website is one input to Google’s Knowledge Graph, but Wikidata is a separate and higher-authority input. Facilities with clean Schema.org but no Wikidata entry produce partial entity resolution. Adding the Wikidata entry closes the gap.
The specific interaction: Schema.org markup grounds the facility as an entity in Google’s crawl-based understanding of the site. Wikidata grounds the facility as an entity in the open structured-data graph that Google, AI systems, and other knowledge projects consume. Both matter, and they compound rather than substitute. Our entity SEO explainer covers the Schema.org side in depth.
Facilities that carry Wikidata entries also carry sameAs values in their Schema.org markup that reference the Wikidata Q-number. Our sameAs strategy piece walks the identifier grounding. This explicit cross-linking accelerates Google’s entity resolution and produces stronger Knowledge Panel population.
How long does creating a Wikidata entry actually take?
The entry creation itself runs 2 to 4 hours for a facility with pre-gathered source documentation. The specific breakdown: 30-45 minutes on entry setup and initial claims, 60-90 minutes on identifier claims and source documentation, 30-45 minutes on verification and cross-linking to related entities.
The source-gathering step, if not already done, adds meaningfully to the timeline. Facilities without pre-organized independent sources typically spend 4 to 8 hours gathering documentation before the entry creation itself begins.
Ongoing maintenance runs 2 to 4 hours per quarter for keeping claims current, reviewing community edits, and cross-checking against the facility’s other entity surfaces.
What if our Knowledge Panel already shows incorrect information about our facility?
Claim the panel first. The claim process runs through Google Search: navigate to your branded query, click “Claim this knowledge panel” in the panel itself, verify through the Google Business Profile flow. Once claimed, use the suggested-edit workflow to submit corrections.
Simple factual corrections (address, phone, category) typically get accepted within days to weeks. More complex corrections (removing incorrect statements, removing negative content the facility does not control, disputing third-party claims) may require additional source documentation or formal legal request through Google’s process for content removal.
Our entity SEO explainer covers the broader Schema.org discipline that supports Knowledge Panel accuracy. Facilities dealing with persistent Knowledge Panel accuracy issues should audit the full external entity infrastructure, not just the panel itself.
Do AI systems like ChatGPT, Claude, and Perplexity use Wikidata directly?
Yes, in multiple ways. Wikidata is included in the training corpora most major AI systems consume, which means the model has learned entity relationships from Wikidata during training. AI systems with real-time retrieval capabilities (ChatGPT search, Perplexity, Google AI Mode, Google AI Overviews) also consume Wikidata directly at query time when the query maps to a specific entity.
The practical effect: facilities with Wikidata entries appear as entities in AI answer responses more consistently than facilities without. AI systems can resolve queries about the facility to the specific Wikidata entity rather than piecing together an identity from prose content.
The frequency of direct Wikidata consumption varies by system and query type. Broad category queries touch Wikidata less than specific entity queries. The general pattern: the more specific the query intent maps to a single entity, the more likely Wikidata data influences the response.
Should we hire a specialized agency to build our Wikidata and Wikipedia presence?
Depends on scale and objective. Single-facility operators with clean source documentation can typically handle Wikidata entry creation internally with 4 to 8 hours of dedicated effort. Portfolio operators with multiple facilities and complex parent-subsidiary relationships benefit from specialized entity modeling expertise, particularly for the disambiguation work.
Wikipedia article creation, if the facility qualifies for notability, should not be handled by facility staff or paid PR agencies. Wikipedia’s conflict-of-interest guidelines require disclosure, and facility-authored or paid-agency articles typically get flagged for deletion. If the facility qualifies for Wikipedia, identifying an independent contributor with subject expertise is the more defensible path.
The general rule: Wikidata is internally handleable at most scales, Google Knowledge Panel management is internally handleable with the right monitoring cadence, and Wikipedia should be attempted only if the facility qualifies and only by independent contributors.
How does Google Knowledge Graph optimization interact with the 5-Tier SEO Priority Framework?
Knowledge Graph optimization sits inside Tier 4 (Content Depth and Cluster Architecture) of the 5-Tier framework. Google Knowledge Graph is one of the specific external validation surfaces Tier 4 addresses.
The specific dependency: Tier 1 (Technical Health) has to be clear before Google can crawl the facility site to extract the Schema.org markup that feeds Knowledge Graph. Tier 2 (Local Presence) supports Google Business Profile which is one Knowledge Graph input. Tier 3 (Conversion Pathways) is not directly involved in Knowledge Graph optimization but supports the site quality signals Google evaluates.
Once Tiers 1-3 are clear, Knowledge Graph optimization is the specific Tier 4 execution work that produces external entity infrastructure. Facilities that skip the framework tiers and invest directly in Wikidata or Knowledge Panel work sometimes produce entry creation without downstream propagation because the underlying foundation is not clean enough for Google’s Knowledge Graph to weight the entity claims confidently.
When should we expect measurable results from Knowledge Graph optimization?
Knowledge Panel population typically materializes within 90 to 180 days of completing the full deployment sequence (Wikidata entry, Schema.org alignment, Google Business Profile completion, Knowledge Panel claiming). AI citation lift follows Knowledge Panel population by 30 to 60 days as AI answer surfaces re-crawl and re-evaluate the facility’s entity resolution.
Brand-search traffic improvement typically follows citation lift by another 30 to 60 days as improved AI answer visibility produces branded search demand.
The overall timeline from deployment start to measurable brand-search lift runs 6 to 12 months. Facilities that expect faster results typically abandon the work before the citation lift materializes. Facilities that maintain the deployment past the 12-month mark typically see continued compounding benefit as the external entity infrastructure accumulates authority signal.
Trevor Gage is the Director of Marketing at Webserv, a digital marketing agency for treatment centers.
