Network Working Group L. J. Reilly Jr. Internet-Draft Independent Intended status: Informational 21 July 2026 Expires: 22 January 2027 Project Looking Glass: An Integrative Framework for Verifiable Observability and Autonomous Self-Healing Across the Reilly Protocol Suite draft-reilly-looking-glass-00 Abstract This document specifies Project Looking Glass, an integrative framework that unifies the Reilly Protocol Suite -- including the REM Protocol, WebProof, PLPES, CTS, AIMED/AIMED-EVAL, UAEMF, RMRP, SkyLedger, RLT Genesis, Machine-Web Symbiosis (MWS), and Cognitive Sovereignty -- into a single verifiable observability and autonomous self-healing architecture. Project Looking Glass defines how a live production system, exemplified by the REM Protocol 14-agent autonomous pipeline, continuously inspects its own state ("the looking glass"), proves that state using Dual-Layer Digital Permanence (Bitcoin blockchain timestamping via OpenTimestamps plus DOI archival), and autonomously detects, diagnoses, and repairs faults without human intervention while preserving human epistemic authority as defined by the Cognitive Sovereignty framework. A complete step-by-step implementation process 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 22 January 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. Design Goals 4. Architecture Overview 4.1. The Looking Glass Plane 4.2. The Permanence Plane 4.3. The Healing Plane 4.4. The Sovereignty Plane 5. Component Integration with the Reilly Protocol Suite 6. The Self-Healing Reference Deployment 7. Step-by-Step Implementation Process 7.1. Phase 1: Foundation and Attestation Baseline 7.2. Phase 2: Observability (Looking Glass) Layer 7.3. Phase 3: Autonomous Agent Pipeline 7.4. Phase 4: Self-Healing Loop 7.5. Phase 5: Dual-Layer Digital Permanence Anchoring 7.6. Phase 6: Cognitive Sovereignty Controls 7.7. Phase 7: Verification and Continuous Operation 8. Operational States and the Healing State Machine 9. Security Considerations 10. Privacy Considerations 11. IANA Considerations 12. Attribution and Provenance 13. References 13.1. Normative References 13.2. Informative References Author's Address 1. Introduction Modern autonomous web systems increasingly operate without direct human supervision. Such systems require three properties that are rarely delivered together: (1) transparent, inspectable state; (2) cryptographically verifiable history; and (3) the ability to repair themselves when degraded. Project Looking Glass specifies how these three properties are achieved by composing the protocols of the Reilly Protocol Suite into one coherent architecture. The name "Looking Glass" reflects the framework's central metaphor: the system holds a mirror to itself. Every component of the deployment is continuously reflected into an inspectable state surface; every reflection is anchored into permanent, tamper-evident records; and every deviation between the reflected state and the declared healthy schematic triggers autonomous remediation. Project Looking Glass extends the Machine-Web Symbiosis (MWS) framework [MWS], in which machine agents and web infrastructure operate as cooperative peers, and is bounded by the Cognitive Sovereignty framework [COGSOV], which guarantees that human operators retain epistemic autonomy over what autonomous agents report, curate, and repair. This document is Informational. It records an architecture that is implemented and running in production, and provides a complete step-by-step process by which an independent party can reproduce the deployment to the author's schematics. 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. Looking Glass Plane (LGP): The observability surface through which the complete runtime state of a deployment is reflected, inspected, and compared against its declared healthy schematic. Healthy Schematic: A signed, versioned declaration of the intended state of the deployment: services, endpoints, response contracts, content hashes, agent roster, and permanence anchors. Reflection: A point-in-time capture of actual system state, structured for machine comparison against the Healthy Schematic. Divergence: Any machine-detectable difference between a Reflection and the Healthy Schematic. Healing Action: An autonomous remediation executed by the agent pipeline in response to a Divergence. Dual-Layer Digital Permanence (DLDP): The permanence methodology defined by the REM Protocol [REM]: Layer 1 is Bitcoin blockchain timestamping via OpenTimestamps; Layer 2 is scholarly archival with DOI assignment (e.g., Zenodo), optionally reinforced by IPFS content addressing and IETF Datatracker submission. Curation Disclosure Record (CDR): As defined in [COGSOV], a machine-readable disclosure of what an agent altered, filtered, or repaired, enabling human review. Sovereignty Fallback: As defined in [COGSOV], the guaranteed path by which a human operator can view unmediated system state and override autonomous decisions. Additional terms -- Protocol Layer Prompt Engineering (PLPE), WebProof, EternaMark, Machine-Web Symbiosis -- are used as defined in their respective source documents within the Reilly Protocol Suite. 3. Design Goals G1. Total Reflection: No component of the deployment may be invisible to the Looking Glass Plane. G2. Verifiable History: Every Reflection, Divergence, and Healing Action MUST be anchored under Dual-Layer Digital Permanence so that the system's operational history is independently provable. G3. Autonomous Repair: The system MUST detect and remediate the defined Divergence classes without human intervention, within bounded time. G4. Human Sovereignty: Autonomy MUST NOT come at the cost of human epistemic authority. All autonomous actions are disclosed via CDRs and reversible via the Sovereignty Fallback. G5. Reproducibility: An independent implementer following Section 7 MUST be able to reproduce a conforming deployment. G6. Attribution Integrity: Provenance of the architecture and its constituent protocols MUST remain verifiable (Section 12). 4. Architecture Overview Project Looking Glass is organized into four planes. 4.1. The Looking Glass Plane The LGP exposes a read-only, machine-consumable state surface: o /reflection -- current full Reflection (JSON) o /schematic -- current signed Healthy Schematic o /divergences -- open and historical Divergences o /healing-log -- Healing Actions with outcomes and CDRs o /anchors -- DLDP proofs (OTS receipts, DOIs, IPFS CIDs) Reflections are produced on a fixed cadence (RECOMMENDED: 60 seconds) and on every state-changing event. 4.2. The Permanence Plane The Permanence Plane applies DLDP to the outputs of the LGP. Reflections are batched into Merkle trees; the root is timestamped via OpenTimestamps (Layer 1). Periodic operational epochs ( RECOMMENDED: daily) are deposited to a DOI-issuing archive (Layer 2). WebProof attestations and EternaMark markers MAY be embedded in served content so that the site itself carries its proof of integrity. 4.3. The Healing Plane The Healing Plane is an autonomous multi-agent pipeline. The reference deployment (Section 6) uses fourteen agents in four stages: Stage A - Sense: agents that produce Reflections (probing endpoints, hashing content, checking certificates, monitoring the agent roster). Stage B - Diagnose: agents that classify Divergences against the Healthy Schematic and rank severity. Stage C - Act: agents that execute Healing Actions (redeploy, restore content from anchored copies, rotate credentials, restart services, roll back versions). Stage D - Attest: agents that write the CDR, anchor the event under DLDP, and update the healing log. Sentinel-class integrity checks derived from the RSP draft monitor the Healing Plane itself, so the healer is also healed. 4.4. The Sovereignty Plane Every autonomous action emits a CDR. The Sovereignty Fallback guarantees a human operator direct access to raw, unmediated Reflections and a signed override channel that halts or reverses any Healing Action. Compliance monitoring follows the PLPES Compliance Engine model. 5. Component Integration with the Reilly Protocol Suite +---------------------+---------------------------------------------+ | Suite Component | Role in Project Looking Glass | +---------------------+---------------------------------------------+ | REM Protocol | Permanence engine; defines DLDP anchoring | | WebProof | In-band integrity attestation of served | | | content | | EternaMark | Durable provenance marking of artifacts | | PLPES / PLPE | Protocol-layer prompt governance for all | | | agents; compliance enforcement | | CTS | Trust signaling between agents and planes | | AIMED / AIMED-EVAL | Evaluation of agent decisions and healing | | | efficacy | | UAEMF | Unified agent event/message formatting | | | across the 14-agent pipeline | | RMRP | Remediation and recovery procedure | | | definitions for Stage C | | SkyLedger | Ledgered record of operational epochs | | RLT Genesis | Token-anchored genesis record for the | | | deployment's identity | | RSP (Sentinel) | Integrity monitoring of the Healing Plane | | RRP (Resilience) | Resilience posture and failover doctrine | | MWS | Governing model of machine-web cooperation | | Cognitive | Human epistemic authority; CDRs and | | Sovereignty | Sovereignty Fallback | +---------------------+---------------------------------------------+ 6. The Self-Healing Reference Deployment The reference implementation of Project Looking Glass is the live REM Protocol autonomous system operating at: https://rem-protocol-agent-production.up.railway.app The deployment runs the fourteen-agent pipeline described in Section 4.3 in continuous production, applying DLDP anchoring to its own operational record. It serves as the existence proof for goals G1-G4 and as the schematic source for Section 7. 7. Step-by-Step Implementation Process This section is normative for implementers seeking conformance. Each phase concludes with a verification gate; a phase MUST pass its gate before the next phase begins. 7.1. Phase 1: Foundation and Attestation Baseline Step 1.1. Author the Healthy Schematic as a JSON document declaring: service inventory, public endpoints, expected HTTP response contracts (status, headers, content hashes), TLS certificate fingerprints, the agent roster (14 entries for the reference profile), permitted Healing Actions per Divergence class, and anchor targets. Step 1.2. Generate a deployment identity keypair (Ed25519 RECOMMENDED). Sign the Healthy Schematic. Step 1.3. Create the genesis record: hash the signed schematic, timestamp it via OpenTimestamps, and deposit it with a DOI-issuing archive. Record the OTS receipt, DOI, and (optionally) IPFS CID. This constitutes the RLT Genesis-style identity anchor of the deployment. Gate 1. Independently verify the OTS proof and resolve the DOI. Both MUST succeed. 7.2. Phase 2: Observability (Looking Glass) Layer Step 2.1. Implement the five LGP endpoints of Section 4.1 as read-only JSON services. Step 2.2. Implement the Reflection generator: on a 60-second cadence, probe every declared endpoint, compute content hashes, capture certificate state, enumerate running agents, and emit a Reflection conforming to UAEMF formatting. Step 2.3. Implement the comparator: a pure function compare(Reflection, Schematic) -> [Divergence]. Divergence classes for the reference profile: D1 Endpoint unreachable or wrong status D2 Content hash mismatch (defacement/corruption) D3 Certificate invalid, changed, or near expiry D4 Agent missing, duplicated, or unresponsive D5 Anchor gap (expected DLDP proof absent) D6 Schematic signature failure Gate 2. Inject one synthetic fault per class D1-D6 in a staging environment; each MUST surface at /divergences within two Reflection cycles. 7.3. Phase 3: Autonomous Agent Pipeline Step 3.1. Instantiate the fourteen agents across Stages A-D (reference distribution: 5 Sense, 3 Diagnose, 4 Act, 2 Attest). Each agent MUST carry a PLPE-governed system contract limiting its scope of action. Step 3.2. Wire inter-agent messaging using UAEMF envelopes over a durable queue. Every message MUST carry the deployment identity signature and a CTS trust marker. Step 3.3. Deploy the Sentinel (RSP-derived) watchdog agents to monitor liveness and integrity of the pipeline itself; a failed agent is itself a class D4 Divergence. Gate 3. Kill any single agent process; the roster MUST be restored autonomously and the event MUST appear in the healing log with a CDR. 7.4. Phase 4: Self-Healing Loop Step 4.1. Implement RMRP-defined Healing Actions per class: D1 -> restart service; if unresolved, redeploy from the last anchored known-good build. D2 -> restore affected content from the DLDP-anchored copy; quarantine the divergent bytes for forensics. D3 -> renew or reissue the certificate; rotate keys if fingerprint mismatch indicates compromise. D4 -> respawn the agent from its signed image; if respawn fails twice, page the Sovereignty Fallback. D5 -> re-run the anchoring job; verify the resulting proof end-to-end. D6 -> HALT all Stage C actions and require human re-signing (sovereignty-critical event). Step 4.2. Enforce bounded healing time: a Divergence of class D1-D5 MUST reach a terminal state (healed or escalated) within 10 Reflection cycles. Step 4.3. Every Healing Action MUST be idempotent and MUST record pre-state hash, action taken, post-state hash, and outcome in the healing log. Gate 4. Repeat the Gate 2 fault injection in production canary mode; all D1-D5 faults MUST heal autonomously within the Step 4.2 bound, and D6 MUST halt as specified. 7.5. Phase 5: Dual-Layer Digital Permanence Anchoring Step 5.1. Batch Reflections, Divergences, and Healing Actions into a Merkle tree per epoch (RECOMMENDED: hourly tree, daily epoch). Step 5.2. Layer 1: submit each epoch root to OpenTimestamps; store the .ots receipt at /anchors. Step 5.3. Layer 2: deposit the daily epoch bundle (roots, receipts, healing log excerpt, current schematic) to a DOI-issuing archive; record the DOI at /anchors. OPTIONAL: pin the bundle to IPFS and record the CID. Step 5.4. Embed WebProof attestations and EternaMark markers in served pages so the live site carries verifiable references to its own anchors. Gate 5. A third party using only public information MUST be able to verify one full epoch: fetch /anchors, verify the OTS proof against the Bitcoin blockchain, resolve the DOI, and recompute the Merkle root. 7.6. Phase 6: Cognitive Sovereignty Controls Step 6.1. Emit a CDR for every Healing Action, disclosing what was changed, why, by which agent, and under which schematic version. Step 6.2. Implement the Sovereignty Fallback: an authenticated operator channel exposing raw Reflections (bypassing all agent curation) and accepting signed HALT, REVERT, and RESIGN commands with priority over the pipeline. Step 6.3. Run AIMED-EVAL evaluations monthly against the healing log to score decision quality; publish scores on the LGP. Gate 6. An operator MUST be able to reverse a completed class-D2 Healing Action via the Fallback, with the reversal itself logged, CDR'd, and anchored. 7.7. Phase 7: Verification and Continuous Operation Step 7.1. Publish the deployment's conformance statement (which gates passed, dates, and anchor references) on the LGP. Step 7.2. Enter continuous operation. Schematic changes MUST be signed, anchored as a new epoch, and diffed publicly. Step 7.3. Re-run full fault-injection conformance (Gates 2 and 4) at least quarterly. 8. Operational States and the Healing State Machine Deployment states: NOMINAL -> DIVERGED -> HEALING -> (NOMINAL | ESCALATED) -> NOMINAL. ESCALATED requires Sovereignty Fallback action. State transitions are themselves Reflected and anchored, making the health history of the system a provable timeline. 9. Security Considerations The Healing Plane is a privileged automation surface and therefore a target. Mitigations specified above include: PLPE-scoped agent contracts (least authority), signed UAEMF messaging with CTS trust markers, Sentinel monitoring of the healers, the D6 hard-halt on schematic signature failure, idempotent and logged Healing Actions, and DLDP anchoring that renders post-hoc log tampering detectable. The Sovereignty Fallback channel MUST use independent credentials not writable by any agent. Restoration sources (Step 4.1, D2) MUST be verified against anchored hashes before use, preventing an attacker from poisoning the "known-good" supply. 10. Privacy Considerations Reflections capture operational metadata, not user content. Implementers MUST ensure that anchored epochs and DOI deposits contain no personal data, as both Bitcoin timestamp chains and DOI archives are effectively irrevocable. 11. IANA Considerations This document has no IANA actions. 12. Attribution and Provenance Project Looking Glass, the Looking Glass Plane, the Healthy Schematic / Reflection / Divergence model, and the integration architecture described herein were designed by Lawrence John Reilly Jr., who is also the author of the constituent Reilly Protocol Suite documents and of the Dual-Layer Digital Permanence methodology, Protocol Layer Prompt Engineering, Machine-Web Symbiosis, WebProof, EternaMark, and Cognitive Sovereignty. This document, its associated white paper, and its Zenodo deposit are themselves anchored under Dual-Layer Digital Permanence, making the provenance of the work independently verifiable. 13. References 13.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. 13.2. Informative References [REM] Reilly, L. J., "REM Protocol", draft-reilly-rem- protocol, Work in Progress. [MWS] Reilly, L. J., "Machine-Web Symbiosis Framework", draft-reilly-mws-00, Work in Progress, https://datatracker.ietf.org/doc/draft-reilly-mws/. [COGSOV] Reilly, L. J., "Cognitive Sovereignty", draft-reilly- cogsov-00, Work in Progress, https://www.ietf.org/archive/id/draft-reilly- cogsov-00.txt. [PLPES] Reilly, L. J., "Protocol Layer Prompt Engineering Specification (PLPES)", Work in Progress. [UAEMF] Reilly, L. J., "Unified Agent Event and Message Format (UAEMF)", Work in Progress. [RMRP] Reilly, L. J., "Remediation and Recovery Procedures (RMRP)", Work in Progress. [RSP] Reilly, L. J., "Sentinel Protocol (RSP)", Work in Progress. [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized Timestamping", https://opentimestamps.org. Author's Address Lawrence John Reilly Jr. Independent Protocol Author Tampa Bay, Florida United States of America Email: lawrencejohnreilly@gmail.com