ARG Standard

Appearance

Guide v1 — ARG Ontology Construction & Audit ​

(outside ARG protocol and Context Weaver architecture)

1. Purpose of this section ​

This guide aims to reduce the risk of ontological bootstrapping.
If the M2M foundation (Typologies ↔ Clusters ↔ Labels ↔ Nodes) is poorly laid, the system will continuously "correct" offline… but on a shaky foundation.

The goal is therefore to:

  • build quickly but cleanly,
  • detect gaps and contradictions early,
  • have an Audit mode capable of saying:
    "Stop: the structure must be rebuilt before AI."

This guide complements the protocol described in ARG Core, without duplicating it: it focuses on design rules before production deployment and before automatic evolution.

2. Context typology design rules (v1) ​

Context typologies are outside the graph.
They serve to parameterize inference, not to carry business knowledge itself.

Design objective:

  • a typology must be stable,
  • transversal,
  • non-redundant,
  • capable of surviving product evolution.

Architecture reminder: a typology never replaces a manager.
Real governance remains in the Policy Manager,
and taxonomic coherence in the Context Weaver.

2.1 Climb as high as possible in the contextual family ​

When you create a typology, you must seek the level of generality that:

  • crosses the majority of prompts,
  • does not depend on a specific module,
  • does not depend on a versioned product,
  • is not a single use case,
  • is not an action verb.

Control question:
"What is above this?"
You climb until you obtain a stable and durable family.

Heuristic:
If the typology name resembles:

  • a verb ("cancel", "configure", "activate"),
  • a module ("billing", "SSO", "CRM"),
  • a feature ("CSV export", "API webhook"),

→ you are too low.
This level must be managed by cluster/labels/nodes, not by typology
(see the branches/leaves model in Guides).

Stability test:
"If the product changes name, version, or features, does this typology remain valid?"

  • If yes → good level.
  • If no → too low.

2.2 Zero duplication between typologies ​

Two typologies should never explain the same thing.

Each typology must have:

  • a unique scope,
  • a short non-overlapping definition,
  • a clear operational output
    (what it modifies in the inference pipeline).

Anti-overlap test:
If an inference rule could be attached indifferently to two typologies,
you have a design problem.

2.3 Recommended families (consistent with your manager model) ​

You can formalize a "canonical" set:

Master typologies (main rails)

  1. Intention
  2. Complexity
  3. Action Mode (or Execution Mode)

Transversal typologies
4. Policy
5. Trust (Human Touch)
6. Memory Mode
7. UX/UI Style (if your product justifies it)
8. Sales/Commercial (only if your agent has a real commercial role)

Logical order rule:

  • Policy is at the top of governance invariants
    (realized by the Policy Manager engine).
  • Trust/Level modulate human assistance.
  • Intention/Complexity/Action drive business reasoning
    (orchestrated in ARG Core).
  • Memory and UX drive output and writing
    (cf. online/offline memory in ARG Core).

2.4 "Master" typologies ​

A master typology is present in almost all interactions.

Role of master typologies:

  • serve as a navigation backbone outside the graph,
  • frame the complexity budget,
  • stabilize stop decisions and Fast Track,
  • facilitate coverage audit.

Natural examples:

  • Intention
  • Complexity
  • Action Mode
  • Policy (even if its engine is separate)

2.5 "Manager vs Typology" rule ​

You have three coherent layers:

Stand-alone Managers

Context typologies

  • inference profiles and parameters
  • stable families

Taxonomy + Graph

  • clusters/labels/nodes/edges
  • structural core exploited by ARG Core

Golden rule:
A typology must not do the work of a manager.

  • The Policy typology can exist as a profile,
    but the decision logic is in the Policy Manager.
  • The Trust Manager / Level Scorer live as typologies
    in a "Human Touch / User Model" family.

2.6 Explicit "Human Touch" rule ​

To avoid confusion, create a higher family:

Human Touch / User Model

  • Level Scorer (competence)
  • Trust Manager (autonomy & prudence)
  • Human Preferences (style & format)

Anti-confusion rules:

  • Trust ≠ Policy
  • Level ≠ Intention
  • Preferences ≠ Complexity

2.7 Common anti-patterns ​

Typology too low

  • "Subscription cancellation"
    → must be label/node, not typology.

Duplicate typology

  • "Security Context" and "Policy"
    → merge or clarify scope.
    Generally:
    • Product security = cluster/labels
    • Policy = transversal governance

Typology that encodes product

  • "Salesforce Mode", "SAP Mode"
    → prefer capture via product labels
    or policy by project.

Catch-all typology

  • "Misc", "Other"
    → forbidden.

2.8 Quick quality tests ​

Checklist for each new typology:

  1. Is it stable over 12–24 months?
  2. Is it activatable in >20–30% of prompts?
  3. Does it modify a measurable inference decision?
  4. Can you write a one-sentence definition without overlap?
  5. Does it not duplicate a manager?

If an answer is "no",
the typology is probably misplaced.

2.9 Ultra-short summary ​

  • Climb high: a typology is a stable family, not a feature.
  • Zero duplication: unique scope, unique inference rule.
  • Masters = main system rails.
  • Policy and Context Weaver are managers; typologies don't replace them.
  • Trust/Level/Preferences must be grouped in "Human Touch / User Model".

3. Build taxonomy quickly: the "trees-first" method ​

Trees don't carry transversal relationships,
but they are unbeatable for:

  • construction speed,
  • visualization of gaps,
  • initial M2M stability.

3.1 Practical steps ​

Create the cluster tree

  • clusters = large stable domains.

Add labels in cascade

  • label root → label parent → label child → …

Ensure semantic coherence

  • a child label must be definable without re-defining its parent.

Spot gaps

  • empty branches where you know the business has frequent cases.

The operational validation of this tree is then "consumed" by the
Context Weaver.

3.2 Why "trees-first" is crucial for your M2M ​

Because it reduces exponential risk:

  • you lay down a hierarchical backbone
  • before multiplying M2M attachments to nodes.

4. Build the node graph from taxonomy ​

4.1 Basic rule ​

A node is an operational object:

  • title
  • chunk
  • type
  • M2M with clusters/labels/edges

But you want to avoid the "big bang M2M".

4.2 Healthy MVP method ​

  1. Create "root" nodes first
    for the most used label roots.

  2. Attach child labels progressively.

  3. Add semantic edges afterwards.

In other words:
don't try to fill the complete M2M on day 1.

The traversal and scoring logic depends on this structural cleanliness
and is formalized in ARG Core.

5. "Ontological Audit" mode (pre-AI) ​

This is the answer to bootstrapping risk.
The audit is a mechanism before:

  • activating ARG in production,
  • or allowing offline to systematically correct.

5.1 When to activate it ​

  • Before production deployment.
  • Before letting the offline loop industrialize evolutions
    (cf. lifecycle in ARG Core).

5.2 What the audit must measure ​

A) Coverage audit ​

% of reference business prompts covered by at least:

  • one cluster
  • one label root
  • one child label

Alert signal:
too many prompts fall into OOD or onto a catch-all cluster.

B) Granularity audit ​

  • clusters too vast?
  • child labels too rare?
  • inconsistent depth
    (one branch at 6 levels and one at 1)

Alert signal:
a single cluster absorbs too much intention diversity.

C) Redundancy audit ​

  • quasi-synonymous labels under different parents
  • duplicate context typologies

Alert signal:
if two branches solve the same need.

D) Contradiction audit ​

  • impossible or ambiguous label combinations
  • systematic policy vs semantic conflicts

Alert signal:
the system spends its time arbitrating and rejecting.

Policy vs taxonomy conflicts must be handled
with Policy Manager rules
and strict Context Weaver validation.

5.3 "Stop Criteria" (the real red button) ​

You can formalize a clear message to the business:
"Stop and rebuild the initial structure" if you simultaneously observe:

  • a catch-all cluster attracting a large share of requests,
  • high label entropy under this cluster,
  • low specialization capacity,
  • structural increase in OOD despite correct business vocabulary.

This is typically the sign of a poor initial breakdown.

6. Good hygiene rules to avoid exponential growth ​

6.1 A typology ≠ a module ​

A context typology is a family of reading the world,
not a technical brick.

Therefore:

  • Context Weaver is not a typology:
    it's a decomposition engine + taxonomic coherence guardian
    (see Context Weaver).

6.2 Prefer taxonomic evolution before topology ​

When you discover a gap:

  1. add a child label
  2. properly reattach to the parent cluster
  3. only then create a new node

This maintains:

  • stability
  • readability
  • reduced M2M debt

7. Concrete deliverables to request from business ​

To properly industrialize:

  • Map of master typologies + definitions
  • Cluster tree
  • Label trees per cluster
  • "Golden set" test prompts list
    • frequent questions
    • edge cases
    • voluntary out-of-scope

8. Operational summary ​

  • Typologies: climb high, zero duplication, explicit masters.
  • Taxonomy: trees-first for speed + gap detection.
  • Nodes: progressive MVP, avoid big bang M2M.
  • Pre-AI audit: coverage / granularity / redundancy / contradictions.
  • Stop criteria: cluster too large + recurring OOD + high entropy
    ⇒ mandatory rebuild.

Released under the Apache License 2.0

ARG v1.1 Specification