NHE Memory: A Verifiable Memory-Record Format and Reputation-Weighted Reconciliation Protocol

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

Relationship to the NHE Architecture This document specifies the Memory interface of . It supports that model's invariants: inspectability, because provenance () traces any item back through the contributors that produced it; operator control, because a compromised contributor's items can be quarantined by lineage () 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 (). Contributors are named by their NHE identity , to which provenance attribution is bound.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 .

Memory record:: The unit of stored memory; carries a content payload and integrity fields ().
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 .
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 ().

Part I: Verifiable Memory Records

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

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.

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.

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.

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.

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.

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.

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.

Provenance and Lineage Every merged item records an attribution to the contributor that proposed it, bound to that contributor's 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.

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.

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.

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 ) --- are deferred to the next revision.

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 () 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 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 () limits any single contributor's influence, and the independence guard () denies corroboration credit between related contributors; both MUST be enforced. Expressing deletion as confidence reduction () 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.

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 . No IANA action is requested by this skeleton revision.