总体架构：Foundation 到底是什么
先澄清它不是产品 Graph 的旁路校验器，而是可复用的权威基础设施；采用方保留 ontology、提示词、业务角色和交互。
- Foundation 与产品 Agent 的责任边界是什么？
- PostgreSQL、Neo4j 与公开 Runtime 分别承担什么？
Main narrative
推荐主讲路线
先定义产品边界，再证明接入约束没有被简化掉；随后用 Evidence、Memory、Relation 与 Graph 的真实治理链路回答“为什么需要 Foundation”。
产品接入与 Registration
展示“简单接入”只是收敛入口，并没有绕过 capability、Provider Claim、Runtime owner、scope 与 receipt。
- 新项目怎样接入而不伪造能力？
- 约束在统一 Runtime facade 后去了哪里？
权威数据流与持久化边界
拆开 Evidence Authority 与可选的 Observation Routing，并展示 Graph-only Recipe 可直接走 Evidence → Proposal → Graph Authority。
- Graph-only 为什么不需要 Observation、Memory 或 Relation？
- 控制面与 Graph 数据面为什么要分开？
Evidence 失效与下游重验证
把 Evidence lifecycle、support projection 与 eligibility 分开计算：context-only 不影响投影，partial support 默认仍可用，只有 ineligible 才进入保护。
- Evidence 变化后为什么不应一律保护或级联删除？
- 如何做到 protected empty 与可恢复收敛？
Graph Proposal → Review → Apply
展示产品只提交冻结操作，独立 reviewer 形成不可变决定，executor 才消费 durable outbox 写入 Graph。
- 为什么普通 SDK 没有直接 apply？
- 人审、权限与零写阶段如何被证明？
Core mechanisms
核心机制图
同类图在这里被重复使用，因为每张只回答一个机制问题：一次调用怎样走完、Observation 怎样路由、Memory/Relation 如何治理、Evidence 如何形成可失效的依赖。
Runtime 一轮调用如何走完
把 before_model、宿主 Agent、after_model、zero-write planning 与显式治理分开，说明“简单接入”没有把决策权交给 facade。
- Foundation 在模型调用前后分别做什么？
- 为什么 after_model 不等于自动写入？
Observation 如何选择表示
逐 claim 判断 no persistence、Evidence、Memory proposal、Relation proposal、trace 或 quarantine；路由本身保持零写。
- Graph 和 Memory 是怎么区分的？
- 部分阻断为什么不应吞掉安全候选？
Memory 候选、审核与召回
区分低风险 local auto-apply、production owner review、拒绝、幂等重放与后续 recall，避免把模型输出直接当成长期事实。
- 哪些偏好可以自动应用？
- rejected candidate 为什么不会进入 recall？
Relation 状态与时间投影
把 candidate、review、active 与 current/upcoming/historical 投影分开；批准未来关系并不意味着它已经是当前事实。
- 为什么 active 仍可能不出现在 current projection？
- Foundation Relation 与产品 Graph 有什么区别？
Evidence lineage 与不可变 revision
说明 source authority 如何进入不可变 revision，successor、supersede 与 revoke 如何保留历史又避免旧证据继续支撑当前状态。
- 为什么 Evidence 不原地更新？
- 内容相同为什么不能冒充同一来源权威？
Evidence 失效如何通知下游
Evidence lifecycle event、dependency fence 与 durable outbox 形成控制面闭环，再由 bounded revalidator 更新 Memory、Relation 与 Graph projection。
- 如何避免无限级联扫描？
- 读路径为什么会返回 protected empty 或 typed degraded？
Real adopters
真实采用方图
不只画抽象 Foundation：用 TeachFlow 与 TraceWise 的真实 pilot 解释哪些数据已经切换权威、哪些业务事实仍由产品拥有、未 opt-in 范围如何保持兼容。
TeachFlow 双 Authority Pilot
一条链路把作答 Evidence 变成安全个性化 Memory，另一条链路治理 exact pilot 的 Graph proposal；课程、班级与业务 ontology 仍由 TeachFlow 决定。
- Foundation 替换了哪些基础设施？
- 为什么非 pilot 不会被静默迁移？
TraceWise 项目级 Opt-in
默认 registry 为空；只有显式 project Registration 才进入 Evidence → Graph Proposal → Review → Executor，cutover 后 direct legacy mutation fail closed。
- 如何让第二个真实项目接入而不全局切换？
- Foundation 不可用时为什么不能自动回退 legacy 写？
TeachFlow、TraceWise 与 Wrapper 的共同边界
横向比较不同采用方如何复用相同 Foundation authority，又如何保留自己的 ontology、候选生成、角色分配、模型调用与产品体验。
- 多策略适配与硬编码 adopter 有什么区别？
- Wrapper 为什么不是新的权威数据库？
Physical & reliability
物理边界与可靠性图
用于回答最容易被追问的工程问题：数据到底存在哪里、谁能执行写入、PostgreSQL 与 Neo4j 之间发生不确定结果时怎样收敛。
权威存储与执行拓扑
把 local SQLite、生产 PostgreSQL control plane、Memory/Relation authority、durable outbox、独立 executor 与 Neo4j data plane 放在同一物理视图中。
- Foundation 是否真的拥有数据库？
- 为什么不宣称 PostgreSQL 与 Neo4j 跨存储 ACID？
Graph 写入结果未知时如何收敛
用 durable intent、exact operation marker、Graph revision 与 reconciliation 解释：响应丢失不等于操作未发生，也不允许盲目重复 mutation。
- 进程在 Graph commit 后崩溃怎么办？
- 为什么 marker 与业务 mutation 必须同一 Neo4j transaction？
面试现场用法
图不是讲义全文。每张只回答一个核心问题，停下来让面试官选择是否深挖。
建议 10 分钟节奏
0–2 min
总体架构：一句话定位、采用方与 Foundation 的权威边界。
2–4 min
Registration：解释易用入口与 fail-closed 约束为何能同时成立。
4–7 min
权威数据流 + Evidence 生命周期：回答数据落点和失效安全。
7–10 min
Graph 治理时序：用真实 proposal、review、executor 与 receipt 收束。