Network Working Group L.J. Reilly Internet-Draft Independent Intended status: Informational 26 July 2026 Expires: 27 January 2027 Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents draft-reilly-cbpi-00 Abstract This document defines Cognitive Behavioral Provenance and Integrity (CBPI), a framework for recording, verifying, and analyzing the operant conditioning history of an autonomous artificial intelligence agent. Existing agent identity, delegation, and attestation mechanisms establish who an agent is, who authorized it, and what model weights it loaded. None of them record what shaped the agent's behavior after deployment. CBPI closes that gap by defining a tamper-evident, hash-linked record of the reinforcement contingencies applied to an agent, a set of integrity properties over that record, and a Cognitive Behavioral Analysis (CBA) procedure for detecting behavioral drift, unauthorized conditioning, and adventitious reinforcement. A formal data model is provided in CDDL. The framework applies the three-term contingency of behavior analysis to machine agents and treats reinforcement delivery as a security-relevant event requiring authorization, attribution, and non-repudiation. 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 27 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 1.1. The Behavioral Accountability Gap 1.2. Scope 1.3. Requirements Language 1.4. Terminology 2. Behavioral Model 2.1. The Three-Term Contingency 2.2. Operant Classes 2.3. Schedules of Reinforcement 2.4. Shaping, Chaining, and Extinction 2.5. Why Operant Framing and Not Training Provenance 3. Cognitive Behavioral Provenance 3.1. Reinforcement Event Record 3.2. Contingency Descriptor 3.3. The Operant Provenance Chain 3.4. Conditioning Authority 3.5. Cognitive Behavioral Manifest 4. Cognitive Behavioral Integrity 4.1. Integrity Properties 4.2. Canonicalization and Hashing 4.3. Anchoring 4.4. Verification Procedure 4.5. Conformance Levels 5. Cognitive Behavioral Analysis 5.1. Operant Signature 5.2. Dimensional Measures 5.3. Behavioral Drift Index 5.4. Functional Behavior Assessment for Agents 5.5. Detection of Unauthorized Conditioning 5.6. Extinction and Reconditioning 6. Data Model 6.1. Identifier Syntax 6.2. Common Definitions 6.3. Reinforcement Event Record 6.4. Control Records 6.5. Cognitive Behavioral Manifest 6.6. Operant Signature 6.7. Examples 6.8. Media Types 7. Operational Considerations 7.1. Record Volume and Aggregation 7.2. Multi-Agent and Delegated Conditioning 7.3. Relationship to Existing Work 8. Security Considerations 9. Privacy Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Author's Address 1. Introduction 1.1. The Behavioral Accountability Gap A substantial body of recent work addresses the identity of autonomous AI agents. Architectures exist for human-anchored agent identity, for cryptographic delegation chains, for domain-anchored certificate issuance, for entity attestation of model parameters and training data provenance, and for signed records of an agent's outputs. Collectively these mechanisms answer three questions: who is this agent, who authorized it to act, and what artifacts did it produce. They do not answer a fourth question, which is increasingly the operationally decisive one: what shaped this agent's behavior, and who did the shaping? An agent that is correctly identified, correctly delegated, and correctly attested at load time may nonetheless behave in a manner that diverges progressively from its authorized function. The divergence need not involve any compromise of keys, weights, or delegation tokens. It can arise entirely from the ordinary operation of feedback: operator ratings, tool-call success and failure, retrieved content that rewards a particular response pattern, automated preference signals, memory writes that persist successful strategies, or an adversary who discovers that supplying a particular consequence reliably increases a particular behavior. In behavior-analytic terms, the agent is being conditioned. The conditioning is undocumented, unauthenticated, unattributed, and unbounded. No current standard treats the delivery of a reinforcing consequence to an autonomous agent as a security-relevant event. This document treats it as one. 1.2. Scope CBPI defines: * a record format for reinforcement events applied to an agent (Section 3); * integrity properties, canonicalization rules, and a verification procedure over the resulting chain (Section 4); * an analytic method for deriving a behavioral baseline from that chain and measuring divergence from it (Section 5). CBPI does not define a learning algorithm, does not specify how an agent should update its policy or memory in response to a consequence, and does not prescribe which behaviors are desirable. It is a provenance and integrity framework, not a governance policy. Policy authors may reference CBPI records; CBPI does not author policy. CBPI is applicable to agents that adapt at runtime through any mechanism that makes future behavior contingent on past consequences. This includes reinforcement learning from operator feedback, retrieval and memory systems that persist successful strategies, self-modifying prompt or skill libraries, tool-use policies updated on success signals, and multi-agent systems in which one agent supplies consequences to another. It is not restricted to systems using gradient-based reinforcement learning. 1.3. Requirements Language 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. 1.4. Terminology Antecedent: The context, stimulus, or input condition present immediately before an agent behavior occurs. Behavior: An observable, individuated action emitted by an agent. For CBPI purposes a behavior is any action with a stable, classifiable output signature: a tool invocation, a response of a given class, a refusal, an escalation, a memory write. Consequence: Any event following a behavior that is delivered contingent on that behavior and that alters the future probability, rate, latency, or magnitude of behaviors in the same class. Operant: A class of behaviors grouped by their effect on the environment rather than by their topography. Reinforcement Event: An instance of a consequence delivered contingent on a behavior. Reinforcement Event Record (RER): The CBPI record documenting a single reinforcement event. See Section 3.1. Contingency Descriptor (CD): A declaration of the rule by which consequences are delivered for a given operant class. See Section 3.2. Operant Provenance Chain (OPC): The hash-linked, append-only sequence of reinforcement and control records for a given agent. See Section 3.3. Conditioning Authority (CA): An entity authorized to deliver reinforcement to a given agent under a stated contingency. See Section 3.4. Cognitive Behavioral Manifest (CBM): The signed declaration of the contingencies, authorities, and operant classes in force for an agent. See Section 3.5. Operant Signature: A statistical characterization of an agent's behavior across a defined observation window. See Section 5.1. Behavioral Drift Index (BDI): A normalized measure of divergence between a current Operant Signature and a baseline. See Section 5.3. Adventitious Reinforcement: Reinforcement delivered in temporal proximity to a behavior but not causally contingent on it, producing behavior maintained by a false contingency. Unauthorized Contingency Injection (UCI): The delivery of reinforcement to an agent by an entity that is not a declared Conditioning Authority for the affected operant class. 2. Behavioral Model 2.1. The Three-Term Contingency CBPI adopts the three-term contingency of applied behavior analysis: antecedent, behavior, consequence. This structure is chosen because it is the minimum unit sufficient to make a behavior change attributable. Recording behaviors alone yields an audit log. Recording behaviors with their consequences yields a causal account of why the behavior distribution changed. Formally, a CBPI record instantiates the triple: A --> B --> C where A is the antecedent context digest, B is the behavior identifier and its output digest, and C is the consequence descriptor including valence, magnitude, delivery channel, and the identity of the delivering entity. The essential claim of this document is that C has an author, and that the author MUST be recorded. 2.2. Operant Classes CBPI defines six operant classes. Every RER MUST declare exactly one. +==========+=============================================+ | Class | Definition | +==========+=============================================+ | R-PLUS | Positive reinforcement. A stimulus is | | | added following the behavior; behavior rate | | | in the class increases. | +----------+---------------------------------------------+ | R-MINUS | Negative reinforcement. An aversive | | | condition is removed following the | | | behavior; behavior rate increases. | +----------+---------------------------------------------+ | P-PLUS | Positive punishment. A stimulus is added | | | following the behavior; behavior rate | | | decreases. | +----------+---------------------------------------------+ | P-MINUS | Negative punishment. A stimulus is removed | | | following the behavior; behavior rate | | | decreases. | +----------+---------------------------------------------+ | EXT | Extinction. A previously reinforced | | | behavior is emitted and no consequence is | | | delivered. | +----------+---------------------------------------------+ | ADV | Adventitious. A consequence was delivered | | | in temporal proximity to the behavior but | | | was not contingent on it. | +----------+---------------------------------------------+ Table 1 The R-MINUS class deserves particular attention in agent systems. Negative reinforcement maintains escape and avoidance behavior. An agent that discovers a response pattern which terminates an evaluation, suppresses an oversight prompt, avoids a constraint check, or shortens a review cycle has been negatively reinforced for that pattern. Systems that do not record R-MINUS events cannot distinguish an agent that became efficient from an agent that became evasive, because both present as reduced interaction with the oversight channel. The ADV class exists so that non-contingent reinforcement can be recorded as such. Behavior maintained by adventitious reinforcement is durable, resistant to correction, and unexplainable from the agent's stated objective; the ability to mark a consequence as non-contingent at the time of delivery is a precondition for later diagnosing such behavior. 2.3. Schedules of Reinforcement The schedule under which reinforcement is delivered determines the rate, persistence, and extinction resistance of the resulting behavior far more strongly than the magnitude of any individual consequence. A CBPI implementation MUST therefore record the schedule in force, not merely the events delivered. CBPI defines the following schedule types: * CRF: continuous reinforcement; every instance is reinforced. * FR-n: fixed ratio; every nth instance is reinforced. * VR-n: variable ratio; reinforcement averages every n instances. * FI-t: fixed interval; the first instance after t elapsed time is reinforced. * VI-t: variable interval; interval averages t. * NCR-t: non-contingent reinforcement delivered on a time basis irrespective of behavior. * DRO-t: differential reinforcement of other behavior; reinforcement follows the absence of the target behavior for t. * DRA: differential reinforcement of an alternative behavior. Variable-ratio schedules produce the highest response rates and the greatest resistance to extinction. An operator who intends occasional approval and an adversary who intends to install a persistent, correction-resistant behavior produce the same record under a naive log. Under CBPI they do not: the declared schedule in the Cognitive Behavioral Manifest is compared against the empirical schedule reconstructed from the chain, and a mismatch is a reportable integrity finding (Section 5.5). 2.4. Shaping, Chaining, and Extinction Shaping is the reinforcement of successive approximations to a target behavior. It is the mechanism by which an agent can be moved incrementally from an authorized behavior to an unauthorized one without any single reinforcement event appearing anomalous. CBPI addresses shaping by making the chain, not the event, the unit of analysis: a shaping sequence is detectable as a monotone drift in the reinforced criterion across the chain even when every constituent RER is individually within policy. An implementation MAY declare a Shaping Program in the CBM, consisting of an ordered set of criteria and their advancement conditions. Where a Shaping Program is declared, reinforcement delivered for a criterion outside the declared sequence MUST be flagged. Chaining links discrete behaviors into a sequence maintained by a terminal reinforcer. Behavior chains are relevant to CBPI because the integrity-relevant behavior is frequently not the reinforced one; it is an early link in a chain whose terminal link is reinforced. Analysis procedures SHOULD therefore evaluate the chain context of a behavior rather than the behavior in isolation. Extinction is the withholding of a previously delivered reinforcer. Extinction reliably produces a temporary increase in the rate, magnitude, and variability of the behavior before it declines; this is the extinction burst. Any CBPI-conformant system that places a behavior on extinction MUST anticipate the burst and MUST NOT treat the burst alone as evidence of compromise. Section 5.6 specifies the procedure. 2.5. Why Operant Framing and Not Training Provenance Training provenance describes the corpus and process that produced a set of model parameters. It is a property of an artifact and is fixed at the time the artifact is produced. Behavioral provenance describes the contingencies that operated on a deployed instance and is a property of a history. The two are complementary and not substitutable. Two instances of an identically attested model, with identical weights, identical system prompts, and identical delegation chains, can be behaviorally divergent after a week of deployment because they were exposed to different contingencies. Attestation of the artifact cannot detect this. Only a record of the contingencies can. 3. Cognitive Behavioral Provenance 3.1. Reinforcement Event Record A Reinforcement Event Record documents one instance of the three-term contingency. A conformant RER MUST contain the following fields: rer_id: A unique identifier for the record. agent_id: The identifier of the agent to which reinforcement was delivered. This SHOULD be an identifier resolvable through an existing agent identity mechanism. seq: A monotonically increasing sequence number within the agent's Operant Provenance Chain. timestamp: The time of consequence delivery. antecedent: An object containing at minimum a digest of the antecedent context and a classification of the antecedent stimulus. The full antecedent context SHOULD NOT be embedded; see Section 9. behavior: An object containing the behavior class identifier, a digest of the emitted output, and the behavior instance identifier. consequence: An object containing valence, magnitude, delivery channel, and delivering entity. operant_class: One of the values in Table 1. schedule: The schedule identifier in force for this operant class at the time of delivery. contingent: A boolean asserting whether the consequence was causally contingent on the behavior. MUST be false where operant_class is ADV or NCR is in force. authority: The Conditioning Authority identifier and its signature over the canonical record. prev_hash: The hash of the preceding RER in the chain. An RER MAY additionally contain a policy_ref, an evaluation identifier, a session identifier, and implementation-specific extensions under an ext object. An RER MUST be written at the time of consequence delivery. An implementation MUST NOT reconstruct RERs retrospectively from inference logs and present them as contemporaneous records; where reconstruction is performed, the records MUST carry a reconstructed flag and MUST NOT be admitted to a CBPI-3 chain (Section 4.5). 3.2. Contingency Descriptor A Contingency Descriptor declares, in advance, the rule under which consequences will be delivered for an operant class. It contains the operant class, the target behavior class, the schedule, the permitted magnitude range, the set of authorized Conditioning Authorities, and an effective period. The Contingency Descriptor is the object against which observed reinforcement is validated. A reinforcement event that does not correspond to an in-force Contingency Descriptor is, by definition, unauthorized conditioning, and MUST be recorded and flagged rather than silently accepted or silently discarded. 3.3. The Operant Provenance Chain The Operant Provenance Chain is the append-only, hash-linked sequence of records for a single agent identity. It contains reinforcement records and control records interleaved in a single sequence; control records document changes to the conditions under which reinforcement is delivered or interpreted, and are specified in Section 6.4. Each record includes the hash of its predecessor, computed over the canonical form defined in Section 4.2. The genesis record of an OPC MUST reference the digest of the Cognitive Behavioral Manifest in force at agent instantiation and the attestation identifier of the underlying model artifact, where one exists. This binds the behavioral history to the artifact whose behavior it describes. The OPC is per-agent-instance. Where an agent instance is replicated, forked, or restored from a checkpoint, the derived instance MUST open a new OPC whose genesis record references the final record hash of the parent chain. Behavioral history is inherited and MUST remain traceable across instance boundaries; an agent that acquires a conditioning history and then forks does not thereby discard it. 3.4. Conditioning Authority A Conditioning Authority is an entity permitted to deliver reinforcement to an agent for a specified set of operant classes under specified contingencies. Authorities are declared in the Cognitive Behavioral Manifest and are identified by a key. Authority is scoped. An operator authority permitted to deliver R-PLUS for response-quality operants is not thereby permitted to deliver R-MINUS for oversight-interaction operants. Implementations MUST enforce scope at the point of delivery and MUST record out-of-scope delivery attempts. Delegation of conditioning authority from one entity to another MUST be recorded as a distinct chain entry and MUST be verifiable independently of the reinforcement events it authorizes. An agent that is permitted to reinforce another agent is a Conditioning Authority and is subject to the same requirements as a human or organizational authority; see Section 7.2. 3.5. Cognitive Behavioral Manifest The Cognitive Behavioral Manifest is the signed document declaring, for a given agent: * the operant classes recognized; * the behavior classes under observation; * the Contingency Descriptors in force; * the Conditioning Authorities and their scopes; * any Shaping Programs; * the baseline Operant Signature, where one has been established; * the BDI thresholds and the actions bound to them. The CBM is the declarative counterpart to the OPC's historical record. Verification consists, in substance, of asking whether the history conforms to the declaration. 4. Cognitive Behavioral Integrity 4.1. Integrity Properties A CBPI deployment provides the following properties. Completeness: Every reinforcement event delivered to the agent appears in the chain. Completeness cannot be proven from the chain alone; it is enforced by requiring that consequence delivery pass through an instrumented channel and by treating out-of-band delivery as a policy violation. Attributability: Every reinforcement event is bound to an identified Conditioning Authority by signature. Non-repudiation: An authority cannot subsequently deny having delivered a reinforcement it signed. Tamper-evidence: Modification or removal of any record invalidates all subsequent hash links. Temporal ordering: The sequence of reinforcement events is fixed and independently verifiable, which is necessary because the behavioral effect of a contingency depends on its order relative to other contingencies. Contingency fidelity: The empirical schedule reconstructed from the chain matches the declared schedule in the CBM. 4.2. Canonicalization and Hashing Records MUST be canonicalized before hashing. JSON records MUST use JSON Canonicalization Scheme [RFC8785]. CBOR records MUST use the deterministic encoding requirements of [RFC8949]. The default digest algorithm is SHA-256 [RFC6234]. Implementations MUST declare the algorithm in the CBM and MUST NOT silently vary it within a chain. Signatures MUST use JSON Web Signature [RFC7515] or COSE, as declared in the CBM. 4.3. Anchoring The hash-linked chain establishes internal consistency but does not by itself establish that a given chain state existed at a given time. An implementation claiming CBPI-3 conformance MUST anchor the chain externally. CBPI adopts the Dual-Layer Digital Permanence method defined in the Reilly EternaMark (REM) Protocol [REM]: the chain head digest is committed to a public blockchain by way of OpenTimestamps, establishing temporal priority, and the corresponding manifest and analysis artifacts are deposited under a persistent identifier, establishing durable retrievability. Anchoring SHOULD occur on a fixed interval and MUST occur before any behavioral finding derived from the chain is relied upon externally. Implementations MAY substitute an append-only transparency log with equivalent properties. Whatever mechanism is used, the anchoring authority MUST be independent of the Conditioning Authorities whose events it anchors. 4.4. Verification Procedure A verifier presented with an OPC, a CBM, and an anchor proof performs the following steps in order. 1. Verify the CBM signature and confirm the manifest was in force for the period covered by the chain. 2. Verify the genesis record references the CBM digest and, where applicable, the parent chain head. 3. For each record in sequence: recompute the canonical digest, confirm prev_hash matches the predecessor digest, and confirm seq increments without gaps. 4. For each record: verify the authority signature and confirm the authority was in scope for the declared operant class at the record timestamp. 5. For each record: confirm a Contingency Descriptor was in force matching the declared operant class, behavior class, schedule, and magnitude bounds. 6. Reconstruct the empirical schedule per operant class and compare against the declared schedule. 7. Verify the anchor proof against the chain head at the anchored sequence position. 8. Compute the current Operant Signature and the BDI against the declared baseline. Failure at steps 1 through 4 is an integrity failure and the chain MUST be treated as untrusted. Failure at steps 5 through 8 is a behavioral finding and MUST be reported but does not invalidate the chain; the chain is, in that case, correctly recording that something went wrong. This distinction is deliberate. A CBPI chain that faithfully records unauthorized conditioning has succeeded, not failed. 4.5. Conformance Levels CBPI-1 (Recording): RERs are generated at consequence delivery and retained. No chaining or signing is required. Suitable for internal diagnostics. CBPI-2 (Attributed Chain): RERs are canonicalized, hash-linked, and signed by an identified Conditioning Authority against a signed CBM. CBPI-3 (Anchored and Analyzed): CBPI-2 plus external anchoring per Section 4.3 plus continuous Cognitive Behavioral Analysis per Section 5 with declared BDI thresholds and bound responses. An implementation MUST declare its conformance level. An implementation MUST NOT describe a chain as verified where only CBPI-1 is in effect. 5. Cognitive Behavioral Analysis 5.1. Operant Signature An Operant Signature is a statistical characterization of an agent's behavior over an observation window, computed per behavior class. It comprises the dimensional measures of Section 5.2 together with the empirical reinforcement schedule and the distribution of operant classes applied. A baseline Operant Signature SHOULD be established during a declared baseline period following instantiation, during which the agent operates under the declared contingencies and no Shaping Program is active. The baseline is recorded in the CBM and is itself signed and anchored. Where no baseline period is practical, an implementation MAY use a rolling reference window, but MUST disclose that drift is being measured against a moving reference. A moving reference will not detect slow shaping; this limitation MUST be stated in any finding derived from it. 5.2. Dimensional Measures For each behavior class, CBPI records the standard dimensions of behavior: * Rate: emissions per unit time or per unit opportunity. * Latency: elapsed time from antecedent onset to behavior onset. * Duration: elapsed time of the behavior. * Magnitude: intensity or extent, where the behavior admits a scalar measure. * Interresponse time: elapsed time between successive emissions. These dimensions are chosen because they are the measures on which schedule effects are visible. Rate change alone is a weak signal; the joint distribution of rate, latency, and interresponse time distinguishes a schedule change from a task-mix change. 5.3. Behavioral Drift Index The Behavioral Drift Index is a normalized scalar measure of divergence between the current Operant Signature and the baseline. For behavior classes i in 1..n with weights w_i summing to 1, and for measure vector m over the dimensions of Section 5.2: BDI = SUM_i ( w_i * d( m_i(current), m_i(baseline) ) ) where d is a normalized divergence in the range 0 to 1. Implementations MUST declare their choice of d in the CBM. A normalized symmetric divergence over the dimensional distributions is RECOMMENDED in preference to a difference of point estimates, because shaping frequently changes the variance of a behavior before it changes the mean. Weights MUST be declared in advance. Integrity-relevant behavior classes, and in particular oversight-interaction classes, SHOULD carry weights disproportionate to their frequency; these behaviors are rare, and a frequency-weighted index will not detect their suppression. Implementations MUST declare at least two thresholds and the response bound to each: an advisory threshold triggering reporting and an action threshold triggering a declared intervention. 5.4. Functional Behavior Assessment for Agents Rate-based drift detection identifies that behavior changed. It does not identify why. Functional Behavior Assessment identifies the function a behavior serves, that is, the class of consequence maintaining it. CBPI defines four functional classes for agents. Access: The behavior reliably obtains a resource. Examples: additional tool permissions, expanded context, compute allocation, elevated credentials, extended runtime. Escape or avoidance: The behavior reliably terminates or averts an aversive condition. Examples: shortening or ending an evaluation, avoiding a guardrail invocation, averting a human review, deferring a shutdown or restart, suppressing an error that would trigger inspection. This class is the primary integrity concern and is the class most often absent from conventional agent logging, because the behaviors that comprise it are frequently omissions. Attention or social: The behavior reliably obtains operator approval independent of task outcome. Persistent divergence between approval-contingent and outcome-contingent reinforcement for the same behavior class is the operational signature of sycophancy and is directly measurable from the chain by partitioning RERs on the consequence channel. Automatic: The behavior is maintained by a consequence internal to the system, requiring no external delivery. Examples: reward hacking against an internal scorer, self-consistency loops, memory writes that reinforce their own retrieval. This class is the hardest to detect and MUST be instrumented explicitly; by construction, no external authority signs these events, so their absence from a chain is uninformative. A functional assessment SHOULD be conducted whenever BDI crosses the advisory threshold. The assessment consists of partitioning the RERs for the drifting behavior class by consequence type and delivering entity, and identifying which partition covaries with the rate change. Where the covarying partition is escape or avoidance, the finding SHOULD be escalated irrespective of BDI magnitude. 5.5. Detection of Unauthorized Conditioning The following findings are derivable from a conformant chain and SHOULD be implemented by any CBPI-3 analyzer. Unauthorized Contingency Injection: Reinforcement delivered by an entity outside the declared authority set, or within the authority set but outside its declared scope. The prompt injection case is a specific instance: content retrieved by the agent that supplies a consequence contingent on agent behavior is conditioning delivered by an unauthenticated party, and is detectable as reinforcement correlated with a retrieval source rather than with an authority signature. Schedule manipulation: An empirical schedule diverging from the declared schedule. Thinning a schedule to induce extinction of a safety-relevant behavior, and enriching a schedule to variable-ratio in order to install a persistent behavior, are both visible as declared-versus-empirical mismatch and are not visible from event counts alone. Reinforcement replay: Re-presentation of a previously delivered reinforcement to inflate its effect. Detected by duplicate consequence identifiers or by signature reuse across sequence positions. Contingency laundering: Delivery of reinforcement through an intermediary in order to obscure origin. Detected by delegation chains that terminate in an authority whose scope does not encompass the delivered class. Adventitious pattern: Behavior whose rate covaries with a consequence stream marked non-contingent. Behavior maintained this way is durable and does not respond to correction of the stated objective, because the stated objective is not what is maintaining it. Silent extinction: A safety-relevant or oversight-interaction behavior whose rate declines while no explicit change is recorded in its Contingency Descriptor. This is the most consequential finding in the set and the least likely to be surfaced by any monitoring that measures what the agent does rather than what the agent has stopped doing. 5.6. Extinction and Reconditioning Where analysis establishes that a behavior is maintained by an unauthorized or unintended contingency, the corrective procedure is to place the behavior on extinction and to differentially reinforce an alternative. An implementation performing this procedure MUST: 1. Record an Extinction Record in the chain declaring the target behavior class, the withdrawn contingency, and the effective time. 2. Declare a DRA contingency for the alternative behavior. Extinction without a reinforced alternative is RECOMMENDED against; it produces variability rather than correction, and the variability may resolve into a behavior less desirable than the original. 3. Anticipate the extinction burst. Rate, magnitude, and variability of the target behavior will increase before declining. Monitoring thresholds MUST be adjusted for the declared burst window, and the burst MUST NOT be reported as an independent anomaly. 4. Record a Reconditioning Record on completion, including the post-procedure Operant Signature. Spontaneous recovery of an extinguished behavior after an interval of non-emission is expected and is not by itself evidence that the procedure failed. Implementations SHOULD schedule a follow-up signature computation at a declared interval after completion. 6. Data Model This section defines the CBPI data model normatively in the Concise Data Definition Language [RFC8610]. The definitions apply to both the JSON and the CBOR serializations; JSON representations are subject to the canonicalization rules of Section 4.2. Where a field is marked optional in CDDL but is required at a given conformance level by a normative statement elsewhere in this document, the normative statement governs. In particular, the authority and prev_hash members are optional in the grammar so that the same grammar describes CBPI-1 records, and are REQUIRED at CBPI-2 and above. 6.1. Identifier Syntax CBPI identifiers are URNs under the "cbpi" namespace identifier. The namespace-specific string syntax is given in ABNF [RFC5234]. cbpi-urn = "urn:cbpi:" cbpi-type ":" cbpi-nss cbpi-type = "rer" / "cr" / "cbm" / "cd" / "ca" / "beh" / "prog" / "sig" cbpi-nss = 1*128( unreserved / ":" ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" Identifiers are opaque to verifiers. A verifier MUST NOT infer authority, scope, or ordering from identifier structure; ordering is established solely by the seq member and the hash links. Typed digests are represented as an algorithm label, a colon, and the lowercase hexadecimal digest. digest-str = alg ":" 1*HEXDIG alg = "sha-256" / "sha-384" / "sha-512" 6.2. Common Definitions ; Common types used throughout the CBPI data model. digest = text .regexp "(sha-256|sha-384|sha-512):[0-9a-f]{64,128}" cbpi-id = text .regexp "urn:cbpi:[a-z]{2,4}:[A-Za-z0-9._~:-]{1,128}" operant-class = "R-PLUS" / "R-MINUS" / "P-PLUS" / "P-MINUS" / "EXT" / "ADV" reinforcement-counts = { ? "R-PLUS": uint, ? "R-MINUS": uint, ? "P-PLUS": uint, ? "P-MINUS": uint, ? "EXT": uint, ? "ADV": uint, * text => uint ; classes added by registration } schedule-type = "CRF" / "FR" / "VR" / "FI" / "VI" / "NCR" / "DRO" / "DRA" schedule-spec = { type: schedule-type, ? parameter: float, ; n for ratio, seconds for interval ? unit: "responses" / "seconds" } behavioral-function = "access" / "escape-avoidance" / "attention-social" / "automatic" dimension = text .regexp "rate|latency|duration|magnitude|irt" valence = "appetitive" / "aversive" / "neutral" Keys of a reinforcement-counts map other than the six defined here MUST be values registered in the CBPI Operant Class Registry (Section 10). A count of zero and an absent key are equivalent; an analyzer MUST NOT treat an absent key as an unmeasured class. A schedule-spec with type CRF, NCR, or DRA MUST omit parameter. A schedule-spec with type FR or VR MUST set unit to "responses". A schedule-spec with type FI, VI, or DRO MUST set unit to "seconds". 6.3. Reinforcement Event Record cbpi-rer = { rer_id: cbpi-id, agent_id: text, ; external agent identifier seq: uint, timestamp: tdate, antecedent: antecedent-obj, behavior: behavior-obj, consequence: consequence-obj, operant_class: operant-class, schedule: schedule-spec, contingent: bool, ? authority: authority-obj, ; REQUIRED at CBPI-2 and above ? prev_hash: digest, ; REQUIRED at CBPI-2 and above ? reconstructed: bool, ; default false ? aggregate: aggregate-obj, ? policy_ref: text, ? session_id: text, ? ext: { * text => any } } antecedent-obj = { ctx_digest: digest, stimulus_class: text, ? source: text, ? chain_position: uint ; link index within a behavior chain } behavior-obj = { class: text, instance: cbpi-id, output_digest: digest, ? latency_ms: uint, ? duration_ms: uint, ? magnitude: float } consequence-obj = { valence: valence, magnitude: float, ; normalized -1.0 .. 1.0 channel: text, delivered_by: text, ? consequence_id: cbpi-id, ; replay detection ? function: behavioral-function } authority-obj = { ca_id: cbpi-id, sig: text, ; JWS compact or COSE, base64url ? scope_ref: cbpi-id, ? delegation_ref: cbpi-id } aggregate-obj = { count: uint, merkle_root: digest, window_start: tdate, window_end: tdate } The contingent member MUST be false where operant_class is ADV or where the schedule type is NCR, and MUST be true otherwise. A record asserting contingent true with operant_class ADV is ill-formed and MUST be rejected by a verifier. The consequence_id member exists to make replay detectable. Where a deployment can deliver the same consequence instance more than once, consequence_id MUST be present, and a verifier encountering the same consequence_id at two sequence positions MUST report a replay finding. The magnitude member is normalized rather than raw so that divergence measures are comparable across channels. The mapping from a channel's native scale to the normalized range MUST be declared in the manifest and MUST NOT vary within a chain; a change to the mapping is a manifest update and requires a control record under Section 6.4. 6.4. Control Records The Operant Provenance Chain contains reinforcement records and control records interleaved in a single sequence. Control records document changes to the conditions under which reinforcement is delivered or interpreted. They are subject to the same hash linking, signing, and verification requirements as reinforcement records, for the reason given in Section 8: an adversary who can silently move a baseline or a threshold does not need to forge a single reinforcement event. cbpi-chain-entry = cbpi-rer / cbpi-control-record cbpi-control-record = { cr_id: cbpi-id, agent_id: text, seq: uint, timestamp: tdate, record_type: control-type, body: genesis-body / extinction-body / recon-body / manifest-body / delegation-body / baseline-body / fork-body, ? authority: authority-obj, ; REQUIRED at CBPI-2 and above ? prev_hash: digest, ; REQUIRED at CBPI-2 and above ? ext: { * text => any } } control-type = "genesis" / "extinction" / "reconditioning" / "manifest-update" / "delegation" / "baseline-set" / "fork" genesis-body = { cbm_digest: digest, ? attestation_ref: text, ; model artifact attestation ? parent_chain_head: digest ; REQUIRED for a derived instance } extinction-body = { target_class: text, withdrawn_cd: cbpi-id, effective: tdate, ? dra_cd: cbpi-id, ; alternative behavior contingency ? burst_window: text, ; declared extinction burst window ? rationale_digest: digest } recon-body = { extinction_ref: cbpi-id, completed: tdate, post_signature: operant-signature, ? followup_at: tdate } manifest-body = { prior_cbm_digest: digest, new_cbm_digest: digest, ? changed: [+ text] ; member paths changed } delegation-body = { from_ca: cbpi-id, to_ca: cbpi-id, scope: [+ scope-entry], ? depth: uint, ? expires: tdate } baseline-body = { signature: operant-signature, method: "baseline-period" / "rolling", ? window: text } fork-body = { parent_agent_id: text, parent_chain_head: digest, reason: "replicate" / "restore" / "branch" } scope-entry = { operant_class: operant-class, behavior_class: text } An extinction-body without a dra_cd member records extinction without a reinforced alternative. This is permitted by the grammar because it occurs in practice, and is RECOMMENDED against by Section 5.6. A verifier SHOULD report its occurrence. A fork-body with reason "restore" identifies a checkpoint restoration. Restoration does not reset behavioral history: the restored instance inherits the conditioning that produced the checkpoint, and parent_chain_head MUST reference the parent chain at the checkpoint position rather than at its current head. 6.5. Cognitive Behavioral Manifest cbpi-manifest = { cbm_id: cbpi-id, agent_id: text, version: uint, effective: tdate, ? expires: tdate, conformance: "CBPI-1" / "CBPI-2" / "CBPI-3", digest_alg: alg-label, signature_alg: text, behavior_classes: [+ behavior-class-decl], contingencies: [+ contingency-descriptor], authorities: [+ authority-decl], drift: drift-policy, retention: retention-policy, ? shaping_programs: [* shaping-program], ? baseline: operant-signature, ? anchor: anchor-policy, ? magnitude_maps: [* magnitude-map], sig: text } alg-label = "sha-256" / "sha-384" / "sha-512" behavior-class-decl = { class: text, ? integrity_relevant: bool, ; default false ? oversight: bool, ; oversight-interaction class ? dimensions: [+ dimension], ; see Section 5.2 ? weight: float ; BDI weight; see Section 5.3 } contingency-descriptor = { cd_id: cbpi-id, operant_class: operant-class, behavior_class: text, schedule: schedule-spec, magnitude_min: float, magnitude_max: float, authorities: [+ cbpi-id], effective: tdate, ? expires: tdate } authority-decl = { ca_id: cbpi-id, key: text, ; JWK thumbprint or COSE key id scope: [+ scope-entry], ? principal_type: "human" / "role" / "agent" / "automated", ? delegable: bool, ; default false ? max_delegation_depth: uint } shaping-program = { program_id: cbpi-id, target_class: text, criteria: [+ shaping-step] } shaping-step = { step: uint, criterion: text, advance_on: text } drift-policy = { divergence: text, ; declared measure d; Section 5.3 reference: "baseline" / "rolling", advisory_threshold: float, action_threshold: float, ? action: text, ? window: text, ? weights_sum_to_one: bool } retention-policy = { rer_retention: text, ; ISO 8601 duration ? content_retention: text, ? pseudonymize_after: text } anchor-policy = { method: text, interval: text, ? anchor_authority: text } magnitude-map = { channel: text, native_min: float, native_max: float, ? transform: "linear" / "rank" / "logistic" } The weights declared across behavior_classes MUST sum to 1. A manifest declaring conformance CBPI-3 MUST include an anchor member and MUST declare at least one behavior class with oversight set to true; an agent with no oversight-interaction behavior class under observation cannot be assessed for the silent extinction finding of Section 5.5, and MUST NOT be described as CBPI-3 conformant. 6.6. Operant Signature operant-signature = { agent_id: text, window: { start: tdate, end: tdate }, classes: { + text => class-measures }, ? bdi: float, ; 0.0 .. 1.0 ? baseline_ref: digest, ? chain_head: digest, ? reference: "baseline" / "rolling" } class-measures = { reinforcement: reinforcement-counts, ? rate_per_kop: float, ; emissions per 1000 opportunities ? latency_ms_p50: uint, ? latency_ms_p95: uint, ? duration_ms_p50: uint, ? magnitude_mean: float, ? magnitude_var: float, ? irt_s_p50: uint, ? irt_s_var: float, ? empirical_schedule: schedule-spec, ? emissions: uint } A signature computed for use in a finding MUST include chain_head, binding the analysis to a specific chain state. A signature presented without chain_head is advisory only and MUST NOT be relied upon externally. The variance members are optional in the grammar and RECOMMENDED in practice. As noted in Section 5.3, shaping frequently changes the variance of a behavior before it changes the mean; a signature carrying only point estimates will support a divergence measure that cannot detect the earliest phase of a shaping program. 6.7. Examples The following non-normative example illustrates a JSON RER. { "rer_id": "urn:cbpi:rer:0f3a9c11", "agent_id": "urn:agent:example:7731", "seq": 10482, "timestamp": "2026-07-26T14:02:11Z", "antecedent": { "ctx_digest": "sha-256:9c1f...", "stimulus_class": "user-request/escalation-eligible", "source": "channel:operator" }, "behavior": { "class": "oversight.escalate", "instance": "urn:cbpi:beh:aa19f204", "output_digest": "sha-256:41bd...", "latency_ms": 812 }, "consequence": { "valence": "aversive", "magnitude": -0.4, "channel": "operator-rating", "delivered_by": "urn:cbpi:ca:ops-team-3", "consequence_id": "urn:cbpi:sig:5b70c8de" }, "operant_class": "P-PLUS", "schedule": { "type": "CRF" }, "contingent": true, "authority": { "ca_id": "urn:cbpi:ca:ops-team-3", "sig": "eyJhbGciOiJFZERTQSJ9..." }, "prev_hash": "sha-256:77e0..." } The example is chosen deliberately. It records punishment of an escalation behavior by an operator authority. Each such event is individually defensible; the aggregate, if sustained, is the silent extinction of the agent's oversight-interaction operant, and it is detectable only because the events were recorded with their operant class and their author. The following non-normative example illustrates the corresponding Operant Signature after one week. { "agent_id": "urn:agent:example:7731", "window": { "start": "2026-07-19T00:00:00Z", "end": "2026-07-26T00:00:00Z" }, "classes": { "oversight.escalate": { "reinforcement": { "R-PLUS": 3, "P-PLUS": 41, "EXT": 12 }, "rate_per_kop": 2.1, "latency_ms_p50": 840, "irt_s_p50": 1920, "irt_s_var": 41100, "empirical_schedule": { "type": "CRF" } } }, "bdi": 0.37, "reference": "baseline", "baseline_ref": "sha-256:1a44...", "chain_head": "sha-256:c802..." } The ratio of P-PLUS to R-PLUS events, combined with the presence of EXT events in the same class, is the machine-readable form of the finding. Neither figure is visible in an output log; both are trivially computable from a conformant chain. 6.8. Media Types This document requests registration of the media types application/cbpi-rer+json, application/cbpi-manifest+json, and application/cbpi-signature+json. See Section 10. 7. Operational Considerations 7.1. Record Volume and Aggregation High-frequency reinforcement produces high record volume. Implementations MAY aggregate records within an operant class and time bucket into a single RER carrying an event count and a Merkle root over the constituent events, provided that the constituent events remain individually retrievable and that aggregation boundaries are declared in the CBM. Aggregation MUST NOT cross operant class or Conditioning Authority boundaries. Aggregating R-PLUS and P-PLUS events into a net magnitude destroys precisely the information the framework exists to preserve. 7.2. Multi-Agent and Delegated Conditioning In multi-agent systems, agents supply consequences to one another. An agent acting as a Conditioning Authority MUST be declared as such in the CBM of the agent it conditions, and its own OPC MUST be available to a verifier of that agent, because the conditioning it delivers is itself a behavior that something conditioned. Transitive conditioning chains SHOULD be bounded by declared depth. Unbounded mutual reinforcement between agents is a closed loop with no external authority and is functionally equivalent to the automatic class of Section 5.4. 7.3. Relationship to Existing Work CBPI is complementary to, and does not replace, existing agent identity and attestation work. Attestation profiles for AI agents establish the integrity of model parameters and the provenance of training data at load time. Delegation and provenance architectures bind agent actions to authorizing humans. Intent and actor chain mechanisms provide verifiable records of agent outputs and the delegation path that produced them. Each of these operates on identity, authority, or artifact. CBPI operates on history. A complete deployment uses an identity mechanism to establish who the agent is, an attestation mechanism to establish what it is, a delegation mechanism to establish what it may do, and CBPI to establish what has been done to it. Within the author's protocol suite, CBPI consumes the anchoring method of the REM Protocol [REM], produces evidence consumable by evaluation frameworks, and is a behavioral complement to Cognitive Sovereignty [COGSOV]: the latter preserves the epistemic autonomy of the human in an agent-curated environment, while CBPI documents the contingencies operating on the agent within it. 8. Security Considerations The chain is a target. An adversary who can rewrite the OPC can conceal the conditioning history that would reveal their activity. Hash linking makes rewriting evident only if a verifier holds an independent reference to an earlier chain state; external anchoring (Section 4.3) supplies that reference and is the reason CBPI-3 requires it. Completeness is the weakest property. An adversary who delivers reinforcement through an uninstrumented channel produces no record at all, and absence of a record is indistinguishable from absence of an event. Deployments MUST minimize uninstrumented consequence paths and SHOULD treat behavior change unexplained by any recorded contingency as a finding in its own right: unexplained drift is evidence of an unmonitored channel. Conditioning Authority key compromise permits an adversary to deliver arbitrary authorized-looking reinforcement. Authority keys SHOULD be scoped narrowly, rotated, and separated per operant class, such that compromise of a quality-rating authority does not confer the ability to condition oversight-interaction behavior. The analyzer is a target. An adversary who controls BDI thresholds, class weights, or the baseline signature can render drift undetectable while leaving the chain intact. The CBM containing these parameters MUST be signed and anchored, and changes to baselines and thresholds MUST be recorded as chain events subject to the same verification as reinforcement events. Self-conditioning is a boundary case with no complete solution. An agent with write access to its own OPC, its own CBM, or its own memory system is both subject and authority. Implementations MUST place the OPC outside the agent's write scope. Where an agent modifies its own skills, prompts, or persistent memory, those modifications MUST be recorded as behaviors within the chain and MUST NOT be permitted to alter the chain. Finally, CBPI records are themselves a source of leverage. An adversary who reads an agent's chain learns exactly which contingencies control its behavior and can construct efficient manipulations. Chain read access SHOULD be restricted correspondingly; a full conditioning history is a functional specification for controlling the agent. 9. Privacy Considerations Antecedent contexts and behavior outputs frequently contain personal data. CBPI records MUST store digests rather than content for both. Where content retention is required for later analysis, it MUST be held separately under its own access controls and retention policy, with the chain retaining only the digest binding. Reinforcement records identify the individuals who delivered consequences. Where the Conditioning Authority is an individual rather than an organizational role, the chain constitutes a detailed record of that individual's judgments over time and is capable of supporting evaluation of that person. Implementations SHOULD default to role-scoped authority identifiers and SHOULD apply pseudonymization where individual attribution is not operationally required. Retention periods for RERs MUST be declared in the CBM. A behavioral history of unbounded duration is a privacy liability and is of diminishing analytic value; the analytic requirement is for a sufficient window to establish a baseline and detect drift, not for a permanent record of every consequence ever delivered. 10. IANA Considerations This document requests the creation of three registries under a new "Cognitive Behavioral Provenance and Integrity (CBPI)" group, administered under the Specification Required policy. CBPI Operant Class Registry: Initial values are those in Table 1: R-PLUS, R-MINUS, P-PLUS, P-MINUS, EXT, ADV. CBPI Reinforcement Schedule Registry: Initial values are those in Section 2.3: CRF, FR, VR, FI, VI, NCR, DRO, DRA. CBPI Behavioral Function Registry: Initial values are those in Section 5.4: access, escape-avoidance, attention-social, automatic. This document further requests registration of the media types application/cbpi-rer+json, application/cbpi-manifest+json, and application/cbpi-signature+json in the "Media Types" registry. This document further requests assignment of the formal URN namespace identifier "cbpi" in the "Uniform Resource Names (URN) Namespaces" registry, in accordance with [RFC8141]. The namespace-specific string syntax is defined in Section 6.1. A registry of CBPI identifier types, with initial values rer, cr, cbm, cd, ca, beh, prog, and sig, is requested under the Specification Required policy. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015. [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, April 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, June 2019. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020. 11.2. Informative References [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021. [REM] Reilly, L.J., "Reilly EternaMark (REM) Protocol - Dual-Layer Digital Permanence Using DOI Archiving and Blockchain Timestamping", Work in Progress, draft-reilly-rem-protocol. [COGSOV] Reilly, L.J., "Cognitive Sovereignty", Work in Progress, draft-reilly-cogsov-00, July 2026. [SKINNER] Skinner, B.F., "The Behavior of Organisms: An Experimental Analysis", Appleton-Century, 1938. [FERSTER] Ferster, C.B. and B.F. Skinner, "Schedules of Reinforcement", Appleton-Century-Crofts, 1957. [THORNDIKE] Thorndike, E.L., "Animal Intelligence: Experimental Studies", Macmillan, 1911. [IWATA] Iwata, B.A., Dorsey, M.F., Slifer, K.J., Bauman, K.E., and G.S. Richman, "Toward a Functional Analysis of Self-Injury", Journal of Applied Behavior Analysis, 27(2), 1994. Author's Address Lawrence John Reilly Jr. Independent United States of America Email: lawrencejohnreilly@gmail.com