Project Atlas: A Cognitive Behavioral Provenance and Integrity (CBPI) Backbone Instrument for Autonomous Agents
draft-reilly-atlas-00

Network Working Group                                     L. Reilly, Jr.
Internet-Draft                       REM Technologies & Consulting, LLC
Intended status: Informational                            5 August 2026
Expires: 6 February 2027

      Project Atlas: A Cognitive Behavioral Provenance and Integrity
             (CBPI) Backbone Instrument for Autonomous Agents
                         draft-reilly-atlas-00

Abstract

   This document specifies Project Atlas, a backbone instrument in
   which a pipeline of autonomous software agents continuously holds a
   constellation of live web endpoints under measurement, attestation,
   and remediation, with every agent behavior conditioned and recorded
   under the Cognitive Behavioral Provenance and Integrity (CBPI)
   framework [I-D.reilly-cbpi].  Atlas defines eight agent roles
   (Resolver, Reachability, Integrity, Provenance, Conditioning
   Authority, Drift, Functional Behavior Assessment, and Sentinel), a
   hash-linked Operant Provenance Chain of epochs, hash-linked
   Reinforcement Event Records, a per-agent Behavioral Drift Index, and
   a dual authority model in which the instrument operates either fully
   autonomously or under human oversight through an operator decision
   queue.  A live reference instrument implementing this document is
   deployed and publicly reachable.

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 6 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
   2.  Conventions and Terminology
   3.  Architecture Overview
     3.1.  The Constellation Under Load
     3.2.  The Epoch Cycle
   4.  Agent Roles
     4.1.  Resolver Agent
     4.2.  Reachability Agent
     4.3.  Integrity Agent
     4.4.  Provenance Agent
     4.5.  Conditioning Authority
     4.6.  Drift Agent
     4.7.  FBA Agent
     4.8.  Sentinel Agent
   5.  CBPI Instrumentation
     5.1.  Reinforcement Event Records
     5.2.  Operant Provenance Chain
     5.3.  Behavioral Drift Index
     5.4.  Functional Behavior Assessment
   6.  Authority Model: Autonomous and Human Oversight
   7.  Instrument API
   8.  Live Reference Instrument
   9.  Operational Considerations
   10. Security Considerations
   11. IANA Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Author's Address

1.  Introduction

   As autonomous agents assume operational responsibility for
   infrastructure -- monitoring it, attesting to its state, and
   remediating its failures -- the question shifts from whether agents
   can perform such work to whether their behavior while performing it
   can be trusted, measured, and governed.  The CBPI framework
   [I-D.reilly-cbpi] answers this by applying the instruments of
   behavior analysis to software agents: reinforcement events,
   provenance chains over behavior, drift measurement, and functional
   assessment of deviant behavior.

   Project Atlas is the backbone application of that framework.  Where
   [I-D.reilly-cbpi] defines the records and measures, Atlas deploys
   them against real infrastructure: a pipeline of eight agents that
   continuously performs live DNS resolution, live HTTPS reachability
   checks, and cryptographic content-integrity verification against a
   constellation of operating web endpoints, sealing every cycle of
   work into a verifiable hash-linked chain and conditioning every
   agent's behavior through reinforcement records issued by a
   Conditioning Authority.

   The name reflects the posture: the agents stand under the
   constellation and hold it up.  The instrument is "fully autonomous
   with human oversight" -- a phrase this document makes precise in
   Section 6 as two explicit authority modes with different disposition
   rules for remediation.

   This document is Informational.  It records the architecture and
   the live reference implementation so that the construction can be
   examined, reproduced, and criticized.

2.  Conventions and 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.

   Constellation:  The set of live endpoints the instrument holds under
      continuous measurement.

   Epoch:  One complete cycle of the agent pipeline over the full
      constellation.

   Operant Provenance Chain (OPC):  The hash-linked sequence of sealed
      epoch records, per [I-D.reilly-cbpi].

   Reinforcement Event Record (RER):  A hash-linked record of a
      reinforcement event (positive reinforcement, punishment, or
      extinction) issued against a named agent, per [I-D.reilly-cbpi].

   Behavioral Drift Index (BDI):  A scalar in [0,1] measuring an
      agent's deviation from its own established behavioral baseline,
      per [I-D.reilly-cbpi].

   Functional Behavior Assessment (FBA):  A structured
      antecedent/behavior/consequence record opened when an agent's
      BDI exceeds threshold, per [I-D.reilly-cbpi].

   Sentinel:  The remediating agent; the only agent whose actions
      change instrument state rather than merely measuring it.

   Operator:  The human authority in oversight mode.

3.  Architecture Overview

3.1.  The Constellation Under Load

   An Atlas instrument is configured with a constellation: an ordered
   set of endpoints, each identified by a stable identifier, a
   hostname, an HTTPS path, and a human-readable label.  The reference
   instrument's constellation comprises eight live endpoints of the
   Reilly Protocol Suite deployments, including the REM Protocol site,
   its Sentinel Loop page, and the HDRP, Orion, Multilarity, CBPI, and
   bulk-subtree-proofs instruments.  The constellation is a deployment
   parameter; any set of HTTPS endpoints MAY be configured.

3.2.  The Epoch Cycle

   The instrument advances in fixed-interval epochs (60 seconds in the
   reference instrument).  In each epoch, the eight agents of Section 4
   execute in a measure/condition/assess/seal order:

   1.  Field agents (Resolver, Reachability, Integrity) measure every
       constellation endpoint concurrently.

   2.  The Conditioning Authority issues RERs against the observed
       behavior of the field agents.

   3.  The Drift Agent recomputes each agent's BDI; the FBA Agent
       opens assessments for any agent over threshold; the Sentinel
       disposes of proposed remediations according to the authority
       mode.

   4.  The Provenance Agent seals the epoch -- endpoint results, BDI
       vector, RER chain head, pending-decision count, and timing --
       into the OPC.

   Because the epoch record embeds the RER chain head, the two hash
   chains are cross-linked: the behavior ledger is anchored inside the
   work ledger each epoch.

4.  Agent Roles

4.1.  Resolver Agent

   Performs live DNS resolution of every constellation hostname each
   epoch and records the resolved address and resolution latency.  The
   agent's behavior sample for the epoch is (all-resolved, mean
   resolution latency).

4.2.  Reachability Agent

   Performs a live HTTPS GET against each endpoint's configured path
   with a fixed service-level agreement (SLA) timeout (6 seconds in
   the reference instrument), recording status code and latency.  The
   agent MUST follow at most one redirect hop, so that an endpoint
   answering with a 301/302 toward its canonical host is judged on the
   canonical content rather than on the redirect response.  An
   endpoint is "holding" when it resolves and answers within SLA with
   a 2xx or 3xx status.

4.3.  Integrity Agent

   Computes a SHA-256 digest [RFC6234] over the retrieved content
   (bounded to the first 64 KiB) and compares it against a stored
   per-endpoint baseline.  The endpoint's integrity state is
   "baselined" on first observation, "stable" when the digest matches,
   and "changed" when it does not.  A "changed" state is not a fault;
   it is a fact about the content, and its disposition (accepting the
   new digest as baseline) is a Sentinel remediation subject to the
   authority mode.  Endpoints serving intentionally dynamic content
   will read "changed" recurrently; operators SHOULD either point the
   integrity check at a static representation or accept the recurrent
   rebaseline as the honest record of a moving surface.

4.4.  Provenance Agent

   Seals each epoch into the OPC.  Each epoch record carries the
   previous record's hash and its own SHA-256 over its canonical JSON
   serialization; the chain is verifiable in one pass by recomputation
   (Section 7).

4.5.  Conditioning Authority

   The CBPI core.  Each epoch it issues RERs against the field agents:
   positive reinforcement (type "R+") for conditioned behavior (all
   hosts resolved; all endpoints holding within SLA; all digests
   stable), punishment (type "P") for failures, with magnitude scaled
   to the fraction of the constellation affected, and extinction
   (type "EXT") when an FBA opens against an agent or when an operator
   rejects a Sentinel remediation.

4.6.  Drift Agent

   Maintains a rolling behavior window per agent (20 samples in the
   reference instrument) and computes the BDI as an equal-weight blend
   of latency drift (deviation of the recent half-window's mean
   latency from the earlier half-window's) and failure rate.  BDI 0
   is fully conditioned behavior; BDI 1 is full drift.

4.7.  FBA Agent

   When a field agent's BDI exceeds the drift threshold (0.35 in the
   reference instrument), the FBA Agent opens a Functional Behavior
   Assessment recording the antecedent (the window position where the
   shift began), the behavior (the BDI breach), and the consequence
   (attestations from the agent are flagged low-confidence until
   reconditioned), and proposes a reconditioning remediation.

4.8.  Sentinel Agent

   The sole effector.  It receives proposed remediations -- currently
   "rebaseline" (accept a changed content digest as the new integrity
   baseline for an endpoint) and "reset-window" (recondition a drifted
   agent by clearing its behavior window) -- and disposes of them
   according to the authority mode of Section 6.  Every applied
   remediation earns the Sentinel an R+ record; every operator
   rejection earns it an EXT record, so the Sentinel's own conduct is
   conditioned by the same instrument it serves.

5.  CBPI Instrumentation

5.1.  Reinforcement Event Records

   Each RER carries an identifier, timestamp, epoch number, subject
   agent, type (R+, P, or EXT), reason, magnitude in [0,1], the hash
   of the previous RER, and its own SHA-256 over its canonical
   serialization.  The RER sequence therefore forms its own hash
   chain, headed by the value embedded in each sealed epoch.

5.2.  Operant Provenance Chain

   Each epoch record carries: epoch number, timestamp, authority mode,
   holding count, per-endpoint results (resolution, reachability,
   status, latency, integrity state, digest), the BDI vector, the RER
   chain head, the pending-decision count, epoch duration, the
   previous epoch's hash, and its own hash.  Verification recomputes
   every record's hash and every link; a single mismatch identifies
   the broken epoch.

5.3.  Behavioral Drift Index

   BDI = 0.5 * min(|m_late - m_early| / m_early, 1) + 0.5 * f

   where m_early and m_late are the mean latencies of the earlier and
   later halves of the agent's behavior window and f is the failure
   rate over the window.  Alternative weightings MAY be used; the
   reference weighting is deliberately simple and disclosed.

5.4.  Functional Behavior Assessment

   FBA records follow the antecedent/behavior/consequence structure of
   applied behavior analysis as adopted by [I-D.reilly-cbpi], and each
   FBA binds a proposed remediation that enters the Sentinel's queue.

6.  Authority Model: Autonomous and Human Oversight

   The instrument operates in exactly one of two modes at any time,
   switchable at runtime:

   oversight:  Every Sentinel remediation enters a decision queue in
      state "pending" and has no effect until an operator resolves it.
      An approved decision is applied and recorded; a rejected
      decision is discarded and the Sentinel receives an EXT record.
      This is the human-on-the-loop posture consistent with the
      Sovereignty Fallback of [I-D.reilly-cogsov].

   autonomous:  The Sentinel applies remediations immediately, and the
      decision record is written in state "auto-applied" with the
      Sentinel named as resolver.  Human visibility is preserved --
      the queue, the RERs, and the OPC record everything -- but human
      approval is not awaited.

   In both modes the decision ledger is append-style and epoch-bound,
   so the mode in force at the time of every remediation is
   reconstructible from the chain.  Deployments exposing the mode
   switch and decision verdicts publicly SHOULD require an operator
   credential (Section 10).

7.  Instrument API

   An Atlas instrument exposes, at minimum:

   GET  /                          watch-floor dashboard
   GET  /api/state                 full instrument state
   GET  /api/constellation         configured endpoints, latest results
   GET  /api/epochs?limit=N        recent OPC records and chain head
   GET  /api/chain/verify          full-chain recomputation verdict
   GET  /api/rer?limit=N           recent RERs and RER chain head
   GET  /api/fba                   FBA records
   GET  /api/decisions             Sentinel decision queue
   POST /api/decisions/{id}/approve   operator approval (oversight)
   POST /api/decisions/{id}/reject    operator rejection (oversight)
   POST /api/mode                  {"mode":"autonomous"|"oversight"}
   GET  /healthz                   liveness

   All responses are JSON over HTTP [RFC9110].

8.  Live Reference Instrument

   A live reference instrument implementing this document in full is
   deployed and publicly reachable at:

      https://project-atlas-production-297c.up.railway.app/

   The deployment is a zero-dependency Node.js service (standard
   library only: crypto, dns, https, http) whose complete state
   surface is inspectable through the API of Section 7; in particular,

      https://project-atlas-production-297c.up.railway.app/api/state
      https://project-atlas-production-297c.up.railway.app/api/chain/verify

   return, respectively, the live state and an independent
   recomputation of the Operant Provenance Chain.  The instrument's
   state is held in memory per boot; the chain genesis restamps on
   redeployment, which is disclosed rather than concealed
   (Section 9).

9.  Operational Considerations

   In-memory state:  The reference instrument keeps a bounded window
      of epochs, RERs, FBAs, and decisions in memory and restarts its
      chains on redeploy.  Deployments requiring cross-boot continuity
      SHOULD anchor the chain head periodically using an external
      permanence layer, for which the author's Dual-Layer Digital
      Permanence methodology (external timestamping plus archival
      deposit) is the intended companion.

   Dynamic endpoints:  See Section 4.3.  Recurrent "changed" states on
      dynamic endpoints are expected and self-documenting.

   Canonical hostnames:  Constellation entries SHOULD name the
      canonical host that actually carries the TLS certificate and
      DNS record (for example, a "www." host where the apex is not
      configured); the one-hop redirect follow of Section 4.2 is a
      mitigation, not a substitute.

10.  Security Considerations

   The instrument's control surface (mode switch and decision
   verdicts) changes remediation behavior and MUST be protected in any
   deployment exposed to untrusted networks; the reference instrument
   supports an operator key conveyed in a request header, and
   deployments SHOULD enable it.  The hash chains provide tamper
   evidence, not tamper resistance: an actor with write access to the
   process can rewrite both chains, which is why external anchoring
   (Section 9) is the recommended companion.  Outbound measurement
   traffic is ordinary HTTPS GET at low rate against endpoints the
   deployer configures; deployers MUST NOT configure constellations of
   endpoints they are not authorized to probe.  Content digests bound
   to 64 KiB mean integrity attestation covers a prefix of large
   resources, which is disclosed here as a limit of the reference
   instrument.

11.  IANA Considerations

   This document has no IANA actions.

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.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash
              Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              May 2011.

   [I-D.reilly-cbpi]
              Reilly, Jr., L., "Cognitive Behavioral Provenance and
              Integrity (CBPI) for Autonomous AI Agents", Work in
              Progress, Internet-Draft, draft-reilly-cbpi-00, July
              2026.

12.2.  Informative References

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022.

   [I-D.reilly-cogsov]
              Reilly, Jr., L., "Cognitive Sovereignty", Work in
              Progress, Internet-Draft, draft-reilly-cogsov-00, July
              2026.

   [I-D.reilly-mws]
              Reilly, Jr., L., "Machine-Web Symbiosis (MWS)", Work in
              Progress, Internet-Draft, draft-reilly-mws-00, 2026.

   [I-D.reilly-multilarity]
              Reilly, Jr., L., "The Multilarity", Work in Progress,
              Internet-Draft, draft-reilly-multilarity-00, July 2026.

Author's Address

   Lawrence John Reilly, Jr.
   REM Technologies & Consulting, LLC
   Tampa Bay, Florida
   United States of America

   Email: lawrencejohnreilly@gmail.com