ARG Standard

Appearance

Guide v1 — Roles, Boundaries & Examples: Cluster / Label / Node / Edge ​

(the "branches & leaves" model + memory impact)

TL;DR ​

Cluster = stable domain root.

Label = hierarchical routing branch.

Node = terminal leaf containing data and/or action.

Edge = movement grammar between leaves.

With this design:

  • Memory is robust because it points to leaves (nodes),
  • Only sensitive case: node split
    → solution: migration table Migration trace:
A → {B, C}

1. The centralizing metaphor ​

Your system is best understood as:

Clusters + Labels = taxonomy (branches and roots)

Nodes = leaves (containing useful data: chunk + type)

Edges = circulation rules (movement grammar between leaves)

Therefore:

  • the graph is not a "knowledge graph of unique entities",
  • it's a graph of operational leaves,
  • driven by a taxonomy of branches.

This metaphor is structural to understand:

  • why the Context Weaver must never "invent" structure,
  • why the ARG Core protocol uses taxonomy to stabilize the landing point,
  • and why memory is robust as long as it anchors truth on leaves.

2. Operational definitions (with examples) ​

2.1 Cluster ​

Role: the highest stable level of business organization.

A cluster is:

  • a taxonomic parent,
  • a structure of label families,
  • less granular than a label.

In your model:

  • a cluster is not a knowledge leaf,
  • it serves to:
    • ensure macro semantic coherence,
    • avoid anarchic label dispersion,
    • anchor the Taxonomy Vector Store
      used by the Context Weaver.

A good cluster = stable and durable domain.

✅ Examples:

  • Contracts
  • Billing
  • Support
  • Security

❌ Bad example:

  • "Cancel March invoice"
    → too specific: should be a label or node.

2.2 Label ​

Role: taxonomic granularity exploitable by routing.
Labels are the branches leading to leaves.

Hierarchy:

  • label root → label parent → label child → …

A label is not "the data".
It's a category of meaning + routing.

In your system:

  • a node can be attached to multiple labels (M2M),
  • a label can point to multiple nodes.

Labels are the primary material for:

✅ Hierarchical example (SaaS):

Cluster: Billing

  • Label root: Billing
    • Label parent: Payment
      • Label child: Payment failure
      • Label child: Refund
    • Label parent: Subscription
      • Label child: Cancellation
      • Label child: Plan change

What this provides:
finer routing without immediately multiplying nodes.

2.3 Node ​

Role: terminal unit of action or knowledge.
This is the leaf.

A node contains:

  • title (often keywords)
  • chunk (ultra-refined text)
  • embedding(chunk)
  • type:
    • Decision
    • Info
    • Action
    • MemoryRead
    • MemoryWrite
    • etc.

The node is the object that carries useful truth in your design.
Not the label.

Nodes are attached via M2M with:

  • clusters
  • labels
  • (and edge semantics / edge-tags)

Therefore, a node is a multi-branched leaf,
not a unique entity in a "classic KG".

✅ Examples:

Info Node

  • title: cancel annual subscription
  • type: Info
  • chunk: procedure + conditions + exceptions

Action Node

  • title: cancel subscription
  • type: Action
  • chunk: preconditions + API specs / workflow

2.4 Edge ​

Role: transition semantics and traversal rules.

An edge, in your system, doesn't just serve to conceptually link:
it encodes traversal logic, potentially constrained by:

  • edge type,
  • context typologies,
  • policy,
  • activation conditions via labels.

Edge = movement grammar between leaves.

It provides:

  • authorized trajectories,
  • preferred paths,
  • implicit/explicit guardrails.

✅ Useful examples:

requires
CancelSubscription(Action) → requires VerifyIdentity(Decision)

leads_to
PaymentFailure(Info) → UpdateCard(Action)

related_to
Cancellation(Info) ↔ Refund(Info)

These mechanisms are then exploited by traversal and constraints described in ARG Core.

3. The distinction to engrave: Taxonomy vs Graph ​

Taxonomy (Cluster + Label)
→ structure of meaning and routing.

Operational Graph (Nodes + Edges)
→ structure of resolution
(action or information).

This distinction protects the system against:

  • the illusion that a label is a fact,
  • and the temptation to encode business truth in a vector space without guardrails
    (see motivations in Introduction).

4. Memory impact: why your design is robust ​

Before this clear distinction, the risk of "Memory Rot" existed.
After, it is largely neutralized.

Why?

  • memory references leaves (nodes),
  • and not just abstract classes (labels).

This rule is a pillar of the memory model described in ARG Core
and governed by the Policy Manager via the Memory Guard.

4.1 Risk-free cases ​

Case A — Move a node from one label to another
✅ No problem.
The node ID remains stable.
The route changes, not the memory.

Case B — Reconfigure clusters/labels above a node
✅ No problem.
You modify branches, not the leaf.

Case C — Adjust edges
✅ No problem.
Memory still points to the correct leaf.

4.2 The only sensitive case: Node split ​

Node A

  • title: sales contract
  • chunk: mix "software + service"

Offline: you split into:

  • Node B: software sales
  • Node C: service sales

Mandatory v1 rule:
Keep a minimal migration trace:

Migration trace:

A → {B, C}

Therefore:

  • if memory finds A:
    • it doesn't break,
    • it's redirected to B/C.

This is lightweight, clean, and avoids retagging an entire database.

5. Design rules (anti-chaos) ​

5.1 When to create a cluster ​

Create a cluster only if:

  • very stable domain,
  • transversal to many prompts,
  • large enough to justify a real label family.

❌ Anti-pattern:
clusters too fine → combinatorial explosion.

5.2 When to create a label ​

Create a label if:

  • it improves routing,
  • corresponds to a useful branch,
  • is hierarchically positionable.

If you hesitate:

  • new label
  • new node

→ start with a child label
if you don't yet have a clear branch.

This principle is aligned with controlled evolution described in Context Weaver
and the offline loop of ARG Core.

5.3 When to create a node ​

Create a node if:

  • stable and capitalizable chunk,
  • well-defined action,
  • or decision end-point.

Node = knowledge/action investment.
Labels = navigation structure investment.

5.4 When to create an edge ​

Create an edge if:

  • you observe a useful recurring traversal pattern,
  • or if a semantic relationship must become operational.

❌ Useless edge = navigation noise.

6. Role of the Context Weaver in this model ​

The Context Weaver knows the taxonomy (cluster↔label).
It is not a typology.

It helps to:

  • stabilize the label set,
  • avoid parent/child inconsistencies,
  • improve landing point,
  • better score neighbors,
  • propose offline candidates
    (child labels, edges, sometimes node splits).

But:

  • truth remains in:
    • core knowledge,
    • and node chunks.

7. Ultra-short summary (doc version) ​

Cluster = stable domain root.

Label = hierarchical routing branch.

Node = terminal leaf containing data and/or action.

Edge = movement grammar between leaves.

With your design:

  • robust memory because it points to leaves (nodes),
  • only sensitive case: node split
    → solution: migration table Migration trace:
A → {B, C}
```.

Released under the Apache License 2.0

ARG v1.1 Specification