The Entity Authority Framework

The core idea

Schema declares. Corroboration convinces.

Search and AI engines no longer rank pages in isolation — they resolve entities (people, organisations, works) and decide how much to trust them. On-page markup only declares who someone is. Trust comes from the surrounding graph: independent sources repeating the same facts, linked so a machine can walk the loop and confirm it. Our own verified research says the same thing from the other side: off-site mentions > backlinks > on-page schema — schema is hygiene, the graph is the lever.

The technical standard

The @id is the glue — pick once, freeze forever

Canonical identifier format, used verbatim on every property that mentions the expert:

https://www.muswellrose.com/expert-voices/<slug>/#person
// www + trailing slash — the resolvable canonical (non-www 301s).
// Adam's stays https://www.muswellrose.com/adam-parker#person — his page predates
// the directory. NEVER change an @id once deployed; it resets entity resolution.

Hub template — the unified @graph on the Muswell Rose canonical page:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://www.muswellrose.com/expert-voices/derren-powell/#person",
      "name": "Derren Powell",
      "description": "Payments and fintech specialist; formerly Vice President, Business Development (Merchants) at Mastercard; Transact Payments, Citi and HSBC before that. 25+ years in financial services. Runs Finterra, an independent payments advisory.",
      "url": "https://www.muswellrose.com/expert-voices/derren-powell/",
      "image": "https://www.muswellrose.com/img/derren-powell.jpg",
      "worksFor": { "@type": "Organization", "name": "Finterra", "url": "https://finterra.co.uk/" },
      "hasOccupation": [
        { "@type": "Occupation", "name": "Founder, Finterra" },
        { "@type": "Occupation", "name": "VP, Business Development (Merchants), Mastercard" }
      ],
      "knowsAbout": ["Card payments", "EMIs", "Acquiring", "Card programmes"],
      "sameAs": [
        "https://www.linkedin.com/in/derrenpowell/",
        "https://finterra.co.uk/"
        // NEVER a dead or hijacked URL: the old pay360conference.com speaker page
        // now serves spam (verified 16 Jul) — a broken sameAs is worse than none.
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://www.muswellrose.com/expert-voices/derren-powell/#profilepage",
      "mainEntity": { "@id": "https://www.muswellrose.com/expert-voices/derren-powell/#person" }
    },
    {
      "@type": "Organization",
      "@id": "https://www.muswellrose.com/#organization",
      "name": "Muswell Rose",
      "url": "https://www.muswellrose.com/"
    }
  ]
}

Spoke template — on every fleet article the expert reviews:

"reviewedBy": { "@id": "https://www.muswellrose.com/expert-voices/derren-powell/#person" }
// plus a compact local Person node with the SAME @id + name + url + sameAs,
// so the reference resolves on-site too. author works identically.

Beyond Google

Same graph, different doors

The architecture doesn't change per engine — what changes is which corroboration each engine walks in through. (Fleet ground truth, verified 16 Jul: ChatGPT is currently the only AI engine delivering leads, and its lane is Bing indexation + live fetches — this framework feeds exactly that.)

Operations

Onboarding a new expert — the pipeline

What actually has to happen, per expert, in order. (Owner tags: who does it.)

1. Verify the footprint Claude

   Real, checkable credentials: LinkedIn, Companies House, speaker pages, their own company site, press. If the footprint can't be verified, stop — a decorative byline is worse than none.

2. The consent conversation Adam

   Plain-English explainer (the one-pager), the two-way benefit for their own site, and their yes to: named bio + photo + links, and genuinely reviewing the content that carries their name.

3. Agree the canonical fact-set Adam Claude

   ONE job title, one base bio, exact career dates and org names — captured in the Entity Bible. Facts must be identical everywhere the expert appears (their own site, LinkedIn, our pages, later Wikidata); the wording can flex per context, the facts cannot. Reconcile their LinkedIn/site to it before we publish, not after.

4. Build the canonical hub page Claude

   muswellrose.com/expert-voices/<name>/ — bio, photo, dated career timeline, credentials with issuers, media/evidence links, unified @graph with the frozen @id, curated sameAs. Expert approves before deploy.

5. Spoke pages + scoped bylines Claude

   Lightweight on-site profile (byline target, disclosure line, "Full profile →" up-link) + "Reviewed by" on the exact-credential money pages only. reviewedBy schema references the canonical @id. Editorial-policy page current on that site.

6. Close the loop from their side Adam

   Their own site gets the reverse edge (reviewer line + link to their MR profile — for Derren we build it, we run Finterra's site) and their LinkedIn adds the profile link. This is the strongest single verification signal.

7. Grow the evidence graph Adam Claude

   Media/mentions section on their profile (kept current), speaking pages, any research or data they contribute (DOI-registered where real). Evidence density is what AI engines cite.

8. Wikidata — when referenced Adam

   Only once steps 4–7 give the item independent references. Add the QID to sameAs everywhere when it exists.

9. Protect it Claude

   FLEET_REALITY revert-catch checks on every page that carries the byline; quarterly audit of links, schema and fact-consistency (stale graphs read as abandoned graphs).