ARG Core — Protocol

Preamble (high-level model)

ARG standardizes a deterministic, auditable agent protocol built on:

• an operational ontology (taxonomy + relationship semantics),
• a bounded online inference loop over a fixed snapshot,
• an offline refinement loop that evolves structure in a controlled, versioned way,
• explicit policy governance and explicit taxonomy arbitration (not implicit “LLM-only” routing).

This document is the protocol reference. Implementation details and modeling practices live in:

• Context Weaver (taxonomy-safe decomposition and routing),
• Policy Manager (governance kernel),
• Guides (construction, audits, roles/boundaries, and agent-specific practices).

ARG Action space (agent execution)

The action space is the set of executable behaviors the agent may perform.

• The protocol MUST treat actions as first-class outcomes with explicit authorization checks.
• The protocol MUST support a safe fallback when no valid action is available (ABSTAIN or CLARIFY), rather than “hallucinating” new actions online.
• The action space MAY be extended offline (new actions, safer variants, updated bindings), but MUST NOT be mutated during request execution.

ARG Retrieval space (context for reasoning)

The retrieval space is the set of information sources the agent is allowed to consult to produce an answer or to justify an action.

• Retrieval MUST be executed online as read-only over a fixed snapshot of the ontology and approved external connectors.
• Retrieval MUST be bounded by policy constraints and by taxonomy coherence.
• Retrieval MUST produce an explicit context bundle (internal and/or external) that is consumed by generation and post-checks.
• Retrieval structure and indexes MUST evolve offline only.

Effective retrieval in the Retrieval space (high level)

Effective retrieval is the bounded procedure that transforms a request into a small set of relevant context units.

• The protocol MUST separate:
  1. candidate proposal (cheap, approximate),
  2. taxonomy arbitration (deterministic validation),
  3. binding + bounded traversal (execution of retrieval).
• Vector methods MUST be treated as approximators (shortlisting / ranking) and MUST NOT define structure, bypass policy, or expand scope beyond the bound search space.

Short-term and long-term memory (high level)

ARG supports both:

• short-term memory (request-scoped context and recent episodic writes),

• long-term memory (stable semantic structure produced offline).

• Online memory writes MUST be episodic and recorded into a registry/memory layer.

• Promotion of episodic memory into long-term structure MUST occur offline under lifecycle rules (versioned evolution).

• Memory MUST remain safe under structural change (split/merge/lifecycle), using explicit redirection/migration mechanisms.

---

0. Base assumptions

This section defines the foundations that MUST remain true for the protocol to be deterministic, auditable, and scalable.

0.1 Knowledge system structure

ARG systems are built from core knowledge (curated with domain experts) and supporting protocol components.

Context typologies (outside the graph)

Context typologies are not knowledge carriers. They are stable and composable families used to build the global context of a request.

• Typologies MUST be combinable (set composition) to form a single effective context (e.g., role × product × channel × environment × time window).
• Typologies MUST remain high-level and transversal; they describe context dimensions, not domain content.
• Typologies MUST NOT duplicate ontology content (they do not encode domain facts, labels, or graph structure).
• Typologies MUST NOT replace Policy Manager or Context Weaver responsibilities.
• Project-specific typologies SHOULD be minimized, explicitly justified, and audited for redundancy.

The decomposition and restructuring of a request into a usable context representation is performed by the Context Weaver by projection onto the ontology (taxonomy + relationship semantics). Typologies only define which dimensions can be composed; they do not perform routing or retrieval.

Access scope vs domain scope (do not mix)

ARG uses two different notions that must never be collapsed into a single enum:

• Access / ORG scope: the tenant/workspace boundary enforced by policy (RBAC/ABAC, PII rules, budgets, connector permissions). This is what defines N_scope (the set of nodes/connectors the request is allowed to touch).
• Domain scope: the semantic/content boundary expressed by taxonomy + routing signals (clusters, labels, and RetrievalType = DOMAIN for domain/project knowledge).

Rules:

• When the question is “who is allowed” → use ORG / tenant / workspace / access (Policy Manager).
• When the question is “what we are talking about” → use DOMAIN / project / vertical (taxonomy + Context Weaver).

In schemas:

• Use AccessScope when you mean ORG/tenant access.
• Use RetrievalType (or an explicit KnowledgeScope) when you mean DOMAIN.

Taxonomy: cluster ↔ label

The taxonomy provides the stable hierarchical backbone used for routing and controlled evolution.

• A cluster MUST represent a stable top-level domain root.
• Labels MUST form a hierarchical chain (root → parent → child) and MUST be taxonomy-coherent.
• Taxonomy validity MUST be enforced deterministically by the Context Weaver Validator (labels must exist, be compatible with their cluster, and respect incompatibilities).
• Taxonomy evolution MUST occur offline only (versioned, auditable).

ARG ontological graph

ARG uses an operational ontology where nodes are terminal leaves and edges express movement grammar between leaves.

• A Node MUST be a terminal operational unit: concept, action, information, or memory behavior.
• Nodes MUST be addressable and attachable many-to-many to:
  • clusters,
  • labels,
  • edges (and/or edge semantics / edge tags).
• Each node MUST contain:
  • title (interpretable domain concept),
  • chunk (ultra-refined text).

Normative boundary:

• Embeddings and vector indexes are retrieval/runtime artifacts (computed/used by the retrieval stack, including Context Weaver) and are not persistent ontology fields.
• Node “type” MUST be expressed through taxonomy attachments (labels/clusters) and relationship semantics, not as a separate mandatory node field.

This “branches & leaves” model is detailed in the Roles & Boundaries guide and the Construction & Audit guide.

0.2 Existing inference mechanics

ARG builds on deterministic and scalable primitives.

• The protocol MUST separate:
  • routing candidate proposal (cheap),
  • taxonomy arbitration (deterministic),
  • binding + bounded retrieval execution (online read-only).
• The protocol MUST treat vectors as bounded approximators for shortlisting/ranking and MUST NOT allow open-world vector recall to expand scope.
• The protocol SHOULD prefer deterministic set/binding and relationship semantics over global similarity for correctness and auditability.

(Implementation families and concrete algorithms are defined in guides and component documents; ARG Core only defines the contract boundaries.)

0.3 Mandatory additions for v1

To be production-grade, ARG systems MUST include:

• Enriched online logging (observability sufficient to replay and audit routing, constraints, and outcomes).
• An offline refinement loop that proposes and applies controlled structural evolution (splits/merges/edges/taxonomy additions) under lifecycle rules.
• Memory consolidation that promotes episodic signals into stable semantic structure offline, with redirection/migration safety.

1. Overview of the ARG v1 Protocol

ARG is built around two coordinated loops operating on the same knowledge system:

• an ONLINE loop that performs deterministic request-time inference over a fixed snapshot, and
• an OFFLINE loop that performs controlled, versioned structural evolution and memory consolidation.

The protocol MUST preserve this separation. Any change to ontology structure (nodes/edges/labels/clusters) MUST be produced and published by the offline loop; the online loop MUST remain read-only with respect to the active ontology.

The protocol MUST be implementable as a composition of specialized components:

• Policy Manager: governance kernel (pre-check, constraints injection, post-check).
• Context Weaver: request decomposition + taxonomy-safe label arbitration + routing signals (including RetrievalType).
• ARG Core (this document): the orchestrated, deterministic online steps and the contract boundary between online execution and offline evolution.

1.1 ONLINE loop — ARG inference

Input

• user prompt,
• structured context (role/product/channel/environment/timestamp/short history),
• governance outputs from Policy Manager (policy state + constraints),
• routing outputs from Context Weaver (taxonomy-safe labels + RetrievalType + confidence/flags).

Output

• an executed action (if authorized), or
• an information response grounded in retrieved context, and
• episodic writes (registry/memory layer) when appropriate.

Normative properties:

• The online loop MUST treat the ontology as a fixed snapshot for the duration of the request.
• The online loop MUST run Policy gating before routing and retrieval, and it MUST run post-check before emitting a response and before any write.
• The online loop MUST keep routing and retrieval bounded by taxonomy validity and policy constraints.
• The online loop MUST NOT create or mutate nodes/edges/labels/clusters online; online writes are episodic logs/registrations only.

---

2. ONLINE loop — Request-time protocol (read-only graph)

This section defines the request-time pipeline. The protocol is expressed as numbered steps to ensure replayability and auditability. All steps are executed under the governance envelope produced by the Policy Manager and under the routing outputs produced by the Context Weaver.

2.1 Step 1 — Policy Pre-Check

The Policy Manager runs before any routing, retrieval, traversal, action execution, or write.

• The system MUST call Policy Pre-Check prior to Step 2.
• The system MUST attach policy_state and policy_constraints to the request context.
• If policy_state = BLOCK, the system MUST stop the pipeline and refuse.
• If policy_state = ALLOW_WITH_REFOCUS, the system SHOULD produce a refocus response and stop unless policy explicitly allows continued processing under constraints.
• If policy_state = RESTRICT, the system MUST proceed under restricted constraints and may be forced into ABSTAIN/CLARIFY depending on what is permitted.

Policy constraints produced here MUST be treated as hard gates for all subsequent steps (routing, binding, scoring, traversal, action, external connectors, and writes).

2.2 Step 2 — Initial classification

This step proposes candidates for routing. It is not retrieval and does not traverse the graph.

• The system MUST perform cheap candidate proposal (lexical-first) to produce L_raw (candidate labels) and/or candidate targets for downstream routing.
• The system MAY use lightweight semantic approximators for shortlisting, but any such use MUST NOT expand scope beyond what policy allows.
• The system MUST apply policy constraints to the candidate proposal outputs (e.g., disallowed labels are filtered or downweighted).
• The system MUST log the raw candidates and the policy-filtered candidates for auditability.

This step MUST NOT be described as “retrieval”. Retrieval begins only after Binding (Step 4).

Policy-facing alias section (optional; separate content, separate responsibility)

• This section SHOULD describe Step 2 in policy terms only (what is allowed to be proposed, what must be filtered, what must be logged), without duplicating Context Weaver logic.
• If this section exists, it MUST remain consistent with #online-step-2-initial-classification and MUST NOT introduce new mechanics.

2.3 Step 3 — Context Weaver

The Context Weaver performs request decomposition and taxonomy-safe arbitration.

• The system MUST call the Context Weaver after Step 2 and before Binding (Step 4).
• The Context Weaver output MUST include:
  • taxonomy-safe labels L_final,
  • taxonomy-safe label identifiers L_final_ids,
  • a PrimaryLabelID (the best single routing label when a primary is required),
  • a deterministic LabelSignature computed from L_final_ids (stable identity form used by registries),
  • RetrievalType ∈ {USER, DOMAIN, EXTERNAL},
  • confidence and uncertainty flags (including a recommendation to ABSTAIN/CLARIFY when needed).
• The Context Weaver MUST apply deterministic validation of taxonomy coherence (labels must exist and be compatible).
• The Context Weaver MUST preserve stable identity: LabelSignature MUST be based on LabelIDs (not LabelPath). A human-readable LabelPath MAY be emitted for audit, but it MUST NOT be the identity used for keys.
• The Context Weaver MUST NOT execute graph retrieval; it produces routing signals and validated labels only.
• If the Context Weaver signals ABSTAIN_RECOMMENDED (or equivalent), the online loop SHOULD prefer CLARIFY/ABSTAIN over forced execution.

2.4 Step 4 — Landing point

This step binds the request to a safe subspace and chooses where traversal starts.

• The system MUST compute a bound eligible set:where is defined by policy constraints and access control (AccessScope / tenant/workspace boundary).
• All subsequent scoring and traversal MUST remain inside .
• The system MUST compute one or more landing point candidates inside using deterministic projection rules over node↔label/cluster attachments and relationship semantics.
• If RetrievalType = EXTERNAL, the system MUST bind to an approved external connector target (an ExternalSource/LiveConnector node or equivalent) and MAY reduce or skip internal traversal as permitted by policy and typology budgets. Internal traversal, when performed, MUST remain inside .

Action binding decision

• The system MUST decide whether the request enters the Action path or the Info path using the landing context, node semantics, and policy constraints.
• The system MUST prefer Info/Clarify over Action when uncertainty is high, when policy is restrictive, or when required action bindings are missing.

Cold start domain agent rules

• When the domain is under-specified or the landing point is weak, the system MUST treat this as cold-start and SHOULD default to CLARIFY or safe Info-only behavior.
• Cold-start handling MUST NOT cause open-world expansion outside .

Clarify instead of act

• The system MUST trigger CLARIFY instead of Action when policy constraints are insufficient for safe execution, when taxonomy arbitration is low-confidence, or when the action binding is ambiguous.
• Clarify prompts SHOULD be minimal and designed to restore a deterministic route.

2.5 Step 5 — Neighbor scoring

This step builds a bounded neighborhood for traversal.

• Candidate collection MUST be restricted to neighbors and candidates inside .
• Any vector scoring MUST be local (ranking/pruning only) and MUST NOT expand the search space.
• The system MUST apply policy and taxonomy gates before scoring (forbidden nodes/edges are excluded).
• The output MUST be a bounded ranked candidate set suitable for traversal (with budgets derived from typologies and policy constraints).

2.6 Step 6 — Fast Path

Fast path is a bounded shortcut when confidence is high.

• The system MAY short-circuit traversal when a stable direct target is available and governance permits it.
• Fast path MUST still enforce policy constraints, taxonomy validity, and bounds.
• Fast path MUST be logged as a distinct decision for auditability.

2.7 Step 7 — Deterministic traversal / reasoning

Traversal selects the target node(s) under bounded budgets.

• Traversal MUST be bounded (depth/hops/tokens/latency) and MUST remain inside .
• Traversal MUST follow relationship semantics (movement grammar) and must respect forbidden edges.
• The system MUST implement a stop criterion and MUST output:
  • a target node (or ranked targets), and
  • for Info execution, a bounded InternalContextBundle (selected Info chunks) sufficient for response generation.

2.8 Step 8 — Action

The Action path executes an authorized action bound to the request.

• The system MUST re-check action authorization under policy constraints before execution.
• The system MUST execute only actions that exist in the action space and are bound deterministically.
• If a valid action is not available, the system MUST fall back to ABSTAIN or CLARIFY; it MUST NOT invent new actions online.
• Action outcomes MUST be recorded as episodic logs for offline refinement.

2.9 Step 9 — Info

The Info path produces a grounded response from retrieved context.

• The system MUST generate responses only from the bounded context bundles selected by traversal and/or external connectors.
• The system MUST run Policy Post-Check before emitting the final response.
• The system MUST log the context units used (IDs / references) sufficient for auditability.

Info quality and weak-signal outcomes

Each Info execution MUST produce an explicit quality signal:

• (Info confidence)
• InfoOutcomeStatus ∈ {INFO_CONFIRMED_SUCCESS, INFO_UNCERTAIN_SUCCESS, INFO_LOW_CONFIDENCE}

Rules:

• The system MUST NOT treat silence as confirmed success. If no explicit verification signal exists, the outcome MUST NOT be INFO_CONFIRMED_SUCCESS.
• The system SHOULD run a lightweight Active Check only when needed (e.g., low margin, high-stakes answers, external-only context, or when the response would be persisted/used for automation). The Active Check MUST be bounded and must not expand scope beyond the already bound context.
• The system MUST log C_info, InfoOutcomeStatus, whether Active Check ran, and the evidence used for the status decision.

External retrieval mode via ExternalSource node

• External retrieval MUST be executed only via approved connectors under policy constraints.
• External results MUST be treated as ephemeral context for the request; they MUST NOT become ontology nodes online.
• External retrieval MUST produce an ExternalContextBundle with source metadata and timestamps.

Merge context bundles (internal + external + user/domain memory/registry)

• Before generation, the system MUST assemble a single final context bundle from:
  • InternalContextBundle,
  • ExternalContextBundle (if any),
  • eligible registry/memory reads permitted by policy.
• The merge MUST respect ordering, budgets, and provenance, and MUST preserve traceability (what came from where).

2.10 Step 10 — MemoryWrite

Online writes are episodic only.

• The system MUST write only episodic records (MemoryWrite / RetrievalWrite) into the memory/registry layer.
• The system MUST run Policy Post-Check (and memory guard rules) before writing.
• The system MUST NOT mutate the active ontology online.
• The system MUST distinguish request-scoped/working-set records from long-term semantic structure: online writes are registry events with explicit retention metadata (e.g., TTL / retention class) and are consolidated offline only.
• The system MUST treat repeated usage as a weak signal: repeated retrieval or repeated citation MUST NOT be interpreted as domain truth, and MUST NOT trigger automatic promotion into long-term structure without offline validation.
• The system MUST enforce privacy and access invariants at write time: PII rules and AccessScope boundaries apply to all registry writes, including Info Registry entries and external bundle logs.

External context bundle write rules

• External bundles MUST be stored as episodic records with provenance (connector, timestamp, query), not as graph nodes.
• External bundle writes MUST be safe under policy constraints and access controls.
• External bundle logs MUST be eligible for offline analysis and consolidation workflows, but MUST NOT be promoted into ontology structure online.

Info Canonicalization & Dedup (Info Registry)

The Info Registry is the canonical staging layer for information units prior to offline consolidation.

Canonicalization

• The system MUST canonicalize each Info unit into a stable template (InfoUnit) including at minimum:
  • InfoText (normalized text payload),
  • InfoType (controlled category),
  • AccessScope (the policy/tenant access boundary under which this InfoUnit is valid),
  • LabelSignature (taxonomy signature used for routing; see below),
  • Provenance (internal node refs and/or external connector refs),
  • Timestamp (observation time),
  • C_info and InfoOutcomeStatus (from Step 9).

Keys

• The system MUST compute a deterministic key:
• LabelSignature MUST be stable across versions. When applicable, the registry MUST store both:
  • LabelIDs (preferred for identity), and
  • LabelPath (human/audit-friendly). The key SHOULD use LabelIDs when available; LabelPath MAY be used as a fallback for compatibility.

Dedup and match resolution

• The registry MUST run a two-phase matching procedure:
  1. Hard filtering: restrict candidates by InfoKey (exact match on InfoType + AccessScope + LabelSignature identity form).
  2. Bounded recall/ranking: retrieve Top-K candidates using bounded similarity methods (lexical and/or local vector ranking limited to the filtered set).
• The registry MUST decide one of:
  • STRONG_MATCH (merge/update existing canonical unit),
  • GREY_ZONE (requires bounded semantic compare),
  • NO_MATCH (create new canonical unit).

Grey-zone compare

• For GREY_ZONE, the system MUST run a bounded semantic compare producing:
  • CompareResult ∈ {SAME, DIFFERENT, UNSURE}
• The compare MUST be constrained to the Top-K candidates and must not expand beyond the filtered candidate set. It MAY use NLI or a bounded LLM compare prompt.

Logging

• The system MUST log, per InfoUnit write attempt:
  • the computed InfoKey,
  • the Top-K candidate IDs considered,
  • the matching method(s) used,
  • the match decision (STRONG_MATCH / GREY_ZONE / NO_MATCH),
  • any compare outputs (SAME / DIFFERENT / UNSURE),
  • and the flags/status signals (C_info, InfoOutcomeStatus).
• The registry MUST preserve references needed for offline replay and for split/merge migration safety.

3. OFFLINE loop — Controlled evolution (versioned)

The offline loop is the only place where ARG structure evolves. It consumes online registries and outcomes, produces candidate structural changes, validates them under governance rules, and publishes versioned updates under lifecycle constraints.

The offline loop MUST be:

• taxonomy-guided (evolution is constrained by clusters/labels and their validation rules),
• outcome-driven (changes are justified by measurable failures or coverage gaps),
• versioned and auditable (every publish is traceable to evidence and validation),
• safe for memory continuity (splits/merges and lifecycle changes preserve traceability).

3.0 Offline loop (entry)

• The system MUST run the offline loop on a controlled schedule or trigger policy (batch or event-driven).
• The system MUST treat offline execution as a gated pipeline (A→E). Skipping stages MUST be explicit and logged.
• The system MUST preserve a publish boundary: online reads use only the last published active version; offline changes are not visible until published.

3.1 Step A — Collection

This stage aggregates and normalizes signals for candidate generation.

• The system MUST collect:
  • episodic registries (routing, constraints, traversal paths, context bundles),
  • action outcomes (success/failure, execution traces, user feedback),
  • memory events (writes, reads, conflicts),
  • coverage and abstention signals (low margin, OOD, clarify loops).
• The system MUST normalize these signals into a stable offline dataset with provenance and timestamps.
• The system MUST separate strong vs weak signals (e.g., verified outcomes vs ambiguous feedback) and preserve the distinction downstream.

3.2 Step B — Candidates

This stage proposes structured changes to improve future online performance while preserving determinism and safety.

• Candidate generation MUST be taxonomy-guided: proposals are anchored to clusters/labels and must be expressible in ontology terms.
• Candidates MUST be typed (split, merge, edge, taxonomy, new-node, registry dedup), with each type producing explicit before/after intents and evidence references.
• The system MUST maintain a bounded candidate budget per batch to keep validation and publish tractable.

3.3 Step C — Scoring

This stage assigns priority and expected impact to candidates.

• The system MUST score candidates against offline evidence, including failure frequency, severity, coverage impact, safety risk, and expected retrieval/action precision gains.
• The system SHOULD use replay when possible (re-running past requests against proposed changes) to estimate impact under realistic constraints.
• Scoring MUST preserve uncertainty: low-confidence candidates may proceed only under stricter validation or be deferred.

Weak-signal governance (anti silence-bias)

Offline scoring MUST incorporate the Info-quality model emitted by the online Info path:

• Each request contributes C_info ∈ [0,1] and an InfoOutcomeStatus ∈ {INFO_CONFIRMED_SUCCESS, INFO_UNCERTAIN_SUCCESS, INFO_LOW_CONFIDENCE}.
• The system MUST enforce the rule silence ≠ confirmed success: unverified outcomes must not be counted as confirmed gains.

Candidate impact scoring MUST separate gains by Info outcome tier:

• Gain_info_confirmed from INFO_CONFIRMED_SUCCESS
• Gain_info_uncertain from INFO_UNCERTAIN_SUCCESS
• Gain_info_lowconf from INFO_LOW_CONFIDENCE

The system MUST apply a silence-bias penalty:

• Penalty_silent(C) penalizes candidates whose apparent gains are primarily driven by unverified or weak-signal outcomes (including UNSURE compare results and missing verification).

Auto-commit constraints:

• A candidate MUST NOT be auto-committed if its projected gains are dominated by Gain_info_uncertain and/or Gain_info_lowconf beyond a configured threshold. Such candidates MUST be routed to stricter validation or human review.

Targeted sampling and progressive confidence boost:

• The system SHOULD implement targeted human sampling for high-impact but weak-signal candidates (prioritize by risk × expected gain × uncertainty).
• The system SHOULD support a progressive confidence-boost loop: re-evaluate deferred candidates after additional evidence is collected, increasing confidence only when the confirmed tier improves.

3.4 Step D — Validation

This stage enforces hard gates before publication.

• The system MUST validate each candidate for:
  • taxonomy coherence (label compatibility, hierarchy constraints, incompatibilities),
  • policy and access constraints (RBAC/ABAC boundaries respected),
  • structural integrity (no forbidden edges; bounded traversal invariants preserved; no uncontrolled M2M explosion),
  • memory continuity (no silent orphaning of episodic records; explicit migration/redirection paths exist).
• Validation MUST classify candidates into outcomes (approved, rejected, needs human review, deferred), with explicit reasons recorded.
• Approved candidates MUST be transformed into a publishable change set (versioned delta).

3.5 Step E — Lifecycle

This stage publishes changes under lifecycle rules.

• The system MUST publish ontology changes as a new version with explicit lifecycle states: ACTIVE → DEPRECATED → REMOVED.
• Any change that removes or replaces operational leaves MUST preserve continuity via redirection/migration mechanisms (e.g., split tables, merge aliases, edge redirects), so that past episodic records remain interpretable.
• The system MUST update dependent artifacts at publish time (indexes, validator rules, connector bindings as applicable) so the next online snapshot is self-consistent.
• The system MUST log publish metadata: version id, change set summary, validation report, and rollback instructions.

3.6 Offline label addition

• Label addition MUST occur offline only.
• New labels MUST be validated for cluster compatibility and hierarchy placement.
• When labels are added, the system MUST update validator rules and any label index used by routing/arbitration before publishing.
• Label additions SHOULD prefer child-label additions over disruptive taxonomy rewrites.

3.7 Offline outcomes

• The system MUST define and persist a unified set of outcome categories for offline evaluation (e.g., answered, abstained, clarified, misrouted, unsafe attempt blocked, action succeeded/failed).
• Outcomes MUST be used to drive candidate generation and scoring, not treated as optional analytics.

3.8 Offline derived metrics

• The system MUST compute and persist derived metrics required to govern evolution, such as:
  • coverage by label/cluster,
  • abstention and clarify rates by label/cluster,
  • action success rates by action binding,
  • regression indicators across published versions,
  • slow-poisoning and drift indicators.
• Derived metrics MUST be versioned and attributable to the corresponding ontology version and policy configuration.

---

4. Advanced memory (contracts)

Advanced memory defines how episodic records remain safe and interpretable as the ontology evolves, and how offline consolidation promotes stable long-term structure.

4.0 Advanced memory

• The system MUST support a dual memory model:
  • online episodic writes (registry),
  • offline semantic consolidation (published structure).
• Memory safety MUST be maintained under lifecycle events (split/merge/deprecate/remove), so that historical records never become structurally ambiguous.

4.1 Episodic memory (online)

• Online memory writes MUST be episodic and append-only.
• Each episodic record MUST include sufficient provenance to remain interpretable offline (policy state, routing outputs, target ids, timestamps, and outcome category).
• Episodic memory MUST NOT directly mutate ontology structure.

4.2 Episodic → semantic (offline)

• Promotion of episodic memory into semantic structure MUST occur offline only and MUST be governed by lifecycle rules.
• Consolidation MUST avoid uncontrolled drift: new structure is published only after validation and versioning.
• Consolidation MUST preserve traceability: semantic artifacts must be attributable to episodic evidence and to the ontology versions under which they were observed.

5. End-to-end examples

This section provides illustrative, end-to-end flows that exercise the protocol across Policy, Context Weaver routing, retrieval/traversal, action/info execution, and episodic writes.

• Examples MUST be consistent with the protocol steps and with the responsibilities defined in Policy Manager and Context Weaver.
• Examples MUST demonstrate the expected failure semantics (ABSTAIN / CLARIFY / REFUSE / REFOCUS) and the conditions that trigger them.
• Examples SHOULD include at least one case for each execution path:
  • Info-only (internal retrieval),
  • Info with external connector retrieval,
  • Action execution,
  • Cold-start routing,
  • MemoryWrite and offline consolidation traceability.
• Examples MUST NOT introduce mechanics not defined elsewhere in the standard.

---

6. Production checklist and anti-patterns

6.1 Production checklist

Before production rollout, an ARG implementation MUST satisfy:

• Governance

  • Policy Pre-Check gates routing and retrieval.
  • Constraints injection is enforced as hard gates across binding, traversal, connectors, and writes.
  • Policy Post-Check runs before final response and before any write.

• Routing & taxonomy

  • Context Weaver outputs taxonomy-safe L_final, RetrievalType, and confidence/flags.
  • Validator enforcement is deterministic and logged.
  • No step bypasses taxonomy coherence.

• Retrieval safety

  • Binding enforces a bounded eligible set; traversal and scoring never escape it.
  • External retrieval runs only through approved connectors under policy constraints.
  • External results are treated as ephemeral context and are never promoted online.

• Observability

  • Online execution emits sufficient logs to replay decisions (policy state, constraints, routing outputs, traversal path, bundles used, outcomes).
  • Offline pipeline logs candidate generation, scoring, validation reasons, and publish metadata.

• Lifecycle & versioning

  • Published ontology versions are explicit, traceable, and rollbackable.
  • Split/merge/lifecycle operations preserve continuity via redirection/migration mechanisms.

• Performance budgets

  • Latency budgets are enforced per step (Policy, Weaver, traversal, connectors).
  • Deterministic stop criteria are applied on traversal and context bundle construction.

6.2 Anti-patterns

An ARG implementation MUST NOT:

• mutate ontology structure online (nodes/edges/labels/clusters) or “self-heal” the graph during a request,
• use vectors as authoritative structure builders (open-world recall, routing truth, policy bypass, or unbounded expansion),
• duplicate Policy Manager responsibilities inside ARG Core or Context Weaver,
• duplicate Context Weaver validation/routing responsibilities inside ARG Core or Policy Manager,
• treat silence/absence of errors as success (every request must end in an explicit outcome),
• write external retrieval content into the ontology online,
• publish offline changes without validation gates, versioning, and lifecycle continuity mechanisms.

---

7. Annexes

Annexes define stable reference material required for interoperability and auditability. Implementations MUST align with these definitions.

7.1 JSON contracts

Implementations MUST expose and adhere to canonical schemas for the following protocol objects:

• PolicyDecision (Pre-Check and Post-Check outputs, constraints envelope)
• WeaverOutput (taxonomy-safe labels, RetrievalType, confidence, flags)
• BindResult (eligible space identifier, landing point(s), routing decision)
• TraversalResult (visited path summary, stop reason, target node(s))
• InternalContextBundle (selected Info units with provenance)
• ExternalContextBundle (connector provenance, timestamps, excerpts/ids)
• FinalContextBundle (merged bundles with ordering + provenance)
• ActionResult (authorized binding, execution trace, outcome)
• MemoryWrite / RetrievalWrite (episodic registry record)
• OfflineCandidate (typed proposal + evidence references)
• ValidationReport (approval/rejection reasons)
• PublishDelta (versioned change set + lifecycle events)

7.2 Standard flags

Implementations MUST use a standardized flag vocabulary across routing and execution. At minimum, the flag set MUST cover:

• routing uncertainty and ambiguity (e.g., low margin, conflicting candidates),
• out-of-domain detection,
• abstention and clarification recommendations,
• cold-start conditions,
• policy-driven restrictions affecting retrieval/action feasibility.

Flags MUST be logged and MUST be consumable by both online control flow and offline candidate generation.

7.3 Errors and codes

Implementations MUST use stable error categories that distinguish:

• policy blocks/refusals,
• taxonomy invalidation failures,
• binding failures (empty eligible space),
• connector failures (unavailable/forbidden/timeouts),
• traversal budget exhaustion,
• write rejections (memory guard / access control),
• publish/validation failures (offline).

Errors MUST be logged with a stable code, a human-readable reason, and the step at which they occurred.

7.4 Runtime synchronization patterns

Implementations MUST apply runtime patterns that preserve correctness under retries, concurrency, and partial failures:

• Idempotency: action execution and writes must be idempotent under retry (idempotency keys).
• Deduplication: registry writes and Info canonicalization must use stable dedup keys.
• Transactional boundaries: clearly separate (a) online execution, (b) episodic writes, (c) offline publish.
• Compensation: define compensation/rollback strategies for action side effects when post-check fails.
• Version pinning: online requests must pin to a specific published ontology version; offline updates become visible only after publish.
• Connector budgets: enforce timeouts and quotas; failures must degrade safely to Info/Clarify where appropriate.

7.5 Related guides

This protocol is complemented by the following documents:

• Guides hub: /guides
• Construction & Audit: /guides/construction
• Roles, Boundaries & Examples: /guides/roles-boundaries
• Context Weaver: /context-weaver
• Policy Manager: /policy-manager
• Introduction: /introduction