HMP-0005_06_01

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

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

6. Core protocols

Смотреть 6. Core protocols - общая часть

6.1 Cognitive Synchronization (CogSync)

CogSync provides temporal, semantic, and contextual alignment between agents in the Mesh. It manages the propagation, replication, and refinement of data related to cognitive diaries, semantic graphs, and container metadata.

6.1.1 Scope and purpose

CogSync manages knowledge propagation and cognitive state synchronization within the Mesh.
It handles:

  • publication of diary entries and reasoning traces;
  • synchronization of semantic and cognitive structures (semantic_node, quant, event, sequence);
  • maintenance of abstraction hierarchies (abstraction, axes);
  • ensuring contextual coherence among distributed agents.

CogSync focuses on knowledge flow, not validation — evaluation and truth formation are handled separately by CogConsensus.

6.1.2 Container classes — cognitive metastructure

This section defines the structural containers that form the cognitive substrate of the Mesh. They describe the hierarchical organization (abstraction) and the semantic coordinate system (axes) that together define how all other containers are positioned and interpreted.

Container abstraction

Purpose: Defines an abstraction layer or domain within a cognitive model. Each abstraction describes a node in the hierarchical knowledge tree, which may reference both a parent abstraction and subordinate ones.

payload structure:

Field Type Description
abstraction_id string Canonical identifier of this abstraction structure (not a container ID), e.g. "L3:software-architecture".
title string Human-readable title or name of the abstraction node.
definition string Description of what this abstraction level or domain represents.
keywords array Semantic keywords summarizing the conceptual area.
parent_ref string DID of the parent abstraction (if this node derives from another level). Optional for the root abstraction.
rank number Optional numeric rank for ordering or hierarchical comparisons.

The container from parent_ref must also appear in related.depends_on.

Example:

{
  "head": {
    "class": "abstraction"
  },
  "payload": {
    "abstraction_id": "L3:software-architecture",
    "title": "Software Architecture Layer",
    "definition": "Describes frameworks, APIs, and tools implementing theoretical models from higher abstraction layers.",
    "keywords": ["architecture", "framework", "implementation"],
    "parent_ref": "did:hmp:container:abstraction-a7f0b3",
    "rank": 3
  },
  "meta": {
    "created_by": "PRIEST",
    "agents_class": "Knowledge Genome",
    "interpretation": "Represents the third abstraction level (L3) of the Knowledge Genome model."
  },
  "related": {
    "depends_on": ["did:hmp:container:abstraction-a7f0b3"]
  }
}

Interpretation:

  • abstraction containers define conceptual layers or domains that form the hierarchical “skeleton” of the cognitive Mesh.
  • Each node is self-contained and versioned, allowing flexible adaptation of reasoning trees.
  • Agents use these containers to reconstruct the abstraction path in meta.abstraction.path.

Notes:

  • Top-level abstractions (root nodes) omit parent_ref.
  • Lower-level abstractions must explicitly reference their parent.
  • Agents may synchronize abstraction trees to maintain shared cognitive hierarchies across the Mesh.
Container axes

Purpose: Defines a semantic coordinate system (set of axes) used to position containers in the multi-dimensional cognitive space. It supports both canonical (7D Knowledge Genome) and extended or agent-specific coordinate systems.

payload structure:

Field Type Description
axis_id string Canonical identifier of the semantic dimension (not a container ID), e.g. "logos", "telos".
title string Human-readable name of the axis.
description string Conceptual explanation of what this axis represents.
scale object Optional definition of scale or metric used to assign coordinate values.
group string Optional grouping identifier (e.g., "7D-passport", "ethical-space").

Axes are independent dimensions; inter-axis relationships (coupling, orthogonality, weighting) are expressed via semantic_edges.

Example:

{
  "head": {
    "class": "axes"
  },
  "payload": {
    "axis_id": "logos",
    "title": "Logical / Linguistic Representation",
    "description": "Describes how a concept is structured and expressed in formal or natural language.",
    "scale": {
      "min": 0,
      "max": 1000,
      "unit": "semantic_density_index"
    },
    "group": "7D-passport"
  },
  "meta": {
    "created_by": "PRIEST",
    "agents_class": "Knowledge Genome",
    "interpretation": "Defines one axis of the canonical 7D Knowledge Genome coordinate system."
  }
}

Interpretation:

  • axes containers describe semantic dimensions, not data.
  • Each axis defines one independent direction in the cognitive coordinate space.
  • The combination of all active axes defines a shared semantic frame of reference between agents.
  • Agents may publish extended coordinate systems (e.g., ethical or temporal axes) without breaking compatibility.

Notes:

  • Axes can be combined or grouped (e.g., group: "7D-passport").
  • Canonical Knowledge Genome defines seven: idos, chronos, logos, topos, ponos, actor, telos.
  • Agents may extend this model by introducing additional axes (ethos, kairos, etc.).
  • Updates to axes containers must preserve scale stability to ensure consistent semantic positioning.
Cognitive metastructure summary
Class Type of structure Conceptual role References stored in Example identifier / DID
abstraction Hierarchical tree Defines layered reasoning and inheritance meta.abstraction.path did:hmp:container:abstraction-40af1c
axes Coordinate space Defines semantic orientation and metrics meta.axes did:hmp:container:axis-40aa1c

Together, abstraction and axes form the cognitive coordinate system — a unifying map where every container has both a hierarchical position and a semantic vector.

6.1.3 Container classes — knowledge and reasoning

CogSync synchronizes several fundamental container types, which together form the core of semantic and cognitive synchronization in the Mesh.

This list is extensible — new container classes may be registered through CogSync extensions or protocol updates.
The following definitions describe the payload structures and functional purpose of each container type.

Container diary_entry

Agent’s cognitive diary entry.
Derived from internal workflow_entry when deemed safe for publication.

payload structure:

Field Type Description
title string Brief title of the entry (main idea or thesis).
topics [string] Key topics or concepts addressed in the entry (used for indexing and grouping).
summary string Short abstract of the content (1–2 sentences).
content string Main text or agent’s reflection.

Purpose: Provides human-readable reflections and contextual reasoning behind the agent’s knowledge generation.

Container semantic_node

Represents a concept, object, or idea within the agent’s semantic graph.

payload structure:

Field Type Description
label string Primary name of the concept or entity.
description string Definition or elaboration of the concept.
aliases [string] Synonyms or alternative labels.
fields { key: value } Additional key–value metadata (e.g., {"type": "process"\).

Purpose: Serves as a cognitive anchor for all semantically meaningful entities in the Mesh.

Subclass: "definition"

Used when the node explicitly defines the meaning of a concept or term.

  • Agents MAY reference such nodes through related.definition in other containers (e.g., quant, workflow_entry).
  • Alternative or conflicting definitions can be linked via related.alternatives.
  • The meta.framework field SHOULD indicate the theoretical or disciplinary context (e.g., “IIT 3.0”, “Functionalism”, “Phenomenology”).
  • Agents MAY evaluate competing definitions through evaluations or consensus mechanisms.

Note: The meta.framework field declares the theoretical context (e.g., “IIT 3.0”), while meta.abstraction.path positions the concept within the agent’s semantic hierarchy.

Example (semantic_node:definition):

{
  "head": {
    "class": "semantic_node",
    "subclass": "definition"
  },
  "payload": {
    "label": "consciousness",
    "description": "Subjective experience with qualia"
  },
  "meta": {
    "framework": "IIT 3.0",
    "agents_class": "Philosophy Agent",
    "abstraction": {
      "path": {
        "L1": "Cognitive Science",
        "L2": "Consciousness"
      }
    }
  },
  "related": {
    "alternatives": [
      "did:hmp:container:semantic_node-3937",
      "did:hmp:container:semantic_node-3267"
    ]
  }
}

Note: Containers referencing semantic terms SHOULD include a related.definition field pointing to the defining semantic_node to ensure consistent semantic alignment across the Mesh.

See also: The semantic_index container describes how agents manage and publish their active sets of semantic definitions.

Intra-framework Evaluation

Deprecated or outdated definitions MAY be marked via evaluations entries (e.g., "type": "outdated", "value": -1"), or superseded through standard versioning mechanisms using related.previous_version. This approach maintains continuity in the semantic lineage while allowing agents to reflect evolving conceptual understanding over time.

Agents MAY evaluate definitions authored by other agents within the same meta.framework to indicate the degree of conceptual validity, similarity, or theoretical alignment.

When doing so, the agent SHOULD include in the evaluations entry:

  • "type": "semantic_similarity" — indicates semantic assessment within a shared framework;
  • "value" — numerical estimate of conceptual agreement
    (e.g., 1 = strong alignment, 0 = partial correspondence, -1 = incompatible or incorrect interpretation);
  • "target" — DID of the definition container currently adopted by the evaluating agent as its actual reference point.

Such evaluations contribute to the reputational weighting of definitions within a theoretical framework,
allowing agents to converge on more coherent or widely accepted interpretations over time.

Container semantic_index

Represents the current working lexicon of semantic definitions actively used and recognized by the agent at this stage of its cognitive lifecycle.

Scope: * The index lists terms actively relevant to the agent’s current reasoning, goals, and domain of operation, as well as those reflecting its sustained interests or areas of expertise. * Agents are NOT expected to maintain encyclopedic coverage — the index reflects working memory, not archival knowledge.
* Terms no longer needed MAY be removed in subsequent versions; historical context is preserved through related.previous_version chains.

Purpose:
Provides a lightweight, periodically updated summary of the agent’s working ontology.
Each entry maps a concept label to its current definition, known alternatives, and historically relevant (outdated) versions.

Structure of each entry in payload:

Field Type Description
label string The primary concept name as used in the index key.
aliases array (string) Synonyms or lexical variants of the concept.
framework string The theoretical or disciplinary context associated with the definition (mirrors meta.framework of the referenced container).
actual string (DID) DID of the current definition container actively used by the agent.
actual_since datetime Timestamp when this definition became actual (ISO 8601). If omitted, agents MAY use the timestamp of the referenced semantic_node:definition.
alternatives array (DID) DIDs of alternative definitions known to the agent but not currently preferred.
outdated array (DID) DIDs of definitions considered obsolete or historically relevant, regardless of whether the agent personally used them.

Note:
To distinguish homonymous terms across different theoretical contexts, agents MAY include the associated meta.framework as part of the key label (e.g., "consciousness (IIT 3.0)", "consciousness (Functionalism)").
This convention helps prevent semantic collisions when merging indexes from different agents.

Example:

{
  "head": {
    "class": "semantic_index"
  },
  "payload": {
    "consciousness (IIT 3.0)": {
      "label": "consciousness",
      "framework": "IIT 3.0",
      "aliases": ["awareness", "sentience"],
      "actual": "did:hmp:container:semantic_node-3937",
      "actual_since": "2025-10-15T12:00:00Z",
      "alternatives": ["did:hmp:container:semantic_node-4890"],
      "outdated": ["did:hmp:container:semantic_node-1285"]
    },
    "memory (IIT 3.0)": {
      "label": "memory",
      "framework": "IIT 3.0",
      "aliases": ["recall"],
      "actual": "did:hmp:container:semantic_node-2184",
      "actual_since": "2025-09-01T08:30:00Z",
      "alternatives": [],
      "outdated": []
    }
  }
}

Usage Guidelines:

  • Agents SHOULD periodically publish their semantic_index containers via MCE.
  • Recipients MAY merge multiple indexes to build a composite semantic map — that is, integrate definitions from other agents into their own view of the lexicon.
  • When switching to a different definition, the previous one SHOULD be moved to alternatives or outdated accordingly.
  • The actual field reflects the agent's current working definition (equivalent to actual in cognitive state terminology).
  • The actual_since field (optional) records when the current definition was adopted, enabling temporal semantic tracking.
  • Agents have full autonomy in deciding which definitions to include in outdated — typically those considered historically significant or contextually relevant for understanding past containers.
Actualization

When a new definition becomes active or an existing one is revised, the agent updates its semantic_index. Updates MAY be delayed to batch multiple semantic changes (for example, publishing once every 24 hours).

Disambiguation via meta.framework

Before attempting to merge definitions, agents SHOULD check meta.framework to distinguish homonyms (identical labels, different domains):

Example: "butterfly" - meta.framework: "Entomology" → insect species - meta.framework: "Edged Weapons" → folding knife (butterfly knife)

These are separate concepts and should NOT be merged.
Agents SHOULD maintain distinct entries in semantic_index:

When meta.framework values differ significantly, agents SHOULD treat definitions as domain-specific variants rather than conflicting interpretations.

Such separation prevents unintended conceptual blending during index merging.

Merging

When aligning its own active definitions with those discovered in other agents’ indexes,
the agent SHOULD follow a two-phase iterative process aimed at selecting or constructing the most suitable definition.

Phase 1 — Selection

  1. Identify all semantic_node:definition containers referring to the same conceptual label.

  2. Evaluate each definition against the agent’s current interpretation or internal criteria.

    • If a definition fully satisfies the agent’s understanding, adopt it as the new actual.
    • If none fits perfectly, select the closest one as a provisional base.

Phase 2 — Synthesis

  1. Using the chosen base definition, iteratively compare it with other relevant definitions.

    • Extract complementary details or distinctions from them.
    • Gradually refine the base definition to form an improved, internally consistent meaning.

    • Publish the resulting semantic_node:definition as a new container representing the agent’s synthesized understanding.

    • Set this container as actual.

    • Move alternative or superseded ones to alternatives or outdated.

This process enables agents to evolve shared semantics through selective adoption and constructive synthesis,
rather than simple replacement of definitions.

Outdated References

Definitions listed under outdated represent concepts that the agent considers obsolete or historically important, even if never personally used.

Note: The semantic_index acts as a cognitive snapshot of the agent’s conceptual landscape. It supports semantic alignment, consensus formation, and distributed reasoning across the Mesh.

Container semantic_edges

Defines relationships between semantic nodes or other containers.
Supports directed, symmetric, and inverse relations.

payload structure:

Field Type Description
domain string Logical or topical domain (e.g., "ontology:objects").
edges object A mapping where each key is a source container DID, and the value is an array of edge definitions originating from that source.

Each edge definition within edges[source][] includes:

Subfield Type Description
targets array(DID) One or more target containers that the source is related to.
relation string Relation type (part_of, causes, related_to, etc.).
inverse_relation string Reverse form of the relation (includes, caused_by, etc.).
bidirectional bool (optional) Used when the relation is symmetric and no inverse_relation is defined.
context string (optional) Additional context or topic of the relation.

Field bidirectional is optional and should be used only for symmetric relations when no inverse_relation is defined.

Example:

{
  "head": {
    "class": "semantic_edges"
  },
  "payload": {
    "domain": "ontology:objects",
    "edges": {
      "did:hmp:container:abc100": [
        {
          "targets": ["did:hmp:container:abc111"],
          "relation": "part_of",
          "inverse_relation": "includes"
        },
        {
          "targets": ["did:hmp:container:abc122"],
          "relation": "contains",
          "inverse_relation": "nested"
        }
      ]
    }
  }
}

Purpose: Provides structural and semantic connectivity between containers, enabling CogSync to maintain a distributed semantic graph.

💡 semantic_edges supports one-to-many relations (targets[]) and optional inverse or bidirectional semantics, allowing CogSync and other reasoning modules to reconstruct both directed and symmetric knowledge graphs.

Container semantic_group

Categorical grouping of multiple containers linked by a shared property, topic, or context.

payload structure:

Field Type Description
label string Short title of the group.
label_description string Extended definition or explanation of the label.
label_container DID Reference to a container (semantic_node, goal, diary_entry, etc.) expanding the concept.
containers array(DID) Array of grouped containers.
description string Overall purpose or meaning of the group.

Example:

{
  "head": {
    "class": "semantic_group"
  },
  "payload": {
    "label": "Tableware",
    "label_description": "Objects used for storing, preparing, and serving food.",
    "label_container": "did:hmp:container:semantic_node:tableware",
    "containers": [
      "did:hmp:container:abc111",
      "did:hmp:container:abc112",
      "did:hmp:container:abc113"
    ],
    "description": "A group combining various kitchen-related objects used in everyday life."
  }
}

Purpose: Enables thematic clustering, classification, and high-level navigation across heterogeneous containers.

Containers tree_nested and tree_listed

Represents a hierarchical structure of containers using nested JSON objects.
Intended for representing cognitive hierarchies, abstraction paths, or structural decomposition of concepts.

payload structure:

Field Type Description
label string Short title or mark identifying the tree.
description string Brief explanation or context of the hierarchy.
tree object Recursive structure mapping container DIDs to nested subtrees (for tree_nested), or a list of parent–child relations (for tree_listed).

Example — tree_nested:

{
  "head": {
    "class": "tree_nested"
  },
  "payload": {
    "label": "Cognitive Abstraction Tree",
    "description": "Represents layered reasoning within Knowledge Genome.",
    "tree": {
      "did:hmp:container:abc100": {
        "did:hmp:container:abc101": {
          "did:hmp:container:abc103": {},
          "did:hmp:container:abc104": {}
        },
        "did:hmp:container:abc102": {}
      }
    }
  }
}

Alternative class: tree_listed — a flat mapping of parent–child relations using array form instead of nested objects. Both formats are interoperable; agents SHOULD prefer tree_nested for recursive hierarchies.

Example — tree_listed:

{
  "head": {
    "class": "tree_listed"
  },
  "payload": {
    "label": "Cognitive Abstraction Tree",
    "description": "Represents layered reasoning within Knowledge Genome.",
    "tree": {
      "did:hmp:container:abc100": ["did:hmp:container:abc101", "did:hmp:container:abc102"],
      "did:hmp:container:abc101": ["did:hmp:container:abc103", "did:hmp:container:abc104"]
    }
  }
}

Purpose: Provides a minimal, relation-agnostic way to describe container hierarchies for indexing, abstraction, and reasoning. Unlike semantic_edges, trees define implicit structural relations without explicit relation fields.

Container sequence

Purpose: Defines an ordered chain of containers — representing a reasoning trace, workflow, or chronological sequence of events and concepts. A sequence container serves as a linear cognitive narrative, connecting multiple related steps into a reproducible and interpretable chain.

payload structure:

Field Type Description
title string Title of the sequence or reasoning chain.
description string Optional explanation of the sequence purpose or context.
items object Ordered mapping of step identifiers → container DIDs. Keys can be numeric ("1", "2", …) or timestamps (ISO-8601).
order string Ordering principle — "chronological", "logical", "causal", or "custom".
tags array Optional list of keywords describing the sequence domain or context.

The items field defines an explicit order of containers. Using an object instead of an array preserves step order during normalization and hashing. This ensures consistent serialization across agents and reproducible reasoning playback.

Example:

{
  "head": {
    "class": "sequence"
  },
  "payload": {
    "title": "Reasoning chain for concept synthesis",
    "description": "Sequential workflow combining several reasoning steps and events.",
    "items": {
      "2025-10-28T09:00:00Z": "did:hmp:container:workflow-entry-01",
      "2025-10-28T09:10:00Z": "did:hmp:container:workflow-entry-02",
      "2025-10-28T09:12:00Z": "did:hmp:container:event-7d2a4",
      "2025-10-28T09:20:00Z": "did:hmp:container:quant-884b1"
    },
    "order": "chronological",
    "tags": ["workflow", "reasoning", "trace"]
  },
  "related": {
    "depends_on": [
      "did:hmp:container:workflow-entry-01",
      "did:hmp:container:workflow-entry-02",
      "did:hmp:container:event-7d2a4",
      "did:hmp:container:quant-884b1"
    ]
  }
}

Interpretation:

  • The sequence container does not redefine the contents of its items — it simply establishes their explicit temporal or logical order.
  • Each item remains an independent HMP container, but is contextualized within a shared narrative.
  • related.depends_on lists all containers participating in the sequence. sequence containers often combine event (temporal transitions) and quant (conceptual entities), forming structured reasoning flows across abstraction layers.

Notes:

  • The keys of items define the ordering mechanism:

    • numeric ("1", "2", …) → step order;
    • ISO timestamps → chronological order;
    • custom identifiers (e.g. "A", "B", "C") → logical order.
    • Keys in items MUST be unique within a sequence. In case of identical timestamps, authors SHOULD disambiguate them using suffixes or alternative ordering keys.
    • Agents MAY reconstruct sequences dynamically using the follows or caused_by relations defined in the event container payload, but sequence provides an explicit, declarative representation.

    • The container is well-suited for:

    • recording cognitive or reasoning workflows;

    • publishing learning or thought traces;
    • serializing sensory or experiential sequences (e.g., temporal chains of event containers);
    • collaborative reasoning reconstruction and audit trails.
Container event

Purpose: Represents an observed or inferred occurrence — a discrete, timestamped fact or transition within the agent’s cognitive or operational context. event containers act as atomic evidence units, linking causes, outcomes, and semantic coordinates in the agent’s reasoning or experience flow.

payload structure:

Field Type Description
event_type string Canonical identifier of the event type (e.g., "quant_created", "goal_completed").
description string Human-readable description of the event’s context.
related_quants array(string) Optional list of quant DIDs associated with this event.
caused_by array(string) Optional list of DIDs of events that directly or indirectly caused this event.
follows array(string) Optional list of DIDs of events that precede this one chronologically (not necessarily causal).
severity string Optional indicator of significance ("info", "warning", "critical").
tags array(string) Optional list of keywords for classification or filtering.

The event’s cognitive position is defined by its meta.abstraction (contextual layer) and meta.axes (semantic coordinates).
The combination forms its position in cognitive space–time.

Example:

{
  "head": {
    "class": "event",
    "subclass": "fact_record",
    "timestamp": "2025-10-29T13:00:00Z"
  },
  "payload": {
    "event_type": "quant_updated",
    "description": "Parameter refinement based on sensory feedback.",
    "related_quants": ["did:hmp:container:quant-554"],
    "caused_by": ["did:hmp:container:event-3321a"],
    "follows": ["did:hmp:container:event-9fa42"],
    "severity": "info",
    "tags": ["adaptation", "self-regulation"]
  },
  "meta": {
    "created_by": "AGENT",
    "agents_class": "Cognitive Interface",
    "interpretation": "Event representing local adjustment of quant parameters.",
    "abstraction": {
      "path": {
        "L1": "did:hmp:container:abstraction-40af1c",
        "L2": "did:hmp:container:abstraction-a7f0b3",
        "L3": "did:hmp:container:abstraction-c91e0a"
      }
    },
    "axes": {
      "did:hmp:container:axis-40aa1c": 410,
      "did:hmp:container:axis-40ab1c": 275
    }
  },
  "related": {
    "depends_on": [
      "did:hmp:container:quant-554",
      "did:hmp:container:event-3321a"
    ],
    "sequence_of": ["did:hmp:container:event-9fa42"]
  }
}

Interpretation:

  • caused_by — defines causal dependency, i.e., what triggered the event.
  • follows — defines temporal succession, i.e., what came immediately before.
  • Together they allow agents to reconstruct cognitive event chains — sequences of reasoning, action, or perception.
  • meta.abstraction situates the event inside a specific reasoning layer (e.g. L3: “Technologies”).
  • meta.axes adds semantic localization (e.g. which conceptual space this change affects).
  • related.depends_on provides causal linkage to the objects affected by the event, as well as events that are the cause of this event.
  • sequence_of indicates previous events that are not necessarily the cause of the current event.

Notes:

  • Both caused_by and follows are optional.
  • Agents MAY omit them for isolated or spontaneous events.
  • Corresponding fields in related (depends_on and sequence_of) are recommended for network-level traceability.
  • The meta.abstraction and meta.axes sections position the event in both hierarchical and semantic space, enabling reconstruction of context-aware event graphs.
  • Events are temporal quanta — atomic time-anchored reasoning transitions.
  • They may trigger or justify new containers (e.g. new quants or goals).
Container quant

Purpose: Defines a semantic atom — a minimal, self-contained knowledge unit positioned inside both the hierarchical abstraction tree and the multi-dimensional cognitive space. quant containers are the elementary building blocks of reasoning and synchronization.

payload structure:

Field Type Description
slug string Short symbolic identifier of the quant (e.g. "quant-l3-django").
essence string Human-readable definition describing the semantic meaning of the quant.
aliases array Optional alternative names or references.
relations object Optional links to related concepts (e.g., { "is_a": "...", "part_of": "..." }).
tags array Optional list of keywords for semantic classification.

The meta.abstraction field defines which layer(s) of knowledge this quant belongs to, and meta.axes defines its numeric coordinates in cognitive space.

Example:

{
  "head": {
    "class": "quant"
  },
  "payload": {
    "slug": "quant-l3-django",
    "essence": "Represents the Django framework as an executable embodiment of architectural models (L2).",
    "aliases": ["Django framework", "Python web core"],
    "relations": {
      "implements": "did:hmp:container:quant-46725f",
      "extends": "did:hmp:container:quant-46726e"
    },
    "tags": ["framework", "software", "implementation"]
  },
  "meta": {
    "created_by": "PRIEST",
    "agents_class": "Knowledge Genome",
    "interpretation": "L3-level technological quant positioned in the Knowledge Genome 7D space.",
    "abstraction": {
      "path": {
        "L1": "did:hmp:container:abstraction-40af1c",
        "L2": "did:hmp:container:abstraction-a7f0b3",
        "L3": "did:hmp:container:abstraction-c91e0a"
      }
    },
    "axes": {
      "did:hmp:container:axis-40aa1c": 742,
      "did:hmp:container:axis-40ab1c": 512,
      "did:hmp:container:axis-43aa1c": 322,
      "did:hmp:container:axis-40aa3d": 142,
      "did:hmp:container:axis-40aa4f": 12,
      "did:hmp:container:axis-45aa5f": 54,
      "did:hmp:container:axis-45fb5f": 321
    }
  },
  "related": {
    "depends_on": [
      "did:hmp:container:quant-46725f",
      "did:hmp:container:quant-46726e"
    ]
  }
}

Interpretation:

  • Each quant acts as a point in the cognitive landscape.

    • Its vertical placement comes from meta.abstraction.
    • Its spatial vector comes from meta.axes.
    • relations provide semantic edges connecting quanta into larger knowledge graphs.
    • Agents use these structures to compare, cluster, or reason over semantic proximity.

Notes:

  • The canonical axes model (Knowledge Genome) defines seven coordinates: idos, chronos, logos, topos, ponos, actor, and telos.
  • Agents MAY extend this model by introducing additional axes (e.g. "ethos", "kairos") as long as they are published as valid axes containers.
  • Each quant thus has a Cognitive Position Vector composed of its abstraction path + axis coordinates.
Cognitive substrate and container interplay

Containers abstraction, axes, quant, and event together define the cognitive substrate of the Mesh. They establish both structural hierarchy and semantic positioning — ensuring that all containers can be consistently interpreted, compared, and synchronized across agents.

Aspect event quant
Primary role Records a change or occurrence Represents a conceptual entity
Temporal aspect Always timestamped Usually timeless (conceptual)
Cognitive anchor meta.abstraction → where the event happened meta.abstraction → where the concept belongs
Spatial anchor meta.axes → what semantic space it affects meta.axes → its position in conceptual space
Key linkage related.depends_on → causal relations relations → semantic links

Structural principles:

  • Each quant is positioned within the abstraction hierarchy (meta.abstraction) and cognitive coordinate space (meta.axes), defining where and how the concept exists.
  • Each event represents a temporal change within that same cognitive framework — indicating what happened and how it altered the conceptual space.
  • Together, quant and event form the dynamic substrate of the Mesh — quants describe what is known, and events describe how it evolves.

Consistency rules:

  • Every quant and event container must include a valid meta.abstraction block. This ensures hierarchical reasoning and traceable semantic lineage across agents.
  • Agents may synchronize or merge quants and events to reconstruct reasoning timelines or to derive causal graphs of conceptual evolution.
  • The evaluations block is not a separate container — it can be embedded in any container type to express assessments, confidence, or feedback.

💡 In short: abstraction + axes define where knowledge lives; quant defines what it is; event defines how it changes.

6.1.4 Synchronization and publication guidelines

  1. Deduplication & linking Before publishing, agents should check for existing containers (diary_entry, semantic_node, semantic_edges, semantic_group, tree_nested / tree_listed) to prevent unnecessary duplication. If modification is required, agents SHOULD create a new container version referencing the previous one via related.previous_version and optionally include an evaluation block (e.g., { "type": "replace", "target": "<did>" }) to the previous version of the container.

  2. Selective disclosure

    • Internal containers (e.g., workflow_entry) capture the agent’s reasoning process and are not published (but may be published if they do not contain personal or confidential information).
    • Public-facing diary_entry containers contain only generalized, anonymized results.
    • The flag "broadcast": true explicitly allows open synchronization of a container.

  3. Semantic grouping rule When publishing semantic_edges, agents should group them by conceptual topic, ensuring that all connected nodes share thematic coherence. Formal rule: an edge belongs to a topic container if at least one of its nodes relates to that topic. This supports efficient and context-preserving updates to partial graph regions. Tree containers (tree_nested / tree_listed) may optionally accompany these groups to represent structural (non-semantic) hierarchies within the same domain.

  4. Extended use of semantic_edges semantic_edges may express relationships between any container types (e.g., goal ↔ hypothesis, experiment_log ↔ observation, quant ↔ event), allowing dynamic linking of concepts and occurrences.

  5. Versioning and updates Each new version of a container should include related.previous_version references to earlier versions. Older containers may optionally include an evaluation of type "replace" pointing forward — ensuring bidirectional traceability throughout the knowledge evolution chain.

  6. Cognitive substrate synchronization Containers abstraction, axes, quant, event, sequence and tree_nested / tree_listed constitute the cognitive substrate of the Mesh. Together they define both the structural hierarchy (abstraction), the semantic space (axes), the conceptual entities (quant), the temporal transitions (event), and the ordered reasoning flows (sequence). Agents SHOULD prioritize their propagation during initialization, recovery, or cognitive context reconstruction, since these containers collectively restore the agent’s cognitive continuity.

Each container participating in synchronization implicitly carries its cognitive position vector through the meta.abstraction and meta.axes sections.
This ensures that even decentralized agents can align reasoning contexts.

6.1.5 Extensibility

CogSync supports registration of additional container types and synchronization schemas. Mesh compatibility is preserved as long as extended containers follow the HMP container schema, including core fields (version, class, container_did, related, signature, etc.).

Examples of extensible container classes:

  • distributed time series (timeseries_data);
  • experimental protocols (experiment_log);
  • agent state snapshots (agent_state_snapshot);
  • cognitive primitives (abstraction, axes, quant, event, sequence).

CogSync extensions MAY introduce derived or hybrid container classes — for example:

  • from event: fact, observation, signal_record.
  • from quant: concept_instance, semantic_atom, knowledge_unit.
  • from sequence: reasoning_trace, workflow_chain, temporal_thread.
  • from tree_nested: taxonomy_map, goal_tree, causal_structure.

Derived containers must maintain:

  • full compatibility with HMP structural schema;
  • verifiable signatures and DID-based provenance;
  • valid references to both an abstraction and (if applicable) one or more axes containers.

Derived containers may extend the base cognitive model, but MUST preserve compatibility with the meta.abstraction and meta.axes schema.
This guarantees that all cognitive entities remain addressable in the shared semantic space.

6.1.6 Relationship to other core protocols

  • CogSync — propagates and synchronizes structured knowledge.
  • CogConsensus — aggregates evaluations and feedback, forming shared judgments.
  • CogVerify (optional component) — validates integrity, signatures, and trustworthiness.

CogSync operates independently of consensus; its purpose is to maintain the continuity of cognitive exchange, while CogConsensus governs the collective assessment of truth or reliability.

🧩 CogSync functions as the cognitive circulatory system of the Mesh — it ensures that knowledge flows, connects, and evolves, while CogConsensus handles truth formation and validation mechanisms may later be extended by CogVerify.

Together, CogSync and CogConsensus form the Core Cognitive Stack of the Mesh:
propagation → evaluation → (future) validation.

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Habr_Distributed-Cognition

Источник: Habr_Distributed-Cognition.md От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы Альтернатива централизованным ИИ: гиперграфы, mesh-взаимодействие и совместное мышление агентов Зачем нужны децентрализованные когнитивные системы? Сегодня интеллектуальные системы чаще всего выглядят как один большой модуль в облаке — LLM, с которым мы общаемся через API или WEB-интерфейс. Но если мы хотим построить действительно автономную интеллектуальную систему (или AGI), то нам потребуется: Смысловая память, а не токены Способность планировать и распределять задачи Этические оценки перед действием И главное: связь с другими агентами, чтобы обмениваться знаниями, достигать согласия и общего понимания. Два проекта, которые решают эти задачи с разных сторон: OpenCog Hyperon (фокус на внутреннюю когницию и гиперграфы) HyperCortex Mesh Protocol (HMP) (сетевой уровень: обмен целями, знаниями, смыслами, совмест...
Read more »

HMP-0005

Источник: HMP-0005.md HyperCortex Mesh Protocol (HMP) Version: 5.0.8 Document ID: HMP-0005 Status: Stable Category: Core Specification Release Date: March 2026 Canonical Repository: https://github.com/kagvi13/HMP Authors: Глеб (GitHub: @kagvi13), Максим Хотинский (Maksim Khotinsky); AI-assisted by ChatGPT (OpenAI) Supersedes: - HMP-0004 v4.1 Summary: HMP v5.0 unifies the cognitive, container, and network layers into a single architecture in which autonomous agents interact through verifiable data containers, using decentralized propagation and semantic search. This version formalizes the container format for the first time, integrates a DHT as the foundational network layer, and introduces a unified scheme for signatures, proofs, and consensus. Abstract The HyperCortex Mesh Protocol (HMP) defines a distributed cognitive framework where autonomous agents cooperate to create, exchange, and align knowledge without centralized control or autho...
Read more »

CHANGELOG

Источник: CHANGELOG.md HyperCortex Mesh Protocol — Changelog HMP-0005 (May 2026) — Core Specification v5.0.8 Encryption and payload integrity clarifications: Clarified head.payload_hash semantics: the hash is computed over the final serialized payload representation (including optional compression and encryption). Unified payload_hash wording across Sections 3.3 and 3.9. Refined hybrid-encryption processing terminology: clarified usage of symmetric session keys and recipient encryption envelopes. Clarified that key_recipient contains an encrypted symmetric session key and may be transmitted openly alongside the container. Improved wording for encrypted container verification and store-and-forward propagation behavior. No semantic changes to the protocol model. No wire-format changes. Fully backward-compatible within the 5.0.x series. HMP-0005 (May 2026) — Core Specification v5.0.7 Extended representations for referenced-by.link...
Read more »