| Internet-Draft | NHE Memory | August 2026 |
| Ruvalcaba | Expires 12 February 2027 | [Page] |
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.¶
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 (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. 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.¶
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 references at the time it was written. This gives per-record, on-demand verification and tamper localization without traversing or recomputing a whole chain.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].¶
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.¶
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.¶
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.¶
Two independent checks, each needing only the record and the records it directly references:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶