# NOVA–ISQL Native Program Graph（NIPG）架構規格 v0.1

**NOVA–ISQL Native Program Graph Architecture**

**版本：** v0.1  
**作者：** Neo.K  
**機構：** EveMissLab  
**日期：** 2026-09-16  
**狀態：** Architecture Draft / Native Program Graph Contract

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

---

## 0. 背景

現有 PBSOI / CISG 的核心問題是：

> 當權威程式物件是傳統 Source Code 時，如何從實作中反演出真正的程式結構？

因此：

$$
C_L
\xrightarrow{\rho_L}
G_{\mathrm{CISG}}
$$

其中 $C_L$ 是某種語言的 Source Projection。

但 NOVA 與 ISQL-M 的方向不同。

NOVA-Core-Closure 已明確定義：

$$
\boxed{
\text{Canonical Program}
=
\text{Typed Structural Graph}
}
$$

NOVA-Language 也保留：

$$
\boxed{
\text{Program Authority}
=
\text{Typed Structural Machine Object}
}
$$

Human-readable source、graph view、AI transaction 與 foreign-language bridge 都只是 projection / authoring surface。

因此，若仍使用 CISG 作為 NOVA 的主要程式圖，就會產生本體方向倒置：

$$
\text{Authoritative Graph}
\rightarrow
\text{Text Projection}
\rightarrow
\text{CISG Re-inference}
$$

這沒有必要。

NOVA / ISQL 的原生工作流應改為：

$$
\boxed{
P^\ast_{\mathrm{NOVA}}
\xrightarrow{\pi_{\mathrm{NIPG}}}
G_{\mathrm{NIPG}}
}
$$

其中 $P^\ast_{\mathrm{NOVA}}$ 本身就是權威 typed structural machine object。

---

# 一、NIPG 的定位

本文定義：

# **NOVA–ISQL Native Program Graph（NIPG）**

NIPG 是：

> **專供 AI、PSMR、工具鏈、跨系統語義查詢、修改規劃與驗證使用的原生程式媒介圖。**

它不是：

- NOVA canonical graph 的替代品；
- ISQL-M state object 的替代品；
- NOVA-Language compiler IR 的替代品；
- universal AST；
- universal ontology；
- SREG / NOVA equivalence layer。

核心原則：

$$
\boxed{
\text{NIPG}
\neq
\text{Program Authority}
}
$$

而是：

$$
\boxed{
\text{NIPG}
=
\text{Program Authority-aware Mediation Graph}
}
$$

---

# 二、與 CISG 的分工

## 2.1 CISG

對傳統程式：

$$
\boxed{
\text{Source}
\rightarrow
\text{Observed / Inferred Semantic Graph}
}
$$

其核心 epistemic 問題是：

> Source 真正表示了什麼？

---

## 2.2 NIPG

對 NOVA：

$$
\boxed{
\text{Canonical Structural Object}
\rightarrow
\text{Native Program Mediation Graph}
}
$$

其核心問題是：

> 權威程式物件如何被 AI / PSMR 查詢、連結、規劃、修改與驗證？

因此：

$$
\boxed{
G_{\mathrm{CISG}}
\neq
G_{\mathrm{NIPG}}
}
$$

但兩者可以在 PSMR Workspace 中建立 bridge。

---

# 三、NIPG 必須是 Multiplex Graph

NIPG 不應是一張扁平 node-edge graph。

定義：

$$
\boxed{
\mathcal G_N
=
(
V,
\{E_r\}_{r\in\mathcal R},
L,
P,
Q
)
}
$$

其中：

- $V$：semantic objects；
- $E_r$：typed relations；
- $L$：semantic layers；
- $P$：profile / authority bindings；
- $Q$：evidence / obligation / validation state。

因此同一個 program object 可以同時存在於不同層的關係中，而不需要合併 identity。

---

# 四、六個核心 Layer

第一版 NIPG 至少包含六個 Layer。

---

## 4.1 Identity / Address Layer

來源：

- ISQL-M；
- NOVA stable IDs；
- registry bindings。

包含：

```text
EntityIdentity
SubjectStateIdentity
SemanticAddress
RegistryBinding
RecordIdentity
ProjectionIdentity
VersionIdentity
```

核心區分：

$$
\boxed{
E
\neq
H
\neq
H_M
\neq
A
}
$$

其中：

- $E$：persistent entity identity；
- $H$：represented subject state；
- $H_M$：projection identity；
- $A$：semantic address。

---

## 4.2 Canonical Program Layer

來源：

- NOVA-Core-Closure；
- NOVA-Language machine object。

包含：

```text
Project
Module
Graph
Node
Value
Operator
Input
Output
ScopedSymbol
Type
ExternalContract
```

主要結構：

```text
Project
 └─ Module
     └─ Graph
         ├─ Node
         ├─ Value
         ├─ Constraint
         ├─ Effect
         └─ Output
```

---

## 4.3 Closure / Constraint Layer

包含：

```text
TensorType
Shape
ShapeConstraint
ShapeObligation
Effect
CompositionConstraint
OperatorClosure
BrokenOperator
SemanticObligation
BuildConstraint
ProofStatus
```

這一層回答：

> 哪些條件必須成立，這個 program object 才是合法、可執行或可組合的？

---

## 4.4 Transformation / Planning Layer

包含：

```text
GraphPatch
GraphTransaction
SemanticDelta
DifferentiationRequest
DerivativeGraph
MemoryPlan
ExecutionStrategyPlan
SemanticCandidateSet
SemanticCorrection
SemanticResolution
```

這一層回答：

> 程式如何從一個 canonical state 演化到另一個 state？

---

## 4.5 Projection / Authoring Layer

包含：

```text
HumanSourceProjection
StructuredProjection
GraphView
FormulaProjection
NotebookProjection
AITransaction
ForeignLanguageProjection
DiagnosticProjection
```

核心原則：

$$
\boxed{
\text{Projection}
\neq
\text{Authority}
}
$$

Source location、human name、display label 全部只屬於 projection/evidence。

---

## 4.6 Execution / Evidence Layer

包含：

```text
ExecutionPlan
BackendBinding
RuntimeValue
ExecutionTrace
TestEvidence
GradientCheck
ResourceVerification
BuildAudit
InteropEvidence
CorpusEvidence
```

此層回答：

> 這個 canonical program 在實際執行／驗證時發生了什麼？

---

# 五、第一版 Node Types

NIPG v0.1 建議至少定義下列 node family。

## Identity

```text
identity.entity
identity.state
identity.address
identity.registry
identity.projection
identity.version
```

## Program

```text
program.project
program.module
program.graph
program.node
program.value
program.operator
program.symbol
program.input
program.output
```

## Type / Domain

```text
type.tensor
type.scalar
type.shape
type.dimension
type.domain
type.external
```

## Constraint

```text
constraint.shape
constraint.effect
constraint.resource
constraint.composition
constraint.semantic
constraint.runtime
constraint.obligation
```

## Transformation

```text
transform.graph_patch
transform.transaction
transform.autodiff
transform.memory_plan
transform.execution_plan
transform.semantic_candidate
transform.semantic_correction
```

## Projection

```text
projection.human_source
projection.structured
projection.graph_view
projection.formula
projection.notebook
projection.ai_transaction
projection.foreign
```

## Evidence

```text
evidence.runtime
evidence.test
evidence.audit
evidence.provenance
evidence.validation
evidence.correspondence
```

---

# 六、第一版 Relation Types

NIPG relation 必須 typed。

---

## 6.1 Containment

```text
contains
member_of
declares
```

---

## 6.2 Data / Operator

```text
consumes
produces
input_of
output_of
applies_operator
```

---

## 6.3 Type / Shape

```text
has_type
has_shape
has_dimension
constrained_by
requires_obligation
discharges_obligation
```

---

## 6.4 Effect / Resource

```text
has_effect
requires_resource
owns
borrows
transfers_to
allocated_by
planned_by
```

---

## 6.5 Transformation

```text
patched_by
transforms_to
differentiates_to
lowered_to
planned_as
candidate_for
committed_from
rolled_back_to
```

---

## 6.6 Projection

```text
projects_to
projected_from
authored_through
diagnosed_by
```

---

## 6.7 Identity / Address

```text
identified_by
state_identity
addressed_by
registry_bound
version_of
```

---

## 6.8 Evidence

```text
observed_by
validated_by
tested_by
supported_by
derived_from
audited_by
```

---

## 6.9 Cross-System Correspondence

這一類最重要。

```text
corresponds_to
represented_by
representation_candidate
operator_family_candidate
domain_candidate
```

不得預設：

```text
equivalent_to
same_as
```

---

# 七、ISQL-M F15 對 NIPG 的直接要求

最新 ISQL-M F15 已經建立：

$$
\mathbb R^n
\rightsquigarrow
\operatorname{TensorType}
(
\texttt{f64},
[n],
\texttt{dense},
\texttt{cpu}
)
$$

但其明確聲明：

$$
\boxed{
\text{Representation Correspondence}
\neq
\text{Mathematical Type Equivalence}
}
$$

因此 NIPG 必須能表示：

```text
SREG Domain Node: R^n
        |
        | representation_candidate
        v
NOVA TensorType: f64[n]
```

並同時連接：

```text
validated_claim:
  rank_correspondence

validated_claim:
  dimension_symbol_correspondence

open_obligation:
  rounding_semantics_unproven

open_obligation:
  NaN/Inf_policy_unproven

open_obligation:
  value_domain_equivalence_unproven
```

所以：

$$
\boxed{
\text{Correspondence Edge}
+
\text{Open Obligations}
}
$$

必須是一級結構。

不能只留下：

```text
similarity = 0.97
```

---

# 八、NOVA Core Closure 對 NIPG 的直接要求

NOVA Core 已經具備：

- canonical graph identity；
- semantic hash / record hash；
- tensor / shape；
- runtime；
- GraphPatch；
- automatic differentiation；
- memory/resource planning；
- projection editing；
- AI-native graph construction；
- SOS operator closure；
- execution-paradigm planning；
- ISQL SemanticTensor bridge。

因此 NIPG 不能只是一張：

```text
function → calls → function
```

的 graph。

它必須至少保留：

$$
\boxed{
\text{Program}
+
\text{Type}
+
\text{Constraint}
+
\text{Effect}
+
\text{Resource}
+
\text{Transformation}
+
\text{Projection}
+
\text{Evidence}
}
$$

---

# 九、NOVA-Language 對 NIPG 的直接要求

NOVA-Language Practical Track 進一步加入：

```text
surface syntax
parser
resolver
compiler pipeline
runtime
backend
FFI / ABI
package
debugger
corpus engine
```

因此 NIPG 還需要 Practical Layer relations：

```text
parsed_from
resolved_to
normalized_to
lowered_to
backend_bound
ffi_bound
packaged_as
debug_projection
corpus_recorded_as
```

這些 relation 不屬於 canonical program ontology 本身，但屬於 practical software lifecycle。

---

# 十、NIPG 與 NOVA Canonical Graph 的關係

NOVA canonical graph：

$$
G_N^\ast
$$

是 program authority。

NIPG：

$$
G_M
$$

是 mediation projection。

因此：

$$
\boxed{
G_N^\ast
\neq
G_M
}
$$

但：

$$
G_M
=
\pi_M
(
G_N^\ast,
I,
C,
T,
X,
E,
P
)
$$

其中：

- $I$：identity state；
- $C$：constraints；
- $T$：transformations；
- $X$：execution state；
- $E$：evidence；
- $P$：projections。

---

# 十一、NIPG Identity Rule

每個 NIPG object 至少有：

```text
nipg_id
profile
upstream_system
upstream_id
upstream_revision
authority
semantic_hash
record_hash
```

若上游已有權威 identity：

$$
ID_{\mathrm{NOVA}}
$$

NIPG 不重新發明新的 ontology identity。

它只建立：

$$
ID_{\mathrm{NIPG}}
=
H(
\text{profile},
\text{upstream binding},
\text{projection contract}
)
$$

---

# 十二、NIPG Profile

第一版 profile：

```text
nipg/nova-isql-program/v0.1
```

其上游 profile 至少包含：

```text
isql-m
nova-core
nova-language
runtime
psmr
```

跨 profile equality：

$$
\boxed{
ID_p=ID_q
\not\Rightarrow
\text{Ontology Equality}
}
$$

---

# 十三、Canonical / Derived / Evidence 分離

每個 NIPG fact 必須標記：

```text
canonical
derived
projected
observed
inferred
claimed
unknown
conflicted
```

例如：

```text
NOVA Graph node
→ canonical

Human source name
→ projected

MemoryPlan candidate
→ derived / candidate

Execution trace
→ observed

ISQL-M domain mapping
→ correspondence evidence
```

---

# 十四、NIPG Graph Delta

因為 NOVA 本來就支援 GraphPatch，NIPG 修改不應退回 source diff。

定義：

$$
\Delta G_{\mathrm{NIPG}}
$$

其核心可以直接引用：

```text
NOVA GraphPatch
NOVA GraphTransaction
PSMR SemanticDelta
```

因此 AI-native path：

$$
\boxed{
\text{Intent}
\rightarrow
\Delta G_{\mathrm{NIPG}}
\rightarrow
\text{Candidate GraphPatch}
\rightarrow
\text{NOVA Validation}
\rightarrow
G_N^{\ast\prime}
}
$$

而不是：

$$
\text{Intent}
\rightarrow
\text{Text Patch}
\rightarrow
\text{Parser}
\rightarrow
G
$$

---

# 十五、NIPG Query Model

AI-facing query 建議：

```text
nipg.describe
nipg.search
nipg.subgraph
nipg.identity
nipg.constraints
nipg.obligations
nipg.effects
nipg.resources
nipg.projections
nipg.runtime_evidence
nipg.transform_history
nipg.correspondence
```

---

# 十六、NIPG Semantic Slice

對目標 object $x$：

$$
S(x)
=
(
I,
G,
T,
C,
E,
R,
P,
Q
)
$$

其中：

- $I$：identity；
- $G$：program neighborhood；
- $T$：type/domain；
- $C$：constraints；
- $E$：effects；
- $R$：resource/runtime；
- $P$：projections；
- $Q$：obligations/evidence。

這比單純：

```text
callers
callees
```

更適合 AI-native NOVA。

---

# 十七、NIPG 的三種 Impact

NIPG impact 至少分：

## Structural Impact

```text
graph topology
value dependencies
operator closure
```

## Semantic Constraint Impact

```text
type
shape
effect
obligation
domain correspondence
```

## Execution / Resource Impact

```text
runtime
memory
backend
device
FFI
execution strategy
```

所以：

$$
\boxed{
\text{NIPG Impact}
\neq
\text{Traditional Call Graph Impact}
}
$$

---

# 十八、NIPG 與 PSMR

PSMR 將同時容納：

```text
CISG Provider
NIPG Provider
Schema Provider
Intent Provider
Runtime Provider
```

對傳統程式：

$$
\text{Source}
\rightarrow
CISG
\rightarrow
PSMR
$$

對 NOVA：

$$
\text{NOVA Canonical Object}
\rightarrow
NIPG
\rightarrow
PSMR
$$

因此：

$$
\boxed{
\text{PSMR}
=
\text{multi-program-ontology mediation runtime}
}
$$

而不是只能理解傳統 source code。

---

# 十九、NIPG 與 ISQL-M Structural Witness

ISQL-M Structural Witness：

$$
W
=
\langle
p,
B,
K,
E
\rangle
$$

可以成為 NIPG 中的：

```text
evidence.structural_witness
```

但：

$$
\boxed{
\text{Structural Witness}
\neq
\text{NIPG Program Node}
}
$$

Witness 提供 bridge / evidence。

NIPG 保留 program semantics。

---

# 二十、NIPG 與 SemanticTensor

NOVA G7：

$$
T_{\mathrm{sem}}
\rightarrow
\{\mathcal N_1,\ldots,\mathcal N_k\}
+
\mathcal A
+
\mathcal O
$$

NIPG 應直接表示：

```text
SemanticTensor
 ├─ candidate_for → ProgramCandidate 1
 ├─ candidate_for → ProgramCandidate 2
 ├─ ambiguity → A1
 └─ obligation → O1
```

而不是強迫：

$$
T_{\mathrm{sem}}
\rightarrow
\mathcal N_1
$$

唯一化。

---

# 二十一、NIPG 與 NOVA-Language Source

Human source：

$$
S_H
$$

只是 projection。

因此：

```text
SourceSpan
HumanName
Comment
Formatting
```

不能成為 canonical program identity。

關係應為：

$$
G_N^\ast
\xrightarrow{\pi_H}
S_H
$$

NIPG 保存：

```text
projects_to
source_span_evidence
human_name_projection
```

---

# 二十二、第一版 Schema 骨架

概念物件：

```json
{
  "schema": "nipg/nova-isql-program/v0.1",
  "graph_id": "nipg:...",
  "upstreams": [],
  "nodes": [],
  "edges": [],
  "constraints": [],
  "obligations": [],
  "projections": [],
  "evidence": [],
  "transformations": [],
  "unknowns": [],
  "conflicts": []
}
```

---

# 二十三、第一版最小 MVP

NIPG v0.1 不需要一次映射 NOVA 全部能力。

第一階段只做：

```text
Project
Module
Graph
Node
Value
Operator
TensorType
Shape
Constraint
Effect
GraphPatch
Projection
Runtime Trace
ISQL-M Identity
ISQL-M Correspondence
```

即：

$$
\boxed{
\text{Identity}
+
\text{Canonical Program}
+
\text{Constraint}
+
\text{Transformation}
+
\text{Projection}
+
\text{Evidence}
}
$$

---

# 二十四、第一個驗證案例

建議使用 NOVA Core 的 tensor demo / differentiable example。

流程：

$$
\text{NOVA Project}
\rightarrow
NIPG
\rightarrow
\text{AI Query}
\rightarrow
\text{GraphPatch Proposal}
\rightarrow
\text{NOVA Validation}
\rightarrow
NIPG'
$$

驗證：

$$
\boxed{
\Delta G_{\mathrm{NIPG}}
\approx
\pi_{\mathrm{NIPG}}
(
G_N^{\ast\prime}
)
-
\pi_{\mathrm{NIPG}}
(
G_N^\ast
)
}
$$

---

# 二十五、第二個驗證案例

接 ISQL-M F15：

$$
\mathbb R^n
\rightsquigarrow
f64[n]
$$

建立：

```text
SREG Domain
→ Representation Correspondence
→ NOVA TensorType
→ Constraint / Open Obligations
→ Program Value
```

然後讓 AI 查：

> 這個 NOVA Value 為什麼被表示成 `f64[n]`？哪些性質已被驗證？哪些仍然未知？

這會直接測出 NIPG 是否真的比普通程式圖更適合 ISQL/NOVA。

---

# 二十六、最重要的 Epistemic Invariants

NIPG 必須固定：

$$
\boxed{
\text{Name}
\neq
\text{Identity}
}
$$

$$
\boxed{
\text{Projection}
\neq
\text{Authority}
}
$$

$$
\boxed{
\text{Candidate}
\neq
\text{Committed Program}
}
$$

$$
\boxed{
\text{Representation Correspondence}
\neq
\text{Type Equivalence}
}
$$

$$
\boxed{
\text{Structural Similarity}
\neq
\text{Program Equivalence}
}
$$

$$
\boxed{
\text{Runtime Observation}
\neq
\text{Canonical Program}
}
$$

---

# 二十七、目前三個 Repository 的角色

## ISQL-M

負責：

$$
\boxed{
\text{Identity}
+
\text{Address}
+
\text{Profile}
+
\text{Correspondence Evidence}
+
\text{Recoverability}
}
$$

## NOVA-Core-Closure

負責：

$$
\boxed{
\text{Canonical Program Semantics}
+
\text{Validation}
+
\text{Transformation}
+
\text{Execution Closure}
}
$$

## NOVA-Language

負責：

$$
\boxed{
\text{Practical Authoring}
+
\text{Compiler}
+
\text{Runtime}
+
\text{FFI}
+
\text{Package}
+
\text{Corpus}
}
$$

NIPG 的角色是：

$$
\boxed{
\text{把三者投影成 AI / PSMR 可運算的 Program World}
}
$$

---

# 二十八、結論

CISG 解決：

> **既有 Source Code 真正代表什麼？**

NIPG 解決：

> **已經具有原生 typed structural program ontology 的系統，要如何讓 AI 直接運算它？**

因此未來的程式媒介不再只有一種圖。

而是：

$$
\boxed{
\text{Traditional Software}
\rightarrow
G_{\mathrm{CISG}}
}
$$

與：

$$
\boxed{
\text{NOVA / ISQL Native Software}
\rightarrow
G_{\mathrm{NIPG}}
}
$$

最後共同進入：

$$
\boxed{
\text{PSMR Semantic Workspace}
}
$$

這使 PSMR 從「理解程式碼」進一步成為：

$$
\boxed{
\text{理解並運算不同程式本體的媒介 Runtime}
}
$$