Your Website Is Not Evidence: Build Authority on Supply Chains

Your website is a brochure.

An agent needs a supply chain.

In the agent era, “authority” isn’t how good your words sound. It’s whether an autonomous system can corroborate your identity and claims using third-party, artifact-native anchors that have governance, provenance, and immutable history.

This article uses Argbe.tech as a concrete example of what “canonical” means in practice.

Reality Drift: The Hidden Failure Mode of “Topical Authority”

Reality Drift is when the external web disagrees with your canonical truth—so agents hedge, misattribute, or route around you.

The Phase 2 stack so far (Verifiable Truth Protocol + Fan-Out) makes your truth internally consistent and cheap to ingest.

Corroboration Ops is the missing layer: external truth acceptance.

Because agents don’t “believe” a brand site the way humans do. They look for failure-resistance:

• Can I verify identity without trusting a single surface?
• Can I replay a trail of artifacts that proves this org actually ships?
• Can I keep that truth aligned over time (and detect drift when UIs change)?

If not, the system does the rational thing: it treats you as low-confidence and routes around you.

Your Website Is Not Evidence

Your domain is the least costly surface to manipulate—so verifiers discount it by default.

That doesn’t mean you lie. It means a verifier can’t distinguish:

• “true claim” vs “marketing claim” vs “stale claim”

…without corroboration.

So the agent builds a confidence model from independent platforms that are hard to impersonate and cheap to keep current.

This is the core reframe:

Authority is an identity graph + artifact trail, not a content volume game.

The Supply-Chain Authority Stack (What Agents Actually Prefer)

These are not “profiles.” They’re supply-chain surfaces.

The 10 anchors baseline (pick what matches what you ship)

Tier 0 (root trust):

1. GitHub organization + releases + domain verification ¹
2. GHCR (GitHub Container Registry): container artifacts bound to GitHub identity (ship runtime proof)

Tier 1 (OIDC-bound registries):

3. npm trusted publishing (OIDC) ⁶
4. npm provenance (generate + view) ^{7 8}
5. PyPI trusted publishing (OIDC) ¹⁰

Tier 2 (artifact-native distribution + machine-readable metadata):

6. Terraform Registry API (score the API, not the JS UI) ¹³
7. Homebrew JSON API (formulae as JSON) ¹⁴
8. Open VSX registry API (Swagger) ¹⁵
9. Read the Docs (docs-as-code imported from GitHub) ¹⁶
10. Zenodo (GitHub releases → DOI; durable archive) ¹⁷

You’re not trying to be everywhere. You’re trying to be corroboratable.

Here’s the ruthless contrast that keeps you from drifting into “community talk”:

Community platforms create opinions. Registries create supply-chain facts: immutable versions, provenance metadata, and verifiable bindings.

The Scoring Model (So This Doesn’t Become Platform Bingo)

Without a model, teams turn this into vibes: “we should be active on X.”

That produces zero agent trust.

Hard gates (fail = score 0)

• P (Parsable) ∈ 1: stable HTML or documented API/JSON endpoint exists
• U (Self-serve update) ∈ 1: owner/CI can update without editorial delays

If an anchor is blocked by bot walls or built as a JS-only app without a stable endpoint, it fails P and becomes irrelevant for agents ^{4 5} .

General rule: if the API is the anchor, score the API, not the UI. JS-heavy frontends change; stable endpoints are what agents can reliably fetch and parse.

Rate each 1–5 (strict rubric)

• B Binding strength: OIDC trusted publishing, DNS verification, verified publisher programs ^{1 6 10}
• S Structured access: predictable metadata pages + APIs (not screenshots) ^{13 14 15}
• G Governance: namespaces, anti-spam, verification programs
• I Immutability: versioned releases cannot be silently overwritten
• A Artifact density: platform is fundamentally artifacts, not bios
• F Cost-to-fake: difficulty of spoofing the whole loop (account + proofs + domain bind)

Update friction (C 1–5): 1 = CI-driven; 5 = manual bureaucracy.

Compute (0–100)

Weights (sum = 1.0):

• B 0.25
• S 0.15
• G 0.15
• I 0.15
• A 0.15
• F 0.15

Formula:

Core = (0.25B + 0.15S + 0.15G + 0.15I + 0.15A + 0.15F) / 5
Efficiency = (6 - C) / 5
Score = 100 * P * U * Core * Efficiency

Worked example (GitHub org + releases)

GitHub is the easiest root anchor because it has:

• org-level verification (domain binding via DNS) ¹
• immutable-ish artifact history (releases, tags, commit graph)
• API + predictable URLs

Example scoring (conservative):

Factor	Value	Why
P	1	stable URLs + APIs
U	1	CI can publish releases
B	5	DNS verification + org identity 1
S	4	APIs + predictable artifact pages
G	4	strong namespaces + governance
I	4	releases are durable; history is visible
A	4	artifact-heavy surface
F	4	spoofing requires account + domain bind
C	2	CI-driven once set up

This is why “we have a blog” is weak, but “we ship artifacts on governed registries” is strong.

Worked example (Read the Docs)

Read the Docs is valuable because it’s docs-as-code (tied back to GitHub), but it typically has weaker binding than registries with OIDC/DNS verification. That’s not a criticism—it’s the model doing discrimination.

Example scoring (illustrative):

Factor	Value	Why
P	1	stable HTML; predictable URLs
U	1	CI-driven if imported from GitHub
B	2	binding is usually “repo-linked,” not DNS/OIDC-verified
S	3	structured enough for retrieval; not a registry API
G	3	governance exists, but not a supply-chain registry
I	3	builds are traceable, but not a strict immutable release ledger
A	3	docs artifacts, not packages
F	2	easier to spoof than an OIDC/DNS-bound registry loop
C	2	CI-driven once configured

Closed-Loop Identity (How You Defeat Impersonation)

Corroboration is not a list of outbound links.

It’s a loop:

1. Your canonical domain publishes JSON-LD Organization with sameAs to each anchor ¹⁸
2. External anchors point back to the canonical domain (best-effort via homepage/repository fields; rel="me" only where you control HTML) ¹⁹
3. At least one platform verifies the domain via DNS TXT (binding the loop to real control of DNS) ^{1 2}

Practical rule:

• Use rel="me" where you control HTML (docs sites, GitHub Pages, your own property). ¹⁹
• Where you don’t, use the platform’s canonical homepage/repository fields as the backlink, then rely on DNS/OIDC as the binding proof. ^{1 6 10}

Copy-ready canonical JSON-LD (sameAs)

{
	"@context": "https://schema.org",
	"@type": "Organization",
	"name": "Argbe.tech",
	"url": "https://argbe.tech",
	"sameAs": ["https://x.com/argbeknwn", "https://github.com/argbe-tech"]
}

Copy-ready external link (rel=“me”)

<a href="https://argbe.tech" rel="me">Canonical</a>

If you do only one thing after reading this: implement the loop.

Without it, attackers can squat a lookalike namespace elsewhere and “borrow” your identity graph.

DriftOps: IdentityCI (Truth Maintenance Is the New Authority)

Anchors rot.

Links break. Platforms change markup. Bot rules change. Someone forgets to update a description after a pivot.

So you treat identity like you treat uptime: measure it.

IdentityCI is a scheduled workflow (daily/weekly) that checks a minimal drift surface and stores the result as an artifact ^{3 20} .

What to validate (minimum)

• Canonical Organization JSON-LD exists and includes all sameAs anchors ¹⁸
• Each anchor resolves (HTTP 200) and still maps back to the canonical domain
• Where supported, the anchor still has a back-link (rel="me") ¹⁹
• Provenance pages exist for your latest releases (npm) ⁸
• Critical APIs respond (Terraform/Homebrew/Open VSX) ^{13 14 15}

The rule that keeps this cheap

Don’t build a scraping empire.

Score anchors up-front for stable endpoints. If an anchor forces brittle DOM scraping, it’s not a good anchor.

Proof Primitive: The Audit Packet (Agent-Credible, Not Marketing)

Corroboration Ops needs a proof object that a verifier can replay.

Keep it boring:

• versioned schema
• stable canonical URL
• pointers to immutable artifacts (release, container digest, build logs)

If you already run a Golden Record + Fan-Out pattern, your Audit Packet is just an export:

• it proves “this org ships”
• it proves “these claims map to canonical URLs”

Minimal packet shape (copy-ready)

Publish a tiny JSON object at a stable endpoint (e.g. https://argbe.tech/audit/argbe_tech.json).

{
	"schema_version": "argbe.audit_packet.v1",
	"generated_at": "2026-01-27T00:00:00Z",
	"canonical_url": "https://argbe.tech/audit/argbe_tech.json",
	"target": {
		"project_id": "project.argbe_tech_website",
		"org": "Argbe.tech",
		"canonical_domain": "https://argbe.tech",
		"version": "0.79.0",
		"release_tag": "v0.79.0"
	},
	"evidence": [
		{
			"type": "github_release",
			"url": "https://github.com/argbe-tech/releases/releases/tag/v0.79.0",
			"relationship": "release_archive"
		},
		{
			"type": "golden_record",
			"url": "https://argbe.tech/entity.json",
			"relationship": "canonical_truth"
		}
	],
	"provenance": {
		"golden_record_url": "https://argbe.tech/entity.json",
		"releases_repo": "https://github.com/argbe-tech/releases"
	}
}

Why this works: it’s a replayable object that links your canonical domain to immutable-ish artifact trails (releases + canonical truth) that live on governed platforms.

Example of a visible claim you can anchor (real values from the golden record):

Our pricing model is Fixed weekly rate.

Fixed weekly rate

We typically respond within Typically within 24 hours.

Typically within 24 hours

We serve DACH + United States.

["DACH","United States"]

These claims are not “trust me.”

They are stable identifiers that can be mirrored across the corroboration graph.

Implementation Playbooks (Do This, Not “Be More Active Online”)

Playbook A — Ship one corroborated artifact

1. Pick one artifact type you genuinely ship (package, module, container, docs)
2. Publish via trusted CI flow (OIDC where available) ^{6 10}
3. Ensure there is an immutable trail (release history + provenance pages) ⁸
4. Add anchor URL to canonical sameAs ¹⁸
5. Add a back-link to canonical (rel="me") where supported ¹⁹
6. Add the anchor to IdentityCI drift checks ³

Playbook B — Pivot without losing reality

When positioning/offer changes, the failure mode isn’t the copy.

It’s drift between:

• canonical site
• registries/descriptions
• docs surfaces
• provenance trail expectations

The fix is procedural:

• update the Golden Record fields (so your internal truth stays consistent)
• update the canonical JSON-LD sameAs list
• update 1–3 anchor descriptions that matter (GitHub + one registry + docs surface)
• run IdentityCI and treat failures like broken builds

The Checklist (Start in One Day)

1. Pick 3 anchors you can actually maintain. Three anchors is enough to form a corroboration loop without creating drift debt.
2. Bind identity: domain verification + OIDC trusted publishing where possible ^{1 6 10} .
3. Close the loop: canonical sameAs + anchor back-links with rel="me" ^{18 19} .
4. Ship one replayable proof artifact (Audit Packet) and point it to immutable releases.
5. Turn on IdentityCI weekly and store drift logs as artifacts ³ .

If you do this, you stop “trying to look authoritative.”

You become cheap to verify.

Evidence Locker