Web4: A Verifiable, Agent-Native Architecture for the World Wide Web
draft-reilly-web4-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr | ||
| Last updated | 2026-08-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-web4-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
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,
<https://www.rfc-editor.org/info/rfc6838>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-rem-
protocol/>.
[I-D.reilly-mws]
Reilly, L. J., "Machine-Web Symbiosis (MWS)", Work in
Progress, Internet-Draft, draft-reilly-mws-01, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-mws/>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-cogsov/>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-cbpi/>.
[I-D.reilly-aigov]
Reilly, L. J., "Verifiable AI Governance and Data Privacy
Records", Work in Progress, Internet-Draft, draft-reilly-
aigov-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-aigov/>.
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,
<https://datatracker.ietf.org/doc/draft-reilly-hdrp/>.
[I-D.reilly-resilience-protocol]
Reilly, L. J., "The Reilly Resilience Protocol (RRP)",
Work in Progress, Internet-Draft, draft-reilly-resilience-
protocol-02, 2026, <https://datatracker.ietf.org/doc/
draft-reilly-resilience-protocol/>.
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,
<https://datatracker.ietf.org/doc/draft-reilly-plants-
bulk-subtree-proofs/>.
[I-D.reilly-plpes]
Reilly, L. J., "Protocol Layer Prompt Engineering Standard
(PLPES)", Work in Progress, Internet-Draft, draft-reilly-
plpes-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-plpes/>.
[I-D.reilly-multilarity]
Reilly, L. J., "The Multilarity", Work in Progress,
Internet-Draft, draft-reilly-multilarity-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-
multilarity/>.
[LICKLIDER]
Licklider, J. C. R., "Man-Computer Symbiosis", IRE
Transactions on Human Factors in Electronics HFE-1, March
1960, <https://groups.csail.mit.edu/medg/people/psz/
Licklider.html>.
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]