HMP-0005_11

Источник: HMP-0005_11.md

HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

• Полный документ: HMP-0005.md
• Список разделов: HMP-0005_index.md

---

11. Implementation Notes

This section is intended for developers implementing HMP-compatible nodes, SDKs, LLM integrations, and distributed testing setups. It does not describe protocol semantics; instead, it focuses on engineering practices required for correctness, interoperability, and performance.

---

11.1 Cross-environment Interoperability and Boundary Nodes

HMP v5.0 does not require backward compatibility with experimental versions (including HMP v4.1). If an external implementation appears that uses earlier draft container models, it is treated as an independent environment or external network.

Such environments are integrated via boundary / relay / bridge nodes, which:

• receive containers from the external environment,
• convert them into minimally compatible v5.0 structures,
• apply propagation headers and TTL rules,
• publish only compatible containers,
• may perform partial format down-conversion,
• filter unsupported structures,
• may also transform and forward containers into the external environment, if allowed by their headers.

Thus, any external system — old HMP drafts or entirely different protocols — connects through a bridge, not through direct compatibility.

This greatly simplifies the architecture and removes the need to support historic formats.

---

11.2 SDK and API Guidelines

An SDK should provide two layers.

---

11.2.1 Low-Level API

Low-level functions reflecting the structure and rules of HMP:

• container construction and signing,
• container validation,
• header management (propagation scope, ttl, refs),
• a local container storage manager,
• automatic publication respecting header rules,
• DHT operations (peer discovery, container_request),
• replication primitives (container_index, container_delta, container_ack).

The SDK must not impose an operational model — only provide protocol primitives.

---

11.2.2 High-Level API

The high-level layer simplifies integration:

• IQP query interfaces (semantic selection, summary),
• template-based creation of containers (create_workflow, create_diary_entry, create_goal),
• a local semantic-node index,
• RAG support for LLMs,
• integration of LLMs with CShell or CCore.

The purpose of the high-level API is to simplify development and provide “ready-to-use operations” on top of low-level primitives.

---

11.3 Performance and Caching Considerations

HMP is a distributed system, so node performance depends heavily on caching and local indexing strategies.

---

11.3.1 L1 and L2 Caches

• L1 (instant): recently accessed containers and IQP results,
• L2 (long-term): local persistent storage with heuristic cleanup.

Containers may be evicted based on:

• ttl,
• time since last access,
• semantic irrelevance.

Caches may be cleaned automatically (formal criteria) or at the request of an LLM.

---

11.3.2 Caching of referenced-by and evaluation

Reverse-link and evaluation indices may be stored:

• as part of the containers themselves (embedded blocks),
• and/or as a separate local link database (a table “container → list of references / list of evaluations”).

This accelerates lookup of related nodes and reduces repeated IQP load.

When storing evaluation, its digitally signed sections must be preserved intact.

---

11.3.3 RAG Structures

CShell or CCore may use any retrieval technology to find relevant containers:

• simple keyword search,
• local full-text indexing,
• vector embeddings,
• a local link graph.

HMP does not mandate any technology — it defines only the data model: semantic nodes, diary entries, links, and evaluations suitable for content lookup.

---

11.3.4 DHT Performance

Recommended practices for the DHT:

• store only the minimal required metadata,
• avoid large-scale caching,
• use adaptive polling intervals,
• treat IPFS/BT plugins as optional extensions, not a mandatory part of the protocol.

---

11.4 Testing and Compliance Recommendations

HMP testing should include several levels.

---

11.4.1 Container Validation Tests

Check:

• correct headers,
• correct signatures,
• consistent references,
• valid semantics for each container class.

---

11.4.2 Protocol Tests

For MCE, IQP, CogSync, GMP, EGP:

• message-flow models (“A → B → C”),
• race-condition tests,
• recovery from lost packets,
• network segmentation tests.

---

11.4.3 Agent Behavior Tests

For CCore:

• cognitive cycle operation,
• correctness of workflow_entry,
• semantic updates,
• diary-based reasoning trace.

For CShell:

• correct processing of LLM instructions,
• correct publication respecting headers,
• proper container aggregation,
• structural validation.

---

11.4.4 Cross-environment Interoperability

Tests must include interaction with external environments that:

• use their own container formats,
• implement simplified or outdated mechanics,
• do not support propagation headers,
• lack full MCE / IQP / CogSync stacks.

Boundary nodes must correctly:

• transform container structures,
• filter unsupported fields,
• apply propagation policies,
• isolate segments when incompatibilities arise.

This is the universal mechanism for interacting with older HMP drafts and external systems.

---

11.5 Reference Implementations (Optional)

The project may include:

• CCore-reference — a minimal standalone agent with an embedded model;
• CShell-reference — a proxy agent with an MCP-like API;

• HMP-Node-Lite — a lightweight node supporting:

  • routing,
  • replication,
  • caching,
  • partial DHT,
  • minimal CogSync;
  • Cross-segment relay — a reference bridge between segments.

These implementations are not part of the specification but are useful for compatibility testing and accelerating adoption.