Article 31 Regulation (EU) 2024/2847 · Chapter III 法規 (EU) 2024/2847 · 第三章

Technical documentation — the file every route depends on 技術文件，所有路徑共同倚賴的檔案

Whether the manufacturer self-declares under Module A, goes through an EU-type examination under Module B+C, runs a quality system under Module H, or obtains an EUCC certificate — a compliant Annex VII technical file is the one artefact that is always required. Article 31 is how that file is defined. 不論製造商走 Module A 自我宣告、Module B+C 歐盟型式檢驗、Module H 品質系統、或取得 EUCC 證書，符合附件七之技術檔案是永遠必須的那一份文件。第 31 條定義此檔案。

Paragraphs段落數 · 5 Applies from適用起始 · 11 Dec 2027 Primary audience主要對象 · Manufacturer · Notified body製造商 · 指定機構 Last reviewed最後校閱 · 2026-04-25 Status狀態 · Working書寫

Block 1 · Official text 區塊 1 · 官方條文

What the Regulation actually says 條文實際怎麼寫

Source. Consolidated text from Regulation (EU) 2024/2847 as published in OJ L 2024/2847, 20 November 2024. Translation is unofficial; refer to EUR-Lex for binding text. 來源。條文自《法規 (EU) 2024/2847》整合文本，發布於 OJ L 2024/2847，2024 年 11 月 20 日。中文為非官方翻譯；強制適用條文請見 EUR-Lex。

Core requirement and Annex VII reference 核心要求與附件七引用 ¶ 1 – 2

1. The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I. It shall at least contain the elements set out in Annex VII.

1. 技術文件應載明製造商所採取之所有相關資料或手段細節，以確保具數位元素產品與製造商所建立之流程符合附件一所定基本網路安全要求。技術文件至少應包含附件七所列各項要素。

2. The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.

2. 技術文件應於具數位元素產品投放市場前製備，並於適當情形下，至少於支援期間內持續更新。

Consolidated documentation for Article 12 products 第 12 條產品之合併文件 ¶ 3

3. For products with digital elements as referred to in Article 12, which are also subject to other Union legal acts which provide for technical documentation, a single set of technical documentation shall be drawn up containing the information referred to in Annex VII and the information required by those Union legal acts.

3. 就第 12 條所指之具數位元素產品（同時受其他規定技術文件之聯盟法律行為拘束者），應編製單一套技術文件，涵蓋附件七所指資訊與該等聯盟法律行為所要求之資訊。

Example: a high-risk AI system that is also CRA-scoped must produce one consolidated technical file that satisfies both CRA Annex VII and AI Act Annex IV — not two parallel files.

例：同時屬 CRA 範圍之高風險 AI 系統，須產出一份合併技術檔案同時滿足 CRA 附件七與 AI Act 附件四，不是兩份平行檔案。

Language requirement 語言要求 ¶ 4

4. The technical documentation and correspondence relating to any conformity assessment procedure shall be drawn up in an official language of the Member State in which the notified body is established or in a language acceptable to that body.

4. 涉及任何符合性評鑑程序之技術文件與通訊，應以指定機構所在會員國之官方語言、或指定機構接受之語言編製。

Commission delegated-act power; SME proportionality 執委會授權權限；SME 比例性 ¶ 5

5. The Commission is empowered to adopt delegated acts in accordance with Article 61 to supplement this Regulation by adding elements to be included in the technical documentation set out in Annex VII to take account of technological developments, as well as developments encountered in the implementation process of this Regulation. To that end, the Commission shall strive to ensure that the administrative burden on microenterprises and small and medium-sized enterprises is proportionate.

5. 執委會有權依第 61 條採納授權法規補充本法規，為反映科技發展及本法規實施過程中出現之發展，增加附件七技術文件應載明之要素。執委會應致力確保對微型與中小企業之行政負擔符合比例。

Related but separate: Article 33(5) separately authorises a simplified technical-documentation form for microenterprises and small enterprises, to be specified by Commission implementing act.

相關但獨立：第 33(5) 條另授權由執委會執行法案訂定之微型與小型企業簡化技術文件表式。

Annex VII contents — what the file must include 附件七內容，檔案應包含之項目 Annex VII

Annex VII lists five top-level items, each as applicable to the relevant product:

附件七列出五個主要項目，每項視相關產品情況適用：

1. General product description — intended purpose; versions of software affecting cybersecurity compliance; for hardware products, photographs and illustrations of external features, marking and internal layout; user information and instructions per Annex II.

1. 產品一般描述，預期用途；影響網路安全符合性之軟體版本；硬體產品之外觀特徵、標示與內部布局之照片或圖示；依附件二所列使用者資訊與說明。

2. Design, development, production and vulnerability handling processes — design/development information including drawings, schemes and system architecture; vulnerability-handling specifications including SBOM, CVD policy, evidence of contact address for vulnerability reporting, secure-update distribution solutions; production and monitoring processes and their validation.

2. 設計、開發、生產與弱點處理流程，含圖紙、規劃與系統架構之設計 / 開發資訊；含 SBOM、CVD 政策、弱點通報聯絡地址證據、安全更新派送解決方案之弱點處理規格；生產與監控流程及其驗證。

3. Cybersecurity risk assessment — against which the product is designed, developed, produced, delivered and maintained per Article 13, including how Annex I Part I applies.

3. 網路安全風險評估，依第 13 條，針對設計、開發、生產、交付、維護所依據之評估，含附件一第一部分如何適用。

4. Support period determination information — the factors taken into account to determine the support period per Article 13(8).

4. 支援期間決定之資訊，依第 13(8) 條決定支援期間時所考量之因素。

5. List of applied standards and certifications — harmonised standards cited in the OJEU, common specifications per Article 27, European cybersecurity certification schemes applied; and where any of those have not been applied, descriptions of the alternative solutions adopted to meet Annex I requirements.

5. 所採用標準與認證清單，於《歐盟官方公報》引用之調和標準、第 27 條所定共通規範、已適用之歐洲網路安全認證機制；凡上述任一未適用者，須描述為滿足附件一要求所採之替代解決方案。

Block 2 · Plain language 區塊 2 · 白話解讀

What actually goes into the file 技術檔案裡實際要放什麼

The CRA technical file is not a single document — it is a structured bundle of evidence. Annex VII names five top-level items, each of which expands into multiple artefacts. Below is a working inventory of what a well-constructed CRA technical file looks like for a typical APAC-manufactured Annex III Class I product. Items marked "new" are genuinely novel compared to what an existing RED / EMC / LVD technical file contains.

CRA 技術檔案不是單一文件，是一組結構化的證據集。附件七列出 5 個主要項目，每項展開為多份產出。下面是一件典型 APAC 生產的附件三 Class I 產品、結構良好的 CRA 技術檔案實務清單。標「新」表示相較於既有 RED / EMC / LVD 技術檔案是新增的。

Annex VII item附件七項次	Concrete artefacts具體產出	CRA-new?CRA 新增？
1. General description	Product datasheet; intended-use statement; photos (for hardware); software version matrix with security relevance marked; user manual per Annex II產品資料表；預期用途聲明；硬體照片；標示安全相關性的軟體版本矩陣；依附件二的使用者手冊	Partial — version matrix with security marking is new部分，標示安全性的版本矩陣為新
2a. Design and development	Block diagrams; system architecture; data-flow diagrams; trust boundaries; interface specifications方塊圖；系統架構；資料流圖；信任邊界；介面規格	No — standard technical content否，標準技術內容
2b. Vulnerability handling	SBOM (CycloneDX or SPDX, machine-readable); CVD policy document; evidence of published contact address for vulnerability reporting (security.txt, web page, email); secure-update distribution description (signed firmware, transport encryption, rollback protection)SBOM（CycloneDX 或 SPDX，機器可讀）；CVD 政策文件；弱點通報聯絡地址公開證據（security.txt、網頁、電郵）；安全更新派送描述（簽章韌體、傳輸加密、回退保護）	Yes — entirely new relative to RED/EMC files是，相較於 RED / EMC 檔案為全新
2c. Production and monitoring	Production control procedures; IQC/OQC protocols; batch release criteria; traceability; validation records生產管制程序；IQC / OQC 協定；批號放行基準；可追溯性；驗證紀錄	No — overlaps with ISO 9001 content否，與 ISO 9001 內容重疊
3. Risk assessment	Threat model; asset inventory; risk register; applicability decisions for Annex I Part I 2(a)–(m) with justification for each "not applicable"; mitigation mapping威脅模型；資產清單；風險登錄；對附件一第一部分 2(a)–(m) 各項的適用性判斷，含每個「不適用」的理由；緩解對應	Yes — risk-based approach with explicit Annex I mapping is CRA-novel是，以附件一為顯式對應的風險基礎方法為 CRA 獨有
4. Support period	Support-period declaration (e.g., 5 years); factors considered per Article 13(8) — user expectations, product lifespan, component third-party support, operating environment支援期間宣告（例如 5 年）；依第 13(8) 條考量的因素，使用者期望、產品壽命、元件第三方支援、運作環境	Yes — CRA-specific commitment是，CRA 特有承諾
5. Applied standards	hEN list with OJEU reference; common specifications list; EUCC schemes applied; and where applicable, alternative-solution descriptions with mapping back to Annex I Parts I and II含 OJEU 引用的 hEN 清單；共通規範清單；已適用的 EUCC 機制；適用時，替代解決方案描述並對應至附件一第一、第二部分	Partial — hEN listing is standard; the Annex-I-mapping alternative-solutions narrative is new部分，hEN 列表標準；以附件一為對應的替代方案敘述為新

Three Article 31 details that change the engineering workload.

第 31 條三個會改變工程工作量的細節：

"Continuously updated, at least during the support period" (§2). This is the big difference from existing CE technical files. An EMC test report, once produced, rarely needs updating. A CRA technical file must track every software update, every change to the SBOM, every CVD policy revision. For a 5-year support period, that is five years of continuous maintenance on what used to be a write-once document. Document-control infrastructure — versioning, audit trail, change approval — becomes a hard requirement, not a nice-to-have.

「至少在 support period 內持續更新」（§2）。這是跟既有 CE 技術檔案最大的差別。EMC 測試報告一旦產出，很少需要更新。CRA 技術檔案必須追蹤每次軟體更新、每次 SBOM 變更、每次 CVD 政策修訂。5 年 support period 代表原本是一次性寫成的文件，要做 5 年持續維護。文件管制基礎建設，版本控制、稽核軌跡、變更核准，變成硬需求，不再是可有可無的。
Single consolidated file for Article 12 products (§3). When a product falls under both CRA and another EU regulation that also demands technical documentation — Machinery Regulation, Medical Devices Regulation, AI Act — the regulation requires one technical file covering all applicable regimes, not multiple parallel ones. This forces organisational alignment: CRA technical work must sit inside the same document system as AI Act or MDR technical work, not in a separate cybersecurity silo.

第 12 條產品的單一合併檔案（§3）。當一件產品同時受 CRA 跟其他也要求技術文件的歐盟法規（機械規章、MDR、AI Act）規範時，法規要求一份技術檔案涵蓋所有適用機制，不是多份平行。這逼出組織對齊：CRA 技術工作必須跟 AI Act 或 MDR 技術工作在同一個文件系統裡，不能自成一個網路安全 silo。
The language trap (§4). Technical documentation and correspondence with a notified body must be in an official language of the NB's Member State — or a language the NB accepts. In practice, English is almost always acceptable because NBs' designation scope is usually multilingual. But "almost always" is not "always", and formal submission of voluminous Annex VII content in French, German, or Italian is a genuine cost on APAC manufacturers used to operating in English. When picking a notified body, language policy goes in the shortlist criteria alongside capacity and price.

語言陷阱（§4）。技術文件跟對指定機構的通訊，必須用 NB 所在會員國的官方語言、或 NB 接受的語言。實務上英文幾乎都可以，因為 NB 的指定範圍通常是多語的。但「幾乎都」不等於「都」：正式提交大量附件七內容以法文、德文、義文，對習慣以英文運作的 APAC 製造商來說是實質成本。挑選指定機構時，語言政策要跟容量、價格一起列入篩選條件。

On the retention period: Article 31 itself does not specify how long the technical file must be kept. The 10-year retention that is often cited comes from elsewhere — Annex VIII (each module's "manufacturer keeps technical documentation for 10 years after placing on the market or for the support period, whichever is longer") and Article 28 for the EU Declaration of Conformity. If a manufacturer declares a 12-year support period, the retention floor is 12 years, not 10.

關於保存期間：第 31 條本身沒規定技術檔案要保存多久。常被引用的「10 年保存」來自別處：附件八（各 module 都規定「製造商在投入市場後或 support period（取較長者）保存技術文件 10 年」）跟第 28 條的 EU Declaration of Conformity。如果製造商宣告 12 年 support period，保存下限就是 12 年、不是 10 年。

Block 3 · APAC perspective 區塊 3 · APAC 觀點

The document-system problem APAC ODMs don't see coming APAC ODM 還沒看見的文件系統問題

Ask a Taiwan ODM to see their RED technical file and you typically get a PDF: a few hundred pages of test reports, a bill of materials, a block diagram, declarations from upstream component suppliers, a user manual. Static. Produced once per product model. Filed on a shared drive. Updated only when something fails in the field. This model works because RED, EMC and LVD are mostly snapshot regulations — what the product was at the moment of CE marking is what matters.

找一家台灣 ODM 看他們的 RED 技術檔案，你通常拿到的是一份 PDF：幾百頁測試報告、BOM、方塊圖、上游元件廠的聲明、使用者手冊。靜態。每個產品型號出一次。放在共用硬碟。只在現場出問題時才更新。這個模式可行，因為 RED、EMC、LVD 多半是快照型法規，產品在 CE 標示當下的樣子才是重點。

CRA is not a snapshot regulation. Annex VII sub-item 2(b) alone — the SBOM, CVD policy, evidence of contact address, secure-update distribution description — demands artefacts that change continuously. Over a 5-year support period a typical connected product will have dozens of firmware updates, new vulnerabilities disclosed against upstream components, changes to the published CVD contact. Every one of those changes needs to land in the technical file. Four practical consequences for APAC document systems.

CRA 不是快照型法規。光是附件七第 2(b) 項：SBOM、CVD 政策、聯絡地址證據、安全更新派送描述，就要求持續變動的成品。在 5 年 support period 中，典型聯網產品會有數十次韌體更新、上游元件新弱點揭露、已公開 CVD 聯絡人變動。每一次變動都要落到技術檔案裡。對 APAC 文件系統有四個實務後果：

SBOM tooling is not optional. Generating a CycloneDX or SPDX SBOM by hand every firmware release does not scale beyond a few SKUs. CI/CD integration of SBOM generation (Syft, cdxgen, Microsoft SBOM tool) is standard practice in the software world but still uncommon in APAC firmware teams that think of themselves as hardware manufacturers. The CRA technical file, in effect, pushes firmware teams into a software-engineering document lifecycle.

SBOM 工具鏈不是可選項。每次韌體發布都手動產出 CycloneDX 或 SPDX SBOM，幾個 SKU 以上就擴展不了。CI/CD 整合 SBOM 產生（Syft、cdxgen、Microsoft SBOM tool）在軟體業是標準實務，但在自認為是硬體製造商的 APAC 韌體團隊中還不普及。CRA 技術檔案實質上把韌體團隊推進軟體工程的文件生命週期。

Document storage must survive the support period plus 10 years. A product shipped in December 2027 with a 5-year support period creates a technical-file retention obligation that runs until at least December 2037 — a decade after the product itself is end-of-life. Shared-drive storage policies and ERP systems in APAC ODMs typically do not guarantee that kind of durability. A 10-year retention infrastructure decision — cloud archive, immutable storage, vendor independence — needs to be made once and held steady.

文件儲存必須撐過 support period 加 10 年。2027 年 12 月出貨、5 年 support period 的產品，技術檔案的保存義務至少到 2037 年 12 月，比產品本身 EOL 晚 10 年。APAC ODM 的共用硬碟儲存政策跟 ERP 系統通常無法保證這種持久性。10 年保存的基礎建設決策，雲端封存、不可變儲存、供應商獨立性，必須做一次決定、穩定維持下去。

Supplier documentation flow needs structural redesign. Annex VII risk assessment and vulnerability-handling items depend on upstream data — chipset vendor's security datasheets, OS distribution's CVE feeds, third-party middleware SBOMs. APAC OEMs have historically managed this via e-mail and PDF attachments. CRA turns it into a regulated upstream-to-downstream information chain where every supplier must provide what flows into the customer's technical file. Contract language with upstream suppliers needs to name specific CRA artefacts (SBOM, vulnerability contact, support commitment horizon) rather than generic "compliance with applicable regulations" clauses.

供應商文件流要結構性重新設計。附件七的風險評估跟弱點處理項次依賴上游資料，晶片廠安全 datasheet、作業系統發行版的 CVE feed、第三方中介軟體 SBOM。APAC OEM 過去用 email 跟 PDF 附件管理這些。CRA 把它變成受規管的「上游到下游資訊鏈」，每個供應商都必須提供會進入客戶技術檔案的內容。跟上游供應商的合約條款，要具名指出特定 CRA 成品（SBOM、弱點聯絡人、支援承諾期限），不是泛泛的「符合適用法規」。

The SME simplified form is real but not a free pass. Article 33(5) authorises the Commission to specify a simplified Annex VII form for microenterprises and small enterprises. As of early 2026, the Commission implementing act specifying this simplified form has not been adopted. When it arrives, it will reduce documentation burden for genuine SMEs but will not let a large APAC ODM operating through a small EU sales entity shrink the technical file — "microenterprise" and "small enterprise" definitions under Recommendation 2003/361/EC look at global group turnover and headcount, not the EU sales entity alone.

SME 簡化表式真實存在，但不是免死金牌。第 33(5) 條授權執委會訂定微型跟小型企業的簡化附件七表式。截至 2026 年初，執委會還沒採納這個簡化表式的 implementing act。推出後會減輕真正 SME 的文件負擔，但不會讓透過小型歐盟銷售實體運作的大型 APAC ODM 縮小技術檔案，Recommendation 2003/361/EC 下「微型」跟「小型」企業的定義看的是集團全球營業額跟人數，不是只看歐盟銷售實體。

Block 4 · Cross-regulation map 區塊 4 · 跨法規對照

How Annex VII lines up with other EU technical files 附件七與其他歐盟技術檔案的對應

Two layers, kept separate. Other EU product regulations come with their own technical-file annexes — these are legal instruments parallel to the CRA. International process standards are a different category — voluntary references that shape how engineering work is documented but are not legal sources themselves.

分兩層談、不要混。其他歐盟產品法規各自有技術檔案附件，這些是跟 CRA 平行的法律工具。國際流程標準是不同類別，voluntary 的參考，塑造工程記錄方式、但本身不是法源。

Layer 1 · Technical-file annexes in peer EU regulations 層級一・其他歐盟法規的技術檔案附件

Each is itself a legal instrument with its own technical-documentation annex. APAC manufacturers already filing under one of these can identify reusable content for the CRA file.

每一部本身都是法律工具、各帶技術文件附件。已經依其中一部歸檔的 APAC 製造商，可以從中辨識出 CRA 檔案能重用的內容。

Regulation / Annex法規 / 附件	Content scope內容範圍	Overlap with CRA Annex VII與 CRA 附件七的對應關係
RED Directive 2014/53/EU, Annex V Technical documentation for radio equipment無線電設備技術文件	Product description, design/development, risk assessment, applied standards, test reports. Cybersecurity coverage via RED DA 2022/30 until 11 Dec 2027.產品描述、設計 / 開發、風險評估、所採標準、測試報告。網路安全涵蓋至 2027/12/11 前依 RED DA 2022/30。	Significant overlap in product description (Annex VII item 1) and applied-standards list (item 5). CRA-novel items 2(b) vulnerability handling, 3 risk assessment, 4 support period have no RED equivalent.產品描述（附件七項次 1）跟所採標準清單（項次 5）有顯著重疊。CRA 新增的項次 2(b) 弱點處理、3 風險評估、4 支援期間在 RED 沒對應。
Machinery Regulation (EU) 2023/1230, Annex IV Technical documentation for machinery機械的技術文件	Description of machinery, drawings, risk assessment, applied standards, protective measures. Cybersecurity treated as part of safety where digital controllers are present.機械描述、圖紙、風險評估、所採標準、防護措施。具數位控制器時，網路安全當作安全的一部分。	Overlap on risk assessment methodology (item 3). Machinery Regulation risk assessment is safety-centred; CRA Annex VII risk assessment is cybersecurity-centred — they are not interchangeable but may share threat-model foundations.風險評估方法論（項次 3）有重疊。機械規章的風險評估以安全為中心；CRA 附件七的風險評估以網路安全為中心，不可互換、但可能共享威脅模型基礎。
AI Act (EU) 2024/1689, Annex IV Technical documentation for high-risk AI systems高風險 AI 系統技術文件	General description; data and data governance; training methodology; cybersecurity measures per Article 15; post-market monitoring. 9 top-level items.一般描述；資料與資料治理；訓練方法論；依第 15 條的網路安全措施；上市後監控。9 個主要項目。	CRA Article 31(3) requires a single consolidated technical file when both CRA and AI Act apply. Cybersecurity measures (AI Act Annex IV item 2(h)) map onto CRA Annex VII items 2(b) and 3. Data governance, training methodology and AI-specific items have no CRA counterpart.CRA 第 31(3) 條要求 CRA 跟 AI Act 同時適用時產出單一合併技術檔案。網路安全措施（AI Act 附件四項次 2(h)）對應 CRA 附件七項次 2(b) 跟 3。資料治理、訓練方法論、AI 特定項次在 CRA 沒對應。
Medical Devices Regulation (EU) 2017/745, Annex II Technical documentation for medical devices醫療器材技術文件	Device description, intended purpose, design information, GSPR compliance, risk management per ISO 14971, cybersecurity per MDCG 2019-16. Very extensive.器材描述、預期用途、設計資訊、GSPR 符合性、依 ISO 14971 的風險管理、依 MDCG 2019-16 的網路安全。極詳盡。	Medical devices are out of CRA scope per CRA Article 2(2)(a)-(b). No overlap in obligations. Medical device manufacturers continue under MDR; cybersecurity is handled via IEC 81001-5-1 and MDCG guidance, not CRA Annex VII.醫療器材依 CRA 第 2(2)(a) 到 (b) 條排除在 CRA 範圍外。義務沒重疊。醫療器材製造商繼續依 MDR；網路安全透過 IEC 81001-5-1 跟 MDCG 指引處理，不走 CRA 附件七。

Layer 2 · International process standards (voluntary, structural input) 層級二・國際流程標準（voluntary，結構輸入）

Voluntary international standards. Not laws, not (yet) cited as CRA hENs — but their process language can be mapped onto Annex VII sub-items. Useful internal scaffolding; not a CRA legal route by themselves.

voluntary 國際標準。不是法律、目前也還沒被引用為 CRA hEN：但它們的流程語言可以對應到附件七子項次。可作為內部架構使用；本身不是 CRA 法律路徑。

Standard標準	Content scope內容範圍	Mapping to CRA Annex VII與 CRA 附件七的對應
ISO/IEC 15288 & 12207 Systems and software engineering — lifecycle processes系統與軟體工程，生命週期流程	Process frameworks for full lifecycle documentation. Voluntary; adopted as baseline by many industries.全生命週期文件的流程框架。voluntary；許多產業採用為基線。	Useful internal scaffolding for Annex VII item 2 (design / development / production). ISO/IEC 15288 process artefacts can be mapped to Annex VII sub-items, reducing duplicate work. Not itself a presumption-of-conformity route.對附件七項次 2（設計 / 開發 / 生產）有用的內部架構。ISO/IEC 15288 流程產出可對應到附件七子項次、減少重複作業。本身不是合規推定路徑。
IEC 62443-4-1 prAA:2026 Secure product development lifecycle requirements安全產品開發生命週期要求	Under revision as EN IEC 62443-4-1 prAA:2026. Defines 47 practices across eight categories (security management, specification, design, implementation, verification, defect management, security update management, security guidelines).修訂中、現為 EN IEC 62443-4-1 prAA:2026。定義八類共 47 項實務（安全管理、規範、設計、實作、驗證、缺陷管理、安全更新管理、安全指引）。	Strong fit with Annex VII item 2(b) vulnerability handling and item 2(c) production/monitoring. Whether it becomes a CRA hEN is not yet confirmed in the Official Journal. Treat as informative input, not as a presumption-of-conformity path.跟附件七項次 2(b) 弱點處理及 2(c) 生產 / 監控強配合。是否成為 CRA hEN 還沒在官方公報確認。當作參考輸入、不當合規推定路徑。