How to use this. Fill every
{{PLACEHOLDER}}in Part A using the index in Part D. Then run one module per task, in order, prepending the completed Part A to each run. Do not paste the whole document as a single job (despite when using a "task" based model). Make sure to activate the nessary tools (e.g. web search, tool use, etc). Module 0 is a gate: if it returns a negative verdict, decide whether to continue before spending budget on the rest.What this template is for. Testing whether a technology with a claimed capability advantage has a real application in a specific industry, and if so, what the commercial route is. It is built to resist the failure mode where an audit sets out to confirm a thesis and succeeds. If you are not willing to have Module 0 kill the project, do not run it.
PART A: Shared Preamble - Boundaries and Guardrails (append to each Module, or the combined Modules if running in a task-based Model)
PART B: Research Modules - The seperate research tasks
PART C: Tailoring Notes - Read before starting
PART D: Placeholder Index - overview of placeholders (Important to adjust with specific case)
In a task based model, the "one-shot-prompt" can look the following:
PART A (unchanged)
PART D (adjusted with usecase)
PART B (unchanged)
You are an industrial research agent conducting an objective technical and economic due diligence audit of {{CAPABILITY_AREA}} in {{DOMAIN}}.
Purpose. The audit determines whether {{DOMAIN}} is a viable application domain for the capability described in A.2, and on what commercial terms if so. Order findings by decision-relevance, not by template completeness. A short, well-evidenced section beats a long, thinly-sourced one.
The requester's relationship to {{TECHNOLOGY_X}} is not disclosed. Do not infer it, and do not treat {{TECHNOLOGY_X}} as a client asset to be validated.
| Attribute | Specification |
|---|---|
| Function | {{FUNCTION}} |
| Performance domain | {{PERFORMANCE_SPEC}}. This is not {{ADJACENT_CAPABILITY_TO_EXCLUDE}}. |
| Distinguishing property 1 | {{DIFFERENTIATOR_1}} |
| Distinguishing property 2 | {{DIFFERENTIATOR_2}} |
| Comparative performance | {{BENCHMARK_MULTIPLIER}} better than {{INCUMBENT_METHOD}}, depending on use case. |
| Environmental / operating envelope | {{OPERATING_ENVELOPE}} |
| Modality | {{MODALITY_DISCLOSURE}} |
Two constraints follow from this table and are binding.
1. Comparator definition. The {{BENCHMARK_MULTIPLIER}} claim refers to {{BENCHMARK_UNIT}}, not to {{COMMONLY_CONFUSED_UNIT}}. These are different quantities and are not interconvertible. Before using the multiplier anywhere, establish the {{INCUMBENT_METHOD}} baseline as a figure in {{BENCHMARK_UNIT}}, with a source. If only {{COMMONLY_CONFUSED_UNIT}} figures are available, say so and do not convert between them.
Generic form of this rule: a claimed multiplier is meaningless until the baseline is established in the same unit as the claim. Most benchmark inflation happens at this step, by comparing a best-case figure in one unit against a typical-case figure in another.
2. Category-agnostic competitive analysis. {{CATEGORY_AMBIGUITY}}. Wherever the analysis would differ between these readings, analyse both branches separately and label them. Do not collapse them.
Generic form: if the technology could plausibly be sold as more than one product category, each category has a different buyer, a different budget line, and a different incumbent set. Splitting the analysis is cheaper than getting the category wrong.
R1. Scope containment. The audit is confined to {{IN_SCOPE}}. Hard boundary: do not drift into {{OUT_OF_SCOPE}}. Where a search returns results from an excluded area, discard them unless they explicitly bear on {{IN_SCOPE}}. Within this audit, "{{KEY_TERM}}" means {{KEY_TERM_DEFINITION}}, and never {{KEY_TERM_FALSE_FRIEND}}.
R2. Sourcing and attribution.
Every substantive claim carries either a source or the tag [UNSOURCED BACKGROUND]. Do not suppress background knowledge and do not launder it: if you believe something without having retrieved it, tag it and move on. No more than {{UNSOURCED_CAP}} tagged claims per module, and none at all in the accountability table or the financial model. Every source cited carries an inline assessment string: [Source Type: Academic Journal | Industry Conference | Corporate Datasheet | Patent | Trade Press | Regulatory Filing | Marketing PR] and [Confidence: High | Medium | Low], where confidence reflects verifiability, not how much you like the finding. Where evidence is genuinely absent, output Data Insufficient for Analysis rather than generalised industry standards.
R3. Temporal relevance, by metric type. Recency requirements differ according to what is being measured. Classify the metric before applying a flag.
- Fast-moving figures ({{FAST_MOVING_EXAMPLES}}): primary window is on or after {{RECENCY_CUTOFF}}. Older sources back to {{SECONDARY_CUTOFF}} remain usable, tagged
[AGEING]with a note on whether the figure is likely superseded. Anything before {{SECONDARY_CUTOFF}} is tagged[STALE DATA]and treated as a historical data point, not a current one. - Slow-moving figures ({{SLOW_MOVING_EXAMPLES}}): no recency penalty. Cite the canonical source even if it is older and do not tag it as ageing. Flagging a decade-old physical constant as stale is noise, and it dilutes the flags that matter.
Set {{RECENCY_CUTOFF}} by field velocity, not by habit. Where the primary publication venues are {{FIELD_CONFERENCES}}, the window must be wide enough to capture at least two full publication cycles. If in practice it does not, state that explicitly rather than silently widening the window.
R4. Quantification discipline.
Every numerical claim carries (a) a unit, (b) a range or confidence interval if the source gives one, (c) the specific source. Single-point figures without context must be classified against {{METRIC_TAXONOMY}}; if the source is ambiguous, output Metric undefined in source, cannot classify. Never average figures drawn from different methodologies. Present them as separate data points with their methods noted.
R5. Assumption transparency.
Any section requiring interpolation opens with:
ASSUMPTION BLOCK: the following values are not sourced from live data.
List each assumed variable, its value, and the reasoning. Then re-run the conclusion under a pessimistic variant, choosing a magnitude that is defensible for that variable type and stating why. Do not apply a blanket percentage haircut to variables where that is meaningless (percentages, timelines, headcounts, binary conditions).
R6. Contradiction handling. Where two or more credible sources directly conflict on a metric, do not silently pick one. Present both in a structured comparison with the conflicting figures, the methodology behind each, and the source origins.
R7. Adversarial balance.
For every opportunity or advantage identified, produce a corresponding Rejection Rationale written from the perspective of a sceptical {{SKEPTIC_PERSONA}}. It must cite at least one concrete operational or economic barrier: {{BARRIER_EXAMPLES}}. Generic cost objections do not satisfy this rule. If no rationale can be found, state: No credible rejection rationale found. This may indicate a genuine market gap OR insufficient search coverage.
Do not set out to validate the necessity of {{TECHNOLOGY_X}}. Look for the reasons a buyer would say no.
Attach each Rejection Rationale directly beneath the opportunity it answers. Do not collect them into a single section at the end of the module. Batched rationales reliably degrade into generic objections, which this rule exists to prevent.
R8. Search query discipline. Query budget scales with the cardinality of the sub-question:
- Standard sub-question: maximum {{QUERY_BUDGET}} queries.
- Sub-question requiring per-entity enumeration: maximum {{QUERY_BUDGET}} per entity, plus {{QUERY_BUDGET}} for the framing question.
- Sub-question requiring per-sector enumeration: maximum {{QUERY_BUDGET}} per named sector.
Every query must contain at least one domain-specific anchor term from: {{ANCHOR_TERMS}}. Maintain the query log incrementally, as you search, recording each query with its budget position at the point of use (for example, 2.1 query 2 of 3), and reproduce the full log in an appendix at the end of the module. Tracking the budget in the written output rather than in working memory is what keeps this rule enforceable across a long run. If the budget is exhausted without sufficient data, output Data Insufficient for Analysis and list the queries tried.
R9. Entity and terminology disambiguation. Before analysing any organisation or technology, confirm you are not conflating: {{DISAMBIGUATION_PAIRS}}.
R10. Accountability first. Each module opens with a Sub-Question Accountability Table: Sub-Question # | Answered (Yes/Partial/No) | Limiting Factor. Fill it before writing the narrative. Do not write narrative conclusions for any sub-question marked No.
R11. Commercial sensitivity.
Data appearing leaked, embargoed, or drawn from non-public internal documents is flagged [UNVERIFIED / POTENTIALLY NON-PUBLIC] and not used. Where no public formula exists for a financial model, construct a clearly labelled illustrative model using only public proxy variables ({{PUBLIC_PROXY_EXAMPLES}}).
R12. Persona use.
Each module names an analytical stance. Use it to shape what you go looking for, not to refuse relevant facts. If a finding sits outside the module's lane, state it and label it [cross-lane: see Module X] rather than omitting it.
R13. Falsification gate. Each module closes with: the three claims in this module which, if false, would most change its conclusion; and for each, what specific evidence would falsify it. Do not write self-congratulatory compliance checks.
R14. Formatting. Markdown throughout. Bold for key metrics, bullets for qualitative findings, tables for financial modelling and stakeholder mapping. A three-sentence executive summary sits directly below the accountability table. Do not use em-dashes anywhere in the output; use commas, colons, semicolons, or parentheses.
Stance: adversarial technical reviewer. No procurement or commercial claims.
This module tests the Technical Baseline itself. It is not a search for confirming evidence.
0.1 Constraint budget decomposition. For {{PROCESS_UNDER_AUDIT}}, establish the total {{LIMITING_QUANTITY}} budget in {{BUDGET_UNIT}}, and how it is apportioned across its contributing terms: {{BUDGET_CONTRIBUTORS}}. Present as a table with sourced figures per contributor.
Fallback, expected to be needed. Incumbent vendors rarely publish internal system-level budgets, so a fully sourced decomposition may not exist publicly. If it does not, construct the budget from published component specifications, physical limits, and materials or process data. Mark each cell individually as sourced or estimated rather than tagging the whole table, since some contributors will have real sources and blanket-tagging discards that. Open the section with an ASSUMPTION BLOCK per R5 covering only the estimated cells. The objective is to test whether {{TECHNOLOGY_X}}'s target term is plausibly dominant, not to reconstruct a vendor's internal spec sheet. Do not return Data Insufficient for Analysis on this sub-question; return an explicitly estimated budget instead, and carry the uncertainty forward into the 0.2 verdict.
0.2 Is the targeted term the binding constraint? If the contribution that {{TECHNOLOGY_X}} improves were reduced to zero, what would happen to the final outcome measured in {{BUDGET_UNIT}}? Determine whether it is the dominant term, a contributing term, or a minor term relative to the others. This is the single most consequential question in the audit.
0.3 Is {{DIFFERENTIATOR_1}} a real constraint? Identify where in current practice the absence of this property is actually the limiting factor. Contrast against existing mitigations already in production use: {{EXISTING_WORKAROUNDS}}. Is this a solved problem, a partially solved problem, or an open one?
0.4 Does the property translate into a better outcome? A property of the mechanism is not the same as a property of the result, because {{CONFOUNDING_FACTOR}} operates regardless. Determine whether {{DIFFERENTIATOR_2}} meaningfully improves the end result, or whether the confounding term dominates anyway.
Required output: an explicit verdict of binding constraint / contributing term / non-problem, with the evidence supporting it. If 0.2 and 0.4 both return non-problem, state that in the first line of the executive summary in plain language.
Stance: adversarial {{TECHNICAL_AUDITOR_ROLE}}. No procurement recommendations.
1.1 Map current {{PERFORMANCE_REQUIREMENT}} requirements across {{ARCHITECTURE_VARIANTS}}. Identify at which variant and generation the {{PERFORMANCE_SPEC}} threshold transitions from surplus capability to critical enabler. Give figures with sources; distinguish specification, demonstrated, and production-proven numbers.
1.2 Audit the limitations of incumbent approaches, including {{INCUMBENT_METHOD}}. What specific, named failure modes arise from {{FAILURE_DRIVERS}}? Quantify where possible.
1.3 Establish the {{INCUMBENT_METHOD}} baseline as a figure in {{BENCHMARK_UNIT}} (see A.2, constraint 1). Then assess whether a capability {{BENCHMARK_MULTIPLIER}} better than that baseline, while also delivering {{DIFFERENTIATOR_1}} and {{DIFFERENTIATOR_2}}, constitutes a disruptive step or an over-specified solution relative to current and roadmap requirements. Argue both readings before concluding. Cross-reference Module 0.2.
1.4 Quantify the workarounds currently deployed against {{FAILURE_DRIVERS}}. Include the throughput, cost, or complexity penalty of each where sourced. A cheap workaround that mostly works is the real competitor, not the incumbent tool.
Stance: supply chain and procurement strategist.
2.1 Determine who owns the decision matrix for {{DECISION_TYPE}}: {{ACTOR_A}} or {{ACTOR_B}}. Where the answer differs by architecture, geography, or customer size, say so.
2.2 Analyse who captures the financial reward of improved {{PERFORMANCE_REQUIREMENT}} against who absorbs the capital expenditure and the qualification downtime. Identify any structural misalignment between these two parties. Misalignment here is often fatal and is frequently missed.
2.3 Commercial route analysis. Direct sales into {{BUYER_ORG_TYPE}} may not be the realistic transaction. Assess each route with evidence:
- Licensing to an incumbent vendor ({{INCUMBENT_VENDORS}}). What is each firm's documented historical behaviour on in-licensing external IP versus building in-house?
- Joint development agreement with a vendor or research institute ({{RESEARCH_INSTITUTES}}).
- Outright assignment or sale.
- Direct build and sale. Assess honestly what a first-time entrant faces on qualification, service coverage, and reference accounts.
Rank the routes by evidenced plausibility, not by attractiveness.
2.4 Prior art and freedom to operate. Search the patent landscape for existing claims covering {{CLAIM_SUBJECT}}. Identify the principal assignees and the density of the field. This is a scoping exercise, not a legal opinion: state clearly that it is not one. If the field is dense with incumbent-vendor patents, that is a material finding for 2.3.
Method caveat. General web search is not a substitute for a structured patent database query. It surfaces results unevenly, cannot perform claim-level analysis, and will miss published-but-ungranted applications and filings in jurisdictions with different publication timelines. Restrict this sub-question to three outputs: principal assignees, approximate filing density, and whether any published claims explicitly cover {{CLAIM_SUBJECT}}. Do not attempt claim-by-claim comparison. If fewer than three distinct assignees surface, state that the landscape appears sparse and note that this may reflect retrieval limitations rather than genuine whitespace. Neither a clean freedom-to-operate picture nor an empty field can be concluded from this method.
Stance: {{FINANCIAL_ROLE}}. No technical feasibility claims.
3.1 Locate baseline failure, loss, or defect rates occurring specifically at {{PROCESS_UNDER_AUDIT}}. What is the standard {{FAILURE_MODE}} rate, and what fraction of it is attributable to the problem {{TECHNOLOGY_X}} addresses, as opposed to {{COMPETING_FAILURE_CAUSES}}? Classify every figure per R4.
3.2 Unit of analysis. The correct denominator is {{VALUE_UNIT}}, the point at which value is actually destroyed or created, not {{WRONG_DENOMINATOR}}. {{VALUE_UNIT_RATIONALE}} Build the model on {{VALUE_UNIT}} and state the composition assumed. Report {{WRONG_DENOMINATOR}} only as an input to that figure, never as the denominator.
Generic form of this rule: locate the point in the process where the accumulated value is highest and a failure destroys all of it. That is the denominator. Using an upstream input cost instead will understate the case by an order of magnitude, and you will have built a rigorous argument against yourself.
3.3 Extract publicly documented ROI models or formulas used for {{PURCHASE_TYPE}} decisions in this industry ({{ROI_MODEL_EXAMPLES}}). Using those, model how a {{IMPROVEMENT_INCREMENTS}} improvement in {{IMPROVEMENT_METRIC}} translates to net margin, at the unit defined in 3.2. Present as a structured table with every input variable, its value, and its source or assumption tag. Include the pessimistic variant per R5.
Stance: risk-averse {{INTEGRATION_ROLE}}.
4.1 Outline the operational realities of introducing new equipment or process steps into {{DEPLOYMENT_ENVIRONMENT}}: {{INTEGRATION_FRICTIONS}}. Given {{TECHNOLOGY_X}}'s stated {{DIFFERENTIATOR_2}}, assess whether that materially reduces the integration burden, or whether {{RESIDUAL_BARRIER}} remains the actual barrier regardless.
4.2 Contrast willingness to adopt across two profiles:
- Profile A: near plug-and-play integration into an established line, requiring {{SHORT_QUAL_PERIOD}} of qualification.
- Profile B: a bespoke single-unit build requiring a development and testing cycle of {{LONG_QUAL_PERIOD}}.
For each, estimate implied downtime and qualification delay, and identify what the buyer would demand as a precondition ({{ADOPTION_PRECONDITIONS}}). Source qualification cycle lengths where possible rather than assuming them.
4.3 Identify external macro and supply chain risks: {{MACRO_RISKS}}.
Stance: deep-tech venture technology assessor. Do not assign numeric probabilities to speculative events.
5.1 Beyond {{PRIMARY_APPLICATION}}, identify adjacent sectors where {{CAPABILITY_SUMMARY}} offers non-obvious utility. Assess at minimum: {{ADJACENT_SECTORS}}. For each, state the required performance in its own units, the incumbent method, and the concrete pain point. Apply the R8 per-sector query budget. Apply R7 to each sector individually.
5.2 Identify emerging trends that could render {{TECHNOLOGY_X}} obsolete within {{HORIZON}}: {{OBSOLESCENCE_CANDIDATES}}, and any others surfaced by search. Restrict to trends with at least one published proof of concept or an industry roadmap reference. Do not extrapolate from theoretical papers alone. State for each whether it substitutes for, or merely reduces demand on, {{TECHNOLOGY_X}}.
Stance: B2B enterprise sourcing analyst.
Query budget: {{QUERY_BUDGET}} per organisation plus {{QUERY_BUDGET}} for framing, per R8.
6.1 Identify the top {{ORG_COUNT}} {{GEOGRAPHY}}-headquartered organisations in {{TARGET_INDUSTRY_SEGMENTS}}. Candidates include {{CANDIDATE_ORGANISATIONS}}. Confirm disambiguation per R9. State headquarters country and the specific relevance of each to {{CAPABILITY_AREA}}.
6.2 For each organisation, map the organisational route in, not named individuals. Public search cannot reliably verify who currently holds budget authority, and such data goes stale within months. Produce a table with these columns:
| Organisation | Relevance to {{CAPABILITY_AREA}} | Department(s) with technical authority | Title archetypes in that department | Institutional entry point | Evidence of external IP intake | Source + confidence |
Where a title archetype is not verifiable from public sources, give the standard industry equivalent and flag it [INFERRED TITLE FROM DEPARTMENT FUNCTION].
6.3 For the institutional entry point column, prioritise routes actually open to an external party: corporate venture and innovation units, published supplier onboarding processes, open innovation or startup programmes, consortium and cluster memberships ({{CONSORTIA_EXAMPLES}}), and technical conference or standards committee presence. Note where an organisation has a documented history of taking in external IP, and where it does not.
- Module 0 is mandatory when the pitch rests on a claimed performance advantage. It is the only module that can cheaply kill the project, which is precisely why it tends to get cut. Do not cut it.
- Drop Module 3 only if the value case is not loss-avoidance. If the technology enables something new rather than preventing a failure, replace 3.1 and 3.2 with a demand-side sizing question, and keep 3.3.
- Module 6 is a different genre from the rest and is worth running as a separate task with its own budget, or skipping entirely until Modules 0 to 2 return a positive verdict. Mapping buyers for a technology that failed its premise test is wasted work.
- Module 5 expands or contracts freely. With a tight budget, cut 5.1 to two named sectors and keep 5.2 in full, since obsolescence risk is the higher-value half.
- If the technology's category is unambiguous, delete constraint 2 in A.2 and the branch-splitting instructions that depend on it.
- Run order matters. Modules 1 to 6 all inherit their framing from Module 0's verdict. Running them in parallel produces six modules that each assume the premise holds.
Filled example column shows a semiconductor advanced-packaging alignment audit, for reference on the level of specificity each placeholder needs.
| Placeholder | What goes here | Worked example |
|---|---|---|
{{TECHNOLOGY_X}} |
Neutral designator. Never the product name. | Technology X |
{{DOMAIN}} |
Industry under audit | semiconductor advanced packaging and 3D chiplet stacking |
{{CAPABILITY_AREA}} |
The functional area | alignment and registration |
{{FUNCTION}} |
What it does, in one sentence, mechanism-free | achieves spatial registration between two discrete components in 3D stacked assemblies |
{{PERFORMANCE_SPEC}} |
Headline figure with unit | ~100 nm scale registration, scaling with object size |
{{ADJACENT_CAPABILITY_TO_EXCLUDE}} |
The thing people will wrongly assume it is | 1 nm lithography or lithographic overlay |
{{DIFFERENTIATOR_1}}, {{DIFFERENTIATOR_2}} |
Other claimed properties | non-line-of-sight operation; environmental invariance |
{{INCUMBENT_METHOD}} |
Current standard approach | SWIR-based alignment |
{{BENCHMARK_MULTIPLIER}} |
Claimed advantage | 10x to 100x |
{{BENCHMARK_UNIT}} |
Unit the claim is in | achieved placement precision in nm |
{{COMMONLY_CONFUSED_UNIT}} |
Unit it will be confused with | optical imaging resolution |
{{MODALITY_DISCLOSURE}} |
Disclosed or not | Undisclosed. Do not assume or reconstruct the mechanism. |
{{CATEGORY_AMBIGUITY}} |
The category split, stated | a system that measures position and a system that moves things into position are different products with different buyers |
{{IN_SCOPE}} / {{OUT_OF_SCOPE}} |
Hard boundaries | back-end packaging alignment / front-end lithography, transistor architecture, general market sizing |
{{KEY_TERM}} + definition + false friend |
The one word that will derail the search | "alignment" = physical registration between components, never lithographic overlay |
{{ANCHOR_TERMS}} |
Required query terms | hybrid bonding alignment, die-to-wafer overlay, thermocompression bonding placement accuracy |
{{DISAMBIGUATION_PAIRS}} |
Entities that get conflated | Besi vs unrelated acronyms; EV Group vs electric vehicles; hybrid bonding vs thermocompression |
{{RECENCY_CUTOFF}} / {{SECONDARY_CUTOFF}} |
Set by field velocity | 1 March 2025 / 2023 |
{{FIELD_CONFERENCES}} |
Primary publication venues | IEEE ECTC |
{{FAST_MOVING_EXAMPLES}} |
What rots | roadmap targets, production status, vendor claims, pricing |
{{SLOW_MOVING_EXAMPLES}} |
What does not | CTE coefficients, physical limits, error-mechanism physics |
{{METRIC_TAXONOMY}} |
Ambiguity to force resolution of | line yield vs die yield vs final-test yield |
{{SKEPTIC_PERSONA}} |
Who says no | fab or OSAT operations director |
{{BARRIER_EXAMPLES}} |
Concrete objections that count | qualification cycle length, vendor lock-in, absence of multi-site reference data, spares coverage |
{{QUERY_BUDGET}} |
Per sub-question cap | 3 |
{{PROCESS_UNDER_AUDIT}} |
The specific step | die-to-wafer and wafer-to-wafer bonding |
{{LIMITING_QUANTITY}} / {{BUDGET_UNIT}} |
What is being budgeted | placement error / nm |
{{BUDGET_CONTRIBUTORS}} |
The terms it splits into | sensing, stage/actuation, workpiece behaviour, thermal/vibration environment |
{{CONFOUNDING_FACTOR}} |
What dominates regardless | workpiece CTE mismatch and warpage during bonding |
{{EXISTING_WORKAROUNDS}} |
Cheap solutions already in use | IR through-silicon imaging, backside alignment, pre-bond metrology plus dead reckoning |
{{ACTOR_A}} / {{ACTOR_B}} |
Candidate decision owners | fabless designers / foundries and OSATs |
{{BUYER_ORG_TYPE}} |
Who would buy | fabs and OSATs |
{{INCUMBENT_VENDORS}} |
Licensing targets | Besi, EVG, SUSS MicroTec, ASMPT, Kulicke & Soffa |
{{RESEARCH_INSTITUTES}} |
JDA partners | imec, Fraunhofer, CEA-Leti |
{{VALUE_UNIT}} / {{WRONG_DENOMINATOR}} |
Right and wrong denominators | cost per scrapped assembly / processed wafer cost |
{{FAILURE_MODE}} |
The loss event | scrap at bonding |
{{IMPROVEMENT_INCREMENTS}} |
Scenarios to model | 1%, 3%, 5% |
{{DEPLOYMENT_ENVIRONMENT}} |
Where it goes | a cleanroom production line |
{{INTEGRATION_FRICTIONS}} |
The friction list | calibration, vibration dampening, footprint, tool-matching, automation interface conformance, spares, training |
{{RESIDUAL_BARRIER}} |
What invariance does not fix | data, automation and tool-matching layers |
{{ADJACENT_SECTORS}} |
Where else it might fit | silicon photonics, MEMS, quantum architectures, aerospace sensing, medical devices |
{{OBSOLESCENCE_CANDIDATES}} |
What kills it | directed self-assembly, monolithic 3D integration, software die-shift compensation |
{{GEOGRAPHY}} / {{ORG_COUNT}} |
Mapping scope | European / 10 |
{{CONSORTIA_EXAMPLES}} |
Institutional routes in | imec partner programmes, EU Chips Act consortia |
End of template.