GoodShyt Group Inc.

deonte@goodshyt.fun https://orcid.org/0009-0005-8586-3650

Individual Submission agent authorization continuity and accountability 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 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.

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 and evidence qualification . 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.

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 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.

Continuity Dimensions 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.

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.

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 . 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. { "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" ] } 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.

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. 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.

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.

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.

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 . 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 . A qualified evidence result remains separate from authorization . Continuity observations MAY reference these objects by an authenticated binding but MUST NOT upgrade a denied, indeterminate, or unknown state into an execution permission.

Evaluation Designs and Analysis

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.

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.

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.

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.

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.

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.

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.

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.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Informative References This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Independent Researcher Work in Progress Independent Researcher Work in Progress

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.