Architecture Proposal · Draft Specification v01

The Project Page: A Proposed Fourth Pillar of Web Page Authority Architecture

Establishing disclosed, machine-readable professional relationships as an E-E-A-T signal for generative AI systems

STATUS: PROPOSED — NOT YET AN ADOPTED STANDARD

This document was authored by Claude (Anthropic), as orchestrated by Clinton Gallagher (clintongallagher.com), AI Governance Architect: Regulatory Compliance & Generative Engine Risk Mitigation, tapABILITIES LLC, Wauwatosa, Wisconsin.

Draft Specification v01 · Generated 2026-07-01 17:26 UTC (12:26 PM CDT) · Status: Proposed, not yet adopted · License: CC BY 4.0 (recommended for publication)

Abstract

Regulatory compliance has come to the WWW. The emergence of the Experience, Expertise, Authority and Trustworthiness (E-E-A-T) metric utilized by Generative AI systems to determine who can and who cannot be trusted to refer or cite is expected to be ratified statutorily itself. Risk is especially germaine to statutory licensees. This document formalizes a preliminary concept into a versioned draft specification: the Project Page, proposed as a fourth standard page type — alongside Home, About Us, and Contact Us — present in a site's primary navigation. Its purpose is to give both human readers and generative AI systems a single, disclosed, machine-readable location where an organization's verifiable professional relationships (licensing bodies, affiliated firms, referral Projects, credentialing authorities, collaborators) are declared using Schema.org structured data, in support of E-E-A-T signaling and Answer/Generative Engine Optimization (AEO/GEO).

Background & Problem Statement

Generative AI systems synthesize answers from the open web and are vulnerable to manipulation by low-quality, marketing-driven content that has historically optimized for search-engine ranking signals rather than factual verifiability. This has produced pressure toward provable authority: content and entities that can demonstrate real-world credentials, licensure, and verifiable relationships are increasingly favored as citation sources, while unsubstantiated marketing claims are discounted or flagged as unreliable.

Three page types are already de facto conventions across the commercial web: the Home page (orientation), the About Us page (identity and history), and the Contact Us page (reachability and legitimacy). None of these three conventionally carries a disclosed, structured account of an entity's professional relationships — the network of licensing bodies, affiliated professionals, referral Projects, and collaborators that a human due-diligence reviewer would ordinarily want to see. The proposal under review argues that this is a gap, and that closing it with a fourth standard page — the Project Page — would give both human readers and AI systems a consistent, predictable location to find and verify that relationship graph.

Critique of the Preliminary Concept

The uploaded source material for this proposal consisted of a background paragraph and a set of AI-mode search-engine query links exploring the idea aloud. It did not contain an actual technical specification, so the critique below addresses the reasoning captured in those queries, not a design that was already drafted.

Risk"Linking back and forth" reads as a reciprocal-link scheme

A network of "hundreds or maybe a thousand" pages exchanging reciprocal links is exactly the pattern search engines and AI crawlers are trained to discount or penalize as link manipulation, regardless of the underlying relationships being genuine. Fix The specification below replaces raw reciprocal HTML anchor exchange with a disclosed, structured relationship declaration (JSON-LD) that states the nature of each relationship explicitly, rather than relying on the mere existence of a link as the signal.

Risk"De facto standard" is asserted, not yet earned

The proposal's framing treats adoption as close to inevitable. No page type becomes a convention because one practitioner declares it so; Home, About Us, and Contact Us became conventions through years of independent, convergent adoption across the entire web, not through a single publication. Fix This document is framed throughout as a proposed convention with an explicit adoption pathway (Governance section below), not as an already-achieved standard. Overclaiming status it doesn't yet hold would itself be an E-E-A-T liability.

RiskNo answer to the SQL-vs-static-file question

The source material raises, but does not resolve, whether a SQL database is needed to manage large numbers of Project relationships. Left unanswered, this leaves implementers to guess. Fix Addressed directly in the Scalability section below with a concrete recommendation and explicit thresholds.

RiskFragment identifiers vs. canonical URLs

Consistent with findings already identified in your own audit work (e.g., the cgcinc.net review), a Project Page that lists relationships as in-page anchors only (/Projects#firm-x) is a weaker citation surface than one where each significant relationship — or at minimum the page itself — resolves to a discrete, canonical URL. Fragment-only references are harder for a generative engine to cite unambiguously and are vulnerable to being invisible if the anchor target is removed or reordered.

Formal Specification: Project Page v01

Nomenclature & Placement

Required Page Elements

Minimum content requirements for a conforming Project Page
ElementRequirement
Disclosure statementPlain-language statement of what a "Project" means on this site and how relationships are verified, placed above the fold
Relationship typeEach entry explicitly labeled: licensing/regulatory body, referral Project, subcontractor, professional affiliation, vendor, collaborator, etc. — never left implicit
VerifiabilityEach entry links to an independent, third-party-controlled page confirming the relationship (a licensing board's public register, a Project's own site) — not solely to another page you control
Structured dataSchema.org JSON-LD per template below, embedded server-side in the initial HTML response
Reciprocity disclosureIf the relationship is mutual (both parties list each other), state that explicitly rather than leaving it implied
Last-verified dateHuman-readable date each relationship was last confirmed active

Structured Data Template

Schema.org has no native ProjectPage type. Rather than inventing an unrecognized ad hoc type (which reduces machine legibility rather than improving it), this specification composes existing, well-supported types: CollectionPage containing an ItemList of Organization/Person entities, each carrying an explicit relationship property.

{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "Projects",
  "url": "https://example.com/Projects/",
  "about": {
    "@type": "Organization",
    "name": "Example Firm LLC"
  },
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "item": {
          "@type": "GovernmentOrganization",
          "name": "Wisconsin Department of Safety and Professional Services",
          "url": "https://dsps.wi.gov/",
          "additionalType": "https://schema.org/RegulatoryAuthority",
          "sameAs": "https://dsps.wi.gov/"
        }
      },
      {
        "@type": "ListItem",
        "position": 2,
        "item": {
          "@type": "Organization",
          "name": "Referral Project Firm",
          "url": "https://Projectfirm.example.com/",
          "description": "Reciprocal referral Projectship, active since 2024",
          "sameAs": "https://Projectfirm.example.com/Projects/#example-firm-llc"
        }
      }
    ]
  },
  "dateModified": "2026-07-01"
}

Why not a custom "ProjectPage" @type?

Generative engines and structured-data validators reward vocabulary they already recognize. An unrecognized custom type is either ignored or requires the consumer to guess its meaning from the property names alone. Composing CollectionPage + ItemList + typed relationship items achieves the same disclosure using vocabulary every major consumer already parses.

Scalability: Static Relationship Graph vs. SQL Database

Direct answer to the open question in the source material:

Recommendation by scale
ScaleRecommended approachRationale
Up to a few hundred Project relationships A single git-versioned Projects.json (JSON-LD @graph) rendered server-side into the page Fully auditable change history, no query layer to secure or maintain, trivially citable, works on static hosting
Several hundred to low thousands, with filtering/search needs Static JSON-LD source of truth, optionally indexed into a lightweight database (SQLite) purely to power on-page filtering — the database is a read cache, not the canonical record Preserves git as the auditable source of truth while allowing interactive lookup
Multi-tenant / many organizations maintaining their own entries A proper relational database (PostgreSQL/MySQL) with a publish step that regenerates the static JSON-LD on change At this scale, concurrent editing and access control genuinely require a database; JSON-LD generation should remain a build step, not a runtime query, so the citable page stays static and fast

HTMX is not a scalability answer to this problem in any of the three tiers above — it addresses how a browser updates its DOM after user interaction, not how a crawler or LLM ingests the page on first load. It could reasonably be used later for an admin interface that edits Projects.json, which is a legitimate but entirely separate use case from the public-facing citation surface.

WCAG 2.2 Accessibility Requirements

Governance & Path to Adoption

Becoming an actual convention — the way Home, About Us, and Contact Us are conventions — requires independent, convergent adoption, not a single declaration. This document proposes the following realistic path rather than asserting the outcome:

  1. Publish as a versioned open specification on GitHub under an open license (CC BY 4.0 recommended), with a clear changelog, so the document can be cited, forked, and improved by others independent of any one author.
  2. Implement it first on your own properties (clintongallagher.com and client sites where appropriate) as reference implementations, each with the JSON-LD template above, so the proposal is demonstrably working code, not only a document.
  3. Publish case studies showing before/after citation behavior in generative engines where feasible, with methodology disclosed.
  4. Solicit outside review from relevant technical communities — e.g., the Schema.org community group, IndieWeb, and structured-data practitioners — where feedback can meaningfully improve or challenge the design before wider promotion.
  5. Track adoption honestly. A public "who has implemented this" list, updated over time, is stronger evidence of a real convention forming than a claim of standard status made in advance of any independent adoption.

Limitations & Open Questions

This is a proposal, not an adopted standard

Nothing in this document should be represented to clients, colleagues, or the public as an already-accepted industry standard. It is a well-reasoned, versioned proposal with a concrete reference implementation, seeking adoption.