docs: define bounded AI execution OS charter

.github/ISSUE_TEMPLATE/01-research-proposal.yml

@@ -49,8 +49,15 @@ body:
   - type: textarea
     id: safety
     attributes:
-      label: Safety and fallback
-      description: List hard invariants, forbidden actions, deterministic fallback, and rollback.
+      label: Authority, containment, and fallback
+      description: List principals, capabilities, hard invariants, forbidden actions, blast radius, deterministic fallback, and rollback.
+    validations:
+      required: true
+  - type: textarea
+    id: evidence
+    attributes:
+      label: Execution and evidence boundary
+      description: Explain how authorization, execution result, provenance, external readback, and unresolved outcomes remain distinct.
     validations:
       required: true
   - type: checkboxes

.github/pull_request_template.md

@@ -19,5 +19,8 @@ List the checks and experiments actually executed. State explicitly what was not
 
 - [ ] Planned work is not described as implemented or validated.
 - [ ] Hard invariants and deterministic fallback remain explicit.
+- [ ] Principal, authority, execution, provenance, and evidence claims are not conflated.
+- [ ] Failure containment, rollback, and recovery impact are stated where relevant.
+- [ ] Prior art or copied code has a traceable source and compatible license boundary.
 - [ ] No credential, private data, proxy setting, or workstation-specific path is included.
 - [ ] Documentation links and status labels remain consistent.

CONTRIBUTING.md

@@ -7,7 +7,9 @@ FlowKernel 当前处于研究规划阶段，尚未进入实现。贡献应帮助
 
 - 操作系统调度、cgroup、`sched_ext`、eBPF 和容器生命周期相关文献或基线；
 - 生命周期状态、进展信号、检查点和迁移模型；
-- 机制与策略分离、确定性 Guard 和降级设计；
+- Principal、Capability、委托、撤销和最小权限模型；
+- 机制与策略分离、确定性 Guard、fault containment 和降级设计；
+- 来源记录、外部验收、维护者迁移和工程恢复边界；
 - 可复现的实验设计、评价指标和失败案例；
 - 文档中的错误、歧义和失效链接。
 
@@ -21,5 +23,20 @@ FlowKernel 当前处于研究规划阶段，尚未进入实现。贡献应帮助
 4. 新增结论时同时记录替代方案、反例和演进触发条件。
 5. 不提交密码、Token、Cookie、私人数据、代理配置或本机绝对路径。
 6. 实现阶段开始后，代码变更必须附带测试和可重复实验入口。
+7. 区分 Proposal、Authorization、Execution、AcceptanceVerdict、Evidence 和 EpistemicStatus；
+   人工批准或执行成功不能自动写成事实成立。
+8. 引用 Linux 或其他实现时记录来源与许可证；不确定的复制边界必须在合入前停止并审查。
+
+## 宪法变更
+
+[执行操作系统宪法](docs/execution-os-constitution.md) 不是不可修改的口号，但修改它需要比普通
+文案更完整的理由。相关 PR 必须说明：
+
+- 哪个实现证据、反例或前人工作推翻了现有边界；
+- 对 Principal、authority、硬不变量、来源或恢复路径有什么影响；
+- 哪些旧声明和实验坐标需要保留；
+- 怎样回滚，而不把新结论倒写成项目最初就有的历史。
+
+单维护者当前仍可完成这些步骤，但不能据此声称职责分离或多人治理已经得到验证。
 
 Pull Request 必须列出实际执行的检查；未运行的验证应明确写明原因。

README.md

@@ -4,33 +4,45 @@
 [![Status](https://img.shields.io/badge/evidence-planned-6f624b)](#实现契约)
 [![License](https://img.shields.io/badge/license-Apache--2.0-4f7668)](./LICENSE)
 
-> A planned C-first experimental kernel researching lifecycle-aware,
-> continuity-preserving, and AI-assisted resource scheduling.
+> A planned C-first experimental AI execution kernel researching how fallible
+> policy can act inside deterministic authority, resource, isolation,
+> provenance, and recovery boundaries.
 
 **Evidence state: Planned. Implementation has not started.**
 
-FlowKernel（流核）的长期目标是构建一个以 freestanding C 为可信核心的实验性操作系统内核，
-研究操作系统能否不仅观察任务消耗了多少资源，还能理解任务所处的生命周期、真实进展和
-连续运行价值，并据此改进长期资源策略。
+FlowKernel（流核）的长期目标是构建一个以 freestanding C 为可信核心的实验性 AI Execution
+OS。它不试图让 AI 接管内核，也不假设人类拥有天然的最终正确性；它研究如何让规则、强化
+学习、Agent 与大模型等不完全可靠的策略源，在确定性的身份、权限、资源、隔离、生命周期、
+来源记录和恢复边界内提出并执行有界动作。
+
+资源调度仍是第一个核心研究方向：操作系统能否不仅观察任务消耗了多少资源，还能理解任务
+所处的生命周期、真实进展和连续运行价值，并据此改进长期策略。项目扩展的是这个问题的上游
+边界——谁有权行动、行动留下什么历史、行动后的事实如何成立——不是推翻原始问题。
 
 本仓库现在只保存研究问题、架构假设、实验路线和证据规则。它不是一个已经可运行的内核，
 也不把路线图描述成已实现能力。
 
 ## 实现契约
 
-> C owns mechanism and enforcement; AI may only propose bounded policy.
+> C owns mechanism and enforcement; policy sources may only propose bounded actions.
 
 - **The trusted core is C-first.** 内核主体使用受限的 freestanding C；只有启动、中断入口和
   上下文切换等硬件边界允许隔离、可枚举的最小汇编，不引入第二套策略逻辑。
 - **Lifecycle is an explicit state machine.** Spring Boot 只提供生命周期问题的启发；内核使用
   自己的构造、绑定、启动、运行、降级、停止和回收状态，不移植应用框架。
 - **AI is advisory.** AI 负责识别状态、评估长期策略并提出动作建议。
+- **Competence is not authority.** 人、Agent、服务及策略运行时作为 Principal；规则、模型和
+  policy 是带版本的 Artifact。会做、建议或批准某件事，不自动获得对目标 Object 的执行权。
 - **Enforcement remains deterministic.** C 状态机、Guard 和有限动作执行器负责约束和执行；
   模型缺席、超时或失效时，确定性基线仍能独立运行。
 - **Safety invariants are not learned policies.** 权限、硬资源上限、最低保障、紧急资源和
   迁移前有效检查点等约束不能交给奖励函数自行领悟。
 - **Mechanism and policy stay separated.** 学习系统可以调整策略，但不重写上下文切换、
   中断、页分配和锁等底层机制。
+- **Execution is not truth.** `ALLOW` 只表示动作获准，`SUCCEEDED` 只表示执行器报告完成；
+  关于现实的声明仍需独立读回和证据裁决。
+- **Every privileged transition has provenance and recovery.** 记录 Principal、授权、目标、前后
+  状态、结果与恢复引用；记录本身仍需身份、完整性和外部验收约束。
 - **Continuity first, peak controlled.** 对正在取得真实进展的长任务优先控制峰值并保持
   连续性，而不是仅根据瞬时占用粗暴终止。
 
@@ -40,60 +52,68 @@ FlowKernel（流核）的长期目标是构建一个以 freestanding C 为可信
 能力齐全。工程上分成两个可比较边界：
 
 - **FlowKernel target：** 用受限 freestanding C 建立最小可启动内核、显式生命周期状态机、
-  确定性调度基线、C Guard 和可回退动作执行器；
+  有界能力与资源边界、确定性基线、C Guard、动作执行器和恢复钩子；
 - **Linux reference lab：** 使用 Linux、cgroup、`sched_ext` 和 eBPF 作为传统对照组、观测
   实验台与早期假设验证工具，不把实验台结果冒充 FlowKernel 内核能力。
 
 在这两个边界上逐步研究：
 
+- Principal、Object、Capability、委托、撤销和执行所有权；
 - 进程、容器和长周期 Agent workload 的生命周期建模；
 - CPU、内存、I/O、网络和加速器资源预算；
 - 重试、停滞、检查点、迁移和恢复等长期状态；
 - Attention 或状态筛选对高维系统观测的压缩；
 - 规则、模仿学习和强化学习策略的可比较演进；
 - 单节点到多节点的放置、限流、暂停、迁移和恢复；
+- 特权转换的来源记录、独立验收与事实资格；
+- 维护者换机、凭据轮换和托管平台失效后的工程连续性；
 - 吞吐、延迟、公平、能耗、完成率和工作流连续性的多目标权衡。
 
 ## 候选结构
 
 ```mermaid
 flowchart TD
-    state["System and workload state"] --> observe["Lifecycle observer"]
-    observe --> lifecycle["Deterministic C lifecycle machine"]
-    lifecycle --> baseline["Rule baseline"]
-    lifecycle --> attention["Slow-path state selection"]
-    attention --> policy["External or isolated learned advisor"]
-    policy --> proposal["Typed, bounded action proposal"]
-    baseline --> guard["C safety guard"]
-    proposal --> guard
-    guard --> control["Bounded C executor"]
-    control --> runtime["Scheduler / memory / I/O substrate"]
-    runtime --> hardware["Hardware"]
-    hardware --> state
+    principal["Human / Agent / Service\nPrincipal"] --> intent["Intent / Request"]
+    intent --> policy["Slow-path policy\nRule / Heuristic / RL / LLM"]
+    policy --> proposal["Versioned, bounded proposal"]
+    proposal --> guard["C-first trusted core\nCapability / Lifecycle / Resource / Guard"]
+    guard --> control["Bounded executor + recovery"]
+    control --> runtime["Runtime / Hardware"]
+    runtime --> observation["Result / Observation"]
+    observation --> acceptance["External acceptance"]
+    acceptance --> runVerdict["AcceptanceVerdict"]
+    acceptance --> evidence["Evidence"]
+    evidence --> epistemic["EpistemicStatus"]
+    runVerdict --> policy
+    epistemic --> policy
 ```
 
-微秒到毫秒级的 **Fast Path** 继续使用确定性算法。AI 只进入秒级到分钟级的
-**Slow Path**，处理预算调整、异常模式、检查点、迁移和长期优先级。
+微秒到毫秒级的 **Fast Path** 继续使用确定性算法。概率策略只进入秒级到分钟级的
+**Slow Path**，处理预算调整、异常模式、检查点、迁移和长期优先级。C-first 可信核心负责
+授权与执行边界；外部验收产生 AcceptanceVerdict 和 evidence，后者才能支持 EpistemicStatus。
+两者不能
+互相替代。
 
 ## 路线图
 
 | 阶段 | 研究目标 | 当前状态 |
 | --- | --- | --- |
-| R0 | 固定 C 工具链、启动契约、传统策略和 workload 对照基线 | Planned |
-| R1 | 最小可启动 C 内核与显式生命周期状态机 | Planned |
-| R2 | 确定性调度、资源回收、C Guard 与故障回退 | Planned |
-| R3 | 生命周期观测、状态筛选、Attention 与可解释性 | Planned |
-| R4 | 模仿学习、强化学习与受限动作提案 | Planned |
-| R5 | workload 连续性、检查点、迁移与恢复 | Planned |
-| R6 | 多核/多节点、故障注入、公平性和长期稳定性 | Planned |
-| R7 | Agent、模型训练和推理 workload 的对照验证 | Planned |
+| R0 | 固定宪法、可信边界、C 工具链、传统基线与干净机器恢复协议 | Planned |
+| R1 | 最小可启动 C 内核、静态 Principal/Object 句柄与生命周期状态机 | Planned |
+| R2 | 确定性能力、资源和隔离 Guard，有限执行器与故障回退 | Planned |
+| R3 | 特权转换来源记录、恢复与外部验收交接 | Planned |
+| R4 | 生命周期观测、状态筛选、Attention 与可解释性 | Planned |
+| R5 | 规则、模仿学习、强化学习与受限动作提案 | Planned |
+| R6 | workload 连续性、检查点、迁移、委托和撤销 | Planned |
+| R7 | 多核/多节点、AI workload、故障注入和长期稳定性 | Planned |
 
 阶段编号表示依赖关系，不代表承诺日期。每一阶段只有形成可重复实验和对照证据后，才会
 从 `Planned` 更新为 `Validated`。
 
 ## 文档
 
 - [概念起源](docs/conceptual-origin.md)
+- [执行操作系统宪法](docs/execution-os-constitution.md)
 - [C-first 内核契约](docs/c-first-kernel-contract.md)
 - [愿景与边界](docs/vision.md)
 - [研究问题](docs/research-questions.md)
@@ -110,19 +130,23 @@ flowchart TD
 | [DarkRoomLibrary](https://github.com/NoctilumeDev/DarkRoomLibrary) | 增强型单体中的业务闭环与一致性 |
 | [PlainJournal](https://github.com/NoctilumeDev/PlainJournal) | 分布式业务系统的可靠性、恢复与资源边界 |
 | [PlainJournalPro](https://github.com/NoctilumeDev/PlainJournalPro) | 多商户平台、账本结算与异构服务治理 |
-| FlowKernel | 生命周期感知的资源策略与 AI 系统研究 |
+| [VeriTrail](https://github.com/NoctilumeDev/VeriTrail) | 受控执行、事实读回、失败保留与外部验收 |
+| FlowKernel | 概率策略如何在确定性行动、权限、来源和恢复边界内运行 |
 
-前三个项目在操作系统之上验证应用系统；FlowKernel 进一步研究底层资源分配策略。它们是
-问题来源与控制组，不是 FlowKernel 已完成研究的证据。
+前三个应用项目提供所有权、资源、故障与恢复样本；VeriTrail 提供独立验收和事实资格方法；
+FlowKernel 研究这些约束如何进入执行底座。集成的是失败后留下的边界思想，不是把现有项目
+代码拼进内核。它们都是问题来源与控制组，不是 FlowKernel 已完成研究的证据。
 
 ## 当前不做
 
 - 不宣称当前已有可运行内核，也不宣称正在替代 Linux；
 - 不用“C 代码少”替代内存安全、并发安全、状态机和故障恢复设计；
 - 不在最小闭环前同时铺开驱动、文件系统、网络栈、多核和分布式控制；
 - 不让模型直接控制中断、时间片、内存页或内核权限；
+- 不把人工批准当作最终真值，也不把 provenance 当作事实裁决；
 - 不把所有 `if/else` 机械替换为强化学习；
 - 不预选模型、强化学习算法或分布式控制平面；
+- 不在尚无真实社区时宣称多主体治理已经得到验证；
 - 不在没有基线、随机种子和失败证据时发布性能结论。
 
 ## License

SECURITY.md

@@ -6,6 +6,9 @@ FlowKernel 目前只有公开研究文档，没有可部署内核、控制器、
 当前安全范围包括仓库治理、文档中的敏感信息，以及策略层和执行层的
 [威胁模型与安全不变量](docs/threat-model.md)。
 
+当前仓库没有 capability runtime、Guard、来源记录服务、Acceptance Workbench 或多主体治理
+实现。相关文档只定义未来边界，不能被安全报告或宣传材料写成已经部署的防护。
+
 ## 报告安全问题
 
 不要在公开 Issue 中披露未修复漏洞、凭据、个人信息或可直接利用的攻击步骤。优先使用
@@ -18,6 +21,9 @@ GitHub Private Vulnerability Reporting 私下提交；若该入口不可用，
 
 - 受支持版本与实验环境；
 - 模型、策略、Guard 和执行器的信任边界；
-- 权限、资源、观测输入和动作接口；
+- Principal、Capability、委托、撤销、权限、资源、观测输入和动作接口；
 - 策略失效、回滚和确定性降级路径；
-- 依赖、构建产物和漏洞响应流程。
+- Guard、authority root、break-glass 和治理变化的修改路径；
+- 来源记录、身份、完整性、外部验收和记录失败时的 fail-safe 行为；
+- 依赖、工具链、构建产物、供应链来源和漏洞响应流程；
+- 支持的凭据轮换、维护者恢复和主托管平台失效场景。

docs/architecture-hypotheses.md

@@ -72,6 +72,8 @@ C Guard 至少负责：
 - 在策略超时、异常或不可用时切回确定性规则。
 
 这些约束通过 C 代码审查、静态分析、模型检查或可重复测试验证，不通过 reward 间接表达。
+这里的“最终”只指运行时授权链：Guard 有权拒绝动作，但无权把执行结果直接宣布为世界事实；
+Guard 自身、硬不变量和 authority root 的修改还必须经过独立治理路径。
 
 ## H6：Attention 只负责“看什么”
 
@@ -91,3 +93,45 @@ C Guard 至少负责：
 - 控制平面恢复后的对账与收敛。
 
 多节点研究只有在单机生命周期模型和 Guard 已经验证后才开始。
+
+## H8：所有行动主体应进入同一有界授权模型
+
+Human、Agent、Service 和策略运行时都以 Principal 身份发起或承担行动责任。规则、模型与
+policy 是 Principal 使用的版本化 Artifact，不自行持有 Capability。候选 Capability 将特定
+Object、动作权利、范围、预算、时限和版本绑定起来；模型能力、作者身份或人工批准不能形成
+隐藏旁路。
+
+预期收益是最小权限、委托、撤销和责任边界可以统一检查；需要验证的代价是 capability
+传播、撤销缓存、在途动作和恢复所有权带来的复杂度。当前不预选具体能力表示。
+
+## H9：授权、执行与事实应是不同协议
+
+候选控制链是：
+
+```text
+intent
+  -> typed proposal
+  -> authorization
+  -> bounded action
+  -> observation
+  -> external acceptance
+```
+
+C 可信核心对授权和执行完整调停，并锚定 Principal、Capability、输入版本、前后状态和恢复
+引用。外部 Acceptance 读取运行与工件事实，给出验证、反驳或未验证结果；它不能修改被验对象
+来制造通过。
+
+预期收益是一次“成功调用”不会被误当成目标成立；需要验证的代价是来源记录、身份完整性、
+外部事实源和冲突裁决的成本。W3C PROV 或供应链 attestations 只能作为词义与格式参考，不被
+预设成实现依赖。
+
+## H10：故障容纳与恢复应成为一级合同
+
+FlowKernel 不要求策略永远正确，而要求错误影响停留在获授权的隔离域内。资源包络、动作幅度、
+速率、租约、停止线、紧急保留、checkpoint 和确定性 fallback 都应能被单独触发和验证。
+
+恢复对象不只包括 workload。研究还应区分运行时迁移、干净机器重建、凭据撤销与重签发、
+维护者更换和仓库对象恢复。后几项主要属于工程治理，不得为了“统一”强塞进最小 C 内核。
+
+预期收益是 AI、服务、人类或托管平台的错误不自然升级为全局事故；需要验证的代价是恢复路径
+自身的状态空间、保留资源和长期维护成本。