Web4: An Agentic, Verifiable Internet Architecture and the Project Orion Reference System
draft-reilly-web4-orion-00

Internet Engineering Task Force                            L. Reilly
Internet-Draft                                            Independent
Intended status: Informational                          July 24, 2026
Expires: January 25, 2027

           Web4: An Agentic, Verifiable Internet Architecture
                and the Project Orion Reference System
                      draft-reilly-web4-orion-00

Abstract

   This document defines Web4, an architectural model for an agentic,
   cryptographically verifiable Internet in which autonomous AI agents
   operate as first-class participants alongside humans, and every
   published artifact carries independently checkable proof of origin,
   integrity, and time.  Web4 is realized through the Reilly Protocol
   Suite, a set of eighteen active IETF Internet-Drafts spanning
   permanence, integrity, agent orchestration, defense, and human
   epistemic autonomy.  This document also specifies Project Orion,
   the live reference implementation that unifies the full suite
   behind autonomous agents on both backend and frontend, verified
   against three independent Internet-Draft distribution points, and
   operating publicly at
   https://project-orion-production.up.railway.app/.  A step-by-step
   implementation guide is provided.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current
   Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   This Internet-Draft will expire on January 25, 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  The Web4 Architecture Model
     3.1.  Layer 1: Permanence
     3.2.  Layer 2: Integrity
     3.3.  Layer 3: Agentic Operation
     3.4.  Layer 4: Defense
     3.5.  Layer 5: Human Sovereignty
   4.  Utilization of the Reilly Protocol Suite
   5.  Project Orion Reference Implementation
     5.1.  Draft Sources and Triple Verification
     5.2.  Autonomous Agent Architecture
     5.3.  Human-Oversight and Autonomous Modes
   6.  Implementation Guide
     6.1.  Phase 1: Source Aggregation
     6.2.  Phase 2: Triple-Mirror Verification
     6.3.  Phase 3: Permanence Anchoring
     6.4.  Phase 4: Agent Backend
     6.5.  Phase 5: Agentic Frontend
     6.6.  Phase 6: Oversight Toggle
     6.7.  Phase 7: Deployment and Continuous Operation
   7.  Security Considerations
   8.  IANA Considerations
   9.  Informative References
   Author's Address

1.  Introduction

   Web 1.0 delivered readable documents; Web 2.0 delivered writable,
   social platforms; Web 3.0 introduced decentralized ownership.
   None of these generations answers two questions now central to an
   Internet populated by AI agents: (1) can any artifact's origin,
   integrity, and timestamp be verified without trusting its host,
   and (2) can autonomous agents operate web systems continuously
   while humans retain meaningful oversight and epistemic autonomy?

   Web4 is defined here as the architectural generation that answers
   both.  Its two invariants are:

   o  Verifiability by default: every artifact is anchored via
      Dual-Layer Digital Permanence (Bitcoin blockchain timestamping
      plus DOI archival), and served content is cross-checked against
      multiple independent distribution points.

   o  Agency with sovereignty: autonomous agents maintain, heal, and
      present the system under Machine-Web Symbiosis, while humans
      retain Cognitive Sovereignty over agent-curated content and a
      switchable human-oversight mode.

   The Reilly Protocol Suite supplies the protocol substrate; Project
   Orion (Section 5) is the operating proof.

2.  Terminology

   Web4:  The agentic, verifiable Internet architecture defined in
      this document.

   Project Orion:  The unified reference implementation of Web4,
      deployed at project-orion-production.up.railway.app, covering
      all eighteen active drafts of the Reilly Protocol Suite with
      fully autonomous agents on backend and frontend.

   Dual-Layer Digital Permanence:  The methodology of anchoring an
      artifact simultaneously to the Bitcoin blockchain (via
      OpenTimestamps) and to a persistent DOI archive (Zenodo),
      optionally supplemented by IPFS content addressing.

   Machine-Web Symbiosis (MWS):  The operating relationship in which
      autonomous agents and web infrastructure co-maintain a system,
      extending Licklider's 1960 man-computer symbiosis framing
      [MWS].

   Cognitive Sovereignty:  The property that humans retain epistemic
      autonomy over agent-curated content, supported by the Curation
      Disclosure Record (CDR) and Sovereignty Fallback [COGSOV].

   Triple Verification:  Cross-checking each Internet-Draft against
      three independent distribution points: the IETF archive, the
      FUNET mirror (nic.funet.fi), and the OTEnet mirror
      (ftp.otenet.gr).

3.  The Web4 Architecture Model

   Web4 is organized into five layers.  Each layer is normatively
   realized by one or more drafts of the suite (Section 4).

3.1.  Layer 1: Permanence

   All artifacts are anchored using Dual-Layer Digital Permanence.
   An artifact without a blockchain timestamp and archival DOI is not
   Web4-compliant.  Realized by the REM Protocol [REM] and applied
   uniformly across the suite.

3.2.  Layer 2: Integrity

   Domain-specific integrity assurances for content and institutions:
   web content proof (WebProof), banking integrity (RBIP), government
   integrity (RGIP), and ledger/token integrity (RLT Genesis,
   SkyLedger).

3.3.  Layer 3: Agentic Operation

   Autonomous agents perform monitoring, compliance, evaluation, and
   self-healing: PLPES (Protocol Layer Prompt Engineering), CTS,
   AIMED and AIMED-EVAL, UAEMF, and RMRP.  MWS defines the governing
   symbiosis model.

3.4.  Layer 4: Defense

   Resilience and moving-target defense: RRP (resilience), RSP
   (sentinel/AI integrity), and HDRP [HDRP], whose hypercube shard
   topology with rotation-based moving target defense protects data
   at rest against static-target attacks.

3.5.  Layer 5: Human Sovereignty

   Cognitive Sovereignty [COGSOV] governs how agent-curated output is
   disclosed to humans via the CDR, and guarantees a Sovereignty
   Fallback to non-curated sources.  Project Looking Glass [LG]
   integrates all five layers into a single self-healing deployment
   pattern.

4.  Utilization of the Reilly Protocol Suite

   The following table maps the eighteen active drafts to Web4
   functions.

   +---------------------+--------+----------------------------------+
   | Draft / Protocol    | Layer  | Web4 Function                    |
   +---------------------+--------+----------------------------------+
   | REM Protocol        | 1      | Permanence anchoring; REMID      |
   |                     |        | verification records             |
   | WebProof            | 2      | Verifiable web content           |
   | RBIP                | 2      | Banking integrity                |
   | RGIP                | 2      | Government integrity             |
   | RLT Genesis         | 2      | Token/ledger genesis integrity   |
   | SkyLedger           | 2      | Distributed ledger services      |
   | PLPES               | 3      | Protocol-layer prompt            |
   |                     |        | engineering; compliance engine   |
   | CTS                 | 3      | Trust/compliance services        |
   | AIMED               | 3      | AI model evaluation/description  |
   | AIMED-EVAL          | 3      | Evaluation harness               |
   | UAEMF               | 3      | Unified agent evaluation and     |
   |                     |        | management framework             |
   | RMRP                | 3      | Monitoring and reporting         |
   | MWS                 | 3      | Machine-Web Symbiosis model      |
   | RRP                 | 4      | Resilience                       |
   | RSP                 | 4      | Sentinel / AI integrity          |
   | HDRP                | 4      | Hypercube rotation defense       |
   | Cognitive           | 5      | CDR disclosure; Sovereignty      |
   |   Sovereignty       |        | Fallback                         |
   | Looking Glass       | 1-5    | Integrative self-healing pattern |
   +---------------------+--------+----------------------------------+

   Live systems demonstrating suite utilization include the REM
   Protocol 14-agent autonomous pipeline
   (rem-protocol-agent-production.up.railway.app) and the HDRP site
   (hdrp-hypercube-site-production.up.railway.app).

5.  Project Orion Reference Implementation

   Project Orion is publicly deployed at:

      https://project-orion-production.up.railway.app/

   The application ("Project Orion -- The Reilly Protocol Suite")
   renders the eighteen Internet-Drafts as a living constellation:
   each draft is a selectable star exposing its status, brief,
   permanence verification, and source links.  Companion panels
   include the Agent Constellation (live agent state), Pending
   Approvals (oversight-mode action queue), Mission Log, and Suite
   Insight (a cartographer agent mapping the dependency graph across
   drafts).

5.1.  Draft Sources and Triple Verification

   Project Orion aggregates the suite from the author's IETF
   Datatracker author profiles and performs Triple Verification of
   each draft against:

   1.  The IETF Internet-Drafts archive (www.ietf.org/archive/id/)
   2.  The FUNET mirror (nic.funet.fi)
   3.  The OTEnet mirror (ftp.otenet.gr, Greece)

   A draft is presented as verified only when all reachable
   distribution points agree.  At initial deployment (July 23, 2026)
   Project Orion confirmed 18 of 18 drafts live on the Datatracker.

5.2.  Autonomous Agent Architecture

   Agents operate on both tiers:

   o  Backend agents: source polling, Triple Verification, permanence
      checks (OpenTimestamps proofs, Zenodo DOIs), health monitoring,
      and self-healing per the Looking Glass pattern.

   o  Frontend agents: presentation, summarization, and navigation of
      the suite for human visitors, with curation disclosed via CDR
      per Cognitive Sovereignty.

5.3.  Human-Oversight and Autonomous Modes

   The system exposes a mode toggle:

   o  Autonomous mode: agents act on findings (re-verification,
      content refresh, healing) without human approval.

   o  Human-oversight mode: agents propose actions; a human operator
      approves or rejects via the Pending Approvals queue.  This is
      the Web4 embodiment of the Sovereignty Fallback at the
      operations level.

   The HUMAN OVERSIGHT / AUTONOMOUS toggle is exposed directly in the
   deployed interface, and all agent activity is surfaced in the
   Mission Log.

6.  Implementation Guide

   The following seven phases reproduce a Project Orion class Web4
   deployment.

6.1.  Phase 1: Source Aggregation

   1.  Enumerate the target draft set from the author's Datatracker
       profile(s).
   2.  Fetch canonical text from the IETF archive
       (https://www.ietf.org/archive/id/<draft-name>-<rev>.txt).
   3.  Store draft name, revision, and SHA-256 digest of each file.

6.2.  Phase 2: Triple-Mirror Verification

   1.  Fetch the same draft from the FUNET mirror and the OTEnet
       mirror.
   2.  Compare digests across all three sources.
   3.  Mark VERIFIED on full agreement; mark DEGRADED (with the
       agreeing subset) if a mirror is unreachable; mark FAILED and
       quarantine on digest mismatch.
   4.  Re-run on a fixed interval and on any upstream change event.

6.3.  Phase 3: Permanence Anchoring

   For each verified artifact:

   1.  Create an OpenTimestamps proof anchoring its digest to the
       Bitcoin blockchain.
   2.  Deposit the artifact and metadata to Zenodo, obtaining a DOI.
   3.  Optionally pin to IPFS for content-addressed retrieval.
   4.  Record the resulting REMID verification record per the REM
       Protocol.

6.4.  Phase 4: Agent Backend

   1.  Implement agents as independent workers: fetcher, verifier,
       permanence auditor, health monitor, healer, reporter.
   2.  Coordinate via a shared state store; every agent action is
       logged with timestamp and rationale.
   3.  Apply UAEMF/RMRP monitoring so agent behavior is itself
       evaluated and reported.

6.5.  Phase 5: Agentic Frontend

   1.  Serve the suite as a navigable application; frontend agents
       generate summaries and answer visitor queries.
   2.  Attach a Curation Disclosure Record to agent-generated
       presentation, identifying source drafts and transformations.
   3.  Always provide a Sovereignty Fallback link to the raw,
       verified draft text.

6.6.  Phase 6: Oversight Toggle

   1.  Implement a global mode flag (AUTONOMOUS / OVERSIGHT).
   2.  In OVERSIGHT, agent-proposed actions enter an approval queue
       with human accept/reject; in AUTONOMOUS, actions execute and
       are reported after the fact.
   3.  Mode changes are themselves logged and permanence-anchored.

6.7.  Phase 7: Deployment and Continuous Operation

   1.  Publish the repository to GitHub; deploy via Railway (or an
       equivalent PaaS) with automatic redeploy on push.
   2.  Confirm end-to-end status: all drafts VERIFIED, permanence
       records present, agents reporting healthy.
   3.  Operate continuously: scheduled re-verification, self-healing
       on failure per the Looking Glass pattern, and periodic
       permanence audits.

7.  Security Considerations

   Triple Verification reduces reliance on any single distribution
   point but assumes mirror independence; operators SHOULD monitor
   mirror provenance.  Blockchain timestamps prove existence-by-time,
   not authorship; authorship claims rest on the archival (DOI)
   layer and IETF submission records.  Autonomous agents acting on
   external content are exposed to prompt-injection style inputs;
   frontend agents MUST treat fetched content as data, and the
   OVERSIGHT mode provides a containment control.  Data-at-rest
   protections SHOULD apply HDRP rotation-based moving target
   defense.  Availability of third-party services (mirrors, Zenodo,
   IPFS gateways, PaaS) is outside the operator's control; the
   DEGRADED verification state exists for this reason.

8.  IANA Considerations

   This document has no IANA actions.

9.  Informative References

   [REM]      Reilly, L., "REM Protocol", draft-reilly-rem-protocol,
              September 2025.

   [MWS]      Reilly, L., "Machine-Web Symbiosis (MWS)",
              draft-reilly-mws-00, 2026,
              <https://datatracker.ietf.org/doc/draft-reilly-mws/>.

   [COGSOV]   Reilly, L., "Cognitive Sovereignty",
              draft-reilly-cogsov-00, July 2026,
              <https://www.ietf.org/archive/id/
              draft-reilly-cogsov-00.txt>.

   [LG]       Reilly, L., "Project Looking Glass",
              draft-reilly-looking-glass-00, July 2026.

   [HDRP]     Reilly, L., "Hypercube Data Rotation Protocol (HDRP)",
              draft-reilly-hdrp-00, July 2026,
              <https://datatracker.ietf.org/doc/draft-reilly-hdrp/>.

   [ORION]    Reilly, L., "Project Orion -- The Reilly Protocol
              Suite", reference implementation, July 2026,
              <https://project-orion-production.up.railway.app/>.

Author's Address

   Lawrence John Reilly Jr.

   Email: lawrencejohnreilly@gmail.com