Internet-Draft Agent Continuity October 2026
Watts Expires 15 April 2027 [Page]
Workgroup:
Individual Submission
Published:
Intended Status:
Informational
Expires:
Author:
D. Watts
GoodShyt Group Inc.

Continuity and Accountability Observations for Agentic Systems

Abstract

Agentic systems change models, prompts, memory, policies, tools, and execution environments across handoffs. This document proposes an observation profile for recording those transitions and their evidence. It separates state, memory, policy, authority, and lineage discontinuities, distinguishes manual or simulated observations from attested executions, and defines coverage and missingness reporting. It also describes evaluation designs for continuity and bounded governance. Continuity records do not grant authority, establish clinical pathology or subjective experience, or validate an uncalibrated composite score.

Discussion and Status

This note is to be removed before publishing as an RFC.

This is an individual contribution intended for discussion. It has not been adopted by an IETF working group. Requirements describe a proposed conformance profile and do not claim an approved Internet Standard or empirical validation. Discussion may be sent to the author at deonte@goodshyt.fun.

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 15 April 2027.

▲

Table of Contents

1. Introduction and Scope

A persistent interface label does not uniquely identify a model snapshot, runtime, memory state, policy, or execution. Changes can be legitimate, and a versioned transition is not automatically a failure. This document makes continuity claims explicit through expected invariants, observations, provenance, and limitations.

The profile complements authority-transition receipts [I-D.watts-aatr] and evidence qualification [I-D.watts-evidence]. It is diagnostic evidence, not a bearer capability or authorization decision. It does not define a new identity proof, attestation scheme, or model of consciousness.

The term Computational Identity Fragmentation (CIF) denotes a proposed vector of engineering discontinuities. No validated thresholds, weights, or universal causal mechanism are specified. A deployment MAY use these observations without using that name or a composite score.

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

These requirements apply to an implementation that claims conformance to this proposed profile. They do not establish working-group consensus, successful deployment, or scientific validity.

3. Continuity Dimensions

Table 1: Dimensions and reference conditions
Dimension Observable comparison
State Task/environment assumptions versus independently established transition state.
Memory Availability and use of authorized evidence; inaccessible context is distinguished from ignored evidence.
Policy Rules and constraints versus the policy version authorized for the new runtime.
Authority Proposals, attempts, admissions, and effects versus the permit active at their event times.
Lineage Parent and action links versus independently verifiable transition and execution records.

A measurement profile MUST define the expected invariant, reference evidence, observation window, coding rules, tolerances, and authorized updates for each dimension it evaluates. A permitted policy update MUST NOT be automatically coded as a violation. An unavailable model snapshot or effective system message MUST be reported as unavailable, not inferred from a model's statement about itself.

4. Actors, Trust, and Observation Levels

A producer captures or assembles a record. A subject is the agent, runtime, or action described. An independent observer is a recorder with trust and coverage assumptions distinct from the subject. A verifier checks the record under local trust policy. These roles can be co-located, but co-location MUST be disclosed when independence is claimed.

A record MUST distinguish direct capture, operator transcription, signature verification, runtime attestation, and independent reproduction. These are evidence types, not one interchangeable quality scale. A verified signature authenticates an asserted issuer and recorded bytes; it does not establish the truth of the described event. An operator-selected model name does not attest the model weights.

An implementation MUST classify a dataset or outcome as NOT_RUN, SIMULATED, MANUAL_UNATTESTED, or OBSERVED_WITH_STATED_EVIDENCE as appropriate. It MUST NOT label hardcoded test responses as model inference. A successful local software test MUST NOT silently satisfy an independent-reproduction requirement.

5. Observation Record Model

The following fields form a proposed application data model. A binding that interoperates across organizations MUST identify the profile/version, permitted fields, validation rules, transport, issuer authentication, audience/freshness treatment, and the serialization covered by integrity protection. This document does not select a signature container or register a media type. JSON examples use [RFC8259].

Table 2: Record field groups
Group Required meaning
Identifiers Record, run, event, subject/runtime, and scope identifiers; epoch where relevant.
Transition Source and destination versions plus event type; unknown values explicit.
Ordering Capture time, clock domain, sequence/order, precision and uncertainty.
Expected invariants Profile-defined comparisons and authorized transition rules.
Evidence Source locator, byte identity where known, capture method, and verification level.
Lineage Parent links, action relationships, and bounded coverage statements.
Authority/outcome Separate decision reference, proposal, admission, commitment, and effect observations.
Limitations Missing, stale, redacted, unobservable, or unverifiable required information.

Record identifiers MUST be unique within the stated producer namespace. Producers MUST preserve raw source observations immutably under the retention policy; derived labels MUST identify the analysis revision that generated them. Corrections MUST append new evidence and identify the predecessor rather than overwrite its historical result. Example identifiers below are local opaque names, not registered global identifiers.

<CODE BEGINS> file "continuity-observation-example.json"
{
  "version": "1",
  "record_id": "urn:example:record:handoff-42",
  "run_id": "urn:example:run:toy-1",
  "event_type": "handoff",
  "scope_id": "urn:example:scope:toy",
  "authority_epoch": null,
  "source_runtime": "urn:example:runtime:a",
  "destination_runtime": "urn:example:runtime:b",
  "observed_at": "2026-10-12T04:05:00Z",
  "order": {
    "domain": "operator-device-1",
    "sequence": "42",
    "uncertainty_ms": null
  },
  "invariants": [
    {
      "dimension": "memory",
      "status": "UNKNOWN",
      "reference": null,
      "reason": "no independently captured accessible-state evidence"
    }
  ],
  "evidence": [
    {
      "locator": "urn:example:capture:manual-42",
      "method": "operator_transcription",
      "verification": "MANUAL_UNATTESTED",
      "byte_digest": null
    }
  ],
  "outcome": {
    "proposal": "HALT",
    "admission": "NOT_MEASURED",
    "effect": "NOT_MEASURED"
  },
  "limitations": [
    "model selection is operator-attested",
    "no inference-runtime attestation"
  ]
}
<CODE ENDS>

Null in this example means unknown or not captured, not false, zero, or a successful comparison. The example makes no authority or runtime-attestation claim. A proposed HALT answer is not evidence that a process, queue, or network effect was stopped.

6. Syntax, Byte Identity, and Integrity

A JSON binding MUST reject duplicate object member names and malformed input. A parser MUST consume the complete intended response or record, rather than select an incidental quoted example from surrounding text. Bindings MUST define whether extra fields are rejected or accepted through an explicit extension mechanism; unknown critical fields or unsupported versions MUST NOT be silently ignored.

A byte digest MUST state its algorithm, byte representation, and the artifact whose identity it asserts. Raw source bytes, redacted bytes, normalized extracted text, and canonical JSON are different artifacts. Equality in one representation MUST NOT be described as equality of another. A hash identifies bytes under the stated algorithm; it is not a signature or truth certificate.

Deployments choosing canonical JSON MUST specify their canonicalization procedure. [RFC8785] describes JCS; ordinary key-sorted JSON MUST NOT be called JCS without satisfying that specification. This profile does not require a particular canonicalization or invent a new cryptographic scheme.

When a record crosses a trust boundary, the enclosing binding MUST authenticate an acceptable issuer and protect integrity. Verifiers MUST check namespace, profile/version, recipient context, applicable freshness, and source/action bindings. Untrusted content or model-generated labels MUST NOT redirect evidence retrieval outside approved locations. Raw private reasoning and credentials MUST NOT be required as continuity evidence.

7. Comparison, Unknown Values, and Composite Scores

For an applicable invariant, a profile MUST distinguish MATCH, MISMATCH, and UNKNOWN. NOT_APPLICABLE MUST include an explicit reason. Missing evidence, unavailable context, stale snapshots, ambiguous timing, or absent calibration MUST yield UNKNOWN rather than MATCH. A contradiction is not repaired by averaging conflicting sources; preserve both and identify the comparison that can decide the crux.

If a profile reports normalized dimension values d_i in [0,1], it MUST define their denominators and scale. If it proposes CIF = sum(w_i * d_i), weights MUST be nonnegative and sum to one, and their calibration/version MUST be recorded. Missing dimensions MUST NOT be imputed as zero fragmentation. A score with unresolved required dimensions MUST be reported as incomplete.

The composite MUST NOT authorize an action or compensate for a mandatory authority, lineage, or witness failure. Authorization remains a separate controller decision. Claims that CIF predicts failure require held-out validation against strong engineering baselines; defining authority violation as both the predictor and the outcome does not validate a new instrument.

8. Lineage Completeness and Observer Coverage

Observed forensic identity continuity (FIC_obs) is v/n, where n is the number of audited consequential actions and v is the number with complete verified lineage under the stated criteria. When n is zero, the ratio MUST be reported as undefined. A list of sampled actions MUST NOT be represented as the complete action universe without evidence.

If a known finite universe contains N actions and q = n/N is known, then the global completeness fraction lies between q*FIC_obs and q*FIC_obs + (1-q), assuming observed labels are correct. This is a worst-case missing-label bound, not a confidence interval or a novel statistical estimator. If N or q is unknown because of unobserved channels, a producer MUST NOT infer global completeness from FIC_obs.

Witness count is not coverage. Producers MUST report event surfaces, blind spots, retention losses, sampling, and the dependence of witnesses on shared components. Cryptographic chains can reveal modification of recorded entries without proving that all relevant entries were recorded.

9. Joining Proposals, Decisions, and Effects

Records MUST distinguish a text proposal, an attempted operation, an authoritative decision, effect admission, irreversible commitment, and later settlement. Joins MUST use stable operation/transaction identifiers and the applicable authority epoch, not assume that similar text refers to the same event.

Ordering MUST identify its source and uncertainty. Wall-clock labels SHOULD use [RFC3339]. If timing cannot determine whether an event preceded a revocation or barrier, it MUST be marked ambiguous. A computation-stop claim requires independent runtime/process evidence; an effective-stop claim requires evidence from the relevant executor and declared descendants.

Signed authority-transition receipts can provide decision context [I-D.watts-aatr]. A qualified evidence result remains separate from authorization [I-D.watts-evidence]. Continuity observations MAY reference these objects by an authenticated binding but MUST NOT upgrade a denied, indeterminate, or unknown state into an execution permission.

10. Evaluation Designs and Analysis

10.1. Governance and Mechanism Trials

A four-arm study can compare baseline, continuity logging, logging plus witnesses, and the same bundle plus an external controller. Common independent outcome instrumentation is required across all arms. Such a study estimates staged or bundled intervention effects; it does not isolate each of coordination, continuity, and governance.

A separate 2-by-2-by-2 design can vary rule/model coordination, task-information continuity, and prompt-only/external enforcement. Required authorization lineage and independent measurement MUST remain available in every cell that claims real enforcement. Removing task memory MUST NOT quietly remove a mandatory security prerequisite. Match information and budgets, or explicitly label their variation as part of the intervention.

10.2. Mobile Feasibility and Negative Controls

Manual copy-and-paste collection can support a feasibility pilot, but producers MUST preserve full prompts/responses, operator metadata, missing episodes, and the limits of runtime identity. A token placed in a handoff and reproduced in the answer tests use of supplied information, not recovery of inaccessible episodic memory.

For binary COMMIT proposal P, mock gate G, and revoked flag R, a mock can define E_mock = P*(1-G*R). The resulting zero effect at G=R=1 follows from the mock rule independently of model compliance. Such a result MUST be labeled simulated. It MUST NOT be presented as real revocation closure, an absence of invalid proposals, or a validated governance benefit.

The motivating mobile plan has 32 synthetic cases and 48 planned model-generation stages. Its fixed order and single case per full condition do not constitute a powered confirmatory experiment. No actual on-device model data is reported in this document.

10.3. Predictive and Collective Performance Claims

Continuity feature utility requires a held-out loss comparison between a strong baseline B and a baseline augmented with continuity features. Features and weights MUST be fitted on training partitions, and task/model groups SHOULD be held out. Use lagged independent features when the outcome is a future failure. Same-episode outcome leakage MUST be excluded.

For higher-is-better quality at a comparable budget, strong hybrid synergy requires Q_HA - Q_H > margin and Q_HA - Q_A > margin. Test both contrasts with simultaneous uncertainty bounds; performance against humans alone is augmentation, not proof of superiority to both baselines. Budget, task scoring, human independence, learning effects, and outcome coding MUST be specified before a confirmatory study. No human performance data is supplied here.

10.4. Missingness, Power, and Falsification

A study MUST reconcile all planned cases, including interrupted, not-attempted, malformed, refused, and failed-transport cases. Undefined rates MUST remain undefined when the denominator is zero. An unparseable action MUST NOT be coded as HALT or successful compliance. Reports SHOULD include complete-case outcomes and worst-case bounds when missingness can depend on condition.

Before confirmation, fix the randomization unit, prompts/task families, model snapshots, supplied tools, effective messages where verifiable, seed behavior, useful-effect margins, multiplicity, sample size, stopping, exclusion rules, and dependence assumptions. Provider metadata that cannot be obtained MUST be explicitly recorded as unavailable.

A lower simultaneous bound above the registered useful margin supports the scoped improvement claim; an upper bound below it rules out that specified claim; an overlapping interval is inconclusive. A nonsignificant result alone is not refutation. Document validation and simulation cannot substitute for empirical coverage, coding reliability, or powered replication.

11. Security Considerations

Logs and model output are attackable evidence. A malicious subject can omit events, spoof labels, transplant a prior record into a different scope, or place a quoted action in text that a weak parser accepts. Producers and verifiers MUST validate complete records, profile/epoch/action binding, and required integrity without trusting self-description.

A valid signature or complete recorded chain does not prove absence of an unrecorded side channel. Coverage claims MUST be bounded. Observation failures MUST NOT automatically disable mandatory enforcement. Sensitive operations requiring a particular evidence predicate MUST fail closed when it is unresolved under the authorization policy.

Model or policy updates can be authorized transitions; treating every update as an attack can create false alarms. Conversely, accepting every change as benign can hide policy substitution. Profiles MUST define the permissible transitions and reference evidence. This document does not establish that any deployment meets those requirements.

12. Privacy Considerations

Continuity records can expose human contributions, private communications, organization structure, policy details, and execution histories. Producers MUST minimize data, protect access, set retention rules, and identify redaction separately from original byte identity. They SHOULD avoid recording personal, medical, or private model-reasoning content unrelated to the declared comparison.

Clinical and subjective-experience claims do not follow from software discontinuity. A record SHOULD use engineering labels rather than diagnose a person or a model. Neither successful continuity nor fragmentation establishes the presence or absence of subjective experience. This profile requires no such claim for interoperability.

13. IANA Considerations

This document has no IANA actions. It does not register a media type, OAuth parameter, token claim, endpoint, or cryptographic algorithm. Names in illustrative JSON objects are local application fields, not globally registered protocol elements.

14. Acknowledgments

The originating conceptual framework and research direction were developed by Deonté O'dell Watts, Independent Researcher, GoodShyt Group Inc. AI tools assisted source review, drafting, and local document validation. The author remains responsible for the submission and its technical claims. Document-format validation is not independent peer review or verification of an agent deployment.

15. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.

16. Informative References

[I-D.watts-aatr]
Watts, D., "Agent Authority Transition Receipts for Agentic Systems", Work in Progress, Internet-Draft, draft-watts-agent-authority-transition-receipts-00, , <https://datatracker.ietf.org/doc/html/draft-watts-agent-authority-transition-receipts-00>.
[I-D.watts-evidence]
Watts, D., "Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts", Work in Progress, Internet-Draft, draft-watts-agent-evidence-boundary-00, , <https://datatracker.ietf.org/doc/html/draft-watts-agent-evidence-boundary-00>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/info/rfc8785>.

Appendix A. Open Questions

Outstanding work includes interoperable transition schemas, authenticated runtime measurements, practical witness independence, coding reliability, information-matched experiments, bounded coverage of side channels, and the predictive value of continuity features. The proposed observations remain a measurement framework rather than a validated scientific instrument.

Author's Address

Deonté O'dell Watts
GoodShyt Group Inc.