Skip to content

Context Weaver Architecture — 100ms Budget Mode

(with Taxonomy Vector Store scalability, Fast Track, distilled-first routing and taxonomy stability)


0. Role

The Context Weaver transforms a noisy linguistic signal (user prompt + early lexical candidates) into a taxonomy-coherent routing output that can be safely consumed by the online loop.

It does two things:

  1. Decomposition
    It breaks the prompt into context units (intent, entities, constraints, hints).
    In parallel, typologies stay high-level context dimensions (role, product, channel, environment, time window). They define what can be composed, but they do not carry knowledge by themselves.

  2. Projection + arbitration
    It projects those units onto the taxonomy and outputs:

  • RetrievalType (USER / DOMAIN / EXTERNAL)
  • a validated label set L_final
  • confidence and flags

Once you have L_final, routing becomes set theory:

  • each label (or label region) corresponds to a set of eligible nodes N(L_final) (many-to-many attachments)
  • policy gives the allowed scope N_scope
  • the binding filter is the intersection:

Those outputs are then used for:

It adds linguistic nuance while keeping routing bounded and auditable: it can refine labels, but it cannot invent new structure at runtime.


1. Non-negotiable principles

  • Taxonomy validity always wins.
    The deterministic Taxonomy Validator is the final arbiter.

  • Vector similarity is an approximator, not truth.
    It restricts the space of choice; it does not define structure.

  • The Weaver does not create the taxonomy online.
    It can detect missing labels and emit offline candidates.

  • The LLM is an escalation tool, not a default step.
    It must not be in the hot path for >80–95% of requests.

  • Budget-time first.
    Each sub-step supports early exit and controlled degradation.

These rules exist to keep the online loop deterministic and policy-safe
(see Policy Manager).


2. Inputs and outputs

Inputs

  • user prompt
  • structured context
    (role, product, channel, short history, etc.)
  • L_raw from initial classification / candidate proposal (lexical-first)
    (BM25 / TF-IDF / equivalent)
    → see ARG Core — Step 2: Initial classification
  • policy envelope (constraints + access boundary) produced by the Policy Manager
    (Context Weaver consumes these constraints; it does not define them.)
  • core knowledge:
    • context typologies (to parameterize constraints)
    • taxonomy: cluster → label root → parent → child
    • explicit incompatibility rules (if available)

Outputs

The Context Weaver output MUST provide stable identity for downstream binding and registries:

  • L_final
    validated and weighted labels (human/audit friendly form)
  • L_final_ids
    the corresponding stable LabelIDs for every label in L_final
  • PrimaryLabelID
    the best single routing label when a primary label is required
  • LabelSignature
    a deterministic signature computed from L_final_ids (stable identity form for keys and registries)
  • RetrievalType ∈ {USER, DOMAIN, EXTERNAL}
  • confidence_global
  • flags:
    • OOD
    • VECTOR_AMBIGUITY
    • LOW_MARGIN
    • ABSTAIN_RECOMMENDED
    • NEW_INTENT_CANDIDATE
    • UNKNOWN_LABEL_CANDIDATE
    • CONFLICT_POLICY_STRONG_SIGNAL
    • LLM_ESCALATED

Optional (audit-only):

  • LabelPath (human-readable taxonomy path)
    (MAY be emitted for debugging/audit; MUST NOT be used as identity in keys.)

Optional (stable, non-contradictory to v1 if enabled):

  • COLD_START_BUFFER_CANDIDATE
    → routes to a pre-existing system label Pending_*

3. Sub-modules (100ms version)

3.1 Label Interpreter — dual mode

Two implementations activated by the cascade:

3.1.1 Distilled Label Router (default hot path)
A small fast model (or linear head over embeddings + engineered features), trained on logs.

Responsibilities:

  • propose Top-N labels
  • estimate conf_distilled
  • pre-detect ambiguity and OOD risk (pre-flags)

3.1.2 Bounded LLM Proposer (exception path)
Activated only if:

  • persistent LOW_MARGIN, or
  • strong VECTOR_AMBIGUITY, or
  • conf_distilled too low.

It is strictly bounded by Top-K labels from the Taxonomy Vector Store.
This switch is a key condition for the 100ms target.


3.2 Taxonomy Validator (deterministic)

Applies core knowledge strictly:

  • label existence
  • cluster↔label compatibility
  • parent/child coherence
  • explicit incompatibilities
  • policy and typology constraints
    → see Policy Manager and Guides

3.3 Conflict & Uncertainty Manager

Decides rapidly whether to:

  • accept the label route,
  • trigger a cautious traversal profile,
  • recommend abstention/OOD,
  • or escalate to the bounded LLM proposer.

This manager prevents unstable label sets from leaking into
landing-point computation and traversal
(see ARG Core).


4. Online Context Weaver pipeline — 100ms cascade

This pipeline is referenced by
ARG Core — Step 3 taxonomy arbitration.


OW-0 Fast Track Gate

Goal
Decide in ~1–3ms whether the heavier steps can be skipped.

Typical conditions

  • very high lexical TopLabelScore
  • trivial taxonomy coherence
  • simple context (e.g., “standard” typology)

If satisfied

  • bypass OW-2 and OW-3
  • jump directly to OW-5

Output

  • FAST_TRACK = true/false

OW-1 Lexical canonicalization (deterministic)

Simple normalization:

  • known aliases
  • lexical variants
  • light cleanup

Output

  • L_norm

OW-2 Taxonomy retrieval (Taxonomy Vector Store)

OW-2.0 Taxonomy Vector Store design
For each label, store:

  • label_id
  • label_name
  • label_description
  • cluster_parent_name
  • optional:
    • validated synonyms
    • examples
    • negative examples
    • taxonomy_path_tokens (e.g., "Root > ... > Parent > Label", compact)
    • sibling_hint_tokens (optional, few nearby sibling names; compact)

Each vector-index release MUST also record:

  • taxonomy_version (Validator/core-knowledge version)
  • embedder_id (embedding model identifier for this index)
  • vector_index_version (ANN build/version identifier)
  • optional: feature_schema_version (if v_label composition changes over time)

Vectorization
Build a single text view v_label and embed it:

  • v_label = Name + Description + Cluster parent + Synonyms
  • plus optional structure-derived hints (do not define structure, only improve matching):
    • + taxonomy_path_tokens
    • + sibling_hint_tokens
    • + negative examples (if present)

Note: the Taxonomy Vector Store is an approximate restrictor; taxonomy structure remains enforced by OW-5.

OW-2.1 Prompt embedding

  • e_q = embed(prompt)
  • embedder_id_q = current_embedder_id

OW-2.2 kNN search

  • Top-K labels = kNN(e_q, TaxonomyVectorStore)

100ms optimizations

  • K = 10–20
  • aggressive ANN
  • compact embeddings
  • optional: cache (prompt_hash → L_vec_topk) for hot queries

Output

  • L_vec_topk (with label_id + ANN similarity score + taxonomy_version + embedder_id)

OW-2.3 Release compatibility & drift control (required)

Online compatibility rule

  • The Context Weaver MUST treat any mismatch between:
    • the taxonomy_version attached to L_vec_topk and the active Validator taxonomy_version, or
    • the embedder_id attached to L_vec_topk and embedder_id_q, as a reliability degradation signal (lower confidence) and MAY raise the flag VECTOR_INDEX_VERSION_MISMATCH.

Offline non-regression checks (recommended minimum)

  • Maintain a canonical prompt set (domain + edge cases).
  • On each release, compare against the previous ACTIVE index:
    • Top-K stability (Jaccard overlap / rank correlation),
    • margin distributions (top1 - top2),
    • flag rates (LOW_MARGIN, VECTOR_AMBIGUITY, OOD, ABSTAIN_RECOMMENDED).
  • If regression exceeds thresholds, do not promote the index from SHADOW to ACTIVE.

OW-3 Label interpretation (distilled-first)

OW-3.1 Distilled Label Router (hot path)

Inputs

  • prompt
  • L_raw
  • L_vec_topk

Outputs

  • L_distilled (Top-N + scores)
  • conf_distilled
  • preliminary flags:
    • LOW_MARGIN
    • VECTOR_AMBIGUITY
    • OOD_CANDIDATE

OW-3.2 Bounded LLM Proposer (cold path)

Activated only if:

  • persistent LOW_MARGIN, or
  • strong VECTOR_AMBIGUITY, or
  • conf_distilled too low.

Inputs

  • prompt
  • structured context
  • Top-K labels

Instruction

  • “Choose only among these labels or ABSTAIN.”

Outputs

  • L_llm
  • LLM_ESCALATED = true

OW-3.3 Constrained Reranker (learned, optional)

Goal
Improve ordering and scoring of candidate labels using learned signals (logs), while respecting taxonomy structure and keeping OW-5 as the final arbiter.

This step MUST:

  • rerank only within an existing candidate set (no new labels),
  • preserve provenance fields (lexical, vector, distilled, llm),
  • remain compatible with the 100ms hot-path budget when enabled.

This step MUST NOT:

  • create labels, parents, or edges,
  • bypass OW-5 strict validation,
  • redefine taxonomy structure.

Activation

  • enabled by configuration (RERANKER_ENABLED = true), and/or
  • enabled only when ambiguity is detected (LOW_MARGIN or VECTOR_AMBIGUITY).

Inputs

  • L_raw
  • L_vec_topk (with ANN similarity scores)
  • L_distilled (Top-N + scores)
  • optional: L_llm (if OW-3.2 ran)
  • optional: structure features S(l) from OW-4.b (if available at this stage; otherwise omitted)
  • optional: policy/typology hints (for feature computation only; policy enforcement remains in OW-5 / final purge)

Learned model (implementation-defined)

  • recommended: lightweight ranking model (linear head / small MLP / GBDT)
  • trained offline on logged outcomes (successful routing + downstream resolution)
  • feature inputs MAY include:
    • source scores (distilled, vector, lexical)
    • margins (top1 vs top2)
    • inter-signal agreement indicators
    • optional structure features (taxonomy distance / branch coherence / cluster entropy)

Outputs

  • L_reranked (same labels as the input pool, reordered with updated scores)
  • conf_rerank (optional scalar, for OW-7 fusion)
  • optional reranker diagnostics (for offline QA): rerank_version, feature_schema_version

Contract

  • L_reranked ⊆ union(L_raw, L_vec_topk, L_distilled, L_llm if present)
  • L_reranked MUST be treated as a scoring/ranking override only; OW-4.a still builds L_union from the underlying sources.
  • Downstream stages MUST still run:
    • OW-4.a union,
    • OW-5 strict validation,
    • OW-6 controlled hierarchy expansion,
    • OW-7 unified confidence & flags.

This completes the 100ms-mode front half of the Context Weaver.
The remaining stages (union, strict validation, controlled hierarchy expansion, confidence/flags) should follow the contract already referenced in:

and will be kept consistent with this cascade.


OW-4.a Source fusion (deterministic)

Build the unified candidate set:

[ L_{union} = union(L_{norm}, L_{raw}, L_{vec_topk}, L_{distilled}, L_{llm\ if\ present}) ]

Each label in L_union MUST carry provenance metadata:

  • lexical (present in L_raw and/or L_norm)
  • vector (present in L_vec_topk and/or selected by a vector-bounded proposer)
  • distilled (present in L_distilled)
  • llm (present in L_llm, if present)

This provenance is mandatory for:

  • confidence computation,
  • conflict analysis,
  • offline diagnostics and taxonomy evolution.

Output

  • L_union (with provenance stamped per label)

OW-4.b Structure Scoring (deterministic)

Goal
Compute lightweight, deterministic structure-aware signals to improve downstream confidence, ambiguity detection, and optional reranking — without defining taxonomy structure.

This step MUST NOT:

  • create new labels,
  • alter the taxonomy,
  • bypass OW-5 validation.

It MAY:

  • attach per-label structural features,
  • compute global structural ambiguity measures,
  • provide an optional reranking hint within L_union only.

Inputs

  • L_union (with provenance)
  • core knowledge:
    • taxonomy tree (cluster → label root → parent → child)
    • explicit incompatibilities (if available)
    • typology constraints (if needed for feature computation)

Per-label structural features (examples, deterministic) For each candidate label l ∈ L_union, compute a feature bundle S(l) such as:

  • taxo_depth(l) and taxo_path_signature(l) (stable identifiers)
  • branch_coherence(l)
    (agreement with the dominant branch/ancestors implied by strong signals)
  • taxo_distance_to_consensus(l)
    (distance to a consensus branch / nearest common ancestor)
  • incompatibility_risk(l)
    (penalty if l conflicts with high-support candidates)
  • cluster_alignment(l)
    (consistency with the implied parent cluster / typology bounds)

Global structural ambiguity (examples)

  • cluster_entropy(L_union) or cluster_entropy(L_vec_topk)
    (continuous version of “spans multiple distant parent clusters”)
  • branch_fragmentation_score
    (how many mutually distant branches are simultaneously plausible)

Output

  • L_scored = {(l, provenance(l), S(l))}
  • optional: R_hint (a reranking hint over L_union, never a hard decision)

L_scored is passed to OW-5 (which remains the final arbiter) and OW-7 (for confidence/flags).


OW-5 Strict taxonomy validation (deterministic)

The Taxonomy Validator filters L_union against core knowledge and policy constraints.

Checks include:

  • Existence

    • if a label is missing → reject
      set UNKNOWN_LABEL_CANDIDATE
  • Cluster↔label compatibility

  • Parent/child coherence

    • avoid simultaneous activation of structurally incompatible branches
  • Explicit incompatibilities

  • Policy / typology constraints
    governed by the Policy Manager
    and parameterized by rules in the Guides.

Output

  • L_valid

OW-6 Controlled hierarchical expansion

Apply ascending-only propagation:

  • child → parent → root

No descending expansion by default.

This prevents over-activation that would reduce routing precision.

Output

  • L_expanded

OW-7 Unified confidence scoring & flags

Compute confidence_global from a weighted blend of:

  • post-validation taxonomy coherence
  • distilled margin (top1 vs top2)
  • vector margin (top1 vs top2)
  • inter-signal convergence
    (lexical / distilled / vector)
  • policy conflicts
  • proportion of labels outside consensus
  • structural agreement signals (from OW-4.b Structure Scoring):
    • cluster_entropy / branch_fragmentation_score
    • branch_coherence_score
    • taxo_distance_to_consensus penalties

Implementation note: OW-7 specifies ingredients and flag logic; exact weights are implementation-defined and MUST be versioned with the taxonomy release.

Flag triggers

  • VECTOR_AMBIGUITY
    if Top-K spans multiple distant parent clusters or cluster_entropy is high,
    and vector margin is low.
    (Structural formulation recommended: high branch_fragmentation_score + low margin.)

  • LOW_MARGIN
    if distilled or vector margins are weak.

  • CONFLICT_POLICY_STRONG_SIGNAL
    if a label strongly supported by user-facing signals
    is rejected by policy.

  • UNKNOWN_LABEL_CANDIDATE
    if OW-5 rejected non-existent labels.

  • NEW_INTENT_CANDIDATE
    if:

    • domain vocabulary seems plausible,
    • consensus remains weak,
    • and no stable child label fits.
  • OOD
    if:

    • confidence is very low,
    • taxonomy coherence fails,
    • or no plausible parent emerges.
  • ABSTAIN_RECOMMENDED
    if:

    • confidence is low,
    • and disagreement cannot be stabilized
      by Validator + policy constraints.

Optional (stable if enabled):

  • COLD_START_BUFFER_CANDIDATE
    if:
    • strong proximity to a known parent exists (e.g., low taxo_distance_to_consensus),
    • but no child label emerges cleanly,
    • and the system prefers neither hallucination nor OOD.

This requires a pre-existing system label family Pending_*
in core knowledge.

Final output

  • L_final = L_expanded
  • L_final_ids + PrimaryLabelID + LabelSignature
  • RetrievalType
  • confidence_global
  • flags

L_final is taxonomy-valid. Policy enforcement remains a hard gate owned by the Policy Manager; the Weaver only consumes the policy envelope to filter/flag invalid routes.

This output is consumed by:


5. Expected online behaviors (100ms)

Standard case (~80–95%)

  • FAST_TRACK or distilled-only flow
  • no LLM
  • labels usable in <100ms

Ambiguous case (~5–20%)

  • LLM_ESCALATED
  • higher latency acceptable
  • strictly confined to grey zones

Cold start case (if enabled)

  • COLD_START_BUFFER_CANDIDATE
  • route to Pending_* (pre-existing)
  • log NEW_LABEL_REQUIRED for offline taxonomy evolution

Cold-start buffering must remain Info-first and must not enable
unsafe direct Action routing under ambiguity.
See cold-start safety rules in ARG Core.


6. Offline role of the Context Weaver

The Weaver does not “fix the graph.”
It taxonomically qualifies what math and usage signals detect.

6.1 Split candidates

  • compute plausible taxonomy signatures
  • propose:
    • existing child-label attachments, or
    • a new child-label candidate

6.2 Merge candidates

  • penalize taxonomically dangerous merges

6.3 New edge candidates

  • propose coherent edge types
    via shared labels/parents

6.4 Taxonomy evolution Detect missing labels from:

  • UNKNOWN_LABEL_CANDIDATE
  • NEW_INTENT_CANDIDATE
  • repeated VECTOR_AMBIGUITY
  • COLD_START_BUFFER_CANDIDATE (if enabled)

These signals feed the offline loop in
ARG Core.


7. Incremental maintenance: adding labels

7.1 Principle No routine creation of new context typologies or clusters.
Prefer adding child labels.

7.2 Update chain

A) Core Knowledge

  • add the new label in the tree:
    • under an existing parent
    • within an existing cluster

B) Context Weaver

  • update the Taxonomy Validator
  • update the Taxonomy Vector Store
  • update policy constraints if needed

C) ARG Core

  • update M2M attachments:
    • node ↔ label
    • node ↔ cluster (if necessary)
  • adjust edges if new granularity requires safer routing

Summary

  • The Weaver guarantees taxonomy validity.
  • ARG attaches leaves to the new branch.

7.3 Mandatory checks

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

7.4 Progressive activation

  • CANDIDATE → SHADOW → ACTIVE

SHADOW labels can be suggested but with limited routing weight,
reducing blast radius during early adoption.


8. Observability

Track at minimum:

  • FAST_TRACK rate
  • LLM_ESCALATED rate
  • Weaver latency p50 / p95
  • OOD rate
  • VECTOR_AMBIGUITY rate
  • LOW_MARGIN rate
  • UNKNOWN_LABEL_CANDIDATE rate
  • NEW_INTENT_CANDIDATE rate
  • optional: COLD_START_BUFFER_CANDIDATE rate

These metrics are used to:

  • prioritize taxonomy refinement,
  • calibrate distilled routing,
  • and detect drift early.

Released under the Apache License 2.0