Part VI — Crossing Embedding Spaces

A map is not a bridge

Chapter 19 produced a matrix W (or an MLP) that translates vectors from space A to space B. Deploying that matrix as “space A and space B are now compatible” is the mistake this chapter prevents.

A map is a function. A bridge is a map plus the record of what it was shown to preserve, for whom, under what conditions — and, crucially, an explicit scope of what it must not be used for.

What has to travel with a translation so that a system consuming it knows exactly how far to trust it?

The bridge artifact

bridge:
  id:                  <uuid>
  source_space_hash:   <exact, from Ch17>     # translating FROM
  target_space_hash:   <exact, from Ch17>     # translating TO
  direction:           A_to_B                 # bridges are directional
  method:              <procrustes | linear | cca | mlp>  (+ preprocessing)
  checkpoint:          <weights hash / storage ref>
  training:
    anchor_set_id:     <ref>
    n_train / n_test:  <int / int>
    anchor_coverage:   <domain + difficulty coverage report>
    fitted_at:         <timestamp>
  metrics:
    reconstruction:    {cos_to_target, mse}
    preservation:      {nbr_overlap@k, rank_corr, cluster_agreement,
                        recall@1, recall@10, mrr, ndcg@10,
                        order_preservation, hard_negative_agreement}
  calibration:
    score_map:         <how a translated-space similarity relates to a
                        native target-space similarity>   (Ch14, cross-space)
    operating_points:  <per usable_for scope>
  usable_for:          [ retrieval, clustering, dedup, ... ]   # explicit allowlist
  not_usable_for:      [ threshold_transfer, relation_tasks, ... ]  # explicit denylist
  status:              <draft | evaluated | approved | deprecated>
  approved_by / date:  <...>

usable_for is the point

A bridge should not automatically claim universal compatibility. The usable_for list is an allowlist of tasks the preservation metrics actually support, at stated operating points. From the Chapter 19 demonstration numbers, a linear A→B bridge might carry:

usable_for:
  retrieval (top-10):        YES   retrieval_agreement 0.79, above the 0.75 bar
  clustering (coarse):       YES   cluster_agreement 0.82
  dedup (near-duplicate):    CONDITIONAL   only above translated-cos 0.9
  ranking (fine-grained):    NO    rank_corr 0.6 on near-ties
  threshold transfer:        NO    score distributions differ; recalibrate per scope
  relation / polarity tasks: NO    hard_negative_agreement 0.41, near the source
                                   encoder's own native score on these pairs

A consumer asks the bridge “can I use you to cluster?” and gets a yes/no/conditional with the metric behind it — not a blanket “spaces are compatible.”

    flowchart TD
    C["consumer wants a cross-space operation: retrieve / cluster / dedup / threshold"] --> B["bridge looks up the measured preservation metric for THAT task"]
    B --> Q{"metric vs the stated bar"}
    Q -->|"above bar"| Y["YES — operation allowed, with the metric attached"]
    Q -->|"above bar only in a sub-range"| CO["CONDITIONAL — e.g. only above translated-cos 0.9"]
    Q -->|"below bar"| N["NO — operation DENIED, with a one-line reason (e.g. hard_negative_agreement 0.41)"]
  

This is the usable_for layer of the identity / compatibility / usability separation (Chapter 17): identity is the two space_hash values, compatibility is the measured preservation profile (Chapter 21), and usable_for is the scoped policy the bridge exposes to consumers.

A bridge preserves one property while destroying another

This is the deep point of Part VI, and it earns a name:

A transformation can preserve retrieval adequately while destroying calibration. It can keep clusters while losing rank order. Compatibility is not a single bit; it is a vector over tasks, and each entry must be measured.

Concretely: the linear bridge above keeps 79% retrieval agreement (neighbors mostly stay neighbors) but the scores in the translated space are compressed and shifted, so a 0.8 threshold calibrated on native B means something different on translated-A vectors. Retrieval survives; the duplicate filter does not, until it is recalibrated on translated vectors.

Directionality and composition

• Bridges are directional. An A→B bridge inverted is not a valid B→A bridge (least-squares and MLP maps are not invertible in general; even Procrustes’ inverse should be re-evaluated).
• Bridges compose, badly. A→B ∘ B→C is a valid map but its preservation is the product of losses and must be measured end-to-end, not assumed from the parts.
• A bridge is pinned to two exact hashes. Re-embedding either side with a new model version invalidates the bridge; the Observatory marks it deprecated automatically when a referenced space_hash leaves the registry’s active set.

Sidebar: space incompatibility is not a privacy boundary

It is tempting to treat “these are vectors from a private/unknown encoder, and nobody has the matching model” as a security property. It is not.

• Embeddings invert. Given only embeddings and query access to the encoder, an iterative correct-and-re-embed attack recovers 92% of 32-token inputs exactly, and full names from clinical notes (Morris et al., 2023).
• Translation removes the “unknown encoder” defense. Unpaired translation (vec2vec, Chapter 18) maps vectors from an unknown encoder into a known one’s space using shared latent-geometry structure alone — no paired data, no access to the source model. Inversion and attribute-inference tools then run on the translated vectors. vec2vec’s authors demonstrate topic and attribute recovery from a database of nothing but embedding vectors.
• The bound. Attribute inference through a translation is materially weaker than on native vectors, and exact inversion degrades. The realistic threat is “sensitive topics and attributes leak,” not “verbatim reconstruction of every document.” Still consequential.

Treat a vector store as a store of the underlying documents’ topics and sensitive attributes, for access-control purposes — regardless of which encoder produced the vectors or whether you still have it.

This is a corollary of the bridge material, not a new subject; the book does not pursue embedding security further.

Demonstration: the bridge in a migration

MEASURED on RELATE v0.1, Wave 3 row 3.4 — artifact experiments/embeddings-from-first-principles/wave3/artifacts/ladder-8property-matrix.json. Bridge all-MiniLM-L6-v2 → all-mpnet-base-v2 (a family “upgrade”), Procrustes, anchors from split_entity:train.

Chapter 17’s upgrade, now with a bridge: legacy corpus in the smaller space, new queries in the larger one, a Procrustes bridge fitted on the train-entity anchors.

property                                          bridged legacy vectors
retrieval nDCG@10 ratio vs a full re-embed              0.91
10-NN neighborhood overlap vs native v2                 0.74
calibration threshold transfer                          0.76   ← usable_for: threshold = NO
hard-negative margin ratio                               0.47
reconstruction on TRAIN entities vs TEST entities        1.00 vs 0.56   ← the bridge overfits the anchor entities

MEASURED: the bridge buys ~91% of a full re-embed’s retrieval on the entities it was fitted near, with retrieval on its usable_for list and threshold_transfer explicitly off it (calibration transfers at only 0.76). The number that decides its lifetime is the last row: reconstruction drops from 1.00 on the anchor entities to 0.56 on entities the bridge never saw. A bridge fitted on 5,000 anchors is a migration tool for the corpus those anchors represent — it is not a permanent substitute for re-embedding, and it degrades exactly where the new data is least like the old.

What this chapter establishes and what it does not

Establishes: the distinction between a map and a bridge; the bridge artifact with exact directional source/target hashes, method, checkpoint, both metric families, cross-space calibration, and explicit usable_for / not_usable_for scopes; that compatibility is a per-task vector; that bridges are directional, compose lossily, and are pinned to exact hashes; that space incompatibility is not a privacy boundary (unpaired translation + inversion).

Does not establish: that every model pair admits a useful bridge (some do not clear any usable_for bar), or that a bridge ever fully replaces re-embedding. It establishes the artifact and the discipline of scoped, measured compatibility.

Lab 20: build a scoped bridge

PROPOSED, not executed.

Setup. Two spaces with exact hashes. Anchor set with a coverage report. Labeled eval for ≥3 downstream tasks (retrieval, clustering, dedup).

Task.

1. Fit the bridge (from Chapter 19’s winner).
2. Measure the full preservation metric set per task.
3. Set a bar per task (e.g. retrieval agreement ≥ 0.75, cluster agreement ≥ 0.8, dedup FAR ≤ 1% after recalibration).
4. Populate usable_for and not_usable_for from the measurements.
5. Try inverting the bridge; re-measure. Is B→A on the usable_for list?

Success criterion. A bridge artifact with a populated usable_for list where every YES has a metric above a stated bar, and a one-line reason for every NO.

Companion component: the bridge registry

bridge_registry:
  bridges:  { (source_hash, target_hash, direction): bridge }
  lookup:   given a source and target space, return the bridge or NONE
  enforce:  a cross-space operation checks the bridge's usable_for for that
            operation's task; NONE or not-listed  →  operation DENIED
  lifecycle: auto-deprecate when either space_hash leaves the active registry

The Observatory’s cross-space operations (Chapter 17’s denied list) become conditionally allowed — gated on a bridge whose usable_for covers the specific operation.

Failure modes

• Shipping a map as “compatibility.” No scope, no metrics, no operating points.
• Empty or aspirational usable_for. Every entry needs a measurement above a bar.
• Inverting a bridge without re-evaluation. Direction matters.
• Composing bridges and assuming preservation multiplies predictably. Measure the composed bridge end-to-end.
• Keeping a bridge alive after a model version bump. New space_hash → the bridge is stale.
• Using a retrieval-scoped bridge for a thresholded decision. Recalibrate first; that is a different scope.

What this chapter established

• A map is a function; a bridge is a map plus its measured, scoped preservation record and an explicit usable_for / not_usable_for.
• The bridge artifact: exact directional source/target hashes, method, checkpoint, reconstruction and preservation metrics, cross-space calibration, scoped operating points, status.
• Compatibility is a per-task vector: a bridge can preserve retrieval while destroying calibration, or keep clusters while losing rank order.
• Bridges are directional, compose lossily, and are pinned to exact hashes — auto-deprecated when a space leaves the registry.
• In a migration, a retrieval-scoped bridge gave a usable v2 experience over legacy vectors a few points below a full re-embed.
• The bridge registry: cross-space operations conditionally allowed, gated on a bridge whose scope covers the operation.
• Space incompatibility is not a privacy boundary. Unpaired translation maps unknown-encoder vectors into a known space; inversion and attribute inference then apply. Treat a vector store as a store of the documents’ topics and sensitive attributes.

Next

The bridge artifact lists preservation metrics. The next chapter is the empirical investigation behind those numbers: cosine preservation, top-1 preservation, rank preservation, Recall@k, MRR, nDCG, order preservation, cluster preservation — computed, compared, and interpreted for what each does and does not certify.