昨天談到：
如果真的要讓 Sol 進入 AICAN 展示中心，
第一步不是控制。
而是：
Read-Only。
先看。
先盤點。
先理解。
因為如果連世界都還沒有看懂，
根本沒有資格談 Action。
但真的開始想 Read-Only Mapping 之後，
下一個問題馬上就出現。
一棟建築裡面的資料，真的非常多。

做智慧建築、智慧空間的人應該很熟悉。
系統裡可能有：
Lighting。
HVAC。
Temperature。
Humidity。
CO₂。
VOC。
Energy Meter。
Door。
Curtain。
Occupancy。
Alarm。
Scene。
Setpoint。
Equipment Status。
而每一個系統底下，
又可能有：
幾十個 Point。
幾百個 Point。
甚至幾千個 Point。

對工程師來說，
我們看到這些 Point，
通常大概知道它們在做什麼。
但對 AI 來說，
事情沒有這麼簡單。
假設我只給 Sol 一個數字：
826
這代表什麼？
826 ppm？
826 W？
826 Lux？
826 rpm？
哪一個房間？
哪一個設備？

多久以前更新？
現在還有效嗎？
這個數值可以控制嗎？
還是只能讀？
如果沒有 Context，
826 就只是：
一個 Number。

這也是我後來越來越在意的一件事情。
Data 不等於 Meaning。
更不等於：
Reality。

所以我們開始把一個 Point 拆得更細。
不是只記：
Tag Name。
Value。
Timestamp。
而是希望至少知道：
Identity
這是哪一個 Point？

Device
它屬於哪一台設備？

Location
它在哪一個 Space？

Type
它是：
Sensor？
Command？
Setpoint？
State？
Derived Value？

Semantic Meaning
它在現實世界裡真正代表什麼？

Unit
ppm？
°C？
%？
kW？
Lux？

Capability
它可以：
Read？
Write？
Control？

Relationship
它跟哪個：
Space。
Device。
Scene。
State。
Actor。
有關？

當這些東西開始被建立起來，
Point 才開始從：
Data
慢慢變成：
Site Knowledge。

這也是我們為什麼開始規劃：
Site Knowledge Pack
它不是單純把所有設備名稱存進資料庫。
而是希望建立：
一個真實場域的語意結構。
讓 AI 未來看到一筆資料時，
不只是知道：
「這裡有一個值。」
而是知道：
這個值在這個 Site 裡到底代表什麼。

例如今天看到：
Zone3_CO2 = 1350
這裡只是示意例子，
不是我現在公開 AICAN 展示中心的真實 Point。
Illustrative Example。
如果 Sol 只看到：
1350。
她能做的事情非常有限。

但如果她知道：
這是某一間會議室。
Unit 是 ppm。
目前有人。
數值持續上升。
Fresh Air System 服務同一個 Space。
目前設備沒有 Alarm。
資料 Timestamp 是新的。

那這一筆資料才開始從：
Value
變成：
Situation。

也就是：
Data
↓
Semantic Meaning
↓
Relationship
↓
Context
↓
Reality Understanding

這裡我覺得最重要的地方是：
Semantic Meaning。
因為智慧建築很容易出現一種狀況。
工程師很清楚：
某一個 Tag 是什麼。
但這個知識只存在：
工程師腦袋裡。

例如：
AHU_03_SA_TEMP
有經驗的人可能一眼看得懂。
但 AI 如果沒有相應的 Semantic Mapping，
那只是一串字。
更麻煩的是：
不同案場。
不同廠牌。
不同 SI。
不同年代。
命名方式可能完全不一樣。

這也是為什麼我現在覺得：
AI-native Building 最重要的事情之一，
可能不是先增加更多 AI。
而是：
把現場原本隱藏在人腦裡的 Meaning，逐步結構化。

這對 AICAN 其實很有意義。
因為我們本來就在做：
跨品牌。
跨 Protocol。
跨設備。
如果未來 Sol 要站在這些系統上面，
她不能依賴：
「所有設備都使用同一種命名方式。」
不可能。
真正要建立的是：
Vendor-neutral Semantic Layer。

底下可以是：
ComfortClick。
BACnet。
Modbus。
MQTT。
KNX。
或其他系統。
但上層看到的應該逐步變成：
這是一個：
Temperature Sensor。
它屬於：
Meeting Room。
這是一個：
HVAC Capability。
它影響：
同一個 Space。

也就是說，
Protocol 解決的是：
怎麼連。
Site Knowledge 解決的是：
連進來之後，它到底是什麼。
這兩件事情完全不同。

而且 Site Knowledge 還牽涉一個很重要的安全問題：
Capability Classification。
因為不是所有 Point 都一樣。
有些只能：
Read。
有些可以：
Write。
有些甚至真的可以：
改變 Physical State。
所以 AI 不只要知道：
「這是溫度。」
還要知道：
「這是一個 Sensor，只能讀。」
或者：
「這是一個 Command，未來如果真的要 Write，需要更高的 Authority。」

這件事情跟前面的 Governance 也全部接起來了。
Day 14：
Permission 有 Scope。
Day 20：
Physical Action 需要 Trust Boundary。
Day 21：
第一步 Read-Only。
到了今天：
Site Knowledge 本身就必須知道 Capability Boundary。

而且我現在越來越覺得，
Read-Only 階段其實不是什麼「低階工作」。
它反而是一個非常重要的 Reality Validation 過程。
因為這個階段可以先檢查：
Space Mapping 對不對？
Point Meaning 對不對？
Device Relationship 對不對？
Capability Classification 對不對？
資料 Freshness 有沒有問題？

如果這些基本事情都還錯，
那後面的 AI Reasoning 再厲害，
也只是：
在錯誤的世界模型上做更高級的推理。

這件事情對我衝擊滿大的。
因為我們很容易把 AI 的價值放在：
推理。
預測。
最佳化。
自動控制。
但在 Physical AI 裡，
其實前面還有一個很樸素的問題：
它到底知不知道自己正在看什麼？

所以 Day 22，我最想留下的一句話是：
Data is not reality.
資料只是 Reality 留下來的一部分訊號。
AI 如果要真的開始理解一個 Site，
還需要：
Meaning。
Relationship。
Space。
State。
Capability。

這裡我也要把目前 Development State 講清楚。
Site Knowledge Pack：
目前是：
SPECIFIED
AICAN Showroom Point Mapping：
目前仍然是：
READ-ONLY MAPPING — NEXT ENGINEERING STEP
不能因為今天文章把方法講得很完整，
就寫成：
「AICAN 展示中心 Site Knowledge 已經全部建完。」
還沒有。
而 Production Write / Control：
也沒有因此自動被授權。

但至少，
方向現在非常清楚。
Physical AI 的第一步，
不是讓 AI：
動世界。
而是先讓它：
正確描述世界。

而當 Sol 未來開始知道：
這是 Sensor。
這是 Command。
這是 Space。
這是 Capability。
這是 Relationship。
下一個問題馬上就會出現。
如果 Human 說：
「Sol，把會議室變舒服一點。」
這一句自然語言，
到底怎麼安全地走到設備端？
它不能直接跳成：
Relay。
BACnet Command。
Modbus Write。
明天 Day 23，
我們來談一句我現在非常堅持的話：
自然語言不能直接接 Relay。