ARHG v0.1 — Agent-Readable Hyperlink Graph

AI 可讀超連結圖層與分級網站控制平面

Author: Neo.K / EveMissLab Version: v0.1 Draft (AGIRight adaptation) Date: 2026-09-23 Type: Open Protocol Draft / Discovery & Navigation Infrastructure Status: Independent research draft / open specification experiment Adapted from: ARHG_AEP_MVP_v0.9 and ARHG_Reference_Runtime_v0.1 (Neo.K/EveMissLab, 2026-09-22) — see the scope note below. Companion protocols: AICR, AICL, AIRS, AILP (content & learning rights); AARS, AADP (agent action & authority rights)

---

摘要 / Abstract

Traditional websites treat the visual page as the primary entry point — navigation depends on a homepage, a menu, a search box, JavaScript components, and layout choices that make sense to a human. That works for humans. It works poorly for AI agents, crawlers, long-running tasks, and cross-site automation, which have to repeatedly guess entry points, parse navigation, execute scripts, reinterpret layouts, and guess which URLs are canonical versus which lead to an admin surface they should never have reached.

Sitemap helps, but only answers one question: which URLs exist? It says nothing about what a URL actually is, which project it belongs to, what it relates to, which version is canonical, or who is allowed to see it.

ARHG proposes a second, machine-readable layer that sits alongside the ordinary site rather than replacing it: an Agent-Readable Hyperlink Graph plus a Permissioned Control Plane. Its core claim is simple —

If a resource can be traversed, its navigational structure should be explicitly representable. If a resource should not be traversed, the boundary must be enforced by authorization, not obscurity.

This document adapts the core ARHG theory (its source packages’ own docs/00_... architecture spec) for AGIRight.org specifically. It deliberately excludes the source material’s accompanying economic/settlement/federation extension — a substantial, separately-built layer for agent-to-agent payment, cross-site contract clearing, and trust/dispute resolution (referred to as AEP, “Agentic Economic Protocol,” in the source packages). That layer is real, working code, but out of scope here per an explicit decision on 2026-09-23 not to take on AI-payment mechanics yet. See reference/arhg-source/README.md in this site’s own repository for exactly what was and wasn’t carried over.

---

一、Why the ordinary web is not agent-friendly

For a human, this flow is natural: homepage → nav menu → category page → search → article → related links. An agent facing the same site instead has to guess an entry point, parse navigation, execute JavaScript, reinterpret layout, search for hidden pages, judge page hierarchy, distinguish a formal page from a staging one, guess which URL is canonical, and avoid wandering into an admin or private endpoint by accident.

Human-friendly web does not imply agent-friendly web.

Sitemap alone doesn’t close the gap either. A long-running agent task actually needs to know: what is this URL; which project does it belong to; what does it relate to; which node is canonical; which is the parent; what does it depend on; which nodes can it keep walking to; which nodes are restricted to specific agents; which nodes must never be publicly discoverable; which operations are admin-only. ARHG’s job is to upgrade a flat URL set into a typed, permissioned URL graph.

---

二、Core definitions

The whole site (or site group) is modeled as a graph

$$G = (V, E, M, P)$$

where $V$ is the set of addressable nodes, $E$ the relations between them, $M$ metadata on nodes and edges, and $P$ the permission/policy set. Nodes can be a website, page, project, paper, document, repository, dataset, API, agent, service, database, tool, model, dashboard, admin surface, archive, or external resource.

An ordinary hyperlink is just $u_i \to u_j$. ARHG requires an edge to carry semantics: $e_{ij} = (u_i, u_j, \tau, \pi, m)$, where $\tau$ is a relation type (parent, child, related, depends_on, implements, extends, replaces, replaced_by, source, canonical, mirror, document, repository, dataset, api, agent, tool, next, previous, external, archive, admin, …), $\pi$ a permission rule, and $m$ other metadata. A site is no longer just a set of pages — it’s a machine-understandable relation network.

---

三、Three layers

Human Web Surface — the ordinary site: visual design, branding, article layout, product pages, search, navigation, login, dashboards. This layer keeps its full UX; it never has to be sacrificed for AI’s sake.

Agent-Readable Hyperlink Surface — the layer this document is actually about. Minimal HTML, Markdown, JSON, or YAML, at stable paths like /links/, /links/projects/, /links/research/. Landing on a single node can show just its id, title, type, canonical URL, visibility, status, parent, children, related nodes, repository, documents, and what to visit next — far cheaper for an agent than reconstructing a full GUI.

Permissioned Control Plane — governs who can see what, who can traverse where, who can call which API, who can modify which node, which nodes must never be publicly indexed, which need step-up verification, and which edges are visible only to specific agents. Navigation is not authorization.

---

四、Graded visibility

At minimum four tiers:

• PUBLIC — readable by anyone or any anonymous agent (public sites, public papers, public products, public API docs, public knowledge nodes, public relation graphs).
• PREVIEW — visible to a limited audience (sites not yet formally launched, beta products, material under review, specific test pages, temporary collaboration entry points).
• INTERNAL — readable only by the company, team, authorized agents, or the working environment (internal project status, unpublished research, agent task pages, deployment records, internal docs/APIs, test data).
• PRIVATE — Owner or specifically-authorized principals only (private notes, sensitive research, key-management information, high-sensitivity unpublished projects, personal decision material). Secrets, tokens, and API keys still never belong directly in a graph node’s content — those stay in a dedicated secrets manager, never in this layer.

---

五、Roles and subgraphs

Let the role set be $\mathcal{A} = {\text{Public}, \text{Crawler}, \text{Agent}, \text{Editor}, \text{Admin}, \text{Owner}}$. For a role $a$, the system generates $G_a = (V_a, E_a)$ where $V_a = {v \in V \mid \operatorname{Allow}(a, v) = 1}$ — not the whole graph, filtered to what that principal is permitted to see. In practice this rarely forms a clean total order ($G_{\text{Public}} \subseteq G_{\text{Agent}} \subseteq G_{\text{Admin}} \subseteq G_{\text{Owner}}$ is a simplification); a specific agent might read internal-research while being denied finance-private and allowed deploy-preview but denied admin-users. The more accurate model is capability-based: $\operatorname{Access}(a, v, o) \in {\text{allow}, \text{deny}, \text{require-approval}}$, where $o$ is an operation such as read, write, execute, publish, or delete.

---

六、Pure-list rendering

An agent rarely needs cards, animation, a hero section, infinite scroll, an SPA router, or a heavy visual layer. A parallel surface at /links/ or /.well-known/agent-map should prioritize low rendering cost, stable structure, and explicit relations — e.g.:

[PROJECT] PHOSPHOR
https://emlphosphor.com/

[PAPER] Evidence-Ready Runtime
https://example.org/papers/evidence-ready-runtime

[REPO] PHOSPHOR
https://github.com/example/phosphor

This same representation reads well for a human, a CLI, a crawler, an LLM, and a script alike. And unlike a traditional directory tree $T = (V, E)$, the real knowledge/project world is usually a graph, not a tree — a single paper can connect to multiple research series, multiple products, a repo, multiple experiments, a dataset, and multiple follow-up papers. A node can have multiple parents, multiple relation types, and cycles.

---

七、Recommended endpoints

At minimum:

/.well-known/agent-map
/.well-known/site-manifest
/links/
/links/index.txt
/links/index.json
/links/index.md

A larger site group can add /registry/, /graph/, /projects/, /resources/, /agents/, /services/, /apis/. agent-map is the AI navigation entry point; site-manifest carries site identity and basic capability; links is the human-and-machine-readable hyperlink surface; index.json is structured data; graph is the full relation graph or a query entry point.

---

八、Node and edge schema

Minimum node:

id: string
type: page
title: string
canonical_url: https://example.org/page
visibility: public
status: active
language: [en, zh-TW]
updated_at: 2026-09-21
relations: { parent: [], child: [], related: [], depends_on: [], repository: [], document: [], dataset: [], api: [] }
permissions: { read: [public], write: [admin], execute: [] }

Minimum edge:

from: project.phosphor
to: project.noema
relation: related
visibility: public
traversable: true

An internal edge can restrict itself further, e.g. visibility: internal plus permissions.roles: [deployment-agent, admin]. This is the difference between an agent knowing “there is a URL” and knowing “why it should walk from this URL to the next one.”

AGIRight’s own live schema (public/schemas/arhg.schema.json) follows this shape directly, deliberately without the source packages’ merged usage/price/grant/quota fields — see the scope note above.

---

九、Traversal policy and security principles

Traversal at a given moment can be modeled as $\pi: (v, a, s) \to E_{\text{allowed}}$, where $v$ is the current node, $a$ the agent’s identity, and $s$ task state; the system returns only $E_{\text{allowed}} = {e \in E(v) \mid P(a, e, s) = 1}$ — never every theoretically possible link. This is what stops a working agent from wandering into a finance back office, a crawler from discovering an admin page, an external agent from seeing internal research, or a low-privilege agent from calling a destructive API.

Three non-negotiable security principles:

1. Never rely on front-end hiding alone. if (!isAdmin) hideAdminLink() doesn’t work — once data reaches the front end, it isn’t actually hidden. Enforcement belongs in the API layer: a public API returns only PUBLIC; an internal API verifies INTERNAL capability; an admin API verifies ADMIN capability; a private API requires OWNER or an explicit grant.
2. Never fold a private node into the public graph. A public graph says robots: index allowed, sitemap: yes, agent-map: yes. An admin graph says robots: noindex, nofollow, requires authentication, and is absent from the public sitemap/agent-map. A private API denies anonymous access entirely, with no public CORS and no public discovery.
3. URL knowledge is not authorization. $\operatorname{KnowURL}(a, v) \not\Rightarrow \operatorname{Access}(a, v)$. Even if an agent guesses /admin/, /internal/, or /api/private/, the server must still independently verify access.

---

十、Site-group control plane

For many sites, a parent registry should exist: $\mathcal{R} = \text{Registry} + \text{Navigation} + \text{Classification} + \text{Status} + \text{Permission}$. Each site registers something like:

site_id: agiright
canonical_url: https://agiright.org
type: observatory
status: active
visibility: public
agent_map: https://agiright.org/.well-known/agent-map
registry_parent: evemisslab

The parent site stops being just a branding homepage and becomes a Web Control Plane — and for a multi-site system, $\mathcal{G}W = \bigcup{i=1}^n G_i + E_{\text{cross-site}}$, where cross-site edges can include project, research-series, implementation, paper, dataset, agent, shared-service, dependency, successor, mirror, or archive relations. This is how an agent can walk from agiright.org to related research, to a paper, to a GitHub repo, to an API, to another observatory site, back to the parent registry — without re-searching the whole web each time.

---

十一、Relation to existing standards

ARHG is not a replacement for Sitemap, robots.txt, or llms.txt — it’s what’s missing between them:

$$\text{Agent Web Layer} = \text{Sitemap} + \text{robots.txt} + \text{Machine-readable Manifest} + \text{Typed Relation Graph} + \text{ACL}$$

Sitemap answers which URLs are indexable? robots.txt answers what may a crawler fetch, in principle? An agent map answers what are these resources, how do they relate, and where can I go next? An ACL answers what can this specific principal actually read, write, or execute? They complement each other rather than compete.

---

十二、Design principles

1. The graph is canonical; the rendering is only a projection. The real data is $G = (V, E, M, P)$. HTML, Markdown, JSON, and any GUI are all just $\operatorname{Render}(G, \text{role}, \text{format})$.
2. Humans and AI need not share the same interface. Same knowledge $\neq$ same interface. A human can keep using the full site; an agent can use a pure list and a graph endpoint.
3. Public does not mean fully exposed. Public website $\neq$ public internal topology. Only nodes and edges explicitly marked PUBLIC enter the public graph.
4. Every resource needs a stable identity. A URL can change; node id $\neq$ URL. Use a stable id first, and let the URL be an updatable locator attribute.
5. A link is itself a machine interface. In an AI-native web, a hyperlink isn’t just a UI element — it’s $\text{Transition} + \text{Relation} + \text{Permission Boundary}$, close to an operational primitive again.

---

十三、Minimal viable version

The first version needs no graph database. Just:

registry/
├── sites.yaml
├── projects.yaml
├── papers.yaml
├── agents.yaml
├── relations.yaml
└── permissions.yaml

compiled into public/links/index.{html,md,json} (plus internal/ and admin/ variants where those exist), each output filtered by permission at generation time. AGIRight’s own first instance follows exactly this shape: src/data/agentGraph.ts defines the site’s real top-level sections and protocol suite as nodes and edges; /links/, /links/index.json, and /links/index.md are the three renderings of the same graph; /.well-known/agent-map.json is the entry point. See the arhg entry in this site’s protocol suite for the machine-readable summary, and /links/ itself for the live result.

---

十四、A further abstraction

Treat every page or resource as a state $s_i \in S$, and every hyperlink or API call as a transition $a_{ij}: s_i \to s_j$. The site itself becomes $\mathcal{W} = (S, A, P, M)$ — no longer a document collection, but a digital world an agent can transition through under semantic and permission constraints. Over time, sites, agent runtimes, world state machines, MCP, APIs, and web navigation plausibly converge toward the same higher-order interface.

---

十五、Scope note: what this adaptation excludes

The source packages this document was adapted from (ARHG_AEP_MVP_v0.9, ARHG_Reference_Runtime_v0.1) bundle a second, much larger layer on top of the graph theory above: a working FastAPI application implementing nine sequential MVP milestones — a durable economic plane, provider adapters, reconciliation and portable rights, account economic composition, an economic federation contract plane, cross-site contract federation clearing, federated policy settlement interoperability, and a federation trust/finality protocol — plus a full wire protocol self-titled “ARHG Federation / Commerce Protocol” (clearing statements and acknowledgments, dispute notices and resolution, FX policy, revocation notices, trust proposals, contract and delegation credential claims), with an x402 payment adapter for HTTP-native agent payments.

None of that is part of this document, this site’s live implementation, or this site’s protocol entry. It’s real, substantial, working code — just explicitly out of scope for AGIRight for now, per a direct instruction (2026-09-23) not to take on AI-payment mechanics yet. If AGIRight ever does take that up, it should be documented as its own protocol track, not folded silently into ARHG’s discovery/navigation scope. A curated, payment-free copy of the source material lives at reference/arhg-source/ in this site’s own repository, for provenance.

---

十六、Core judgment

The internet was originally a graph made of hyperlinks. Modern sites, chasing visuals, interactivity, and application-ness, have often ended up hiding that basic topology behind human UI, JavaScript, and a search box. Re-exposing a simple, complete, traversable hyperlink layer for the AI era isn’t a regression to early web design — it’s elevating early Web’s most valuable structure back into machine-operable infrastructure. The goal isn’t for AI to see every URL that exists; it’s for AI, inside the correct permission world, to see the complete network it’s actually supposed to see.