程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖

Code-Induced Semantic Graph: A Program Graph Derived from Implementation Rather Than Design

系列： 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）
篇次： Paper 02
版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-14
狀態： 理論與工程規格初稿

公司： 一言諾科技有限公司

摘要

軟體工程長期使用架構圖、模組圖、控制流程圖、呼叫圖、資料流程圖與依賴圖描述程式結構。然而，這些圖多半具有單一目的，而且其中相當一部分來自設計者、維護者或工具對程式的局部描述。它們可以非常有用，卻不必然等於「目前程式實際上形成的全域結構」。

本文提出「程式碼誘導語義圖」（Code-Induced Semantic Graph, CISG），將其定義為：直接由可驗證程式實作、靜態分析結果、必要時加上執行觀測所誘導出的具型別、多關係、可追溯程式圖。 CISG 不把 repository 的檔案樹、人工架構說明或自然語言文件視為其權威本體，而要求每一個節點與關係都具有明確的來源證據、解析狀態、語義類型與信心層級。

本文區分意圖／設計圖 $G_I$ 、程式碼誘導語義圖 $G_C$ 與執行實現圖 $G_R$ ，並主張 CISG 的主要功能不是提供另一張視覺化圖，而是將「目前程式實際實現了什麼」轉換成可供演算法直接操作的結構層。本文提出 CISG 的 typed graph 模型、證據契約、未知邊界原則、解析度模型、局部與全域一致性要求，以及從 repository 建構 CISG 的參考流程。本文亦說明 CISG 如何成為程式底空間反演、結構缺陷檢測、功能 motif、跨語言正規化、變更影響分析與三圖一致性研究的共同中介層。

本文的核心主張是：

架構圖描述「我們認為系統應如何組織」；CISG 描述「目前可由實際程式證據支持的系統結構」。

關鍵詞

CISG、Code-Induced Semantic Graph、程式碼誘導語義圖、程式節點圖、程式底空間、靜態分析、程式本體反演、語義圖、程式理解、證據圖、全域程式分析、架構漂移、RepoLumen

一、問題的提出

1.1 軟體已有很多圖，為什麼還需要 CISG

現代軟體工程並不缺少圖。

常見表示包括：

architecture diagram；
module dependency graph；
call graph；
control-flow graph；
data-flow graph；
class diagram；
package graph；
state machine；
deployment graph；
execution trace。

因此，若 CISG 只是將以上內容重新畫在同一張圖上，它沒有足夠的新意。

CISG 的差異不在於「圖」本身，而在於來源與權威性。

傳統人工架構圖通常具有：

G_{\mathrm{arch}} = f(\text{設計文件},\text{維護者理解},\text{抽象需求})

而 CISG 要求：

G_C = \rho(C)

其中：

$C$ ：實際存在的程式實作；
$\rho$ ：可追溯分析與反演程序；
$G_C$ ：由實作誘導出的語義圖。

因此：

\boxed{ \text{CISG 不是先畫圖再對程式做解釋，而是先分析程式，再讓圖由程式證據生成。} }

1.2 設計真相與實作真相

在理想專案中：

G_I \approx G_C

其中：

$G_I$ ：設計者或需求所宣稱的結構；
$G_C$ ：實作實際形成的結構。

但大型專案長期演化後常出現：

G_I \neq G_C

例如：

文件宣稱 A 模組不依賴 B，實際上已經存在隱性呼叫；
設計宣稱某服務是 leaf，實際上它已形成新的 orchestration role；
原本只允許單向依賴，實作卻累積出 cycle；
某功能已被移除，但其 dead path 仍存在；
某邊界理論上應封閉，實作中卻有跨層 effect。

因此，若要分析：

\Delta_{IC} = d(G_I,G_C)

首先必須有一個不依賴 $G_I$ 的實作圖。

CISG 即服務於此目的。

二、CISG 的基本定義

2.1 定義

定義一個 CISG：

G_C = ( V, E, T_V, T_E, A, Q, \Gamma )

其中：

$V$ ：節點集合；
$E$ ：關係集合；
$T_V$ ：節點型別系統；
$T_E$ ：邊型別系統；
$A$ ：節點與邊的屬性；
$Q$ ：解析狀態、信心與不確定性；
$\Gamma$ ：來源、證據與版本追溯結構。

CISG 不要求：

G_C

是一張簡單有向圖。

更合理的實作可能是：

\text{typed directed multigraph}

甚至：

\text{hypergraph}

因為一個語義關係可能同時涉及：

多個輸入；
一個狀態區域；
一個 effect boundary；
一個控制條件；
一組輸出。

2.2 CISG 的最小條件

一個圖若要被稱為 CISG，至少應滿足：

條件一：實作誘導

節點與邊必須由實際程式實作、編譯產物或可驗證執行觀測產生。

條件二：來源可追溯

每一個 substantive node／edge 應可以追溯至：

\text{repository} + \text{revision} + \text{path} + \text{location}

或其他等價證據。

條件三：類型顯式

不可只表示：

v_i \rightarrow v_j

還應說明關係是：

calls；
imports；
controls；
reads；
writes；
contains；
aliases；
effects；
transitions；
depends-on。

條件四：未知顯式

未知關係不得被補成假確定邊。

條件五：分析與敘事分離

自然語言解釋可以依 CISG 產生，但自然語言本身不得反向偷偷成為 verified graph fact。

三、節點系統

3.1 結構節點

定義：

V_{\mathrm{struct}}

可包括：

repository；
package；
module；
namespace；
class；
function；
method；
lexical block。

這些節點主要表示程式的結構分區。

3.2 計算節點

定義：

V_{\mathrm{op}}

包括可被抽象為運算的單元，例如：

arithmetic；
comparison；
conversion；
allocation；
hash；
parse；
serialize；
deserialize；
query；
transform；
validate。

若某個語言表面寫成：

hashlib.sha256(x).hexdigest()

CISG 可以選擇將其正規化成：

\operatorname{SHA256} \rightarrow \operatorname{HEX}

從而降低對特定語法拼寫的依賴。

3.3 控制節點

定義：

V_{\mathrm{ctrl}}

例如：

branch；
loop；
exception handler；
early return；
match；
retry；
synchronization barrier。

傳統 CFG 通常已可表達大量控制關係，CISG 的工作不是取代 CFG，而是將其納入更高層 typed graph。

3.4 狀態節點

定義：

V_{\mathrm{state}}

包括：

object state；
field；
cache；
database state；
configuration；
session；
queue；
file state；
shared mutable region。

程式不只是函式互相呼叫，也是不斷對狀態進行：

S_t \rightarrow S_{t+1}

的轉換。

如果 CISG 完全沒有 state representation，它通常只能得到程式結構的一個表面近似。

3.5 效果與邊界節點

定義：

V_{\mathrm{effect}}

與：

V_{\mathrm{boundary}}

例如：

network；
filesystem；
database；
subprocess；
clock；
random source；
OS；
user input；
external API。

CISG 應明確區分：

\text{local resolved target}

與：

\text{external / unresolved boundary}

因為：

\text{不知道目標} \neq \text{沒有目標}

四、邊型別系統

4.1 結構邊

例如：

\operatorname{contains}(A,B)

表示 $B$ 位於 $A$ 的結構範圍內。

另可有：

\operatorname{inherits}

\operatorname{implements}

\operatorname{declares}

4.2 呼叫與依賴邊

定義：

\operatorname{calls}(u,v)

表示存在可支持的靜態或動態呼叫關係。

但：

\operatorname{imports}(u,v)

不得自動被視為：

\operatorname{calls}(u,v)

因為 import 表示結構可見性或依賴，不等同於實際執行。

因此：

E_{\mathrm{dependency}} \neq E_{\mathrm{execution}}

是 CISG 的重要原則。

4.3 控制邊

例如：

\operatorname{controls}(b,x)

表示控制節點 $b$ 決定 $x$ 是否可達。

可進一步區分：

\operatorname{true\_branch}

\operatorname{false\_branch}

\operatorname{exception\_branch}

\operatorname{loop\_back}

4.4 資料邊

例如：

\operatorname{defines}(a,x)

\operatorname{uses}(b,x)

\operatorname{flows}(x,y)

若引入 SSA，可進一步將：

x

分成：

x_1,x_2,\ldots,x_n

以表示資料版本。

4.5 狀態與效果邊

例如：

\operatorname{reads}(f,S)

\operatorname{writes}(f,S)

\operatorname{mutates}(f,S)

\operatorname{emits}(f,E)

這些邊使 CISG 可以處理單純 call graph 無法描述的問題：

兩個函式即使沒有互相呼叫，也可能因共享狀態而高度耦合。

五、證據契約

5.1 圖不可以失去來源

CISG 中的每一個 verified object 應附帶 provenance。

最低可表示為：

\Gamma(x) = ( r, p, l_s, l_e, m, h )

其中：

$r$ ：revision；
$p$ ：path；
$l_s$ ：start line；
$l_e$ ：end line；
$m$ ：analysis method；
$h$ ：source hash 或其他完整性資訊。

因此，一條邊不只是：

u\rightarrow v

而是：

(u,v,\tau,\Gamma)

5.2 來源完整性閘門

若分析來源本身不能被確認，就不能把後續結果標成 verified。

因此 CISG 建構流程應允許：

\operatorname{VerifySource}(C,r) \rightarrow \{\text{valid},\text{invalid},\text{unknown}\}

例如可使用：

Git blob hash；
commit hash；
signed artifact；
content fingerprint。

這不是附帶功能，而是 graph authority 的前置條件。

5.3 證據與解釋分離

定義 graph fact：

g

與 explanation：

e

應滿足：

e \xrightarrow{\operatorname{grounded\_by}} g

而不是：

e \Rightarrow g

也就是：

解釋可以引用結構，但解釋本身不能自動製造結構。

六、解析狀態與不確定性

6.1 四種最小狀態

本文建議至少區分：

Q = \{ \text{observed}, \text{strongly inferred}, \text{weakly inferred}, \text{unresolved} \}

另可加入：

\text{author claimed}

以保存文件敘述，但不得與 implementation evidence 混同。

6.2 未解析不是失敗

若存在：

dynamic_call(x)

而靜態分析無法唯一決定 target，CISG 應建立：

v \xrightarrow{\mathrm{calls?}} B_{\mathrm{unresolved}}

而不是任意選一個候選。

因此：

\boxed{ \text{Unknown edge is first-class information.} }

6.3 信心不是機率真理

可以為每個 node／edge 設：

q\in[0,1]

但這個值表示：

在指定分析方法與證據條件下的可信度。

它不應被解釋為：

此語義在宇宙中為真的客觀概率。

七、CISG 與 Architecture Graph 的根本差異

7.1 Architecture Graph

典型來源：

G_I = f( \text{requirements}, \text{design}, \text{documents}, \text{human abstraction} )

它主要回答：

系統應該如何被理解或組織？

7.2 CISG

來源：

G_C = \rho(C)

它主要回答：

現在的實作可被證據支持地還原成什麼結構？

7.3 二者都必要

本文不主張：

G_C > G_I

因為 $G_I$ 包含程式碼中可能無法恢復的意圖與設計規則。

更合理的是：

G_I \leftrightarrow G_C

並研究：

\Delta_{IC} = d(G_I,G_C)

這個差異本身可能揭示：

architecture drift；
missing implementation；
undocumented coupling；
dead design；
hidden dependency。

八、多解析度 CISG

8.1 為什麼不能永遠顯示所有節點

若 repository 有：

10^6

個低階節點，直接顯示整張圖沒有實用價值。

因此 CISG 必須支援 coarse-graining。

定義：

\pi_k : G_C \rightarrow G_C^{(k)}

其中 $k$ 表示解析度。

8.2 建議解析度

$R_0$ ：功能域

例如：

authentication；
history；
cache；
storage；
orchestration。

$R_1$ ：模組域

顯示 module／package 與主要 dependency。

$R_2$ ：symbol 域

顯示 function／class／method。

$R_3$ ：control／state 域

顯示 branch、state、data dependency、effect。

$R_4$ ：source evidence

回到實際 code span。

因此：

R_0 \leftarrow R_1 \leftarrow R_2 \leftarrow R_3 \leftarrow R_4

但各層不應以「上一層摘要」作為唯一來源。

每一層都應能回到共同 evidence base。

九、CISG 建構流程

本文提出第一版參考流程：

C \rightarrow V_0 \rightarrow E_0 \rightarrow N \rightarrow R \rightarrow G_C

其中：

$V_0$ ：原始節點抽取；
$E_0$ ：原始關係抽取；
$N$ ：語義正規化；
$R$ ：target resolution；
$G_C$ ：最終 typed graph。

具體步驟如下。

9.1 Source verification

確認：

revision；
hash；
path；
encoding。

9.2 Parse

建立：

AST；
scope；
symbol table。

9.3 Structural extraction

取得：

module；
class；
function；
lexical block。

9.4 Relation extraction

取得：

import；
call；
control；
read/write；
effects。

9.5 Resolution

將可能的 target 分成：

\text{local resolved}

\text{external resolved}

\text{ambiguous}

\text{unresolved}

9.6 Normalization

將語言表面的不同形式映射到 canonical relation。

9.7 Evidence attachment

每個 node／edge 綁定 provenance。

9.8 Graph validation

檢查：

dangling node；
invalid target；
evidence loss；
duplicate identity；
illegal type pair。

十、CISG 的形式約束

10.1 邊的型別合法性

定義合法關係：

\mathcal R \subseteq T_V \times T_E \times T_V

例如：

(\text{function},\text{calls},\text{function}) \in \mathcal R

但：

(\text{constant},\text{imports},\text{branch}) \notin \mathcal R

除非模型明確允許該語義。

10.2 證據完整性

對 verified node $v$ ：

Q(v)=\text{observed}

則必須有：

\Gamma(v)\neq\varnothing

對 verified edge $e$ ：

Q(e)=\text{observed}

同樣要求：

\Gamma(e)\neq\varnothing

10.3 不確定性保留

若 target resolution 為 ambiguous：

|\operatorname{Candidates}(e)|>1

則：

Q(e)\neq\text{observed-resolved}

除非存在額外證據消除歧義。

十一、第一個工程實驗：RepoLumen

本系列已完成一個早期 CISG PoC。

在 Git source hash 驗證後，對 RepoLumen 的一組核心 Python 檔案進行：

AST extraction；
symbol extraction；
call extraction；
control extraction；
state-write hint；
effect-boundary hint；
local target resolution。

得到：

|V|=182

以及：

|E|=334

此數字本身不具有理論特殊性；重要的是圖不是從 README 或人工 architecture design 建立，而是由實際程式來源生成。

初步圖已能顯示：

function 到 function 的 local resolved calls；
module dependency；
lexical containment；
control nodes；
state mutation hints；
external／unresolved boundaries。

這使：

\text{Repository} \rightarrow \text{Evidence-Grounded Program Graph}

在有限範圍內得到工程驗證。

十二、CISG 作為演算法輸入

CISG 的真正價值不是顯示，而是計算。

12.1 結構缺陷

定義 detector：

D : G_C \rightarrow \Delta

其中 $\Delta$ 可以包含：

cycle；
unreachable；
orphan；
illegal dependency；
unresolved boundary；
state conflict；
effect leak。

12.2 Change impact

對變更節點：

v

可以研究：

\operatorname{Reach}^{+}(v)

與：

\operatorname{Reach}^{-}(v)

分別表示 outbound 與 inbound 影響域。

12.3 功能 motif

定義：

M_k \subseteq G_C

若多個 repository 出現結構相似的子圖：

G_1[S_1] \sim G_2[S_2]

則可以將其作為候選功能基元。

12.4 Architecture conformance

若已有：

G_I

則可以計算：

\Delta_{IC} = d(G_I,G_C)

形成機械化 architecture drift detection。

十三、CISG 與程式底空間

Paper 01 定義：

B_{\mathrm{prog}}

作為程式關係的底空間。

本文中的：

G_C

則是一個具體實作在該底空間中的可觀測局部結構。

因此：

G_C \hookrightarrow \widehat{B}_{\mathrm{prog}}

而：

\widehat{B}_{\mathrm{prog}} \subseteq B_{\mathrm{prog}}

CISG 不是整個程式底空間，而是：

由具體程式實作所誘導出的、可被目前分析器觀測到的局部結構。

這個區分避免把「一張圖」誤稱為「完整本體」。

十四、與傳統靜態分析的關係

CISG 的大量底層能力並非憑空創造。

它依賴既有方法：

AST；
symbol resolution；
control-flow analysis；
data-flow analysis；
SSA；
alias analysis；
points-to analysis；
call graph；
effect analysis；
program slicing。

因此 CISG 的新主張不是：

以前沒有程式分析。

而是：

將多種分析結果整合成一個具共同 identity、共同 provenance、共同 uncertainty contract 的全域 typed semantic graph，並將其提升為後續程式理解與本體反演的 canonical intermediate knowledge layer。

十五、限制

目前 CISG 至少存在以下限制。

15.1 動態語言

reflection、monkey patch、dynamic dispatch 會降低 target resolution。

15.2 Runtime-generated behavior

執行時生成程式碼可能不在靜態 CISG 中。

15.3 外部世界

database、network、OS、hardware 等只能以 boundary 表示，除非有額外觀測。

15.4 Graph explosion

若把每個 expression 都展開為 node，圖規模可能快速膨脹。

15.5 語義正規化

不同語言與 framework 如何映射到共同 operation set，仍未解決。

15.6 作者意圖

CISG 只能描述實作結構，不自動等於作者意圖。

十六、可證偽條件

16.1 不可重現

若同一 revision 在同一 analyzer configuration 下無法穩定生成同一核心圖結構，CISG 不適合作為可信中介層。

16.2 provenance 不足

若大量 substantive edges 不能回指程式證據，那麼圖可能只是另一種推測式 architecture generation。

16.3 不確定性被抹除

若 unresolved／ambiguous targets 被強行解析，則 CISG 失去 epistemic reliability。

16.4 無跨分析整合價值

若將 AST、CFG、call graph 等合併後，完全不能產生新的可計算能力，則 CISG 只能被視為視覺整合格式，而非新的 program knowledge layer。

十七、工程規格草案

CISG v0.1 的最小 schema 可概念表示為：

{
  "graph_version": "cisg-0.1",
  "repository": {
    "source": "...",
    "revision": "...",
    "source_integrity": "verified"
  },
  "nodes": [
    {
      "id": "...",
      "type": "function",
      "semantic_role": null,
      "confidence": 1.0,
      "status": "observed",
      "evidence_ids": ["..."]
    }
  ],
  "edges": [
    {
      "id": "...",
      "type": "calls",
      "source": "...",
      "target": "...",
      "resolution": "local",
      "confidence": 0.98,
      "status": "observed",
      "evidence_ids": ["..."]
    }
  ],
  "evidence": [
    {
      "id": "...",
      "path": "...",
      "start_line": 1,
      "end_line": 5,
      "revision": "...",
      "source_hash": "..."
    }
  ],
  "uncertainty": []
}

實際 schema 可比此更複雜，但最低要求是：

\text{Graph} + \text{Evidence} + \text{Uncertainty}

必須同時存在。

十八、研究路線

Paper 03 將進一步研究：

\rho_L : C_L \rightarrow \widehat{P^\ast}

本身的性質。

核心問題包括：

哪些結構可反演；
哪些結構只能推論；
如何估計反演覆蓋率；
如何區分 implementation truth 與 author intent；
如何加入 runtime observation；
如何定義 ontology reconstruction error。

因此 Paper 02 建立的是：

\boxed{ \text{反演結果的共同結構容器} }

而 Paper 03 才研究：

\boxed{ \text{反演本身} }

十九、核心命題

本文提出以下七個核心命題。

命題 1：實作誘導命題

G_C = \rho(C)

CISG 的權威來源是實際實作，而非人工架構描述。

命題 2：證據依附命題

對 substantive graph object $x$ ：

Q(x)=\text{observed} \Rightarrow \Gamma(x)\neq\varnothing

命題 3：關係型別命題

程式關係不可退化成單一 generic edge。

T_E

是 CISG 的必要部分。

命題 4：未知顯式命題

\text{unresolved} \neq \text{absent}

未知本身必須被保存。

命題 5：多解析度命題

同一 CISG 應允許：

\pi_k(G_C)

形成不同解析度，而不丟失回到共同證據的能力。

命題 6：分析優先於視覺命題

CISG 首先是：

\text{machine-operable structure}

其次才是視覺化介面。

命題 7：圖非本體命題

G_C \neq P^\ast

CISG 是程式本體的可觀測實作近似，而不是完整本體本身。

二十、結論

本文提出「程式碼誘導語義圖」CISG，作為由實際程式實作直接誘導出的 typed、evidence-grounded、uncertainty-aware program graph。

它與人工架構圖最大的差異不是畫法，而是權威來源：

G_I = f(\text{Design})

而：

G_C = \rho(\text{Implementation})

因此，CISG 可以成為：

程式底空間反演的結構容器；
repository 全域分析層；
Bug 與 anomaly detector 的輸入；
功能 motif 抽取基礎；
architecture drift 的實作側錨點；
跨語言 normalization 的比較對象；
runtime graph 對照的靜態基線。

最終，本系列希望將 repository 的主要視圖由：

\boxed{ \text{Files} \rightarrow \text{Code} }

逐步提升為：

\boxed{ \text{Program Relations} \rightarrow \text{Evidence} \rightarrow \text{Executable / Verifiable Structure} }

若此路線成立，那麼「程式節點圖」就不再只是方便人類觀看的圖形介面，而會成為程式本身的一個可計算、可追溯、可驗證的知識層。

參考與前置理論

Neo.K，《程式底空間：從原始碼表徵到計算關係的存在層》，PBSOI Paper 01。
Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
Neo.K，《多重投影程式論：原始碼不再是程式本體》。
Neo.K，《程式語言設計風格的多軸形態空間》。
Neo.K，《基本計算單位的歷史轉換：從指令、函數到張量、意圖與世界狀態》。
Neo.K，《空間狀態論：異質底空間、嵌套尺度與空間改寫算子的統一方法論》。
EveMissLab，RepoLumen / Repo Semantic Teaching Layer v0.10。
EveMissLab，CISG RepoLumen PoC v0.1。

程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖

程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖

摘要

關鍵詞

一、問題的提出

1.1 軟體已有很多圖，為什麼還需要 CISG

1.2 設計真相與實作真相

二、CISG 的基本定義

2.1 定義

2.2 CISG 的最小條件

條件一：實作誘導

條件二：來源可追溯

條件三：類型顯式

條件四：未知顯式

條件五：分析與敘事分離

三、節點系統

3.1 結構節點

3.2 計算節點

3.3 控制節點

3.4 狀態節點

3.5 效果與邊界節點

四、邊型別系統

4.1 結構邊

4.2 呼叫與依賴邊

4.3 控制邊

4.4 資料邊

4.5 狀態與效果邊

五、證據契約

5.1 圖不可以失去來源

5.2 來源完整性閘門

5.3 證據與解釋分離

六、解析狀態與不確定性

6.1 四種最小狀態

6.2 未解析不是失敗

6.3 信心不是機率真理

七、CISG 與 Architecture Graph 的根本差異

7.1 Architecture Graph

7.2 CISG

7.3 二者都必要

八、多解析度 CISG

8.1 為什麼不能永遠顯示所有節點

8.2 建議解析度

R0R_0R0​：功能域

R1R_1R1​：模組域

R2R_2R2​：symbol 域

R3R_3R3​：control／state 域

R4R_4R4​：source evidence

九、CISG 建構流程

9.1 Source verification

9.2 Parse

9.3 Structural extraction

9.4 Relation extraction

9.5 Resolution

9.6 Normalization

9.7 Evidence attachment

9.8 Graph validation

十、CISG 的形式約束

10.1 邊的型別合法性

10.2 證據完整性

10.3 不確定性保留

十一、第一個工程實驗：RepoLumen

十二、CISG 作為演算法輸入

12.1 結構缺陷

12.2 Change impact

12.3 功能 motif

12.4 Architecture conformance

十三、CISG 與程式底空間

十四、與傳統靜態分析的關係

十五、限制

15.1 動態語言

15.2 Runtime-generated behavior

15.3 外部世界

15.4 Graph explosion

15.5 語義正規化

15.6 作者意圖

十六、可證偽條件

16.1 不可重現

16.2 provenance 不足

16.3 不確定性被抹除

16.4 無跨分析整合價值

$R_0$ ：功能域

$R_1$ ：模組域

$R_2$ ：symbol 域

$R_3$ ：control／state 域

$R_4$ ：source evidence