Abstraction Nodes

[anormang1992]

Summary

Introduce abstraction nodes — emergent higher-order groupings of primitives that share similar depth properties — to serve as "neural shortcuts" for future auto-learning and graph navigation.

Problem Statement

As the epistemic graph grows, primitives naturally cluster around shared depth-level properties. For example, File, Directory, and Symlink all share similar D1 identity properties (path-addressable, named, container-aware) and D2 capabilities (read, write, delete). These clusters exist implicitly in the graph structure but are invisible to the agent and to any future auto-learning system.

Without abstraction nodes, an auto-learning agent proposing new primitives has no structural shorthand — it must reason about individual nodes and their full depth properties every time, even when the new concept clearly belongs to an existing cluster. Abstraction nodes would make these clusters explicit and navigable.

Proposed Solution

An abstraction node is a meta-primitive that represents a shared property cluster. It is not a concept in the domain sense (not "File" or "Create") but a structural grouping ("FilesystemEntity", "MutativeAction").

Key design considerations:

• Derived, not authored: Abstraction nodes should be computed from graph structure (shared depth properties, relata patterns), not manually curated. A clustering pass over existing primitives identifies candidates.
• Non-epistemic: Abstraction nodes are navigational aids, not knowledge. They do not participate in grounding queries or depth resolution. The agent cannot "ground" against an abstraction node.
• Shortcut for learning: When the auto-learning system (VRE Informed Agentic Auto Learning #4) proposes a new primitive, it can reference an abstraction node to inherit a template of expected depths and relata, reducing the search space for candidate properties.

Possible implementation:

• A new node label in Neo4j (AbstractionNode) linked to member primitives via an ABSTRACTS relation
• A periodic or on-demand clustering pass that identifies primitives with overlapping depth properties above a similarity threshold
• An API to query which abstraction an unknown concept might belong to, assisting auto-learning proposals

VRE Design Alignment

• Does not affect the agent–VRE contract: Abstraction nodes are invisible to grounding, policy, and gap surfacing. They exist in the graph but are filtered out of epistemic queries.
• No new depth semantics: Abstraction nodes do not have depths. They are structural metadata.
• New relation type: Introduces ABSTRACTS (abstraction → primitive), which is navigational only and excluded from epistemic traversal.
• Preserves epistemic honesty: The agent never reasons through abstraction nodes. They assist the meta-epistemic learning layer, not the grounding layer.

Acceptance Criteria

• AbstractionNode model distinct from Primitive (no depths, no participation in grounding)
• ABSTRACTS relation type linking abstraction nodes to member primitives
• Clustering algorithm that identifies candidate abstraction nodes from shared depth properties
• PrimitiveRepository can store and retrieve abstraction nodes without polluting epistemic queries
• GroundingEngine ignores abstraction nodes during traversal
• Unit tests confirming abstraction nodes are invisible to grounding

Open Questions

• What similarity threshold defines a cluster? Shared properties at which depths?
• Should abstraction nodes be immutable once created, or should they evolve as the graph changes?
• Should there be a hierarchy of abstractions (e.g. FilesystemEntity → PersistentEntity)?
• How does this interact with the auto-learning proposal flow (VRE Informed Agentic Auto Learning #4) — does the agent see abstraction nodes in meta-epistemic discussion mode (Section 9.2)?

Dependencies

• VRE Informed Agentic Auto Learning #4 (VRE Informed Agentic Auto Learning) — primary consumer of abstraction nodes
• Implement Per-Primitive Confidence-Based Epistemic Metric #2 (Confidence metric) — could inform clustering similarity (optional)