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