NHE Memory: A Verifiable Memory-Record Format and Reputation-Weighted Reconciliation Protocol
draft-ruvalcaba-nhe-memory-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Cristian Xavier Ruvalcaba | ||
| Last updated | 2026-08-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ruvalcaba-nhe-memory-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
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,
<https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
hctp-00>.
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,
<https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
nhe-arch-00>.
[I-D.ruvalcaba-nhe-identity]
Ruvalcaba, C.X., "NHE Identity", Work in Progress,
Internet-Draft, draft-ruvalcaba-nhe-identity-00, August
2026, <https://datatracker.ietf.org/doc/html/draft-
ruvalcaba-nhe-identity-00>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Author's Address
Cristian Xavier Ruvalcaba
Saluca LLC
Email: cristian@saluca.com
Ruvalcaba Expires 12 February 2027 [Page 9]