From RAG to TAG: Defining a Mechanism Transfer Protocol (MTP)

This article is the second in a series, but every piece stands on its own — no prior reading is required. For context: Part 1 introduced the Innovation Wormhole, the idea that AI should transfer proven mechanisms between industries instead of reinventing them. This piece turns that idea into a concrete, machine-readable protocol

Retrieval-Augmented Generation (RAG) changed how AI systems answer questions. Instead of generating text from parametric memory alone, a RAG system retrieves relevant documents and conditions its output on them.

But RAG has a structural limitation: it retrieves documents, not mechanisms.

A RAG pipeline can hand you forty papers about predictive maintenance. It cannot tell you that the anomaly-detection technique you need was already proven in radio astronomy, that its assumptions survive the transfer to vibration data, and that the evidence for it is strong enough to justify a pilot project.

This article defines Transfer-Augmented Generation (TAG) and proposes a concrete, machine-readable Mechanism Transfer Protocol (MTP) for building such systems.

Why Retrieval-Augmented Generation Stops at Documents

RAG retrieves chunks of text based on semantic similarity between a query and a corpus. This works well when the answer lives inside a single document. It fails when the answer lives in the structural relationship between two documents from unrelated fields.

The failure has three root causes:

• Vocabulary mismatch. The same mechanism is described with completely different words in different industries. A fluid-flow control solution patented in aerospace uses terminology a civil engineer will never search for. Keyword-based and embedding-based retrieval both break here — this is a documented, well-known barrier in cross-domain patent search (PatSnap: AI-Augmented Analogical Reasoning).
• Surface similarity hides structural equivalence. Two problems can be structurally identical while lexically unrelated. Embedding models trained on distributional similarity rank "similar industries" higher than "equivalent problem structures."
• Documents are the wrong unit of transfer. A paper mixes problem statement, mechanism, results, and context. What needs to move across industries is only one of those layers: the mechanism.

Research systems already point in this direction. Scideator extracts facets — purpose, mechanism, evaluation — from research papers and lets humans recombine them, and its user study showed significantly more creativity support than a raw LLM baseline. Analogy mining demonstrated that purpose-level deep models trained on crowdsourced analogies retrieve cross-domain analogies from real repositories like the U.S. patent database. The Analogy Search Engine found structurally similar problems across AI subfields by encoding background, purpose, mechanism, and findings separately.

The pattern across all of them: separate the mechanism from its context, then match structures.

Core Definitions

To make the protocol precise — and to give future articles and implementations a shared vocabulary — the following definitions are used throughout the series.

Definition 1 — Problem Structure. A problem representation stripped of industry-specific vocabulary:

P = ⟨O, C, F, M⟩ where O = objectives, C = constraints, F = failure modes, M = success metrics.

Definition 2 — Mechanism. The minimal transferable unit of a solution, abstracted from its original context:

K = ⟨T, A, E, V⟩ where T = state transformation ("what it does"), A = enabling assumptions ("what it needs"), E = evidence set ("what proves it"), V = validity envelope ("where it holds").

Definition 3 — Cross-Domain Transfer. A transfer τ: (K, P_target) → K′ is valid if and only if every assumption in A′ (the adapted assumption set) is satisfied within the target problem structure P_target, and the target's operating conditions fall inside the adapted validity envelope V′.

Definition 4 — Transfer-Augmented Generation (TAG). Generation constrained by retrieved and validated mechanisms, in which every generated recommendation is grounded in an evidence set E and annotated with its transferability assessment.

The critical distinction: RAG conditions output on retrieved text. TAG conditions output on retrieved, decontextualized, and validated mechanisms.

The MTP Schema: Three Machine-Readable Cards

MTP is a data protocol first and a workflow second. It defines three record types that travel through the pipeline.

Card 1: Problem Card

The Problem Card is the structured output of problem decomposition. It is deliberately industry-agnostic.

{
  "problem_card_id": "PC-2026-0114",
  "objectives": [
    "Detect rare abnormal events in high-dimensional periodic signals before failure"
  ],
  "constraints": {
    "hard": ["latency < 200 ms", "no labeled failure data at deployment"],
    "soft": ["interpretable detection rationale"]
  },
  "failure_modes": ["missed detection", "false alarm flooding"],
  "success_metrics": [
    { "metric": "recall @ 1% false-positive rate", "target": "≥ 0.85" }
  ],
  "signal_properties": {
    "dimensionality": "multivariate time series",
    "noise_profile": "colored, non-stationary",
    "event_rarity": "< 0.1% of samples"
  },
  "industry_of_origin": "manufacturing / predictive maintenance"
}

The signal_properties block is what makes cross-domain retrieval possible: it describes the physics of the problem, not the vocabulary of the industry.

Card 2: Mechanism Card

The Mechanism Card is extracted from patents, papers, and case studies. Structured extraction of technical functionality from patents — for example Subject-Action-Object (SAO) triplets — is an established technique that overcomes vocabulary mismatch by searching patents by function instead of by words (IntechOpen: Patent Mining as Strategic Intelligence).

{
  "mechanism_card_id": "MC-ASTRO-0442",
  "mechanism": "Matched-filter + periodogram-based change-point detection on detrended periodic signals",
  "transformation": "raw noisy signal → statistically significant anomaly score",
  "assumptions": [
    "signal contains a dominant periodic component",
    "noise is approximately stationary within analysis windows",
    "training data contains at least instrument-noise-only segments"
  ],
  "evidence": [
    { "type": "peer_reviewed", "ref": "decades of pulsar-timing literature" },
    { "type": "operational", "ref": "production pipelines in radio observatories" }
  ],
  "validity_envelope": {
    "signal_type": "periodic or quasi-periodic, 1–100 Hz effective band",
    "data_regime": "low labeled-event count tolerated",
    "compute": "commodity CPU sufficient"
  },
  "industry_of_origin": "radio astronomy",
  "extraction_source": ["patent:US…", "doi:10…"]
}

Card 3: Transfer Feasibility Score (TFS)

Every candidate pair (K, P_target) receives a score that is auditable by construction — it is computed from named sub-scores, never from a black-box gut feeling:

TFS = (w_s · S_struct + w_f · S_func + w_c · S_causal) − (R_ctx + R_econ)

• S_struct — structural similarity: do the problem structures match at the level of signal physics and failure modes?
• S_func — functional similarity: does the mechanism's transformation produce the target outcome?
• S_causal — causal compatibility: do the mechanism's causal chains survive the transfer intact? (Causal extraction and cross-domain causal similarity comparison on patents is already an active research direction (ScienceDirect: causal extraction for cross-domain patent exploration).)
• R_ctx — context risk: how much of the original context must be rebuilt in the target industry?
• R_econ — economic friction: integration cost relative to expected ROI.

The weights are configuration, not truth. They must be reported with every recommendation.

The MTP Pipeline

MTP defines a five-stage pipeline. Each stage is auditable and independently testable:

[Customer Problem]
        |
        v
(1) Problem Decomposition ------> Problem Card
        |
        v
(2) Mechanism Indexing ---------> Mechanism Cards
    (patents, papers, case studies)
        |
        v
(3) Structure Matching ---------> Candidate (K, P) pairs + TFS
        |
        v
(4) Evidence Validation ---------> Per-assumption checks
        |
        v
(5) Human Validation Gate ------> Transfer Report

Stage 1 — Problem Decomposition. The customer's problem is rewritten as a Problem Card. This stage removes industry vocabulary on purpose: the goal is to expose the underlying engineering structure.

Stage 2 — Mechanism Indexing. A standing corpus of patents, papers, and case studies is continuously decomposed into Mechanism Cards. Knowledge-graph-assisted design-by-analogy research shows this works: domain distance between an engineering function and a candidate analogical source can be computed as a graph distance, and combined with TRIZ conflict resolution to produce feasible transfers (Cambridge AI EDAM: Knowledge graph-assisted DbA). LLM-driven conceptual design research reaches the same conclusion: structured, facet-based retrieval beats unstructured prompting for analogy-based design (Advanced Engineering Informatics 2025).

Stage 3 — Structure Matching. The similarity engine matches Problem Cards against Mechanism Cards on four dimensions: structural, functional, behavioral, and causal similarity. Domain distance is a feature to maximize within validity bounds, not minimize — the value of a transfer comes from distance.

Stage 4 — Evidence Validation. Every assumption in the candidate mechanism's A set is checked against the target's C constraints, and evidence in E is graded (peer-reviewed > operational > anecdotal). A candidate with no checkable evidence is discarded. Hallucinated innovation is worthless; transferable evidence is valuable.

Stage 5 — Human Validation Gate. The system outputs a Transfer Report — never a decision.

Worked Examples: Two Wormholes, Fully Traced

MTP requires that every proposed idea demonstrate applicability in at least two unrelated industries. Here are two complete traces.

Wormhole 1: Radio Astronomy → Predictive Maintenance

• Source industry: radio astronomy (pulsar timing).
• Mechanism: matched filters and periodogram-based change-point detection, engineered to find faint periodic signals buried in heavy colored noise.
• Target problem: predicting bearing failure on a production line from vibration data.
• Why the structure matches: both problems are "rare event detection in quasi-periodic, non-stationary signals with almost no labeled anomalies" — the signal_properties blocks of the two Problem Cards are nearly identical, even though the vocabularies share zero words.
• Assumption check: bearings produce dominant periodic components — assumption holds; industrial noise is non-stationary within shift changes — assumption adapts by windowing.
• Required modifications: replace telescope-specific detrending with order-tracking normalization for rotating machinery.

Wormhole 2: Biological Immune Systems → Cloud Security

• Source domain: immunology (negative selection — the body trains its defenses only on self, so anything not matched as self is treated as foreign).
• Mechanism: generate a detector population filtered against "self" samples; alert on anything a detector binds to.
• Target problem: anomaly detection in infrastructure telemetry where attack patterns are unknown in advance.
• Why the structure matches: both are "detect the previously unseen by learning what is normal" — a perfect functional match with zero lexical overlap.
• Required modifications: scaling detector generation to high-dimensional telemetry; handling concept drift as "self" changes during legitimate deployments.

The deeper point: these connections are not speculative. Cross-industry transfer demonstrably does not happen by chance — it requires structural analogies and intermediaries who can build them, as documented in the Pumps & Pipes collaboration between the petroleum and medical industries (Springer: Cross-Industry Innovation Does Not Happen by Chance). Frans Johansson's The Medici Effect (Wikipedia) made the same argument at the business-strategy level: breakthrough innovations concentrate at intersections of unrelated fields. What has been missing is the engineering layer that makes those intersections searchable by machines.

Failure Modes: What Breaks a Transfer

A protocol that only describes success is marketing, not engineering. These are MTP's named failure modes — every Transfer Report must state which ones were checked:

Failure mode	What goes wrong	MTP countermeasure
Vocabulary mismatch	Retrieval misses the mechanism due to lexical distance	Function-level indexing (SAO / Problem-Card physics)
Structural superficiality	The match is real but too shallow to transfer	S_struct uses signal/problem properties, not topic labels
Causal break	The correlation holds but the causal chain doesn't	S_causal requires causal-chain comparison, not co-occurrence
Scale mismatch	Valid at lab scale, invalid at industrial scale	Validity envelope V must cover target operating conditions
Regulatory invalidation	Evidence is scientific but inadmissible in the target's regulatory regime	Evidence validation includes regulatory constraints
Economic infeasibility	Technically valid, commercially absurd	R_econ subtracts integration cost from the score

Authorization Boundaries: Where AI Proposes and Where Humans Decide

MTP takes a strict position on the division of labor. This is not decoration — it is a protocol requirement.

• AI is autonomous in: problem decomposition, mechanism indexing, structure matching, evidence lookup, drafting the Transfer Report.
• A human gate is mandatory before: any transfer with safety, regulatory, or financial exposure; any transfer whose validity envelope is extrapolated rather than matched; any adaptation that changes a mechanism's causal structure.
• AI must never: silently override a failed assumption check; present an unmatched-validity-envelope transfer as low-risk; generate evidence citations that do not resolve to real sources.

The protocol follows a simple rule: AI accelerates discovery; humans own applicability. Domain experts remain part of the workflow precisely because tacit industry knowledge — regulation, culture, unwritten constraints — is the part of a transfer that no corpus fully contains.

Technical Challenges and Open Problems

MTP is a proposal, not a finished system. These problems remain open, and they are research problems in knowledge engineering, not prompt engineering:

• Representing structural similarity. What is the right formal representation of "problem structure"? Function-based and SAO-based representations exist; neither fully captures causal structure.
• Quantifying transferability. The TFS weights (w_s, w_f, w_c) are currently heuristic. How do we calibrate them against realized transfer outcomes, not expert intuition?
• Conflicting evidence. When two sources support the same mechanism but disagree on its validity envelope, what is the resolution semantics?
• Continuous learning from expert feedback. When a domain expert rejects a transfer, how does the rejection propagate back into the matching functions?
• Explainability as a first-class requirement. Every recommendation must be reproducible from its cards — the score, the assumption checks, and the evidence chain must be inspectable, not just the final prose.

Why This Matters

RAG gave language models a memory. TAG gives them engineering judgment's raw material: validated mechanisms with explicit assumptions, evidence, and boundaries.

The organizations that benefit first will not be the ones with the largest R&D budgets. They will be the ones whose innovation pipelines treat knowledge as structured, transferable, and machine-readable — where a solved problem anywhere is a candidate solution everywhere, provided the structure matches and the evidence survives the crossing.

The hardest open problem above — quantifying transferability — deserves a complete treatment of its own: building ground truth from realized transfers, defining evaluation metrics, and proposing an open benchmark that any TAG system can be measured against. That is the next standalone article in the Innovation Wormhole series; follow the series if you want it in your feed.

What would you index first — patents, papers, or post-mortems? And which pair of industries would you connect through the wormhole? I'd love to hear your thoughts in the comments.

References

1. Scideator — Human-LLM Compound System for Scientific Ideation through Facet Recombination and Novelty Evaluation — arXiv:2409.14634
2. Accelerating Innovation Through Analogy Mining — arXiv:1706.05585
3. Analogy Search Engine: Finding Analogies in Cross-Domain Research Papers — ResearchGate
4. Knowledge graph-assisted design-by-analogy: promoting product innovation through structured analogical knowledge retrieval — Cambridge AI EDAM
5. From Analogy to Innovation: A creative conceptual design approach leveraging large language models — Advanced Engineering Informatics, 2025
6. Discovering new applications: Cross-domain exploration of patent documents using causal extraction and similarity analysis — ScienceDirect
7. Patent Mining as a Strategic Intelligence tool for SMEs — IntechOpen
8. AI-Augmented Analogical Reasoning for Engineers — PatSnap
9. Cross-Industry Innovation Does Not Happen by Chance: The Role of Facilitation — Springer Professional
10. The Medici Effect — Frans Johansson — Wikipedia
11. Part 1 of this series — Building an AI-Powered Innovation Wormhole

---

created by Seyed Alireza Alhosseini Almodarresieh
https://almodarresieh.github.io/