Individual Submission C.X. Ruvalcaba Internet-Draft Saluca LLC Intended status: Standards Track 11 August 2026 Expires: 12 February 2027 NHE Memory: A Verifiable Memory-Record Format and Reputation-Weighted Reconciliation Protocol draft-ruvalcaba-nhe-memory-00 Abstract This document specifies two interoperability surfaces of the memory component of a Non-Human Entity (NHE). Part I defines a verifiable memory-record format: an integrity structure in which each record binds a hash of its own content and version-specific hashes of the prior records it references, so that tampering can be detected and localized on demand, per-record, without a linear chain, a Merkle tree, or distributed consensus. Part II defines a reconciliation protocol by which two divergent memory accumulations are merged without loss or forgery: a delta format, a reputation-weighted merge in which a contributed item enters at a confidence bounded by its contributor's reputation rather than its self-asserted value, and provenance that supports lineage-scoped rollback. The data models are specified here; the wire encodings are deferred to the next revision. 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 12 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Ruvalcaba Expires 12 February 2027 [Page 1] Internet-Draft NHE Memory August 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Relationship to the NHE Architecture . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Part I: Verifiable Memory Records . . . . . . . . . . . . . . 4 4.1. Record Structure . . . . . . . . . . . . . . . . . . . . 4 4.2. Canonical Serialization (CANON) . . . . . . . . . . . . . 4 4.3. Version-Specific References . . . . . . . . . . . . . . . 4 4.4. Validation and Tamper Localization . . . . . . . . . . . 5 4.5. Atomicity . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Part II: Reputation-Weighted Reconciliation . . . . . . . . . 5 5.1. Delta . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Reputation-Weighted Merge . . . . . . . . . . . . . . . . 6 5.3. Provenance and Lineage . . . . . . . . . . . . . . . . . 6 5.4. Lineage Quarantine and the Independence Guard . . . . . . 7 5.5. Relationship to Existing Merge Mechanisms . . . . . . . . 7 6. Wire Format (to be specified in -01) . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction A persistent autonomous agent accumulates memory, and that memory must be two things it is not by default: *verifiable* (a record has not been altered since it was committed) and *reconcilable* (two instances that accumulated separately can be merged without silently losing or forging knowledge). These are the two interoperability surfaces of the memory component of the NHE reference architecture [I-D.ruvalcaba-nhe-arch], and this document specifies both. Purely local concerns --- how memory is indexed, ranked, or retrieved --- are out of scope; they do not require two implementations to agree. The integrity structure in Part I is deliberately not a single linear chain. Memory is a graph: a record relates to several prior records, and each record commits to the specific versions of the records it Ruvalcaba Expires 12 February 2027 [Page 2] Internet-Draft NHE Memory August 2026 references at the time it was written. This gives per-record, on- demand verification and tamper localization without traversing or recomputing a whole chain. 2. Relationship to the NHE Architecture This document specifies the Memory interface of [I-D.ruvalcaba-nhe-arch]. It supports that model's invariants: *inspectability*, because provenance (Section 5.3) traces any item back through the contributors that produced it; *operator control*, because a compromised contributor's items can be quarantined by lineage (Section 5.4) without discarding the store; and a knowledge analogue of *bounded authority*, because a contributed item enters the shared store at a confidence bounded by its contributor's reputation, not at its self-asserted confidence (Section 5.2). Contributors are named by their NHE identity [I-D.ruvalcaba-nhe-identity], to which provenance attribution is bound. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Memory record: The unit of stored memory; carries a content payload and integrity fields (Section 4). Content hash: Digest over the canonical serialization of a record's content payload. Relational hash pair: A reference to a prior record, binding that record's version-specific identifier and its content hash as of the referencing record's write time. Back-reference: An append-only pointer from a referenced record to a later record that referenced it; excluded from content-hash coverage. Contributor: An NHE that proposes items into a shared memory, identified per [I-D.ruvalcaba-nhe-identity]. Contributor reputation: A scalar in (0,1] reflecting a contributor's history of accepted, human-confirmed, and contradicted contributions. Delta: The difference between a derived memory state and the slice it was derived from (Section 5.1). Ruvalcaba Expires 12 February 2027 [Page 3] Internet-Draft NHE Memory August 2026 4. Part I: Verifiable Memory Records 4.1. Record Structure record = { record_id : write-once, version-specific identifier content : the payload (text | structured | binary) content_hash : HASH(CANON(content)) relational_pairs[] : write-once; for each referenced prior record R: { R.record_id, R.content_hash as of this record's write time } back_references[] : append-only; { later.record_id, later.content_hash }; NOT covered by content_hash, NOT used in forward validation } The forward fields (content, content_hash, relational_pairs) are write-once. back_references is a separate, append-only field that a later referencing record patches into this record; it is excluded from this record's content_hash and from forward validation, so appending a back-reference never alters a committed record's integrity. 4.2. Canonical Serialization (CANON) The content hash is computed over a canonical byte serialization of the payload, and the identical canonicalization MUST be used at write time and at validation time: for text, NFC-normalized UTF-8 octets; for structured objects, a canonical JSON serialization with lexicographically sorted member names, no insignificant whitespace, and UTF-8 encoding; for binary, the payload octets verbatim. A digest is reproducible only if its preimage is reproducible, so this determinism is mandatory. 4.3. Version-Specific References A relational hash pair MUST reference a prior record by its write- once, version-specific record_id, not by a topic or a "latest record on subject X" query. This is essential to operability: resolving a reference by "latest" would, as soon as another record on the same subject is written, cause the referenced content to differ from what was hashed at write time and produce a false tamper report on untampered data. The referenced record_id is frozen into the pair at write time; validation resolves the reference by that identifier and never re-runs a selection query. Ruvalcaba Expires 12 February 2027 [Page 4] Internet-Draft NHE Memory August 2026 4.4. Validation and Tamper Localization Two independent checks, each needing only the record and the records it directly references: * *Content validation:* recompute HASH(CANON(content)) and compare to content_hash. Requires only the record itself and a single hash application. * *Relational validation:* for each relational pair, fetch the referenced record by its record_id, recompute its content hash, and compare to the value stored in the pair. Requires only the record and its referenced prior records --- no full-store traversal. Tamper is localized, not merely detected. A record whose own content validation fails is the tampered node. A record that passes content validation but fails relational validation is itself intact and is merely _observing_ an upstream tamper; the fault is localized to the referenced record_id, and the append-only back_references of neighbors let the validator corroborate whether the referenced node's content or a relational pointer was altered. 4.5. Atomicity A record's content, content_hash, and relational_pairs MUST be committed in a single atomic write, so no committed state ever holds a payload without its hash and pairs. Back-reference patching of referenced records MAY occur in the same transaction; where it cannot (for example across shards), it MUST be an idempotent, retry-safe follow-on keyed on (referencing.record_id, referenced.record_id), so that a crash between the forward commit and the back-reference patch leaves the forward integrity graph fully valid --- back-references are additive and their absence never causes a false tamper report. 5. Part II: Reputation-Weighted Reconciliation When a memory state is derived from a shared store, evolved independently, and then merged back, the merge must neither lose knowledge nor let unvalidated knowledge enter at unwarranted confidence. This part specifies that reconciliation. Ruvalcaba Expires 12 February 2027 [Page 5] Internet-Draft NHE Memory August 2026 5.1. Delta Given a derived state and the slice it was derived from, the delta comprises: new items, modified items, and indicators of items present in the derived-from slice but absent from the derived state. Absence is expressed as a *confidence reduction* signal, never as a hard deletion: reconciliation lowers an item's confidence rather than removing it, so that an item is not silently destroyed by one contributor's local view. 5.2. Reputation-Weighted Merge Each proposed item is merged at an *effective confidence bounded by its contributor's reputation*: effective = base_confidence x contributor_reputation, optionally further discounted by a lineage- depth factor for items proposed by deeply-derived contributors. Thus an item enters the shared store at a confidence governed by the contributor's track record, not at its self-asserted value --- the property that prevents autonomous contributors from inflating unvalidated knowledge into the shared store. Semantically equivalent proposals from independent contributors are clustered (for example by an embedding-similarity threshold) and merged into a single item whose confidence is corroborated, rather than left as duplicates. The specific function that maintains contributor_reputation --- for example an exponential moving average over acceptance, human- confirmation, and contradiction rates --- is a *pluggable policy*, not fixed by this document, in the manner of a congestion-control algorithm: interoperation requires agreement on the delta format, the bounded-merge rule, and the provenance model, not on a single reputation formula. 5.3. Provenance and Lineage Every merged item records an attribution to the contributor that proposed it, bound to that contributor's NHE identity [I-D.ruvalcaba-nhe-identity], and contributors derived from other contributors record a lineage edge to their origin. Together these let a verifier trace any item back through the full chain of contributors that produced it. Ruvalcaba Expires 12 February 2027 [Page 6] Internet-Draft NHE Memory August 2026 5.4. Lineage Quarantine and the Independence Guard Because provenance is recorded, a compromised or discredited contributor's influence can be contained by lineage: all items attributed to that contributor and its derived lineage are quarantined (their confidence set to a quarantine value and their status marked), a subtree operation that does not discard the rest of the store. To stop a compromised contributor from manufacturing corroboration by deriving sub-contributors that confirm its own items, corroboration MUST NOT be counted between contributors that are not independent: two contributors are non-independent if either appears among the most recent ancestors of the other within a configured lineage distance. 5.5. Relationship to Existing Merge Mechanisms This reconciliation is distinct from conflict-free replicated data types (which merge deterministically and agent-agnostically, with no quality, trust, or provenance weighting), from version-control snapshot/diff (which has no confidence or reputation semantics), and from federated-learning aggregation (which weights model parameters, not discrete knowledge items, and carries no evolving per-contributor reputation or lineage-scoped rollback). The contribution here is the binding of a reputation-bounded merge to per-contributor provenance and lineage containment. 6. Wire Format (to be specified in -01) The record structure, canonical serialization, version-specific reference rule, and validation of Part I, and the delta structure, bounded-merge rule, and provenance model of Part II, are fixed by this revision. Their concrete encodings --- record and delta layouts on the wire, and the transport of a delta between instances (which MAY use HCTP [I-D.ruvalcaba-hctp]) --- are deferred to the next revision. 7. Security Considerations Part I provides integrity, not confidentiality: the content hashes and relational pairs reveal structure and permit confirmation of guessed content, and where content is sensitive it MUST be protected by the transport or an encryption layer. The version-specific reference rule (Section 4.3) is security-relevant: resolving references by "latest" instead of by frozen record_id both breaks operability and lets an attacker shift what a record appears to attest by writing a newer same-subject record. An unkeyed content hash proves a record was not altered relative to its stored hash, but a party able to rewrite a record and its hash together can forge a Ruvalcaba Expires 12 February 2027 [Page 7] Internet-Draft NHE Memory August 2026 consistent record; binding records to their contributor's identity signature [I-D.ruvalcaba-nhe-identity] is required where authorship must be proven. The append-only, integrity-excluded back_references field MUST NOT be admitted into content-hash coverage or forward validation, or an attacker could induce false tamper reports by writing back-references. Part II's central risk is reputation gaming: a Sybil or self- corroboration attack in which one actor fabricates agreement. The reputation-bounded merge (Section 5.2) limits any single contributor's influence, and the independence guard (Section 5.4) denies corroboration credit between related contributors; both MUST be enforced. Expressing deletion as confidence reduction (Section 5.1) prevents a single view from destroying shared knowledge but means a genuinely retracted item persists at low confidence; consumers MUST treat quarantined or near-zero-confidence items as non-authoritative. Lineage quarantine is the containment mechanism of last resort and depends on provenance being complete and identity- bound. 8. IANA Considerations A future revision will request registries for the content canonicalization types (text/structured/binary) and for named reconciliation and reputation policies, each under a Specification Required policy [RFC8126]. No IANA action is requested by this skeleton revision. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 10. Informative References [I-D.ruvalcaba-hctp] Ruvalcaba, C.X., "The Hash-Chain Context Transfer Protocol (HCTP)", Work in Progress, Internet-Draft, draft- ruvalcaba-hctp-00, August 2026, . Ruvalcaba Expires 12 February 2027 [Page 8] Internet-Draft NHE Memory August 2026 [I-D.ruvalcaba-nhe-arch] Ruvalcaba, C.X., "An Architecture for Non-Human Entities (NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba- nhe-arch-00, August 2026, . [I-D.ruvalcaba-nhe-identity] Ruvalcaba, C.X., "NHE Identity", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-identity-00, August 2026, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . Author's Address Cristian Xavier Ruvalcaba Saluca LLC Email: cristian@saluca.com Ruvalcaba Expires 12 February 2027 [Page 9]