# SEDB–UIR–ISQL Integration Note

**副標題：Semantic Persistence、Representation Operation 與 Semantic Intent 的責任邊界與未來整合接口**  
**版本：** v0.1  
**日期：** 2026-09-17  
**文件類型：** Integration Note / Architecture Handoff  
**狀態：** Proposed / Integration Deferred  
**對應系統：** SEDB / UIR / ISQL / Research Object Runtime

---

## 0. 目的

本文件不是新的大型理論，也不是新的技術白皮書。

它只固定一件事：

> 在 SEDB、UIR、ISQL 未來真正整合之前，先明確定義三者各自負責什麼、交換什麼、以及不應該越界做什麼。

目前狀態：

```yaml
integration:
  status: proposed
  implementation: deferred

systems:
  SEDB: evolving
  UIR: conjecture + whitepaper + MVP_v0.1
  ISQL: evolving
```

因此：

$$
\boxed{
\text{Define Interfaces Now}
\neq
\text{Integrate Systems Now}.
}
$$

---

# 1. 三層核心分工

本文固定：

$$
\boxed{
\begin{aligned}
SEDB &: \text{Semantic Persistence / Evolution}\\
UIR &: \text{Representation Resolution / Operation}\\
ISQL &: \text{Semantic Intent / Navigation}
\end{aligned}
}
$$

並加入第四層：

$$
\boxed{
ArtifactStore
=
\text{Native Payload Carrier}.
}
$$

一句話表示：

$$
\boxed{
\text{ISQL navigates;}
\quad
\text{SEDB stores and evolves;}
\quad
\text{UIR resolves and operates.}
}
$$

---

# 2. SEDB 的責任

SEDB 負責：

- persistent object identity；
- canonical semantic state；
- version；
- lineage；
- relations；
- provenance；
- lifecycle；
- governance state；
- representation metadata；
- capability declaration；
- evidence / claim state；
- current / historical state。

可概括為：

$$
\boxed{
SEDB
=
\text{Semantic Persistence Plane}.
}
$$

SEDB 回答：

> 這個東西是誰？

> 現在狀態是什麼？

> 以前狀態是什麼？

> 跟誰有關？

> 哪個 representation 是目前有效的？

---

# 3. SEDB 不負責

SEDB 不應預設負責：

- decode video；
- render 3D；
- execute simulation；
- parse every native format；
- run native binaries；
- perform model inference；
- store every large payload directly。

因此：

$$
\boxed{
SEDB
\neq
UniversalRuntime.
}
$$

---

# 4. UIR 的責任

UIR 負責：

- representation discovery；
- media / carrier resolution；
- adapter selection；
- capability discovery；
- transformation；
- conversion；
- rendering；
- sampling；
- execution；
- operation provenance；
- loss declaration。

可概括為：

$$
\boxed{
UIR
=
\text{Representation Operation Plane}.
}
$$

UIR 回答：

> 這個 object 要怎麼讀？

> 哪個 adapter 可以操作？

> 它能 render、query、simulate 或 convert 嗎？

---

# 5. UIR 不負責

UIR 不應決定：

- 哪個 theory 是 canonical；
- 哪個 claim 應被接受；
- 哪個 research version 是 current；
- 哪條 lineage 是正式治理結果；
- 哪個 object 在研究體系中具有最高 authority。

因此：

$$
\boxed{
UIR
\neq
CanonicalSemanticAuthority.
}
$$

---

# 6. ISQL 的責任

ISQL 負責：

- semantic intent；
- semantic addressing；
- query；
- navigation；
- selection；
- cross-object retrieval；
- high-level action request。

可概括為：

$$
\boxed{
ISQL
=
\text{Semantic Intent Plane}.
}
$$

ISQL 回答：

> 我要找什麼？

> 我要哪個版本？

> 我要哪種 representation？

> 我要對它做什麼？

---

# 7. ISQL 不負責

ISQL 不應預設：

- 永久儲存 canonical state；
- 自己 decode 所有 native format；
- 自己執行所有 capability；
- 成為 universal storage format。

因此：

$$
\boxed{
ISQL
\neq
SEDB
}
$$

且：

$$
\boxed{
ISQL
\neq
UIR.
}
$$

---

# 8. Artifact Store

大型 native payload 應獨立保存，例如：

- models；
- arrays；
- videos；
- scene files；
- simulation states；
- executables；
- datasets；
- sensor streams。

Artifact Store 負責：

> 真正的 bytes / payload 在哪裡？

而不是：

> 它在整個知識體系中代表什麼？

因此：

$$
\boxed{
SEDB
=
\text{Semantic State}
}
$$

$$
\boxed{
ArtifactStore
=
\text{Payload State}.
}
$$

---

# 9. 四層責任表

| 系統 | 主要責任 | 不應主要負責 |
|---|---|---|
| SEDB | identity、semantic state、version、lineage、relations、provenance | decode / render / execute native artifacts |
| UIR | representations、adapters、resolver、capabilities、conversion、execution | canonical theory governance |
| ISQL | intent、query、navigation、selection | persistence 與 native parsing |
| Artifact Store | payload、binary、model、stream | semantic governance |

---

# 10. 最小整體架構

$$
\boxed{
\begin{array}{c}
Human / AI / Agent\\
\downarrow\\
ISQL / Semantic Intent\\
\downarrow\\
SEDB / Canonical Semantic State\\
\downarrow\\
UIR / Resolver + Capability\\
\downarrow\\
Artifact Store / Native Payload
\end{array}
}
$$

實際運行中，UIR 可以把 operation result 與 provenance 回寫 SEDB。

---

# 11. 查詢流程範例

使用者要求：

> 找目前最新版 Exo-Eye 3D 模型並顯示。

### Step 1｜ISQL

```text
target:
    research_object = Exo-Eye

constraints:
    representation = 3D
    state = canonical
    version = latest

operation:
    render
```

### Step 2｜SEDB

SEDB 回：

```text
object_id
representation_id
semantic_type
current_version
artifact_ref
provenance
trust_state
```

### Step 3｜UIR

UIR 接收：

```text
object_id
representation_id
capability = render
```

並執行：

$$
\boxed{
Capability
\rightarrow
Resolver
\rightarrow
Adapter
\rightarrow
NativePayload
\rightarrow
Render.
}
$$

---

# 12. UIR 回寫 SEDB

若 UIR 產生：

- simulation result；
- converted representation；
- rendered derivative；
- validated output；

可回寫：

```text
artifact_id
generated_by
derived_from
representation_role
content_hash
adapter
timestamp
validation_state
```

而大型 payload 本身仍留在 Artifact Store。

---

# 13. UIO 與 SEDB

UIR v0.1 使用 UIO manifest。

未來接入 SEDB 後，UIO 不一定需要以 JSON file 作 canonical source。

可以改成：

$$
\boxed{
SEDB
\rightarrow
UIOProjection.
}
$$

例如：

```text
SEDB canonical state
→ object.uio.json
```

或：

```text
SEDB
→ runtime manifest
```

因此：

$$
\boxed{
UIOManifest
\neq
CanonicalDatabaseRecord.
}
$$

---

# 14. Adapter Registry 與 SEDB

Adapter Registry 的治理 metadata 很適合放在 SEDB：

```text
adapter_id
version
publisher
accepted_media_types
semantic_types
capabilities
hash
status
deprecated
superseded_by
validation_state
```

真正的 adapter bytes 則可存在：

- Python package；
- WASM；
- native library；
- container；
- remote service。

因此：

$$
\boxed{
SEDB
=
AdapterSemanticState
}
$$

$$
\boxed{
ArtifactStore
=
AdapterArtifact
}
$$

$$
\boxed{
UIR
=
AdapterExecution.
}
$$

---

# 15. 最小 SEDB → UIR Contract

```json
{
  "object_id": "...",
  "semantic_type": "...",
  "representations": [
    {
      "representation_id": "...",
      "role": "...",
      "media_type": "...",
      "artifact_ref": "...",
      "schema": "...",
      "adapter_hint": "...",
      "status": "..."
    }
  ],
  "relations": [],
  "provenance": {},
  "trust": {}
}
```

---

# 16. 最小 UIR → SEDB Contract

```json
{
  "operation_id": "...",
  "source_object": "...",
  "source_representation": "...",
  "capability": "...",
  "adapter": "...",
  "adapter_version": "...",
  "result_artifact": "...",
  "result_semantic_type": "...",
  "loss_profile": "...",
  "timestamp": "...",
  "validation_state": "..."
}
```

---

# 17. 最小 ISQL → SEDB Contract

```json
{
  "target_type": "research.object",
  "filters": {
    "name": "Exo-Eye",
    "state": "canonical"
  },
  "representation": {
    "role": "3d-model"
  }
}
```

---

# 18. 最小 ISQL → UIR Contract

Object 已 resolved 後：

```json
{
  "object_id": "RO-EXO-001",
  "capability": "render",
  "parameters": {}
}
```

---

# 19. Authority Boundary

本文固定：

$$
\boxed{
\text{SEDB decides state}
}
$$

$$
\boxed{
\text{UIR decides operation path}
}
$$

$$
\boxed{
\text{ISQL expresses intent}.
}
$$

三者不應默認越界。

---

# 20. Canonical State Boundary

只有 SEDB / governance layer 可以正式標記：

```text
canonical
active
historical
superseded
```

UIR 不因成功 render 某 artifact 就自動宣告它 canonical。

---

# 21. Execution Boundary

只有 UIR / execution layer 決定：

```text
which representation
which adapter
which execution path
```

SEDB 不需要知道 parser 內部怎麼工作。

---

# 22. Intent Boundary

ISQL 不應直接指定：

```text
use parser class X
call library Y
read byte offset Z
```

這些都屬於 Runtime resolution。

---

# 23. Integration Anti-Patterns

### A

$$
\boxed{
SEDB
\leftarrow
\text{all payloads + all parsers + all execution}
}
$$

結果會變成 monolith。

### B

$$
\boxed{
UIR
\leftarrow
\text{canonical semantic governance}
}
$$

Runtime 會開始決定研究本體。

### C

$$
\boxed{
ISQL
=
\text{storage + query + runtime}
}
$$

Intent layer 會失去邊界。

### D

要求所有 artifact 先轉成 JSON 才能進系統。

本文仍維持：

$$
\boxed{
\text{Native Representations First}.
}
$$

---

# 24. Research Object Runtime

未來可將 Research Object Runtime 寫成：

$$
\boxed{
ROR
=
SEDB
+
UIR
+
ISQL
+
ResearchProfile.
}
$$

其中 ResearchProfile 定義研究領域專屬語義：

- paper；
- claim；
- evidence；
- lineage；
- TCF；
- ISQL；
- simulation；
- 3D；
- validation；
- citation edition。

ROR 因此不必重新發明 database、resolver 或 query language。

---

# 25. Integration Timing

目前不應立即做完整整合。

原因：

```text
SEDB: evolving
ISQL: evolving
UIR: v0.1 MVP complete
```

所以：

$$
\boxed{
\text{Interface Freeze First}
\rightarrow
\text{Integration Later}.
}
$$

---

# 26. Future Integration Trigger

只有在以下條件成立後再實作：

```text
SEDB core contract stabilized
ISQL intent contract stabilized
UIR MVP contract remains compatible
```

接著才做：

```text
SEDB bridge
UIR bridge
ISQL frontend
integration tests
```

---

# 27. 第一個真正整合測試

未來第一個 integration test 只需：

```text
ISQL:
    find canonical research object

SEDB:
    resolve latest 3D representation

UIR:
    render representation

SEDB:
    record operation provenance
```

足以驗證三者是否真正分工成功。

---

# 28. Integration Success Criteria

第一階段成功條件：

1. ISQL 不知道 native file details；
2. SEDB 不直接 render；
3. UIR 不決定 canonical state；
4. Artifact payload 不必進 SEDB；
5. operation provenance 能回寫；
6. representation identity 能跨系統保持穩定。

---

# 29. 最終整合狀態

```yaml
integration:
  status: proposed
  implementation: deferred

systems:
  SEDB:
    responsibility: semantic persistence and evolution
    state: evolving

  UIR:
    responsibility: representation resolution and operation
    state: conjecture + whitepaper + MVP_v0.1

  ISQL:
    responsibility: semantic intent and navigation
    state: evolving

  ArtifactStore:
    responsibility: native payload storage
```

---

# 30. 結論

SEDB、UIR、ISQL 並不是三個應該互相吞併的系統。

更合理的關係是：

$$
\boxed{
Intent
\rightarrow
SemanticState
\rightarrow
RepresentationOperation.
}
$$

ISQL 表達：

> 我要什麼。

SEDB 回答：

> 現在存在什麼，以及 canonical state 是什麼。

UIR 回答：

> 這個東西應如何被解析、轉換、顯示或執行。

Artifact Store 則保存：

> 真正的大型 native payload。

因此：

$$
\boxed{
\text{Semantic Persistence}
\neq
\text{Representation Operation}
\neq
\text{Semantic Intent}.
}
$$

保持這些 authority boundaries，可以避免未來架構演化成不可維護的 monolith。

目前最合理的行動不是立即整合，而是保存本 Integration Note，等待 SEDB 與 ISQL 的新版核心 contract 穩定後，再以此文件作為正式 integration 的起點。

---

*SEDB–UIR–ISQL Integration Note / v0.1 / 2026-09-17*  
*EveMissLab — Boundless Knowledge. One Promise Forward.*