Every article in the Innovation Wormhole series 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. Part 2 defined the Mechanism Transfer Protocol (MTP) as machine-readable cards and scores; Part 3 defined how to calibrate those scores against realized outcomes. This piece is the engineering one: how to actually build the system.
Concepts are cheap until they survive contact with production. The previous articles in this series defined what a cross-domain reasoning system should compute: problems as cards, mechanisms as cards, transfers as scored, evidence-checked, human-validated proposals.
This article defines how to build it: a layered reference architecture — the Transfer Stack — with concrete technology choices, explicit failure modes, and a build order that produces a working system in ninety days rather than a beautiful architecture diagram that never ships.
What You Are Actually Building
Before the architecture, the requirements. A Transfer Stack must do six things that ordinary RAG systems do not:
- Extract mechanisms, not documents. Every source (patent, paper, case study) is decomposed into transferable units with assumptions and evidence — not stored as text chunks.
- Match structures, not keywords. Retrieval operates on problem physics and functional descriptions, so vocabulary mismatch between industries cannot hide a solution.
- Score with calibrated numbers. Every transferability score is traceable to named sub-scores and weights fitted against realized outcomes — never to model vibes.
- Check assumptions explicitly. A candidate is only as good as the survival status of its enabling assumptions in the target context.
- Separate proposal from decision. The system emits a Transfer Report; humans own the go/no-go.
- Reproduce everything. Any recommendation can be replayed from its cards, scores, and evidence chain.
One non-goal, stated deliberately: the Transfer Stack is not a general-purpose research assistant. It is a vertical instrument for one job — finding, scoring, and validating cross-domain mechanism transfers.
The Transfer Stack: Seven Layers
The reference architecture has six pipeline layers plus one offline loop. Each layer has one responsibility, one failure mode, and one testable contract.
[Sources: patents, papers, case studies]
|
v
(1) Ingestion & Extraction ------> Mechanism Cards
|
v
(2) Card Store -----------------> versioned, schema-validated records
|
v
(3) Dual Index -----------------> function graph + per-facet vectors
|
v
(4) Matching Engine ------------> candidate pairs + TFS scores
|
v
(5) Evidence Validator ----------> assumption & evidence checks
|
v
(6) Governance & Interface -----> Transfer Report + human gate
[ Offline loop: Calibration Service
+ evaluation harness (TransferBench) --> feeds (4) ]
Layer 1 — Ingestion and Extraction
Responsibility: convert raw sources into schema-valid Mechanism Cards and Problem Cards.
This is the layer where most of the quality is won or lost. The extraction contract is strict: an LLM may draft a card, but every card must pass schema validation, and every evidence entry must resolve to a real, reachable source. Structured, facet-level extraction is precisely what recent research shows works: facet-based retrieval of purposes, mechanisms, and evaluations beats unstructured prompting for analogy-based design (Advanced Engineering Informatics 2025), and purpose-level deep models retrieve real cross-domain analogies from repositories as large as the U.S. patent database (Analogy Mining, arXiv:1706.05585).
- Key techniques: structured output with JSON Schema enforcement; Subject-Action-Object (SAO) extraction for patents — the established way to search patents by function instead of by words (IntechOpen: Patent Mining as Strategic Intelligence); per-card provenance fields pointing back to source text.
- Failure mode: extraction hallucination — plausible cards with invented evidence.
- Mitigation: automatic citation resolution plus human spot-checks on a sampled percentage of cards, with the sample rate published in the system documentation.
Layer 2 — The Card Store
Responsibility: store cards as versioned, queryable records.
Cards are the system's unit of truth, so they get database discipline: schema versioning (a card format change must not silently invalidate history), append-only revisions, and provenance on every field.
- Concrete choices: a relational database with JSONB (Postgres) is enough at any realistic scale; cards are small, structured, and benefit from transactional guarantees.
- Failure mode: schema drift between the extraction layer and the matching layer.
- Mitigation: schema-as-code with contract tests in CI — the same discipline as any data pipeline.
Layer 3 — The Dual Index
Responsibility: make cards retrievable by structure.
This is the architectural heart of the system, and the answer to a question the series has been circling: graph or vectors? The correct answer is both, because they answer different questions:
- The knowledge graph answers relational questions: domain distance between an engineering function and a candidate source, causal chains, industry taxonomies. Graph distance as a domain-distance measure between design targets and analogical sources is exactly how knowledge-graph-assisted design-by-analogy computes novelty and feasibility (Cambridge AI EDAM).
The vector index answers functional questions: which cards describe a similar transformation on similar signal physics — computed on card facets, not raw text. Embedding the mechanism facet separately from the purpose facet is the design choice that makes distant-domain retrieval work (Scideator, arXiv:2409.14634).
Concrete choices: property graph (Neo4j or Apache AGE on Postgres) + vector index (pgvector or Qdrant); one namespace per facet so similarity is computed facet-to-facet.
Failure mode: falling back to whole-document embedding "for now" — which silently converts the system back into RAG.
Mitigation: retrieval evaluation in CI; if whole-text embeddings beat facet embeddings on the benchmark set, the index is broken.
Layer 4 — The Matching Engine
Responsibility: generate candidate (Mechanism, Problem) pairs and score them.
Candidate generation runs two retrieval paths in parallel — facet-vector similarity and graph queries — then unions the results. Scoring applies the Transfer Feasibility Score:
TFS = (w_s · S_struct + w_f · S_func + w_c · S_causal) − (R_ctx + R_econ)
with weights that come from the Calibration Service, not from a config file someone edited optimistically. An LLM judge with a fixed rubric computes the structural-comparison sub-scores; research on computational design-by-analogy tools shows that structured, exploration-based support improves analogical retrieval over plain query search (ASME J. Mech. Des.: VISION).
- Failure mode: the "confident middle" — a model that cannot tell a structural match from a topical one.
-
Mitigation: the causal dimension
S_causalcompares extracted causal chains, not co-occurrence; causal extraction and cross-domain causal similarity comparison is an established direction in patent analysis (ScienceDirect).
Layer 5 — The Evidence Validator
Responsibility: kill candidates whose assumptions do not survive the target context.
For each candidate, the validator checks every enabling assumption against the target Problem Card's constraints, grades the evidence set (peer-reviewed > operational > anecdotal), and stamps the record with which of the named failure modes were checked. A candidate with zero checkable evidence is discarded — the series' standing rule that hallucinated innovation is worthless.
- Concrete choices: a rule store for hard constraints (latency budgets, regulatory regimes), plus source-resolution service for every citation.
- Failure mode: optimistic assumption reinterpretation — the model "arguing" an assumption holds when it does not.
- Mitigation: assumption checks must cite target-context facts, and failed checks cannot be overridden by the model — only by a human gate.
Layer 6 — Governance and Interface
Responsibility: produce the Transfer Report and route it to the right human.
The Transfer Report is the system's single output artifact — a self-contained document with the candidate pair, the TFS decomposition, per-assumption survival status, evidence chain, checked failure modes, and required modifications:
{
"transfer_report_id": "TR-2026-0087",
"problem_ref": "PC-2026-0114",
"mechanism_ref": "MC-ASTRO-0442",
"tfs": { "score": 0.78, "w_s": 1.4, "w_f": 1.1, "w_c": 0.9,
"s_struct": 0.86, "s_func": 0.81, "s_causal": 0.74,
"r_ctx": 0.21, "r_econ": 0.15, "weights_version": "cal-2026-02" },
"assumptions": [
{ "assumption": "dominant periodic component", "status": "holds",
"evidence_ref": "target context doc #12" },
{ "assumption": "stationary noise within windows", "status": "adapted",
"modification": "windowing per production shift" }
],
"failure_modes_checked": ["vocabulary_mismatch", "scale_mismatch"],
"human_gate": "REQUIRED_BEFORE_PILOT",
"repro": { "index_snapshot": "idx-2026-10-31", "model_version": "…" }
}
Authorization boundaries are enforced in this layer, not in a policy document: AI drafts reports; humans approve anything with safety, regulatory, or financial exposure. Cross-industry practice confirms that human intermediaries — people who can build the analogy across domains — are exactly what makes transfers succeed in the field (Springer: Cross-Industry Innovation Does Not Happen by Chance).
The Offline Loop — Calibration and Evaluation
Two services run outside the request path:
- The Calibration Service (from Part 3) fits the TFS weights against Realized Transfer Records with walk-forward validation and publishes versioned weights to the Matching Engine.
- The Evaluation Harness runs the system against a held-out benchmark, with temporal holdout — the defense against the benchmark contamination that quietly corrupts every AI evaluation program.
An agentic five-stage pipeline of exactly this shape — ingestion, decomposition, analogy discovery, knowledge-graph construction, evaluation/scoring — has already been prototyped for reviving dormant patents, which suggests the architecture is buildable, not just theoretical (CMU MSPM: Innovation Mining for Patents).
Technology Choices at a Glance
| Layer | Open, vendor-neutral options | Selection rule |
|---|---|---|
| Extraction | LLM with JSON Schema-constrained output + SAO extraction | Structured output mandatory; free-text extraction forbidden |
| Card Store | Postgres (JSONB) | Transactional, versionable, boring on purpose |
| Graph | Neo4j / Apache AGE / RDF store | Must support domain-distance queries |
| Vectors | pgvector / Qdrant | Must support per-facet namespaces |
| Matching | Hybrid retrieval + LLM judge with fixed rubric | Rubric and model version recorded per score |
| Evidence | Rule store + source-resolution service | Unresolvable citation = invalid card |
| Governance | Ticketed approval workflow + append-only audit log | The audit log is the product, not a side effect |
A Micro-Case: One Query Through the Stack
To show the layers working together, here is the series' running example — a bearing-failure prediction problem — traced end to end:
-
(1) The customer's problem becomes Problem Card
PC-2026-0114withsignal_properties: quasi-periodic, colored noise, rare events, no labeled failures. -
(3) The facet-vector index — searching the signal_properties and transformation facets, not the words "bearing" or "maintenance" — surfaces Mechanism Card
MC-ASTRO-0442from radio astronomy: matched-filter, periodogram-based change-point detection. - (4) The Matching Engine scores TFS = 0.78: the problem physics match is high, the causal chain survives, and the context risk is modest (telescope detrending must be replaced with order tracking).
- (5) The Evidence Validator confirms the evidence trail (decades of pulsar-timing literature and production observatory pipelines) and flags one assumption as adapted rather than held.
-
(6) The system emits Transfer Report
TR-2026-0087withhuman_gate: REQUIRED_BEFORE_PILOT— a proposal, not a decision.
The same stack, instantiated with a healthcare problem card and a logistics mechanism card, runs unchanged. That is the point of the layers: the architecture is domain-agnostic on purpose.
Failure Modes and Boundaries
The production risks that most deserve respect:
- Extraction hallucination — the highest-probability failure. Mitigated by citation resolution and published sampling rates, never by trust.
- Index regression to RAG — the quiet failure where someone adds whole-document embeddings "as a fallback" and the system starts retrieving topical matches again. Retrieval evaluation must run in CI.
- Weight rot — calibration weights aging as industries change. The re-fitting schedule must be published with the weights.
- Metric theater — benchmark results reported on data the system was tuned on. Temporal holdout is a hard rule, not a preference.
- Automation creep — governance gates quietly bypassed under delivery pressure. The audit log exists precisely so this is visible when it happens.
The standing boundary from the series carries into every layer: AI accelerates discovery; humans own applicability.
Build Order: Ninety Days to a Working Stack
| Phase | Weeks | Scope | Exit criterion |
|---|---|---|---|
| 1 | 1–4 | One vertical, two industries, ~500 curated Mechanism Cards, extraction + validation with human spot-checks | Cards pass schema + citation resolution at ≥ 98% |
| 2 | 5–8 | Dual index + matching engine + first Transfer Reports | A known historical transfer is retrieved and scored correctly |
| 3 | 9–12 | Calibration v0 from expert-labeled Realized Transfer Records + governance gates + evaluation harness | Published weights, calibration error reported, human gates enforced in workflow |
The sequencing rule: evidence before scale. A small, correct card corpus with verified evidence beats a large corpus with unverified extraction — because in this system, a wrong card does not just miss; it actively proposes invalid transfers.
Why This Matters
The series has moved deliberately: an idea (transfer mechanisms, don't reinvent them), a protocol (cards, scores, evidence, gates), a measurement discipline (calibration against realized outcomes), and now an architecture that ties them into a buildable system.
What makes the Transfer Stack different from another RAG platform is not any single technology. It is the order of accountability: extraction is validated, indexing is evaluated, scoring is calibrated, evidence is resolved, and decisions stay human. Every layer exists to make the next layer's claims checkable.
The final piece of the series is the one that proves or breaks all of it: a real deployment, with real Transfer Reports, measured against real outcomes. That case study is next; follow the Innovation Wormhole series if you want it in your feed.
If you built this stack, what would your first two industries be — and which would you trust less, the extraction layer or the calibration loop? I'd love to hear your thoughts in the comments.
References
- Scideator — Human-LLM Compound System for Scientific Ideation through Facet Recombination and Novelty Evaluation — arXiv:2409.14634
- Accelerating Innovation Through Analogy Mining — arXiv:1706.05585
- Knowledge graph-assisted design-by-analogy: promoting product innovation through structured analogical knowledge retrieval — Cambridge AI EDAM
- From Analogy to Innovation: A creative conceptual design approach leveraging large language models — Advanced Engineering Informatics, 2025
- Discovering new applications: Cross-domain exploration of patent documents using causal extraction and similarity analysis — ScienceDirect
- Patent Mining as a Strategic Intelligence tool for SMEs — IntechOpen
- AI-Augmented Analogical Reasoning for Engineers — PatSnap
- Design-by-Analogy: Effects of Exploration-Based Approach on Analogical Retrievals and Design Outcomes (VISION) — ASME J. Mech. Des.
- Cross-Industry Innovation Does Not Happen by Chance: The Role of Facilitation — Springer Professional
- Innovation Mining for Patents — an agentic AI pipeline for dormant patents — CMU MSPM
- Part 1 of this series — Building an AI-Powered Innovation Wormhole
created by Seyed Alireza Alhosseini Almodarresieh
https://almodarresieh.github.io/
Top comments (0)