ARG Standard

Appearance

0. Base assumptions ​

This section formalizes the existing foundations of ARG so the rest of the protocol can remain deterministic, auditable, and scalable.

0.1 Knowledge system structure ​

The core knowledge (built with domain experts) includes:

Context typologies (outside the graph) ​

Context typologies are not knowledge carriers.
They are stable families used to parameterize inference:

  • access constraints,
  • preferred node types,
  • complexity budgets,
  • maximum traversal depth,
  • response style.

They are often generic across projects, with a small subset remaining project-specific.
For design rules and audit criteria, see the Guides.

Taxonomy: cluster ↔ label ​

The taxonomy provides the semantic backbone of routing.

  • cluster = top-level parent domain.
  • labels form a hierarchical chain:
    • label root → label parent → label child → …

This hierarchy is the stable structure that enables safe classification and controlled evolution.
Taxonomy-safe classification is enforced by the Context Weaver.

ARG ontological graph ​

ARG uses an operational ontology where:

  • Node = terminal operational unit
    (concept, action, information, or memory behavior).

Each node is many-to-many with:

  • clusters,
  • labels,
  • edges (and/or edge semantics / edge tags).

Each node contains:

  • title (interpretable domain concept),
  • chunk (ultra-refined text),
  • embedding(chunk),
  • type:
    Decision, Info, Action, MemoryRead, MemoryWrite, etc.

This “branches & leaves” model is detailed in the Guides
and implemented end-to-end in the ARG Core.

0.2 Existing inference mechanics ​

ARG builds on deterministic and scalable primitives:

  • Initial classification (lexical first):
    BM25, TF-IDF, etc. → candidate labels
    refined into taxonomy-coherent labels by the Context Weaver.

  • Landing point computed through set theory over:

    • labels,
    • clusters,
    • and node↔label/cluster M2M attachments.

  • Traversal guided by precomputed and local signals:

    • Louvain/Leiden communities,
    • SimRank,
    • v2F,
    • Jaccard,
    • and explicit relationship semantics.

Policy constraints that shape these stages are enforced by the Policy Manager.

0.3 Mandatory additions for v1 ​

To make ARG reliable in production, three components are mandatory:

  • Enriched online logging
    to capture routing, confidence, policy effects, and memory outcomes.

  • An offline refinement loop
    that proposes and applies controlled structural evolution:

    • node split/merge,
    • new edges,
    • taxonomy evolution (primarily child-label additions).

  • Memory consolidation
    promoting episodic signals into stable semantic structure
    under lifecycle and safety rules.

These mechanisms are specified in the ARG Core
and grounded by construction/audit rules in the Guides.

1. Overview of the ARG v1 Protocol ​

ARG is built around two loops operating on the same knowledge system, under one consistent protocol version:

  • an ONLINE loop for deterministic inference at request time,
  • an OFFLINE loop for controlled structural refinement and memory consolidation.

This separation allows ARG to stay fast and reliable in production while still improving over time without drifting into uncontrolled evolution.

1.1 ONLINE loop — ARG inference ​

Input

  • user prompt,
  • structured context (role, product, channel, short history, timestamp, etc.),
  • constraints produced by the Policy Manager,
  • taxonomy-safe labels produced by the Context Weaver.

Output

  • an executed action, or
  • an information response using online retrieval, and
  • memory writes when appropriate.

Key properties

  • Retrieval is online-only.
  • The graph is considered fixed during the request.
    This means that no node/edge/label/cluster is created or modified in the hot path.
    Online memory writes are allowed, but they write into a memory/registry layer rather than altering the active ontology.
    The full mechanics are defined in the ARG Core.

1.2 OFFLINE loop — graph refinement + memory consolidation ​

Input

  • enriched interaction logs,
  • domain outcomes (success/failure/feedback),
  • accumulated episodic memory.

Output

  • structured proposals, then controlled application of:
    • new nodes and edges,
    • node splits/merges,
    • adjustments of node↔label/cluster M2M attachments,
    • episodic → semantic memory consolidation,
    • incremental taxonomy evolution (preferably child-label first).

Key properties

  • The graph evolves through staged, versioned lifecycle rules
    (ACTIVE → DEPRECATED → REMOVED) with alias tables to protect reasoning and memory continuity.
    See the ARG Core for lifecycle mechanics and the Guides for construction and audit principles.

Why this matters

This two-loop design ensures that ARG can:

  • remain deterministic, safe, and low-latency online,
  • improve coverage and precision offline,
  • prevent silent degradation of long-term memory,
  • and preserve structural stability as the domain evolves.

The ONLINE pipeline is detailed in the ARG Core,
with classification guarantees in the Context Weaver
and governance constraints enforced by the Policy Manager.

2. ONLINE loop — ARG protocol (Action / Info / Memory) ​

This section defines the request-time pipeline.
It is designed to remain fast, deterministic, and policy-governed.

The online loop is built on three hard rules:

  1. Policy comes first (hard gate before any routing).
    See the Policy Manager.
  2. Taxonomy validity always wins (labels must be coherent and validated).
    See the Context Weaver.
  3. The graph is fixed during the request
    (no structural edits to nodes/edges/labels/clusters in the hot path).
    See the broader online/offline contract in ARG Core.

2.1 Step 1 — Context normalization + Policy Manager (Pre-Check) ​

Inputs ​

  • raw user prompt
  • metadata:
    • user id / role / permissions
    • channel / language
    • timestamp
    • short-term history

Processing ​

2.1.1 Standard normalization (deterministic) ​
  • light text cleanup
  • language detection
  • structured context assembly

This produces a stable request envelope for downstream modules.

2.1.2 Policy Manager — Pre-Check ​

(transverse safety kernel, independent from domain typologies)

The Policy Manager runs before any classification or routing.
It does not depend on the graph.

It outputs a governance state:

  • ALLOW
  • ALLOW_WITH_REFOCUS
  • RESTRICT
  • BLOCK

It can cover:

  • toxicity / insults
  • disallowed content
  • sensitive topics if required by product scope
  • role/permission controls
  • alignment between the agent’s domain scope and the user’s request

Important

  • This is not a domain typology.
  • It is a safety/governance kernel.
  • If a “Policy” typology is kept, it must remain purely parametric
    (style, strictness thresholds, response form), not decision-making.

Details of this kernel and its sub-modules are specified in the
Policy Manager.

2.1.3 Building policy_state and constraints ​

The system attaches to the request context:

  • policy_state
  • policy_constraints
    (e.g., allowed/forbidden labels for this role, allowed node types, max depth/hops)
  • response_mode
    (normal / cautious / refocus / refuse)

Optionally:

  • embedding(prompt) if used later by scoring.

Role of context typologies (outside the graph) ​

Context typologies are used to activate an inference profile, such as:

  • access constraints
  • preferred node types
  • complexity budget
  • max traversal depth
  • response style

They do not replace the Policy Manager or the Context Weaver.
Design rules for typology families are available in the Guides.

Priority rules ​

  • If policy_state = BLOCK
    → stop the ARG pipeline and return a refusal.

  • If policy_state = ALLOW_WITH_REFOCUS
    → short refocus response and suggest returning to agent scope.

  • Otherwise
    → proceed with the normal pipeline under policy_constraints.

These constraints are consumed by:

  • initial classification (Step 2),
  • taxonomy arbitration in the Context Weaver,
  • landing-point selection and neighbor scoring,
  • traversal limits and action checkpoints.

This completes the governance envelope for the request and ensures that every downstream decision remains policy-safe, taxonomy-aware, and deterministically auditable.

2.2 Step 2 — Initial classification (Retrieval Manager) under Policy constraints ​

Preconditions ​

Retrieval (lexical-first) ​

The system performs fast candidate detection using:

  • BM25
  • TF-IDF
  • or equivalent lexical / lightweight semantic methods

This step is intentionally cheap and broad: it proposes candidate labels, not final routing truth.

Policy-aware filtering (hard gate) ​

Before freezing the raw label set, apply:

  • role-based whitelist / blacklist
  • product / project restrictions
  • exclusion of non-accessible labels
  • security and governance priorities

Output ​

  • L_raw = { label_i : score_i }
  • L_raw_policy_filtered (recommended for observability)

Mandatory logs ​

  • labels proposed vs labels blocked by policy
  • constraint type applied
  • active policy_state

This ensures downstream taxonomy arbitration remains auditable and prevents silent drift caused by hidden policy effects.

2.3 Step 3 — Taxonomy filtering & arbitration ​

Context Weaver + Policy gate (corrected v1)

This step fixes the historical “single point of failure” risk by separating:

  1. taxonomy candidate narrowing,
  2. bounded interpretation,
  3. deterministic validation.

The full low-latency implementation and 100ms cascade are defined in
the Context Weaver.

2.3.1 Taxonomy retrieval (Taxonomy Vector Store) ​

Instead of injecting the full taxonomy into a generative model, the system performs vector search over a dedicated label index built from:

  • label name
  • label description
  • parent cluster context
  • optional validated synonyms/examples

Only the Top-K labels (e.g., 10–20) are surfaced as eligible candidates.

This keeps the vector layer in its intended role:
restricting the space of choice, not defining structure.

2.3.2 Bounded label proposer (escalation-only) ​

When needed (low margin / high ambiguity), a bounded proposer selects labels only from the Top-K list.

Strict instruction:

  • “Choose only among these labels or ABSTAIN.”

In the 100ms mode, this proposer is not mandatory for the hot path;
the distilled-first flow remains the default.
See Context Weaver — 100ms Budget Mode.

2.3.3 Deterministic Taxonomy Validator ​

A validator based on core knowledge verifies:

  • label existence
  • cluster↔label compatibility
  • parent/child coherence
  • explicit incompatibilities
  • policy / typology constraints

The validator is the final arbiter of taxonomy truth.
This guarantees that linguistic nuance does not reintroduce hidden structural invention.

2.3.4 Output of the Context Weaver ​

  • L = { label_i : score_i }
    policy-filtered and taxonomy-coherent
  • confidence_global
  • flags used by the rest of the online pipeline and by offline candidate generation:
    • OOD
    • VECTOR_AMBIGUITY
    • LOW_MARGIN
    • ABSTAIN_RECOMMENDED
    • NEW_INTENT_CANDIDATE
    • UNKNOWN_LABEL_CANDIDATE

2.3.5 Taxonomy maintenance contract ​

When a new label is added offline:

  • Context Weaver side
    • update the cluster↔label tree in core knowledge
    • update Validator rules
    • add/reindex the label in the Taxonomy Vector Store
    • update Policy rules if required
  • ARG consumption side
    • update node↔label (and optionally node↔cluster) M2M attachments
    • adjust edges if new granularity requires a safer or more precise path

In short:

2.4 Step 4 — Landing point computation ​

Set theory + M2M projection

The system projects the final label set L onto the ontology using:

  • node↔label and node↔cluster M2M attachments
  • the cluster↔label hierarchy
  • deterministic set-based rules

Normal output ​

  • node_start (or top-N landing candidates)

This landing point becomes the root for:

  • local neighbor expansion,
  • composite scoring,
  • deterministic traversal.

Critical additions (v1 corrections) ​

The landing-point stage must support safe abstention:

  • ABSTAIN / OOD routing
    • if label scores are too weak,
    • if uncertainty is high,
    • or if strong contradictions with policy/taxonomy exist

Then:

  • route to an OutOfScope node
    or return a controlled fallback path.

Cold-start intent (controlled) ​

If the vocabulary is clearly in-domain but the pattern is novel:

  • allow a conservative approximate landing choice
  • set NEW_INTENT_CANDIDATE

Safety rule (v1.1) Cold-start approximation must not directly land on high-risk Action nodes.
When ambiguity remains, prefer:

  • an Info-first or Clarify-first path,
  • or an explicit abstention branch.

This keeps online behavior safe while enabling the offline loop to add missing child labels or refine nodes.
See evolution rules in the Guides and lifecycle safeguards in
ARG Core — Offline refinement.

2.5 Step 5 — Local expansion & neighbor scoring ​

This step starts from node_start and builds a bounded candidate neighborhood for deterministic reasoning.

Policy constraints are enforced as a hard gate before any scoring.
Policy is not treated as a soft numerical signal.
See the Policy Manager.

Taxonomy coherence is a hard validity condition for candidate consideration.
See the Context Weaver.

2.5.1 Candidate collection ​

Candidates are collected from:

  • direct ontological neighbors of node_start,
  • semantic candidates discovered via embedding proximity within the allowed local scope.

Candidate collection must respect:

  • edge type,
  • edge direction,
  • active context typologies (budget and behavior shaping),
  • policy_constraints.

This preserves deterministic intent while allowing controlled semantic recall.

2.5.2 Anti-hub pruning ​

When a node behaves as a hub (e.g., hundreds of neighbors), apply cheap pre-filters:

  • allowed edge types only,
  • taxonomy coherence checks (with support from the Context Weaver),
  • role and context constraints from the Policy Manager,
  • typology-based budget limits.

Reduce to a bounded set K (e.g., 30–80 candidates).
This keeps latency predictable and prevents traversal from being dominated by structural noise.

2.5.3 Composite scoring (policy-gated) ​

After pruning and gating, compute a composite score for each candidate node n:

  • S_struct(n)
    structural affinity
    (e.g., SimRank, Jaccard, community proximity from Louvain/Leiden)

  • S_sem(n)
    semantic affinity
    embedding(prompt) ↔ embedding(chunk)

  • S_taxo(n)
    hierarchical compatibility between the final label set and the candidate’s cluster/label attachments
    (computed with help from the Context Weaver)

  • S_typology(n)
    preference shaping driven by active context typologies
    (budget, node-type preference, depth controls)

  • S_memory(n)
    historical usage signal without confusing frequency with truth

Hard gates (must be applied before scoring):

  • if policy_forbidden(n) → exclude
  • if taxonomy_incoherent(n) → exclude

Composite score: [ Score(n)=\alpha S_{struct}+\beta S_{sem}+\gamma S_{taxo}+\delta S_{typology}+\epsilon S_{memory} ]

S_memory should be time-decayed and capped to avoid locking the system into historical bias.
Memory governance rules are defined in the Guides.

2.6 Step 6 — Fast Path ​

To reduce unnecessary search, ARG may short-circuit when:

  • node_start confidence is very high,
  • the active typology indicates a “simple” profile,
  • and the target node (or immediate neighbor) is a stable shortcut type such as:
    • Shortcut
    • FAQ
    • DirectAction
    • InfoStable

In this case, the system may skip full beam/best-first expansion and proceed to target resolution.

This optimization must still respect:

  • policy_state and policy_constraints,
  • taxonomy coherence from the Context Weaver.

2.7 Step 7 — Deterministic traversal / reasoning ​

ARG performs guided search (best-first or beam):

  • exploration order is determined by Score(n),
  • constrained by node types and ontological rules,
  • bounded by typology-driven budgets.

Anti-cycle protections

  • strict visited_nodes tracking,
  • max_hops determined by active typologies,
  • blocking semantic “vector jumps” that would close forbidden loops.

Traversal semantics and guardrails are specified in the
ARG Core and grounded by lifecycle and structure rules in the Guides.

2.8 Step 8 — Case 1: ARG-Action ​

When node_target.type = Action:

  1. Verify preconditions
  • domain rules
  • policy_state and policy_constraints
  • safety invariants and required checkpoints
  1. Clarify if required
  • request missing parameters
  • prefer minimal, deterministic clarification steps
  1. Execute the action
  • through the defined workflow/API integration
  1. Respond with
  • a human-readable explanation of the path (as allowed by policy)
  • outcome/status and next steps

Mandatory logging

  • raw vs policy-filtered labels
  • active typologies
  • landing point
  • selected path (nodes + edges)
  • action invoked
  • system outcome

The pre/post enforcement of action safety is governed by
the Policy Manager.
Action routing and deterministic path rules are specified in the ARG Core.

2.9 Step 9 — Case 2: ARG-Info (online retrieval) — weak-signal aware ​

When node_target.type ∈ {Info, MemoryRead} the system follows a controlled retrieval + generation path, then evaluates information confidence before interpreting outcomes.

This step remains bound by:

2.9.1 Context acquisition (unchanged principle) ​

Collect:

  • the target node chunk,
  • a controlled local neighborhood (bounded by edge rules, typology budgets, and policy).

2.9.2 Combined retrieval (unchanged principle) ​

Use:

  • structured graph retrieval within the allowed subgraph,
  • vector retrieval restricted to the local neighborhood.

Vector search remains a local accelerator, not an open-world memory dump.

2.9.3 LLM generation (unchanged principle) ​

Generate an answer grounded in the retrieved domain context.

The Policy Manager retains the right to enforce a Post-Check before the final response.

2.9.4 New: “Info” confidence estimation C_info ​

Before any implicit success interpretation, compute an information confidence score using:

  • lexical alignment between the prompt and final labels,
  • embedding(prompt) ↔ embedding(chunk(s)) alignment,
  • taxonomy stability along the selected path
    (supported by the Context Weaver),
  • absence of policy conflicts,
  • distance from fallback / OOD path.

Output

  • C_info ∈ [0,1]

2.9.5 New: light Active Check ​

Users are not queried systematically — only strategically.

Triggers

  • low or mid C_info,
  • known ambiguous zones (VECTOR_AMBIGUITY),
  • controlled random sampling for global quality estimation.

Mechanisms

  • binary micro-feedback:
    “Did this help? Yes/No”
  • minimal disambiguation:
    “Do you mean X or Y?”
    when two nearby branches remain plausible.

2.9.6 New: Info-quality logging ​

Always log:

  • C_info,
  • ActiveCheckTriggered (true/false),
  • UserFeedback if present,
  • SilentOutcome = true when no explicit signal is obtained.

2.9.7 New: Info outcome status ​

Replace “implicit success” with three explicit states:

  • INFO_CONFIRMED_SUCCESS
    (explicit positive feedback or strong validated proxy)
  • INFO_UNCERTAIN_SUCCESS
    (no feedback, medium/high confidence)
  • INFO_LOW_CONFIDENCE
    (low confidence without validation)

Rule Silence feeds UNCERTAIN, never CONFIRMED.

This outcome model is used by the offline loop to prevent silent metric inflation
(see offline scoring rules in ARG Core).

2.10 Step 10 — MemoryWrite (online) — corrected v1 with gated semantics ​

ARG uses a two-mechanism memory model.
Online writes must remain conservative and must not modify the active graph structure during the request
(see the online/offline contract in ARG Core).

The Policy Manager enforces a Memory Guard during Pre-Check and Post-Check.

2.10.1 Detect a memorizable fact ​

Identify candidate information worth retaining based on:

  • user intent,
  • node type,
  • domain rules,
  • active typologies.

2.10.2 Classify the fact ​

Assign an InfoType, e.g.:

  • UserProfile
  • Incident
  • PatternUsage
  • ProductConfig
  • etc.

2.10.3 Relevance certificate (label-gated) ​

Semantic memory storage requires a validated label produced by:

If no label can be validated:

  • do not write semantic memory,
  • episodic write is still allowed with the flag:
    • MISSING_LABEL_CANDIDATE

This flag is a direct input for offline taxonomy evolution
(see ARG Core and the taxonomy rules in Guides).

2.10.4 Choose the write mode ​

  • Episodic (online)
    Event-level storage attached to an existing node, safe for immediate recall and offline analysis.

  • Semantic candidate (offline)
    Mark the fact for later consolidation into stable memory structures
    under lifecycle and safety rules.

The online layer captures signal;
the offline layer decides what becomes durable structure
(see ARG Core).

2.10.5 Info Canonicalization & Dedup (Info Registry) ​

Objective
Deduplicate an information unit even when multiple very different chunks express the same fact.
The system does not deduplicate chunks; it deduplicates the InfoUnit.

Principles

  • Labels act as both:
    • a relevance certificate, and
    • a semantic boundary for safe deduplication.
  • Uniqueness must never rely on exact string equality generated by an LLM.
  • The primary uniqueness key must not depend on a mutable taxonomic representation
    (e.g., a human-readable label path).

This subsystem is invoked by MemoryWrite
under constraints from the Policy Manager
and label validity from the Context Weaver.

2.10.5.1 Canonicalization ​

For each candidate fact:

2.10.5.1.1 Deterministic canonicalization when possible
Whenever the InfoType allows it, produce a structured canonical form in key/value style.

Examples of simple patterns:

  • Incident: module, symptom, impact, environment
  • ProductConfig: module, parameter, value, environment
  • UserPreference: object, value, context

2.10.5.1.2 Short canonical summary (domain template)
If a textual summary is needed for indexing:

  • use a strict domain template,
  • minimize free-form generation.

2.10.5.1.3 Normalization

  • lowercase
  • remove non-significant punctuation
  • harmonize validated domain synonyms where available

Outputs

  • canonical_fields (when extractable)
  • canonical_text (optional, template-bound)
  • embedding_canonical_text (if used)
2.10.5.2 Robust uniqueness signature (Context-Weaver aligned) ​

Forbidden

  • Using an exact hash of canonical_text as the primary key.
  • Using a LabelPath as the anchor of uniqueness.

Allowed

  • A stable composite key that constrains semantic scope before any soft matching.
  • A taxonomy signature based on invariant LabelIDs, never on the textual hierarchy.
2.10.5.3 Primary uniqueness key ​

Definition

  • InfoKey = (LabelSignature, InfoType, Scope)

Role of the Context Weaver
The Context Weaver must provide the elements required to compute
LabelSignature under policy constraints.

Where:

  • LabelSignature = stable taxonomy signature derived from the final validated LabelIDs.
    Two accepted forms in v1:

    1. PrimaryLabelID
      a canonical label chosen by the Weaver from L_final_ids
      to represent the “center of gravity” of the fact.
    2. sorted LabelID_set
      used when the project explicitly assumes multi-label uniqueness.

  • InfoType = the nature of the fact
    (UserProfile, Incident, ProductConfig, PatternUsage, …)

  • Scope = User / Org / Global

Expected Weaver outputs

  • L_final_ids
  • PrimaryLabelID (if Primary mode is active)
  • the LabelID-derived LabelSignature (computable deterministically)
2.10.5.4 Status of LabelPath_current ​

LabelPath_current is stored only as indexed metadata for:

  • audit,
  • observability,
  • optional secondary filtering.

It may evolve with the taxonomy without impacting uniqueness.

2.10.5.5 Secondary signature (optional) ​

To speed up candidate recall, the system may add a tolerant signature:

  • SimHash(canonical_text_normalized)
    or
  • MinHash(canonical_text_normalized)

Important

  • The Context Weaver has no structural role here.
    These are computed by the Info Registry after canonicalization.
  • This signature is never sufficient proof of identity by itself.
    It is only a recall index.

Integration rule The Context Weaver does not decide deduplication.
It provides only:

  • the stable LabelID-based signature,
  • and a canonical label if Primary mode is active.

The Info Registry then uses:

  • LabelSignature + InfoType + Scope as the foundation of uniqueness.
2.10.5.6 Search in the Info Registry ​

Search happens in two stages.

2.10.5.6.1 Hard filtering (semantic safety) Limit the search space to InfoUnits that share:

  • the same LabelSignature,
  • the same InfoType,
  • the same Scope.

LabelPath_current may be used as an optimization filter,
but must never be required for identity.

2.10.5.6.2 Soft semantic recall Within this bounded subspace, retrieve candidates via:

  • vector search over canonical_text (or chunks),
  • and/or SimHash/MinHash if enabled.

Output

  • a Top-K list of candidate InfoUnits
2.10.5.7 Uniqueness decision ​

After candidate retrieval, the Info Registry decides whether the incoming fact belongs to an existing InfoUnit or requires a new one.

2.10.5.7.1 Strong match If vector similarity is very high with a candidate InfoUnit:

  • attach the new chunk as an evidence chunk,
  • update internal reliability metrics,
  • do not create a new InfoUnit.

2.10.5.7.2 Grey zone If similarity is moderate:

apply a strict equivalence test using one of:

  • a local NLI / entailment model, or
  • a strictly bounded comparison LLM.

Instruction (bounded task) “Compare this chunk with the canonical description of InfoUnit X.
Respond only with: SAME / DIFFERENT / UNSURE.”

Rules

  • SAME → attach as evidence chunk
  • DIFFERENT → create a new InfoUnit
  • UNSURE → place in staging for offline review

This prevents free-form generative drift while still handling hard semantic cases.

2.10.5.7.3 No match If no candidate is sufficiently close:

  • create a new InfoUnit,
  • register it in the Info Registry.
2.10.5.8 InfoUnit update rules ​

When a new chunk is attached to an existing InfoUnit:

  • retain all evidence chunks,
  • optionally recompute a consolidated canonical_text
    (preferably offline),
  • update an internal reliability score,
  • record provenance and timestamp.

Important This consolidation must never block the user-facing response.

Offline consolidation and promotion rules are defined in the
ARG Core and aligned with lifecycle guidance in the Guides.

2.10.5.9 Protections ​

2.10.5.9.1 Anti-confirmation bias Repeated usage is not a domain truth.

The system must distinguish:

  • strong signals (explicit, reliable outcomes),
  • weak signals (silence, session end, lack of complaint).

An InfoUnit must never be promoted to stable knowledge
based solely on weak signals.

This principle mirrors the Info outcome model in
Step 9 — ARG-Info
and the offline scoring penalties in ARG Core.

2.10.5.9.2 PII / GDPR

  • detect and scrub PII at episodic write time,
  • strictly forbid PII in shared semantic canonical_text,
  • enforce scope rules (User / Org / Global) via the
    Policy Manager.
2.10.5.10 Mandatory logging ​

For every MemoryWrite attempt invoking the Info Registry, log:

  • InfoKey
    (LabelSignature, InfoType, Scope)
  • LabelPath_current
    (audit and debugging metadata)
  • Top-K candidate InfoUnits + similarity scores
  • final decision:
    MATCH / NEW / UNSURE
  • method used:
    VECTOR_ONLY / VECTOR+NLI / VECTOR+LLM_COMPARE / SIMHASH_ASSIST
  • flags:
    • MISSING_LABEL_CANDIDATE
    • NEW_INTENT_CANDIDATE
    • LOW_CONFIDENCE_INFO_WRITE

This logging feeds directly into:

  • offline memory consolidation,
  • slow-poisoning detection,
  • incremental taxonomy refinement
    (especially child-label additions via the Context Weaver).

Lifecycle-safe structural changes are governed by
the offline loop in ARG Core
and validated against construction/audit rules in the Guides.

3. OFFLINE loop — Structural refinement + memory consolidation ​

This is where ARG strongly connects math signals with domain needs without breaking online determinism.

The offline loop consumes enriched logs and outcomes to produce controlled, versioned evolution of:

  • nodes,
  • edges,
  • node↔label/cluster M2M attachments,
  • taxonomy (preferably child-label-first),
  • and semantic memory promotion.

The offline loop is taxonomy-guided by the Context Weaver,
governed by constraints from the Policy Manager,
and validated against construction/audit rules in the Guides.

3.1 Step A — Collection & preparation (weak-signal aware) ​

Inputs collected from logs ​

For each interaction:

  • prompt
  • raw vs policy-filtered labels
  • active context typologies
  • landing point (node_start)
  • path (nodes + edges)
  • target node
  • memory reads/writes
  • system and domain outcomes

This dataset becomes the single source of truth for offline proposal generation and scoring.

3.1.1 Unified outcome definitions ​

For Action Success is a strong system signal, e.g.:

  • API 200 OK
  • workflow completed
  • verified state change

For Info / MemoryRead ARG explicitly separates:

Strong signals

  • explicit positive user feedback
  • optional short-term proxy: immediate reuse of a related action

Weak signals

  • absence of complaint
  • session end
  • no follow-up question

Rule A weak signal must never count as confirmed success.
It may only contribute to uncertain success.

This rule is aligned with the online Info outcome model in
Step 9 — ARG-Info.

3.1.2 Derived node/edge metrics ​

Compute:

  • ConfirmedSuccessRate_info
  • UncertainSuccessRate_info
  • LowConfidenceRate_info
  • ActiveCheckCoverage

These metrics help detect:

  • nodes that appear successful mainly due to silence,
  • zones where real quality remains unknown,
  • edges that systematically lead to ambiguity or low-confidence outcomes.

3.2 Step B — Candidate generation ​

The Context Weaver is central here.
It does not “decide” structure changes; it qualifies taxonomy plausibility of math-driven candidates.

3.2.1 Split candidates ​

For a node N:

  1. aggregate all interactions landing on N,
  2. cluster them by:
    • prompt embeddings,
    • label activation patterns,
    • domain outcomes.

The Context Weaver validates that each proposed sub-cluster corresponds to a plausible taxonomy region.

Output A set of child nodes {N1, N2, ...} with:

  • proposed cluster/label attachments
  • aggregated chunk per subgroup
  • suggested titles

Stability protection

  • splits create children first,
  • the original N moves to DEPRECATED rather than immediate removal.

Lifecycle mechanics are defined in
ARG Core — Lifecycle & versioning.

3.2.2 Merge candidates ​

For nodes A and B:

  • compare chunk and embedding proximity,
  • compare usage similarity,
  • validate taxonomy safety:

Rule Do not merge if the resulting attachments would create
parent/child or cluster↔label incoherence.

Security protection Anticipate and block merges that would create
unsafe shortcut paths bypassing required checks.

Governance rules for action safety remain aligned with the
Policy Manager.

3.2.3 New edge candidates ​

Propose edges when logs show:

  • frequent co-activation patterns,
  • unnecessary detours,
  • taxonomy-consistent adjacency.

The Context Weaver may recommend a more precise edge type
based on shared label parents.

Edge semantics and allowed types are defined in
ARG Core
with conceptual guidance in the Guides.

3.2.4 Taxonomy evolution candidates ​

Sometimes the correct fix is not a new node but:

  • adding a child label, or
  • reattaching a label under the correct cluster parent.

This keeps the graph clean and deterministic while improving routing granularity.

3.2.4.1 Child-label-first addition process ​

Triggers

  • NEW_INTENT_CANDIDATE (online)
  • UNKNOWN_LABEL_CANDIDATE (online)
  • recurring episodic writes flagged as MISSING_LABEL_CANDIDATE
  • repeated VECTOR_AMBIGUITY

Default proposal rule Always propose a child label first:

  • under an existing parent,
  • within an existing cluster.

Automatic checks

  • uniqueness vs siblings
  • parent/child coherence
  • cluster↔label compatibility
  • no new explicit incompatibilities
  • policy non-contradiction

Progressive activation

  • CANDIDATE → SHADOW → ACTIVE

This staged rollout prevents adversarial drift and reduces blast radius.

Where updates apply

  • Context Weaver
    • update Validator rules
    • update Taxonomy Vector Store
  • Policy
    • update label restrictions if required
  • ARG
    • update node↔label (and optionally node↔cluster) attachments
    • adjust edges if new granularity requires safer routing

3.2.5 New node candidates (semantic memory promotion) ​

From episodic memory:

  • detect stable recurring facts
  • confirm demonstrated domain utility

Guardrails

  • do not promote known incorrect usage patterns,
  • strict PII scrubbing (aligned with the Policy Manager).
3.2.5.1 InfoUnit-first dedup before proposing nodes ​

Before proposing any new semantic node:

Rules

  • if the pattern matches an existing InfoUnit:
    • do not propose a new node,
    • enrich the InfoUnit’s evidence set.
  • only if a new stable InfoUnit emerges:
    • then propose a new semantic node.

This prevents duplicate nodes from being created due to
latent-space noise or wording variability.

3.2.5.2 “Slow poisoning” protection ​

A semantic node candidate must never be validated solely by:

  • repetition,
  • positive feedback loops,
  • or weak signals.

Rules

  • require diversity of sources
    (multiple contexts / user segments)
  • reduce the weight of weak outcomes
    in alignment with the Confirmed vs Uncertain model
  • forbid auto-commit if:
    • the benefit is dominated by INFO_UNCERTAIN_SUCCESS, or
    • the supporting user segment is too homogeneous.

Optional internal grounding:

  • check non-contradiction with nearby nodes/chunks,
  • validate against policy/guardrails.

This completes candidate generation for the offline loop.
The next offline stages (replay simulation, scoring with silence penalties, HITL binning, lifecycle publication) remain defined in
ARG Core
and must be consistent with taxonomy staging rules in the
Context Weaver.

3.3 Step C — Math + domain + security scoring (weak-signal corrected) ​

For each candidate change C (split, merge, new edge, new label, new node, attachment change), ARG runs a replay-based evaluation that explicitly separates strong vs weak evidence.

This stage assumes:

3.3.1 Replay simulation (unchanged principle) ​

Replay a representative subset of historical logs and measure:

  • improvement of landing-point quality,
  • reduction of ambiguity,
  • increase in Action success,
  • increase in Info quality,
  • reduction of path length / unnecessary detours.

3.3.2 New: split Info gains into three channels ​

Instead of treating Info success as a single block:

  • Gain_info_confirmed(C)
  • Gain_info_uncertain(C)
  • Gain_info_lowconf(C) (penalty)

This directly aligns offline evaluation with the online outcome states defined in
2.9 Step 9 — ARG-Info.

3.3.3 New: explicit “silence bias” penalty ​

Introduce a penalty:

[ Penalty_{silent}(C)=\kappa \cdot \Delta(\text{Uncertain} - \text{Confirmed}) ]

Intuition
If a modification improves “uncertain” outcomes but not “confirmed” outcomes,
the gain may be an artifact of user silence rather than true quality improvement.

3.3.4 New: corrected Info gain ​

Replace the “Info quality” term with:

[ Gain_{info}(C)=a\cdot Gain_{confirmed}+b\cdot Gain_{uncertain}-c\cdot Gain_{lowconf}-Penalty_{silent}(C) ]

with typical constraints:

  • (a > b)
  • (c) non-negligible

This ensures the system cannot optimize for ambiguity acceptance.

3.3.5 Updated global score ​

The updated candidate score becomes:

[ Score(C)=(Gain_{action}+Gain_{info})-\lambda \cdot Complexité-\mu \cdot Violations_{taxo/ontology}-\nu \cdot Violations_{security} ]

Where:

  • Complexité accounts for maintenance cost and routing inflation,
  • Violations_taxo/ontology penalizes incoherent attachment or hierarchy shifts,
  • Violations_security penalizes any risk of bypassing guardrails and policy constraints.

3.4 Step D — Validation & application (scalable HITL) ​

ARG keeps a three-bin decision model:

  • HIGH_CONF → auto-commit
  • MID_CONF → expert review
  • LOW_CONF → reject / backlog

This stage must remain consistent with:

3.4.1 New: conditional auto-commit rule ​

Even if Score(C) is high:

Auto-commit is forbidden
when improvement is dominated by uncertain Info outcomes.

Example guardrail:

  • Gain_info_confirmed must exceed a minimal threshold
    OR
  • ActiveCheckCoverage must be sufficient on the impacted zone.

This directly prevents silent quality inflation.

3.4.2 New: targeted human sampling ​

Instead of increasing global review load, route to experts:

  • randomly sampled silent successes
  • in strategically important zones

Goal Estimate hidden error rates and recalibrate:

  • C_info,
  • silence penalties,
  • and confidence thresholds.

3.4.3 New: progressive confidence-boost loop ​

If a graph zone is:

  • business-critical,
  • but dominated by weak signals,

then temporarily increase:

  • online Active Check rate, and/or
  • offline human review density

until statistical confidence becomes acceptable.

3.5 Step E — Lifecycle, versioning & safe memory migrations ​

Every accepted structural or taxonomic change must follow a controlled lifecycle:

  • ACTIVE → DEPRECATED → REMOVED

This stage is mandatory once a candidate passes
3.4 Step D — Validation.

3.5.1 Split lifecycle rules ​

When splitting a node N into {N1, N2, ...}:

  • create child nodes first,
  • keep N as DEPRECATED during an observation window,
  • redistribute or conditionally duplicate edges,
  • ensure routing preserves deterministic safety.

3.5.2 Merge lifecycle rules ​

When merging A + B → AB:

  • set A and B to DEPRECATED,
  • create AB,
  • inherit edges under strict constraints,
  • run an integrity test to ensure no guardrail is bypassed.

3.5.3 Obsolescence rule ​

A node can be fast-deprecated if:

  • sustained performance collapse is detected,
  • it is replaced by a finer version,
  • or external constraints change
    (law, process, product policy).

3.5.4 Memory safety under the “branches & leaves” model ​

Because nodes are the leaves that carry operational truth:

  • moving a node between labels/clusters
    → no memory risk (node ID remains stable),
  • reconfiguring labels/clusters above the node
    → no memory risk.

The only sensitive case is a leaf split.

3.5.5 Mandatory split redirection table ​

When:

  • Node A → {Node B, Node C}

ARG must maintain a stable alias/redirect table.

At MemoryRead time:

  • if a memory points to A,
    • redirect to B/C,
    • perform a soft update of the user context.

This avoids mass retagging and prevents
semantic orphaning.

Design rationale and examples for this model are detailed in the Guides.

This concludes the offline refinement loop.

The publication of a new graph/taxonomy release must include:

  • versioned artifacts,
  • updated alias tables,
  • refreshed indexes
    (lexical, node vector store, and the taxonomy label index used by the Context Weaver).

4. Advanced memory system (aligned with v1) ​

ARG keeps a dual memory model to balance online safety with long-term structural reliability:

  • episodic memory online (fast, conservative, non-structural),
  • semantic consolidation offline (controlled promotion into stable structure).

This section complements:

4.1 Online — Episodic memory ​

What is stored Episodic memory captures event-level facts such as:

  • events,
  • preferences,
  • incidents,
  • usage patterns,

and attaches them to:

  • existing nodes,
  • or nodes marked as candidates for offline refinement.

v1 rules

  • No concept creation in real time.
    Online memory cannot create new nodes, edges, clusters, or labels.
  • PII scrubbing at write time.
    PII detection and blocking are enforced by the
    Policy Manager — Memory Guard.
  • Label-gated semantic eligibility.
    If a validated label cannot be produced by the
    Context Weaver, the system:
    • forbids semantic write,
    • allows episodic write with:
      • MISSING_LABEL_CANDIDATE.

This preserves online determinism while creating high-quality signals for offline evolution.

4.2 Offline — Episodic → semantic consolidation ​

Offline promotion is allowed only when all conditions hold:

  • stable recurrence across time,
  • proven domain utility evidenced in offline scores,
  • taxonomy coherence validated by the
    Context Weaver,
  • strict absence of PII.

Possible outputs Depending on what best preserves structure:

  • a new semantic node, or
  • a new child label (preferred when a taxonomy gap is the real issue), or
  • a new explicit edge capturing a validated traversal pattern.

Critical safeguard Before proposing a new semantic node, the system must run:

to prevent duplicate node creation due to wording variation.

4.3 Structural evolution and memory safety (single source of truth) ​

The rules for lifecycle, aliasing, and taxonomy-safe updates are defined once in:

To avoid duplication and cross-page drift, this section only summarizes the non-negotiable invariants:

Branches & leaves invariant

  • Nodes are the leaves that carry operational truth.
  • Clusters/labels are branches that may evolve with traceability.

Implication

  • Moving a node across labels/clusters
    → no memory break (node ID remains stable).
  • Re-parenting or refining labels/clusters above nodes
    → no memory break.

Only sensitive case

  • Leaf node split
    requires a mandatory alias table:

    • Node A → {Node B, Node C}

    used by MemoryRead redirection to prevent semantic orphaning.

Info Registry taxonomy-safe invariant

  • Uniqueness keys must remain path-independent:

    • InfoKey = (LabelSignature, InfoType, Scope)

    where LabelSignature is built from stable LabelIDs produced by the
    Context Weaver.

Taxonomy changes must update:

  • LabelPath_current (metadata)
  • without changing InfoKey.

4.4 Why this dual model is required ​

A single memory mechanism cannot safely satisfy all three constraints:

  1. online speed
  2. long-term stability
  3. controlled evolution

Episodic memory captures signal without structural risk.
Offline consolidation promotes only what proves stable and useful under:

  • taxonomy validity,
  • policy constraints,
  • and lifecycle rules.

This is the foundation that enables reliable long-term agent behavior,
without drifting into uncontrolled vector growth or fragile graph-only rigidity.

For construction, audit, and the branches/leaves model rationale, see the
Guides.

Released under the Apache License 2.0

ARG v1.1 Specification