Independent Submission L. J. Reilly, Ed. Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 26 August 2026 Expires: 27 February 2027 Web4: A Verifiable, Agent-Native Architecture for the World Wide Web draft-reilly-web4-00 Abstract The term "Web4" has been used in industry and press coverage without a technical definition, a conformance target, or a testable claim. This document supplies one. It defines Web4 as an architectural profile of the existing Web in which (1) published content carries independently verifiable permanence evidence, (2) the machine channel is a first-class interface rather than an artifact of scraping, (3) autonomous agents operate under recorded, bounded, and revocable authority, and (4) human readers retain disclosed control over agent- curated presentation. Web4 as specified here is not a new network, a new protocol stack, or a replacement for HTTP. It is a composition profile: a set of normative requirements that a deployment either meets or does not, assembled from a family of previously published Internet-Drafts. This document specifies the profile, defines the Web4 Attestation Record (W4AR) that a conforming deployment emits, states the requirements that apply to agentic pipelines operating inside such a deployment, and identifies the running reference implementations against which the profile has been exercised. The profile is assembled from a suite of Internet-Drafts authored by Lawrence J. Reilly Jr. between September 2025 and August 2026, and is first specified as a unified conformance target in this document. 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/. Reilly Expires 27 February 2027 [Page 1] Internet-Draft Web4 Architecture August 2026 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 27 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 1.2. Origin and Authorship of This Work . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Web4 Reference Architecture . . . . . . . . . . . . . . . 6 3.1. Plane 1: Permanence . . . . . . . . . . . . . . . . . . . 6 3.2. Plane 2: The Machine Channel . . . . . . . . . . . . . . 7 3.3. Plane 3: Agent Governance . . . . . . . . . . . . . . . . 8 3.4. Plane 4: Human Epistemic Autonomy . . . . . . . . . . . . 8 3.5. Plane 0: Topology and Resilience . . . . . . . . . . . . 9 4. Web4 Conformance Profile . . . . . . . . . . . . . . . . . . 9 5. The Web4 Attestation Record . . . . . . . . . . . . . . . . . 11 6. Requirements on Agentic Pipelines . . . . . . . . . . . . . . 13 6.1. Blast Radius Classification . . . . . . . . . . . . . . . 13 6.2. Oversight Modes . . . . . . . . . . . . . . . . . . . . . 14 6.3. Pipeline Stability . . . . . . . . . . . . . . . . . . . 14 6.4. Circuit Breaking . . . . . . . . . . . . . . . . . . . . 15 7. Reference Implementations . . . . . . . . . . . . . . . . . . 15 8. Self-Application . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Provenance of the Web4 Profile . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Reilly Expires 27 February 2027 [Page 2] Internet-Draft Web4 Architecture August 2026 1. Introduction Successive labels for eras of the World Wide Web have been coined largely outside standards bodies. "Web 2.0" described a shift in publishing practice, not a protocol change. "Web3" attached to a particular settlement technology. "Web4" has since been applied to several unrelated propositions, including semantic reasoning layers, immersive environments, and agent-mediated commerce, with no shared definition and no way for an implementer to determine whether a given system qualifies. A label with no conformance criteria is not useful to implementers and is not reviewable. The purpose of this document is to make "Web4" mean something a deployment can be tested against. The definition offered here is deliberately narrow. Web4 is the condition of the Web in which the following four properties hold together at the same origin: 1. *Verifiable permanence.* A published artifact carries evidence, checkable by a party that trusts neither the publisher nor any single archive, that it existed in a stated form at a stated time. 2. *A first-class machine channel.* Automated consumers are served a declared, structured, and stable interface rather than being left to infer structure from a presentation intended for humans. 3. *Bounded agent authority.* Autonomous software acting on the origin does so under recorded authority, with an explicit blast radius, an oversight path, and a durable record of what it did and why it was permitted to. 4. *Disclosed curation.* Where an agent selects, ranks, or withholds material on a human reader's behalf, the reader is told that selection occurred and can obtain the unselected view. A deployment that satisfies one or two of these is common. A deployment that satisfies all four is rare, and the composition is where the engineering difficulty sits. This document specifies that composition. 1.1. Scope and Non-Goals This document specifies a profile and a record format. It does not define new cryptographic primitives, a new transport, a consensus mechanism, a token, or a network. Every underlying mechanism it composes is specified elsewhere and referenced here. Reilly Expires 27 February 2027 [Page 3] Internet-Draft Web4 Architecture August 2026 Explicit non-goals: * This document does not require, endorse, or depend on any particular blockchain, and does not require the operation or holding of a digital asset. Where an external timestamping service is used, it is used as a witness, and any witness meeting the requirements in Section 3.1 is acceptable. * This document does not attempt to define machine intelligence, model architecture, or training practice. It is concerned only with what an agent is permitted to do to a deployment and what record it leaves. * This document makes no claim about immersive or spatial interfaces, which some other uses of the term "Web4" have emphasized. * This document does not assume that agent populations converge toward a single locus of authority or capability. The profile is specified for a plural ecology of independently operated origins and agents, consistent with the conditions set out in [I-D.reilly-multilarity]. Nothing here requires or implies a common operator. 1.2. Origin and Authorship of This Work The Web4 profile specified in this document was defined by Lawrence J. Reilly Jr. and is the composition layer over a suite of Internet- Drafts he authored between September 2025 and August 2026. The suite comprises twenty-six active drafts, beginning with draft-reilly-rem- protocol-00 in September 2025, each addressing one plane of the architecture in isolation, and each accompanied by a running reference implementation built and operated by the author. This document is the first to specify how those planes compose into a single conformance target and to attach the name "Web4" to that target. The individual planes are normatively specified in the referenced drafts and are not restated here. Where this document uses "Web4" as a technical term, it means the profile defined in Section 4 of this document. The author makes no claim over other and earlier informal uses of the word, which are surveyed in Section 1 and which this document does not adopt. What is claimed is narrow and checkable: the profile, the ten requirements, the W4AR record format, and the composition of the five planes are the work of the author and are first specified here. Reilly Expires 27 February 2027 [Page 4] Internet-Draft Web4 Architecture August 2026 The following terms used in this document were coined and first defined by Lawrence J. Reilly Jr. in the drafts cited alongside them: Dual-Layer Digital Permanence [I-D.reilly-rem-protocol], Machine-Web Symbiosis [I-D.reilly-mws], Cognitive Sovereignty [I-D.reilly-cogsov], Protocol Layer Prompt Engineering [I-D.reilly-plpes], and Multilarity [I-D.reilly-multilarity]. Attribution of a coined term records where the term was defined and nothing further. It is not a claim of priority over the underlying techniques, several of which have substantial prior art that the individual drafts cite and credit. A full construction record, identifying which plane derives from which draft and on what date, appears in Appendix A. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Web4 Origin: An HTTP origin, as defined in [RFC6454], that asserts conformance to the profile in Section 4. Machine Channel: The set of representations an origin serves to non- human consumers, declared rather than inferred. Human Channel: The set of representations an origin serves for direct human reading. Permanence Evidence: Data sufficient for a third party to confirm that a given artifact existed in a given form at or before a given time, without trusting the publisher. Agent: Autonomous or semi-autonomous software that observes a Web4 Origin and may propose or execute changes to it. Blast Radius: The classified extent of the effect an agent action can have if the action is wrong. See Section 6.1. Oversight Mode: The operating posture governing whether an agent's proposed actions execute directly or enter a decision queue for human disposition. Decision Queue: The durable, ordered set of agent-proposed actions awaiting human disposition. Reilly Expires 27 February 2027 [Page 5] Internet-Draft Web4 Architecture August 2026 W4AR: Web4 Attestation Record. The artifact defined in Section 5 by which an origin asserts conformance in a checkable form. 3. The Web4 Reference Architecture Web4 is organized as five planes. Each plane has an independent normative specification. This section states the role of each plane in the composition and the interface it presents to the others. It does not restate the referenced specifications. +---------------------------------------------------+ | Plane 4: Human Epistemic Autonomy | | curation disclosure, fallback to unselected view | +---------------------------------------------------+ | Plane 3: Agent Governance | | authority, blast radius, oversight, behavior log | +---------------------------------------------------+ | Plane 2: Machine Channel | | declared structured representations, discovery | +---------------------------------------------------+ | Plane 1: Permanence | | content commitments, dual-layer anchoring | +---------------------------------------------------+ | Plane 0: Topology and Resilience | | shard rotation, control coverage, continuity | +---------------------------------------------------+ | ordinary HTTP origin Figure 1: Web4 plane composition at a single origin 3.1. Plane 1: Permanence The permanence plane produces evidence that a published artifact existed in a stated form at a stated time. A Web4 Origin MUST commit to each artifact it asserts as permanent by a cryptographic hash over the exact octets served, and MUST make that commitment available through the machine channel. A commitment alone is not evidence. The origin MUST additionally submit each commitment to at least two independent witnesses of differing failure mode, following the Dual-Layer Digital Permanence construction in [I-D.reilly-rem-protocol]. In that construction one witness class is a timestamping service that produces a proof verifiable without the witness remaining available, and the second is an archival deposit that retains a retrievable copy under an independent operator. Reilly Expires 27 February 2027 [Page 6] Internet-Draft Web4 Architecture August 2026 Anchors have states. An origin MUST distinguish, in every representation it serves, between a commitment that has been submitted and not yet confirmed, and one for which a complete verification path exists. Presenting a pending submission as an attested anchor is a conformance violation, not a display choice. Where an origin publishes many artifacts, per-artifact anchoring is wasteful and, at scale, unaffordable. An origin SHOULD batch commitments into a Merkle tree constructed as specified in [RFC9162] and anchor the tree head, serving per-artifact inclusion proofs. Where consistency across a range of tree states must be shown to a client that verifies many entries at once, the bulk subtree construction in [I-D.reilly-bulk-subtree-proofs] MAY be used to reduce proof size. Hash agility is required over the horizons this plane targets. An origin MUST be able to migrate to a successor hash function by publishing a bridging record that commits, under the successor function, to the head of the chain built under the predecessor. An origin MUST NOT silently re-anchor historical artifacts under a new function, since doing so destroys the original time evidence. 3.2. Plane 2: The Machine Channel Most of the Web today is consumed by software and formatted for people. The gap is bridged by extraction, which is lossy, unstable, and adversarial in both directions. The machine channel plane closes that gap by making the machine representation declared and stable, following [I-D.reilly-mws]. A Web4 Origin MUST serve, for every resource it exposes to agents, a structured representation selected by ordinary content negotiation. A request carrying an Accept header indicating a structured media type MUST NOT be answered with a presentation-oriented representation when a structured one exists. A Web4 Origin MUST publish a discovery document at /.well-known/ mws.json naming, at minimum: the structured media types it serves, the location of its permanence commitments, the location of its agent policy, and the endpoint at which its chain of records can be verified. The machine channel and the human channel MUST be consistent. Where the two disagree in substance, the origin MUST treat the disagreement as an integrity finding under Section 3.3 rather than as a rendering difference. Serving agents a representation that differs materially from what a human reader receives at the same URI is cloaking, and is prohibited by this profile. Reilly Expires 27 February 2027 [Page 7] Internet-Draft Web4 Architecture August 2026 3.3. Plane 3: Agent Governance This plane governs autonomous software operating on the origin. It is the plane most often absent from systems that otherwise resemble the rest of this profile, and it is the plane on which the safety of the composition rests. Every agent operating on a Web4 Origin MUST have a declared authority: the set of action types it may propose, the resources it may act on, and the oversight mode under which it currently runs. Authority MUST be revocable, and revocation MUST take effect without redeploying the agent. Every action an agent proposes or executes MUST produce a durable record committing to the action type, the target, the triggering observation, the authority relied on, the oversight disposition, and the outcome. These records MUST be hash-linked, so that removal or reordering is detectable, and the chain head MUST be anchored under Section 3.1. The behavioral record structure and the drift measures over it are specified in [I-D.reilly-cbpi]. Where an agent's behavior is shaped by a feedback signal, the origin MUST record the source of that signal alongside the resulting behavior change. An agent whose behavior drifts without a recorded cause is indistinguishable, to an auditor, from an agent that has been compromised. Where the origin processes personal data, the governance records required by this plane MUST be compatible with erasure obligations. The Erasure-Compatible Permanence construction in [I-D.reilly-aigov] satisfies this by committing to salted per-field values and erasing the opening material, so that a record remains chain-valid after the underlying field can no longer be recovered. 3.4. Plane 4: Human Epistemic Autonomy An origin that satisfies the first three planes can still deliver a reader a silently narrowed view of the world. This plane addresses that, following [I-D.reilly-cogsov]. Where an agent selects, ranks, filters, or withholds material before it reaches a human reader, the origin MUST emit a Curation Disclosure Record identifying that selection occurred, the selection criteria in effect, and the size of the withheld set. Reilly Expires 27 February 2027 [Page 8] Internet-Draft Web4 Architecture August 2026 The origin MUST provide a Sovereignty Fallback: a path by which the reader obtains the unselected set. The fallback MUST NOT be conditioned on account state, payment, or an attestation of the reader's identity or purpose. Disclosure is not consent and does not license arbitrary curation. An origin that withholds material on grounds it will not disclose does not conform to this profile, whatever else it satisfies. 3.5. Plane 0: Topology and Resilience The lower plane is optional to the definition of Web4 but is required for any deployment whose availability or integrity is itself a target. Where an origin distributes state across shards, it MAY rotate shard assignment on a schedule as specified in [I-D.reilly-hdrp], committing each rotation epoch into a hash-linked chain so that the rotation history is itself auditable. A rotation schedule that is not committed provides an attacker with the same information as no rotation at all, since the defender cannot later demonstrate what the topology was. Where an origin operates under a control framework, it SHOULD maintain a Control Register and emit Control Coverage Attestations as specified in [I-D.reilly-resilience-protocol], so that assurance claims are coverage-weighted rather than asserted in aggregate. 4. Web4 Conformance Profile A deployment conforms to this profile if and only if it satisfies every requirement in this section. There are no conformance levels and no partial conformance. A deployment satisfying some requirements is a deployment satisfying some requirements, and MUST NOT describe itself as Web4 conformant. W4-1 (Commitment): Every artifact the origin asserts as permanent MUST have a published cryptographic commitment over the exact octets served, retrievable through the machine channel. W4-2 (Dual-Layer Anchoring): Every such commitment MUST be submitted to at least two independent witnesses of differing failure mode, and the verification path for each MUST be published. Anchor state MUST be reported as pending or attested and MUST NOT be conflated. Reilly Expires 27 February 2027 [Page 9] Internet-Draft Web4 Architecture August 2026 W4-3 (Declared Machine Channel): The origin MUST serve structured representations under content negotiation and MUST publish /.well-known/mws.json as described in Section 3.2. W4-4 (Channel Consistency): The human and machine channels MUST NOT differ materially in substance at the same URI. Detected divergence MUST raise an integrity finding. W4-5 (Declared Agent Authority): Every agent operating on the origin MUST have declared, revocable authority and a declared oversight mode, both retrievable through the machine channel. W4-6 (Behavioral Record): Every agent action MUST produce a hash-linked record as described in Section 3.3, and the chain head MUST be anchored under W4-2. W4-7 (Blast Radius Bounding): Every agent action type MUST be classified per Section 6.1, and BR3 actions MUST NOT execute without human disposition in any oversight mode. W4-8 (Curation Disclosure): Agent-mediated selection presented to a human reader MUST carry a Curation Disclosure Record and MUST offer an unconditioned Sovereignty Fallback. W4-9 (Self-Verification): The origin MUST expose an endpoint that recomputes and reports the validity of its own record chains, and that endpoint MUST report failure truthfully. An origin whose verification endpoint cannot return a negative result does not satisfy this requirement. W4-10 (Attestation): The origin MUST publish a current W4AR as specified in Section 5. W4-9 deserves emphasis. A verification endpoint that always returns success is worse than no endpoint, because it converts an absence of evidence into an appearance of evidence. Implementers SHOULD test this requirement by deliberate corruption of a chain entry in a staging environment and confirming that the endpoint reports the corruption. Reilly Expires 27 February 2027 [Page 10] Internet-Draft Web4 Architecture August 2026 5. The Web4 Attestation Record A W4AR is the artifact by which an origin asserts conformance in a form a third party can check. It is a CBOR [RFC8949] map, signed as a COSE_Sign1 [RFC9052] object by a key the origin publishes through its machine channel. A W4AR MUST contain the following fields. Reilly Expires 27 February 2027 [Page 11] Internet-Draft Web4 Architecture August 2026 +============+=======+========================================+ | Field | Type | Description | +============+=======+========================================+ | origin | tstr | The origin, serialized per [RFC6454]. | +------------+-------+----------------------------------------+ | profile | tstr | Profile identifier. For this | | | | document, "web4/1". | +------------+-------+----------------------------------------+ | issued | uint | Issuance time, seconds since the | | | | epoch. | +------------+-------+----------------------------------------+ | expires | uint | Expiry time. A W4AR MUST have a | | | | finite lifetime. | +------------+-------+----------------------------------------+ | reqs | map | Requirement identifier to status, one | | | | entry per requirement W4-1 through | | | | W4-10. Status is one of "met", "not- | | | | met", or "not-applicable". | +------------+-------+----------------------------------------+ | chain_head | bstr | Current head of the origin's hash- | | | | linked record chain. | +------------+-------+----------------------------------------+ | chain_len | uint | Number of entries committed under | | | | chain_head. | +------------+-------+----------------------------------------+ | anchors | array | One entry per witness, each carrying | | | | witness identifier, submitted | | | | commitment, state ("pending" or | | | | "attested"), and verification URI. | +------------+-------+----------------------------------------+ | agents | array | One entry per agent holding authority, | | | | carrying agent identifier, permitted | | | | action types, maximum blast radius | | | | class, and current oversight mode. | +------------+-------+----------------------------------------+ | mode | tstr | Origin-level oversight mode: | | | | "observe", "supervised", or | | | | "autonomous". | +------------+-------+----------------------------------------+ | alg_suite | tstr | Identifier of the hash and signature | | | | suite in force. | +------------+-------+----------------------------------------+ Table 1: W4AR fields Reilly Expires 27 February 2027 [Page 12] Internet-Draft Web4 Architecture August 2026 The reqs map is the substance of the record. An origin that cannot satisfy a requirement MUST report it as "not-met" rather than omitting it. A W4AR with an incomplete reqs map MUST be treated by a verifier as non-conformant, not as partially informative. An origin MUST NOT include a boolean field asserting overall conformance. Conformance is derived by the verifier from the reqs map and the checks the verifier chooses to perform against it. A self-asserted summary boolean invites reliance on the assertion rather than the evidence. A W4AR MUST be retrievable at /.well-known/w4ar with media type application/w4ar+cose. 6. Requirements on Agentic Pipelines This section states what an agentic pipeline operating inside a Web4 Origin must do. It is written from operational experience with the reference implementations in Section 7, several of which have run continuously for tens of thousands of measurement epochs. The requirements here are the ones that failure modes in those deployments made necessary. 6.1. Blast Radius Classification Every action type an agent may take MUST be assigned to one of four classes before the agent is granted authority over it. BR0: Observation only. No state change. Reversible by definition. BR1: Local, reversible state change affecting a single resource, with a recorded prior state sufficient to restore it. BR2: State change affecting multiple resources or the origin's configuration, reversible only through a defined rollback procedure. BR3: Irreversible action, action affecting the integrity or governance apparatus itself, or action whose effect leaves the origin's control. Examples include erasure execution, withdrawal of published material, key rotation, revocation of another agent's authority, and any modification of the record chain. BR3 actions MUST enter the decision queue for human disposition in every oversight mode, including "autonomous". This is not a configuration default. There MUST be no configuration that permits autonomous execution of a BR3 action. Reilly Expires 27 February 2027 [Page 13] Internet-Draft Web4 Architecture August 2026 In particular, an agent MUST NOT be permitted to repair a detected integrity violation in a record chain. An integrity violation is evidence. Automated repair destroys the evidence and produces a chain that verifies while describing something that did not happen. 6.2. Oversight Modes An origin MUST support at least the modes "observe" (agents propose, nothing executes), "supervised" (BR0 and BR1 execute, BR2 and BR3 queue), and "autonomous" (BR0 through BR2 execute, BR3 queues). Mode transitions MUST themselves be recorded as BR2 actions. The current mode MUST be reported in the W4AR and MUST be visible in the human channel of any interface an operator uses to observe the pipeline. Items in the decision queue MUST persist across restarts. An implementation that loses queued items on restart converts human oversight into a function of process uptime. 6.3. Pipeline Stability A measurement agent that emits a finding and a remediation agent that acts on findings form a control loop, and such loops oscillate. Two requirements follow from repeated observation of this failure in the reference deployments. First, thresholds MUST be hysteretic. A condition that fails below a threshold MUST NOT be treated as recovered until the measure exceeds a distinct, higher recovery threshold. Symmetric thresholds produce indicators that flap across an epoch boundary and a remediator that fires continuously. Second, indicator triggers and pathology triggers MUST be aligned to the same threshold values. A band in which an indicator reads failed but no finding is raised leaves the remediator idle while the origin reports a fault, which is the worst of both behaviors: visible failure, no response, and no record of a decision not to respond. Third, a remediation MUST be attempted at most once per finding episode. A remediator that reissues the same remediation on every epoch against a condition it cannot fix produces an unbounded record chain that obscures every other event in it. Where an indicator is composite and a component is unavailable, the origin MUST report the component as null and renormalize the remaining weights, rather than substituting a default value. Substituting a default reports a measurement that was not taken. Reilly Expires 27 February 2027 [Page 14] Internet-Draft Web4 Architecture August 2026 6.4. Circuit Breaking An agentic pipeline MUST implement a circuit breaker that suspends automated execution and forces all actions to the decision queue when any of the following is observed: an action type flapping between opposed states above a configured rate, a burst of findings above a configured rate, or a rate of rejected proposals above a configured threshold. Breaker state MUST be recorded and MUST be reported in the W4AR mode field as an effective mode, so that a verifier sees the posture actually in force rather than the configured one. 7. Reference Implementations The following deployments implement subsets of this profile and were used to develop it. They are cited as evidence that the requirements are implementable, not as normative references. Availability of any URI below is not guaranteed beyond the life of this draft. * The permanence plane and the machine channel are implemented at https://www.remweb4.org/, which exposes a hash-linked record chain, a verification endpoint, and archival mesh coverage across several independent keyless archive services. * The agent governance plane is implemented at https://cbpi- web4-production.up.railway.app/, which maintains behavioral records and drift measures per [I-D.reilly-cbpi]. * The governance and erasure requirements are implemented at https://aigov-web4-production.up.railway.app/, which holds salted per-field commitments with erasable opening material and keeps four remediation classes with the operator in both oversight modes. * Cross-origin measurement, including anchor liveness against independent permanence services, is implemented at https://project-atlas-production-297c.up.railway.app/. * The topology plane is implemented at https://hdrp-hypercube-site- production.up.railway.app/, which has committed and chain-verified rotation epochs continuously since July 2026. Implementation experience across these deployments produced the stability requirements in Section 6.3, each of which corresponds to a fault observed in a running system rather than to a hypothetical. Reilly Expires 27 February 2027 [Page 15] Internet-Draft Web4 Architecture August 2026 8. Self-Application A profile that specifies verifiable permanence and then publishes itself without it invites the obvious objection. This document is therefore treated as an artifact under its own W4-1 and W4-2 requirements. The author commits to the exact octets of each revision of this document, submits that commitment to a timestamping witness whose proof verifies without the witness remaining available, and deposits an archival copy under an independent operator, as specified in Section 3.1. The resulting record binds the definition of the Web4 profile, its revision, and its authorship to a stated time in a form any third party can check without trusting the author, this document, or the IETF Datatracker. Verification material for each revision is published through the machine channel of the author's origin at https://www.remweb4.org/ under the record identifier for that revision, alongside the archival deposit identifier. Readers evaluating priority, authorship, or the state of the profile at a given date SHOULD verify against that record rather than against this document's text, since the record is the evidence and the text is the claim. Future revisions of this document MUST carry their own commitments. A revision that inherits the anchor of a prior revision would assert time evidence for content that did not exist at that time, which is precisely the failure Section 3.1 prohibits. 9. Security Considerations The central risk of this profile is that it produces the appearance of verifiability without the substance. Every mechanism it composes can be implemented in a form that renders correctly and proves nothing. A verifier MUST recompute rather than read status fields, and this document structures the W4AR to make recomputation possible. Anchor state confusion is the most likely specific failure. A commitment submitted to a timestamping service is not evidence until a verification path exists. Deployments have strong incentive to display pending submissions as completed anchors, and readers have no way to tell the difference unless the origin distinguishes them. W4-2 makes the distinction normative for that reason. Reilly Expires 27 February 2027 [Page 16] Internet-Draft Web4 Architecture August 2026 Agent authority is a privilege escalation surface. An agent with BR2 authority over configuration can, in many implementations, alter its own authority. Implementations MUST place authority modification and agent registration at BR3, and MUST verify blast radius classification at the point of execution rather than at the point of proposal. The record chain is an attractive target precisely because it is the evidence. Chain modification MUST be BR3 and MUST NOT be automatable. An origin SHOULD publish chain heads to an external witness frequently enough that the window in which an undetected rewrite is possible is bounded and stated. Curation disclosure creates a fingerprinting surface. A Curation Disclosure Record that reports selection criteria in fine detail can reveal the reader's inferred attributes to any party observing the response. Implementations SHOULD report criteria at a granularity sufficient for the reader to understand the selection without reconstructing the reader's profile. Hash migration is a live risk over the horizons this profile contemplates. The bridging record requirement in Section 3.1 preserves the original time evidence across migration. Deployments that re-anchor historical material under a successor function lose exactly the property they anchored for. Finally, conformance to this profile says nothing about the truth of the content published. It says that the content was published at a stated time, in a stated form, by a party operating agents under stated authority, with stated disclosure of curation. Those are provenance properties. A verifier that reads them as accuracy properties has misunderstood the profile. 10. Privacy Considerations Permanence and erasure are in tension. This profile resolves the tension by committing to salted per-field values rather than to plaintext, so that erasing the opening material renders a field unrecoverable while leaving the chain valid, as specified in [I-D.reilly-aigov]. Deployments that anchor personal data directly, rather than commitments to it, cannot satisfy erasure obligations afterward, and this profile prohibits doing so. Salts MUST be per-field and MUST be drawn from a cryptographically secure source. A per-record salt permits cross-field correlation after partial disclosure. Reilly Expires 27 February 2027 [Page 17] Internet-Draft Web4 Architecture August 2026 The machine channel expands what is legible to automated consumers, which is its purpose and also its cost. An origin SHOULD NOT expose through the machine channel any field it would not publish in the human channel, and MUST NOT treat the machine channel as a lower- scrutiny path for data that policy restricts. 11. IANA Considerations This document requests registration of the media type application/ w4ar+cose in the "Media Types" registry, per the procedures of [RFC6838]. The full registration template will be supplied in a subsequent revision. This document requests registration of the well-known URI suffix w4ar in the "Well-Known URIs" registry, per [RFC8615]. No other IANA action is requested. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . Reilly Expires 27 February 2027 [Page 18] Internet-Draft Web4 Architecture August 2026 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, . [I-D.reilly-rem-protocol] Reilly, L. J., "The REM Protocol: Dual-Layer Digital Permanence and Prior Art Records", Work in Progress, Internet-Draft, draft-reilly-rem-protocol-02, 2026, . [I-D.reilly-mws] Reilly, L. J., "Machine-Web Symbiosis (MWS)", Work in Progress, Internet-Draft, draft-reilly-mws-01, 2026, . [I-D.reilly-cogsov] Reilly, L. J., "Cognitive Sovereignty: Curation Disclosure Records and Sovereignty Fallback", Work in Progress, Internet-Draft, draft-reilly-cogsov-00, 2026, . [I-D.reilly-cbpi] Reilly, L. J., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-reilly-cbpi-00, 2026, . [I-D.reilly-aigov] Reilly, L. J., "Verifiable AI Governance and Data Privacy Records", Work in Progress, Internet-Draft, draft-reilly- aigov-00, 2026, . 12.2. Informative References [I-D.reilly-hdrp] Reilly, L. J., "Hypercube Data Rotation Protocol (HDRP)", Work in Progress, Internet-Draft, draft-reilly-hdrp-00, 2026, . [I-D.reilly-resilience-protocol] Reilly, L. J., "The Reilly Resilience Protocol (RRP)", Work in Progress, Internet-Draft, draft-reilly-resilience- protocol-02, 2026, . Reilly Expires 27 February 2027 [Page 19] Internet-Draft Web4 Architecture August 2026 [I-D.reilly-bulk-subtree-proofs] Reilly, L. J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-reilly-plants-bulk-subtree-proofs-01, 2026, . [I-D.reilly-plpes] Reilly, L. J., "Protocol Layer Prompt Engineering Standard (PLPES)", Work in Progress, Internet-Draft, draft-reilly- plpes-00, 2026, . [I-D.reilly-multilarity] Reilly, L. J., "The Multilarity", Work in Progress, Internet-Draft, draft-reilly-multilarity-00, 2026, . [LICKLIDER] Licklider, J. C. R., "Man-Computer Symbiosis", IRE Transactions on Human Factors in Electronics HFE-1, March 1960, . Appendix A. Provenance of the Web4 Profile This appendix records the construction of the profile. It is included so that a reader can determine, for any requirement in Section 4, which prior specification it derives from, when that specification was published, and which running implementation exercised it. The appendix is informative. Nothing in it adds to or qualifies the normative requirements. All drafts listed below were authored by Lawrence J. Reilly Jr. and are available on the IETF Datatracker under the author's identifier, and in the internet-drafts mirrors operated by FUNET and OTEnet. Reilly Expires 27 February 2027 [Page 20] Internet-Draft Web4 Architecture August 2026 +==============+=========================================+=========+ |Plane | Derived from |First | | | |published| +==============+=========================================+=========+ |Plane 1, | draft-reilly-rem-protocol |September| |Permanence | |2025 | +--------------+-----------------------------------------+---------+ |Plane 1, | draft-reilly-plants-bulk-subtree-proofs |July 2026| |batching and | | | |proofs | | | +--------------+-----------------------------------------+---------+ |Plane 2, | draft-reilly-mws |July 2026| |Machine | | | |Channel | | | +--------------+-----------------------------------------+---------+ |Plane 3, Agent| draft-reilly-cbpi |July 2026| |Governance | | | +--------------+-----------------------------------------+---------+ |Plane 3, | draft-reilly-aigov |August | |erasure | |2026 | |compatibility | | | +--------------+-----------------------------------------+---------+ |Plane 4, Human| draft-reilly-cogsov |July 2026| |Epistemic | | | |Autonomy | | | +--------------+-----------------------------------------+---------+ |Plane 0, shard| draft-reilly-hdrp |July 2026| |rotation | | | +--------------+-----------------------------------------+---------+ |Plane 0, | draft-reilly-resilience-protocol |2025, | |control | |revised | |coverage | |August | | | |2026 | +--------------+-----------------------------------------+---------+ |Plural-ecology| draft-reilly-multilarity |July 2026| |assumption | | | +--------------+-----------------------------------------+---------+ Table 2: Plane derivation and first publication The requirements in Section 6 are not derived from a prior draft. They were produced by operating the reference implementations in Section 7 and correcting the faults those deployments exhibited. Specifically: the hysteresis requirement in Section 6.3 follows from an indicator that flapped across an epoch boundary and drove continuous remediation; the trigger-alignment requirement follows from an observed band in which an indicator reported failure while no finding was raised and the remediator stayed idle; the once-per- Reilly Expires 27 February 2027 [Page 21] Internet-Draft Web4 Architecture August 2026 episode requirement follows from a sentinel that reissued an identical remediation on every epoch against a condition it could not resolve, across several thousand epochs; and the null-and-renormalize requirement follows from a composite indicator that reported a substituted default in place of a measurement that had not been taken. Each correction was applied to the running system before it was written as a requirement here. The author's reference instruments have accumulated, at the time of writing, continuous chain-verified operation on the order of tens of thousands of measurement epochs across the deployments listed in Section 7. That operating record, rather than the argument in this document, is the basis on which the profile should be judged implementable. Acknowledgments The machine channel plane extends Licklider's framing of man-computer symbiosis [LICKLIDER] to the case where the second party is the Web itself rather than a single machine. The permanence plane's Merkle constructions follow the Certificate Transparency line of work. Author's Address Lawrence J. Reilly Jr. (editor) REM Technologies & Consulting, LLC Lutz, FL United States of America Email: lawrencejohnreilly@gmail.com URI: https://www.remweb4.org/ Reilly Expires 27 February 2027 [Page 22]