From 087d01f250d3a8ccf350b3f33f9ef4c6c4d15ce0 Mon Sep 17 00:00:00 2001 From: NoctilumeDev <263493638+NoctilumeDev@users.noreply.github.com> Date: Sat, 29 Aug 2026 01:46:59 +0800 Subject: [PATCH] docs: define bounded AI execution OS charter --- .../ISSUE_TEMPLATE/01-research-proposal.yml | 11 +- .github/pull_request_template.md | 3 + CONTRIBUTING.md | 19 +- README.md | 88 ++++--- SECURITY.md | 10 +- docs/architecture-hypotheses.md | 44 ++++ docs/c-first-kernel-contract.md | 100 +++++++- docs/conceptual-origin.md | 58 +++++ docs/evidence-policy.md | 77 ++++++ docs/execution-os-constitution.md | 238 ++++++++++++++++++ docs/experiment-roadmap.md | 74 +++--- docs/prior-art.md | 57 ++++- docs/research-questions.md | 32 +++ docs/threat-model.md | 47 +++- docs/vision.md | 49 +++- scripts/verify-repository.mjs | 2 + 16 files changed, 824 insertions(+), 85 deletions(-) create mode 100644 docs/execution-os-constitution.md diff --git a/.github/ISSUE_TEMPLATE/01-research-proposal.yml b/.github/ISSUE_TEMPLATE/01-research-proposal.yml index 4f2dd19..caac1c7 100644 --- a/.github/ISSUE_TEMPLATE/01-research-proposal.yml +++ b/.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 diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d400c8b..aaaa180 100644 --- a/.github/pull_request_template.md +++ b/.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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 90966da..c21131b 100644 --- a/CONTRIBUTING.md +++ b/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 必须列出实际执行的检查；未运行的验证应明确写明原因。 diff --git a/README.md b/README.md index 5d3eb0d..a9949cb 100644 --- a/README.md +++ b/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,53 +52,60 @@ 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`。 @@ -94,6 +113,7 @@ flowchart TD ## 文档 - [概念起源](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,10 +130,12 @@ 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 已完成研究的证据。 ## 当前不做 @@ -121,8 +143,10 @@ flowchart TD - 不用“C 代码少”替代内存安全、并发安全、状态机和故障恢复设计； - 不在最小闭环前同时铺开驱动、文件系统、网络栈、多核和分布式控制； - 不让模型直接控制中断、时间片、内存页或内核权限； +- 不把人工批准当作最终真值，也不把 provenance 当作事实裁决； - 不把所有 `if/else` 机械替换为强化学习； - 不预选模型、强化学习算法或分布式控制平面； +- 不在尚无真实社区时宣称多主体治理已经得到验证； - 不在没有基线、随机种子和失败证据时发布性能结论。 ## License diff --git a/SECURITY.md b/SECURITY.md index 0b0e247..2badefa 100644 --- a/SECURITY.md +++ b/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 行为； +- 依赖、工具链、构建产物、供应链来源和漏洞响应流程； +- 支持的凭据轮换、维护者恢复和主托管平台失效场景。 diff --git a/docs/architecture-hypotheses.md b/docs/architecture-hypotheses.md index 95e93b6..f237f12 100644 --- a/docs/architecture-hypotheses.md +++ b/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、服务、人类或托管平台的错误不自然升级为全局事故；需要验证的代价是恢复路径 +自身的状态空间、保留资源和长期维护成本。 diff --git a/docs/c-first-kernel-contract.md b/docs/c-first-kernel-contract.md index a4a5a5b..2c2347b 100644 --- a/docs/c-first-kernel-contract.md +++ b/docs/c-first-kernel-contract.md @@ -28,7 +28,70 @@ C 提供直接且可固定的 ABI 与内存布局控制，但 C 本身不会自 - 同时使用编译器警告、静态分析、sanitizer 宿主测试、模拟器和故障注入； - 把 warning 当作失败，固定工具链和编译参数，保存可重放构建证据。 -## 2. 生命周期不是框架移植 +## 2. C 可信核心不等于“所有确定性软件” + +C-first 约束的是内核侧可信执行边界，不是要求验收器、训练器、研究脚本和仓库治理全部使用 +C。可信核心只保留必须在目标权限级别完整调停的机制： + +- 稳定的 Principal 与 Object 句柄； +- 对 Capability 的范围、权利、版本、有效期与撤销状态检查； +- 生命周期与资源状态机； +- 资源包络、隔离、最低保障和动作幅度限制； +- `ALLOW / CLAMP / DENY` Guard； +- 只执行 allowlist 动作的有限执行器； +- 确定性 fallback、checkpoint 和恢复钩子； +- 将特权转换锚定到持久来源记录的最小接口。 + +身份认证、模型推理、训练、复杂查询、实验分析和外部验收原则上位于可信核心之外。内核可以 +保存身份句柄和授权关系，但不预先承诺自己实现完整账号系统、PKI、证据数据库或社区治理。 + +C 代码仍可能稳定地执行错误合同，因此“由 C 实现”只说明执行边界和候选可审查性，不构成 +正确性证明。可信核心必须尽量小，并通过完整调停、fail-safe default、最小权限和故障注入 +获得证据。 + +## 3. Principal、Capability 与动作合同 + +人、Agent、服务和策略运行时都作为 Principal。Principal 的模型能力、作者身份或人工批准 +不等于执行 authority。候选能力关系是： + +```text +Principal + possesses / receives +Capability + confers bounded authority over +Object +``` + +具体是否采用 seL4 式 capability space、句柄表或其他表示，要由 R0/R1 反证后决定；当前只 +固定以下语义： + +- Capability 必须指向明确 Object，并携带可校验的动作、范围和资源上限； +- 委托不能静默扩大权利，撤销和过期必须在后续访问中被完整调停； +- 执行器不能替调用方成为 confused deputy； +- 旧快照、旧 proposal 和旧 capability 不能在状态或版本变化后自动继续有效； +- break-glass 仍是显式、限域、限时、留痕的授权路径，不是绕过 Guard 的特殊入口。 + +所有特权动作使用有类型的候选合同： + +```text +ActionProposal { + principal; + capability; + target_object; + expected_state_version; + action_kind; + bounded_parameters; + resource_budget; + deadline; + policy_version; + correlation_id; +} +``` + +这不是冻结 ABI。字段名称和布局可以改变，但身份、授权、目标、版本、预算、时限和因果关联 +不能在实现时被省略。 + +## 4. 生命周期不是框架移植 Spring Boot 提供的是问题来源：对象和服务需要被发现、构造、装配、启动、运行、停机和 回收。FlowKernel 借用这套生命周期思维，但不把 Spring 容器、反射或依赖注入机制搬入 @@ -61,7 +124,7 @@ RESET `if`、`for` 和 `while` 足以表达控制流，却不足以自动形成正确系统。可靠性来自状态、所有权、 预算、退出条件和失败闭环都被显式定义，而不是来自语法数量少。 -## 3. 确定性基线永远先于强化学习 +## 5. 确定性基线永远先于学习策略 FlowKernel 首先实现一条不依赖模型也能完整运行的确定性路径： @@ -74,7 +137,8 @@ observed snapshot -> measured result ``` -强化学习只能作为 Slow Path 的策略顾问加入： +规则、启发式、强化学习、LLM 或 Agent 只能作为 Slow Path 的策略顾问加入；Attention 或其他 +状态筛选只能改变它们“看什么”，同样不获得执行权： ```text versioned snapshot @@ -84,7 +148,7 @@ versioned snapshot -> accept / clamp / reject ``` -学习策略不得： +策略源不得： - 直接写内核指针、页表、寄存器、中断状态或任意调度结构； - 在中断、上下文切换、锁和基本内存分配路径中同步推理； @@ -95,7 +159,27 @@ versioned snapshot 策略超时、崩溃、输出非法、版本不兼容、置信度不足或 Guard 拒绝时，系统必须在有界时间内 继续执行确定性基线。模型服务不可用不能成为内核不可用的原因。 -## 4. Linux 的角色 +## 6. 执行、来源记录与外部验收 + +C 可信核心对每次特权转换记录最小因果链：Principal、Capability、Proposal、目标、输入版本、 +Guard 裁决、实际动作、前后状态、结果和恢复引用。必须区分： + +```text +authorization -> execution -> observation +observation -> acceptance run -> AcceptanceVerdict +observation -> evidence -> EpistemicStatus +``` + +`ALLOW` 不表示动作已经成功，执行器返回 `SUCCEEDED` 也不表示业务目标或系统声明已经得到证明。 +外部验收通过 runtime、artifact、database、browser 或独立 verifier 读回结果；一次 run 产生 +`AcceptanceVerdict`，其 evidence 可以支持 `EpistemicStatus`，但二者不自动映射。验收器不能 +通过修改被验对象来制造通过。 + +来源记录也不是天然可信：身份冒用、记录丢失、顺序篡改、存储损坏和错误观测都必须进入威胁 +模型。高风险特权动作如果无法建立其声明所需的持久记录，应被拒绝或进入预先声明的 fail-safe +路径，不能静默降级为“执行了但以后再补日志”。 + +## 7. Linux 的角色 Linux、cgroup、`sched_ext` 和 eBPF 继续作为： @@ -107,17 +191,19 @@ Linux、cgroup、`sched_ext` 和 eBPF 继续作为： 它们不是 FlowKernel 最终可信核心的实现语言或永久执行底座。任何在 Linux 实验台得到的结论 都必须标注环境，不能直接声称已在 FlowKernel 内核中成立。 -## 5. 首个可实现边界 +## 8. 首个可实现边界 首个内核里程碑不追求通用操作系统功能齐全，只要求形成可验证的最小闭环： - 可重复启动、停止和异常退出； - 固定平台上的时钟、中断和最小上下文切换； - 静态任务与资源描述； +- 静态 Principal、Object 与最小权限描述； - 明确的生命周期状态机； - 一条确定性调度与资源回收基线； - 可拒绝非法建议的 C Guard； -- 串行审计记录和宿主侧可重放测试； +- 串行来源记录、宿主侧可重放测试和外部验收交接； +- 明确的 failure containment domain 与可触发的恢复路径； - 模型完全缺席时仍能正常运行。 文件系统、网络栈、驱动生态、多核扩展、在线强化学习和分布式控制都不能挤进这个最小闭环。 diff --git a/docs/conceptual-origin.md b/docs/conceptual-origin.md index 3bff749..9be461c 100644 --- a/docs/conceptual-origin.md +++ b/docs/conceptual-origin.md @@ -68,9 +68,67 @@ R0 还必须先固定受限 C 子集、工具链、启动契约和传统对照 FlowKernel 才会从概念来源进入最小内核实现。应用层项目可以提供 workload、故障模式和 资源边界样本，但它们只是问题来源与候选控制组，不是操作系统研究已经成立的证明。 +## 范围怎样继续演化 + +FlowKernel 的公开历史没有从一开始就包含完整的 AI Execution OS 设想。当前范围由几次可以 +追溯的工程问题逐步扩展： + +```text +Phase 1 +应用生命周期 + -> 长任务连续性 + -> 生命周期感知资源策略 + +Phase 2 +C-first target + -> deterministic Guard + -> bounded learned proposal + +Phase 3 +八仓归档与 Protecting Zero + -> 独立证据 + -> Human is not an Oracle + -> proposal / execution / fact 分离 + +Phase 4 +fresh checkout 与归档生存性 + -> Principal / capability / provenance + -> 维护者与凭据迁移 + -> compromised principal + -> no unchecked authority +``` + +Phase 1 和 Phase 2 形成了当前仓库原有的 C-first 资源策略骨架。Phase 3 和 Phase 4 没有证明 +新架构已经可行，只是把研究问题推进为：一个会误判的人、会幻觉的模型、会 reward hack 的 +策略和会崩溃的服务，能否在同一执行系统里参与决策，却不能未经授权和验收把判断升级为系统 +事实？ + +这次演化保留三条连续性： + +- 资源调度仍是第一个可比较研究方向，不被新术语吞掉； +- C-first 可信核心仍负责机制、完整调停、隔离与回退，不负责“变聪明”； +- 新思想先改变契约、威胁模型和实验顺序，不能被写成已经存在的内核模块。 + +本轮演化使用的工程材料也固定在公开历史坐标上： + +- 主页三篇文章分别讨论[协同能力](https://github.com/NoctilumeDev/NoctilumeDev/blob/281aaa9e3124b5c4018c3a7b1e63bf6edcc284a9/docs/from-tool-gain-to-collaborative-compounding.pdf)、 + [事实资格](https://github.com/NoctilumeDev/NoctilumeDev/blob/281aaa9e3124b5c4018c3a7b1e63bf6edcc284a9/docs/protecting-zero-from-answer-to-fact.pdf) + 和[对抗性验收](https://github.com/NoctilumeDev/NoctilumeDev/blob/281aaa9e3124b5c4018c3a7b1e63bf6edcc284a9/docs/adversarial-engineering-validation.pdf)； +- [VeriTrail 的证据模型](https://github.com/NoctilumeDev/VeriTrail/blob/f50d5e1abfc8fc052a36a5be1d5e09047625ebbf/docs/01-evidence-model.md) + 提供 Subject、Run、Evidence 与 Verdict 的分层参照； +- [MiniSpringBoot 的教学到工程化实验](https://github.com/NoctilumeDev/MiniSpringBoot/blob/946725ed80fed4a364f86d65e4b98962322345e7/docs/teaching-to-engineering.md) + 说明复杂度必须由真实失败空间获得资格，并在越过目标边界时停止； +- [PlainJournal 的 32 GiB 延期协议](https://github.com/NoctilumeDev/PlainJournal/blob/dd5a2f5649265595b4005a9bd451050801c01a37/docs/32gib-extended-validation-runbook.md) + 提供资源停止线、历史证据不回写和新宿主追加证据线的现场样本。 + +这些材料解释研究问题从哪里来，不证明 FlowKernel 已经实现或验证了对应机制。 + +详细边界见 [执行操作系统宪法](execution-os-constitution.md)。 + ## 与其他文档的关系 - [愿景与边界](vision.md) 定义研究对象、Fast Path 和 Slow Path； +- [执行操作系统宪法](execution-os-constitution.md) 定义 Principal、权限、状态轴、来源与恢复边界； - [C-first 内核契约](c-first-kernel-contract.md) 定义语言、生命周期、Guard 和回退边界； - [架构假设](architecture-hypotheses.md) 列出等待验证的结构； - [前人工作与阅读地图](prior-art.md) 约束新颖性判断； diff --git a/docs/evidence-policy.md b/docs/evidence-policy.md index 20b4dfa..288888a 100644 --- a/docs/evidence-policy.md +++ b/docs/evidence-policy.md @@ -15,6 +15,53 @@ FlowKernel 是长期研究仓库。状态标签和证据边界必须比功能数 README、Issue、PR、Release 和论文草稿必须使用这些词区分计划与事实。 +## 状态轴必须分开 + +研究成熟度不能替代一次动作的授权、执行或事实状态。FlowKernel 使用五条互相独立的语义轴： + +| 状态轴 | 状态 | 说明 | +| --- | --- | --- | +| Research maturity | `Idea / Planned / Designed / Prototype / Validated / Rejected` | 假设或实现成熟度 | +| Authorization | `ALLOW / CLAMP / DENY` | Guard 对一次 Proposal 的授权裁决 | +| Execution | `SUCCEEDED / FAILED / PARTIAL / UNKNOWN` | 执行器实际结果 | +| EpistemicStatus | `UNKNOWN / UNVERIFIED / VERIFIED / REFUTED` | 某项关于现实的声明是否获得证据资格 | +| AcceptanceVerdict | `PASS / FAIL / INCONCLUSIVE / BOUNDARY / PENDING` | 一次验收 run 在声明范围内的裁决 | + +不得使用以下推断： + +```text +Designed -> implemented +ALLOW -> action happened +SUCCEEDED -> goal is true +provenance -> evidence is authentic +human review -> final correctness +``` + +EpistemicStatus `UNKNOWN` 表示 Subject、声明或必要观察尚不足以进入验证；`UNVERIFIED` 表示声明 +已经明确且可检查，但 evidence 尚未达到验证或反驳门槛。Execution `UNKNOWN` 只表示动作结果 +无法可靠读回。 + +AcceptanceVerdict 不能机械倒灌到其他状态轴：`PASS` 只支持已声明 assertion 的 +`VERIFIED`；`FAIL` 可能是 Product、Execution、Validation 或 Host failure，只有事实反证才 +支持 `REFUTED`；`INCONCLUSIVE`、`BOUNDARY` 与 `PENDING` 保留当前认识边界。资源不足、事实 +源冲突、记录损坏或验证器越界时，不能为了结束 run 而推断成功。 + +## 特权转换的最低来源记录 + +每个需要 Guard 的动作至少绑定： + +- Principal 与代表关系； +- Proposal、输入 snapshot、policy/version 和 correlation id； +- Capability、目标 Object、动作权利、范围、预算、时限和授权裁决； +- pre-state、尝试动作、实际动作、post-state 与执行结果； +- checkpoint、rollback 或 recovery reference； +- 观测与外部 evidence reference； +- 记录格式、身份和完整性校验版本。 + +来源记录应在逻辑上追加而不是静默回写历史，但“append-only”不是防篡改证明。签名、哈希、 +持久存储和外部锚点分别需要自己的 threat model。记录只能说明它声称的因果链；事实是否成立 +仍由独立读回裁决。 + ## 实验记录最低要求 每项性能或正确性结论至少记录： @@ -29,6 +76,9 @@ README、Issue、PR、Release 和论文草稿必须使用这些词区分计划 - 随机种子、重复次数和统计方法； - latency、throughput、公平、完成率、连续性和控制开销； - 失败、超时、Guard 拒绝、降级、回滚和残留状态。 +- Principal、Capability、Proposal、Guard verdict、执行结果和外部验收的不同坐标； +- stop line、隔离域、预计恢复路径和实际恢复时间； +- 源码、构建物、策略、来源记录和报告各自的不可变身份。 ## 不接受的证据 @@ -41,6 +91,12 @@ README、Issue、PR、Release 和论文草稿必须使用这些词区分计划 - 以“使用 C”或“代码只包含简单循环”证明内核安全、正确或稳定； - 将 Linux reference lab 的结果描述为 FlowKernel target 已实现能力； - 仅优化 reward，却不检查饥饿和硬不变量。 +- 以模型能力、作者身份或人工批准证明动作有权执行； +- 以 Guard `ALLOW` 或执行器 `SUCCEEDED` 证明目标已经成立； +- 以日志存在、字段齐全、哈希一致或签名通过证明记录内容必然真实； +- 使用可移动分支名替代固定 commit、artifact 或 evidence identity； +- 用新机器上的成功覆盖旧宿主上的失败、资源边界或未完成证据； +- 用单维护者模拟的“双角色”证明多人职责分离已经成立。 ## 安全与可恢复性 @@ -52,10 +108,31 @@ README、Issue、PR、Release 和论文草稿必须使用这些词区分计划 - 回退到确定性策略的时间和业务影响； - 策略版本回滚和状态兼容； - 节点、控制器或观测器重启后的恢复。 +- capability 过期、撤销、重放、委托泄漏与 confused deputy； +- Principal 凭据被盗、Guard/authority root 被修改和来源记录被截断或重排； +- 维护者换机、凭据重签发和主托管平台不可用时的工程恢复。 硬不变量发生一次违约，即视为该实验失败，不能用平均收益抵消。 +## 外部 Acceptance 的证据边界 + +FlowKernel target 负责产生受控动作与运行记录，不独占事实解释权。宿主侧 Acceptance 可以读取 +runtime、artifact、database、browser、hardware counter 或独立 verifier，但必须： + +1. 声明 Subject、环境、固定坐标和观察范围； +2. 不修改被验对象、Guard 或权威历史来制造通过； +3. 区分 Product、Validation 与 Host failure； +4. 保留第一次失败、边界、恢复和清理证据； +5. 在证据不足时输出未验证、边界或不确定，而不是推断成功。 + +VeriTrail 的证据模型、GitHub required checks 和发布物读回可以作为方法参照，但当前仓库没有 +实现通用 Acceptance Workbench，也不把这些外部系统写成内核组件。 + ## 发布规则 规划阶段不发布伪造的 `v1.0.0`。首个 Release 应对应可运行、可重复的 R0 基线，并附带 环境、脚本、原始结果摘要和已知限制。版本号表示仓库交付状态，不表示研究结论已经普适。 + +后续实验以追加证据线表达新宿主、新策略或新治理条件；不得回写旧 event 中各轴的原值。例如 +Execution `FAILED`，AcceptanceVerdict `FAIL / INCONCLUSIVE / BOUNDARY / PENDING`，或 +EpistemicStatus `UNVERIFIED / REFUTED`，都只能由新证据线补充，不能被新条件下的结果覆盖。 diff --git a/docs/execution-os-constitution.md b/docs/execution-os-constitution.md new file mode 100644 index 0000000..aa94811 --- /dev/null +++ b/docs/execution-os-constitution.md @@ -0,0 +1,238 @@ +# 执行操作系统宪法 + +**Evidence state: Designed. No implementation has been validated.** + +本文定义 FlowKernel 从“生命周期感知的资源策略研究”继续演化时，哪些边界不能被后续实现、 +模型能力或社区规模冲掉。它是一份研究宪法，不是模块清单，也不证明多主体治理、能力系统、 +来源记录或外部验收已经实现。 + +## 1. 演化后的问题 + +FlowKernel 最初追问：操作系统能否理解 workload 所处的生命周期、真实进展和连续运行价值， +而不只根据瞬时资源占用做决定。这个问题仍然成立，资源调度仍是第一个核心研究方向。 + +后续工程实践又暴露了一个更上游的问题：规则、强化学习、Agent、大模型和人类维护者都可能 +给出局部合理、整体错误的判断。单纯提高模型能力，或者把人工审批放在流程末端，都不能证明 +行动正确。系统需要回答： + +> How can fallible intelligence act without becoming sovereign? + +FlowKernel 因而扩展为一个规划中的 C-first AI Execution OS 研究项目：它研究如何让不完全 +可靠的策略源在确定性的身份、权限、资源、隔离、生命周期、来源记录和恢复边界内提出并执行 +有界动作，使智能可以犯错，但错误不能自然升级为系统级失控或未经验证的工程事实。 + +这不是重写项目起源。原始资源策略问题、C-first 可信核心、Fast/Slow Path、确定性 Guard 和 +Linux reference lab 都继续保留；新增的是行动权、事实资格、治理权和工程连续性边界。 + +## 2. 基本对象与术语 + +本文只固定需要跨阶段保持一致的概念，不预先冻结实现模块。 + +| 概念 | 含义 | +| --- | --- | +| Principal | 发起、委托或承担行动责任的主体；人、Agent、服务和未来的组织身份都属于 Principal | +| Object | 被读取、修改、调度、迁移或治理的系统对象 | +| Capability | 指向特定 Object、携带有限权利并可被校验的授权载体；在能力安全语义中，它本身授予有界 authority | +| Proposal | 规则、启发式、RL、LLM 或人工提出的候选动作，不自带执行权 | +| Authorization | Guard 根据 Principal、Capability、Object、状态和预算作出的 `ALLOW`、`CLAMP` 或 `DENY` | +| Action | 执行器实际尝试的有界状态转换 | +| Observation | 对执行过程或结果的观测；可能缺失、延迟、错误或被污染 | +| Evidence | 能被定位、读回并用于支持或反驳声明的观察材料 | +| EpistemicStatus | 关于现实的声明当前获得的事实资格 | +| AcceptanceVerdict | 一次有明确 Subject、环境与边界的验收 run 得到的结果 | + +规则、模型和 policy 是由 Principal 使用的版本化 Artifact，不因为能生成 Proposal 就自动成为 +持有 Capability 的身份主体；承载它们的 Agent、服务或策略运行时才承担身份与行动责任。 + +因此需要保持两条区别： + +```text +Model competence != execution authority +Capability holder != truth owner +``` + +模型“会做”不等于模型“有权做”；持有执行权、完成一次动作，也不等于关于现实的声明已经成立。 + +## 3. 不能混用的状态轴与验收结果 + +| 状态轴 | 候选状态 | 回答的问题 | +| --- | --- | --- | +| Research maturity | `Idea / Planned / Designed / Prototype / Validated / Rejected` | 研究成熟到哪里？ | +| Authorization | `ALLOW / CLAMP / DENY` | 这个动作是否有权发生？ | +| Execution | `SUCCEEDED / FAILED / PARTIAL / UNKNOWN` | 动作实际执行成什么状态？ | +| EpistemicStatus | `UNKNOWN / UNVERIFIED / VERIFIED / REFUTED` | 关于现实的声明获得了什么事实资格？ | +| AcceptanceVerdict | `PASS / FAIL / INCONCLUSIVE / BOUNDARY / PENDING` | 一次声明过边界的验收 run 得到什么裁决？ | + +EpistemicStatus `UNKNOWN` 表示 Subject、声明或必要观察尚不足以进入验证；`UNVERIFIED` 表示声明已经 +明确且可检查，但当前 evidence 尚未达到验证或反驳门槛。Execution `UNKNOWN` 则只表示动作 +结果无法可靠读回，不能与前两者合并。 + +一个典型链条应当是： + +```text +LLM claim -> UNVERIFIED +typed proposal -> ALLOW +bounded executor -> SUCCEEDED +independent readback -> VERIFIED +``` + +其中： + +```text +ALLOW != TRUE +SUCCEEDED != VERIFIED +``` + +AcceptanceVerdict 也不自动映射为认识状态：`PASS` 只能支持本次已声明 assertion 的 +`VERIFIED`；`FAIL` 可能来自产品、执行器、验证器或宿主，只有事实反证才能支持 `REFUTED`； +`INCONCLUSIVE`、`BOUNDARY` 和 `PENDING` 都不能被升级为成功。资源不足、观测冲突或验收链 +不完整时，系统必须保留 `UNKNOWN`、`PARTIAL` 或未验证状态。 + +## 4. 八条宪法边界 + +1. **概率智能默认不拥有执行主权或事实权。** 规则、启发式、RL、LLM、Agent 与人工判断都 + 可以产生候选策略，但都不能仅凭自信把判断写成系统事实。 +2. **所有行动主体都是 Principal。** Human、Agent、Service 的身份、能力与授权分开；人类 + 可以定义目标和批准高风险动作，但不因处在流程末端就成为天然 Oracle。 +3. **所有特权状态转换必须由确定性可信核心完整调停。** 不为作者、管理员、模型或“紧急 + 情况”保留不可见旁路。 +4. **硬不变量不可学习。** 权限范围、资源上限、隔离、最低保障、合法生命周期边、动作幅度、 + 停止线和确定性 fallback 由可审查机制约束，不能交给 reward 自行领悟。 +5. **特权状态转换必须留下可重建的因果来源。** 但 provenance 只说明记录声称发生了什么， + 不自动证明记录真实、结果正确或业务目标成立。 +6. **错误必须被限制在已授权的隔离域内。** 预算、速率、冷却、租约、checkpoint、回退和恢复 + 都服务于 fault containment，而不是把“模型永不出错”当作前提。 +7. **没有普通 Principal 拥有无限、不可审计、不可约束、不可撤销的系统权力。** 高风险治理 + 变化与 break-glass 必须显式、限域、限时、留痕，并具有撤销或恢复路径。 +8. **UNKNOWN 必须得到保护，系统自身也必须可恢复。** 模型缺席、节点失败、维护者换机、 + 凭据轮换或原托管平台失效，都不能自动抹掉系统事实与工程记忆。 + +这里的“没有绝对控制权”不是声称物理机所有者、固件、编译器或托管平台已经被 FlowKernel +消除。它表示在系统所声明的信任边界内，不给任何日常主体提供未经完整调停的 God Mode； +边界之外的根权限仍必须作为外部 failure domain 明确记录。 + +## 5. 候选控制链 + +```mermaid +flowchart TD + principal["Human / Agent / Service\nPrincipal"] --> intent["Intent / Request"] + intent --> policy["Policy plane\nRule / Heuristic / RL / LLM"] + policy --> proposal["Versioned ActionProposal\nUntrusted"] + proposal --> core["C-first trusted core\nIdentity handles / Capability checks\nLifecycle / Resource / Isolation\nGuard / Bounded executor / Recovery"] + core --> runtime["Runtime / Hardware"] + runtime --> observation["Result / Observation"] + observation --> acceptance["External acceptance\nRuntime / Artifact / DB / Browser / Verifier"] + acceptance --> runVerdict["AcceptanceVerdict\nPASS / FAIL / INCONCLUSIVE / BOUNDARY / PENDING"] + acceptance --> evidence["Evidence"] + evidence --> epistemic["EpistemicStatus\nUNKNOWN / UNVERIFIED / VERIFIED / REFUTED"] + runVerdict --> policy + epistemic --> policy +``` + +这个结构故意保留两条边界： + +- C-first 可信核心负责“动作能否发生、怎样有界发生、失败怎样回退”，不负责替业务世界宣布 + 最终真值； +- 外部验收负责“行动后的现实究竟是什么”，但不直接修改被验对象、Guard 或历史记录。 + +VeriTrail、GitHub 门禁、数据库、浏览器和发布物读回可以为 Acceptance 提供方法或事实源， +但它们不会被机械塞进内核。FlowKernel 集成的是约束思想，不是把现有工具堆成一个产品套件。 + +## 6. 运行权与治理权 + +FlowKernel 必须区分： + +- **Runtime authority：** 谁能让一次状态转换发生； +- **Governance authority：** 谁能改变允许哪些状态转换、谁能授予能力、哪些记录具有权威性。 + +运行时动作由 C Guard 完整调停。修改硬不变量、Guard、authority root、审计要求、特权动作集 +或策略发布规则，则属于治理变化，必须成为独立、版本化、可回滚的对象。 + +成熟阶段可以研究职责分离和多人授权，但不能在单维护者阶段伪造社区治理。本仓库当前仍由 +单一维护者和 GitHub 承载；这只能证明设计方向，不能证明多主体治理已经成立。第一阶段可先 +落实“显式变更对象 + Pull Request + 确定性门禁 + 不可混淆历史”，以后再用真实社区参与反证 +多人授权、委托、撤销与维护者更换。 + +break-glass 不是无条件 bypass。候选合同至少包括：明确 Principal、理由、作用域、到期时间、 +受影响 Object、事前或事后复核要求、完整 provenance，以及恢复到正常权限图的路径。是否需要 +双人规则由风险和阶段决定，不预先把组织规模写成内核机制。 + +## 7. Failure Containment Contract + +FlowKernel 不以消除幻觉、误判或 reward hacking 为可交付目标。它要求错误影响被限制在已经 +授权的隔离域内： + +```text +Error impact is a subset of the authorized isolation domain. +``` + +任何策略源都不能因为一次错误判断而自然获得以下能力： + +- 修改不属于该 Principal 的对象； +- 吃掉内核、Guard、恢复路径或关键 workload 的保留资源； +- 越过 resource envelope、动作幅度、速率与重试上限； +- 跨租户、跨恢复所有者或跨证据边界传播副作用； +- 删除确定性基线、checkpoint 或来源记录； +- 在结果未知时自动扩大权限或继续升压。 + +策略超时、崩溃、输出非法、版本不兼容、震荡或分布漂移时，系统必须在有界时间内进入声明过 +的确定性 fallback。fallback 也需要测试和资源预算，不能只作为架构图上的箭头。 + +## 8. 来源记录、事实与恢复 + +每次特权转换至少应能重建： + +```text +principal +request / proposal +input snapshot +policy and version +capability / authority +target object +resource and time budget +guard verdict +attempted and actual action +pre-state / post-state +result +checkpoint / recovery reference +evidence reference +``` + +逻辑上的 append-only 不能被描述成天然防篡改。来源记录的可信度还依赖身份、密钥、完整性 +校验、存储边界和必要的外部锚点；记录缺失或相互冲突时，验收只能给出未验证或不确定结果。 + +恢复也不只指 workload migration： + +| 层次 | 需要回答的问题 | +| --- | --- | +| Workload portability | 任务能否检查点、迁移和幂等恢复？ | +| Runtime portability | 固定合同能否在另一受支持平台重建？ | +| Maintainer portability | 原机器消失后，维护者能否从版本化资产恢复工程状态？ | +| Authority portability | 凭据能否撤销、轮换和重新签发，而不丢失项目控制链？ | +| Repository survivability | 主托管平台失效后，完整对象图、合同与关键证据能否恢复？ | + +这些层次属于同一恢复哲学，但不应全部塞入最小 C scheduler。内核负责其声明范围内的运行时 +恢复；仓库、构建、发布和维护者连续性由工程治理合同承担。 + +## 9. 当前不冻结的内容 + +本文不预先决定： + +- FlowKernel 最终采用 seL4 式 capability space、句柄表还是其他权限表示； +- provenance 使用图数据库、事件流、文件还是其他载体； +- RL、LLM、Attention 或任何具体模型一定进入最终系统； +- 多节点、分布式证据库、高可用协调器或 GPU scheduler 的产品架构； +- 单维护者阶段以后采用何种社区角色、投票或发布制度。 + +候选核心抽象只有 Principal、Object、Capability、State、Proposal、Action、Artifact、Evidence +和 Recovery。它们的精确对象边界必须由最小实现、反例和前人工作继续压缩，不能由本文提前 +注册成一座组件城市。 + +## 10. 停止条件 + +本轮文档对齐达到以下结果即可停止：项目身份、可信边界、状态轴、威胁模型、证据策略和路线图 +指向同一问题；原始资源调度研究没有被抹除；后来形成的思想没有被伪装成项目起源；未来实现 +仍必须从确定性最小闭环开始。 + +继续增加术语、层级或未来组件不会让这些边界更真实。只有实现、反例或更可靠的前人工作出现 +后，才有资格修改这份宪法。 diff --git a/docs/experiment-roadmap.md b/docs/experiment-roadmap.md index 263921f..2528ac2 100644 --- a/docs/experiment-roadmap.md +++ b/docs/experiment-roadmap.md @@ -3,10 +3,10 @@ 路线图描述依赖顺序，不承诺开始时间。研究生阶段正式启动前，可以继续补充文献、问题和 实验设计，但不使用空实现制造进度。 -## R0：契约、工具链与传统基线 +## R0：宪法、可信边界、工具链与传统基线 -目标：固定目标架构、受限 C 子集、编译/链接/模拟器工具链，并建立可重复 workload、指标和 -Linux 传统策略对照组。 +目标：固定执行操作系统宪法、声明的可信边界、受限 C 子集、编译/链接/模拟器工具链，并建立 +可重复 workload、指标和 Linux 传统策略对照组。此阶段不写空内核制造进度。 最低证据： @@ -15,56 +15,71 @@ Linux 传统策略对照组。 - 保存配置、随机种子和原始结果； - 覆盖 CPU-bound、I/O-bound、memory pressure、重试和长任务； - 报告平均值、分位数、波动和失败，而不是单次最好结果。 +- 明确 Principal、Object、Capability、Proposal、Action、Observation、Evidence、 + AcceptanceVerdict 和 EpistemicStatus 的语义边界，但不预先冻结模块或 ABI； +- 记录宿主、编译器、托管平台和单维护者作为当前外部 failure domain； +- 从干净机器只依靠仓库、文档化工具链和网络重建 R0；失败时记录隐藏环境依赖，不降低门槛。 -## R1：最小 C 内核与生命周期状态机 +## R1：最小 C 内核、静态身份句柄与生命周期状态机 目标：在固定平台上建立可重复启动、停止和故障退出的最小 C 内核，完成时钟、中断、最小 -上下文切换、静态任务与显式生命周期状态机，不引入学习策略。 +上下文切换、静态 Principal/Object 描述、最小权限句柄、静态任务与显式生命周期状态机， +不引入学习策略。 退出条件：每个状态转换都有前置条件、所有者、超时、后置不变量和失败路径；模型完全缺席 -时内核仍可运行；构建和启动可重放。 +时内核仍可运行；无 Capability 的动作默认拒绝；构建和启动可重放。 -## R2：确定性资源机制与 Guard +## R2：确定性 authority、资源、隔离与 Guard 目标：实现确定性调度、资源回收、有限动作执行器与 C Guard，并使用 Linux reference lab -中的 cgroup、容器控制器、`sched_ext` 或 eBPF 建立同语义对照。 +中的 cgroup、容器控制器、`sched_ext` 或 eBPF 建立同语义对照。逐步验证静态 Capability 的 +范围、过期、撤销、时限和版本，而不是先实现通用账号系统或动态委托网络。 -退出条件：每个动作都有权限边界、最大幅度、回滚路径和开销数据；控制器失效不影响 -Fast Path 基本运行；非法建议不能越过 C Guard。 +退出条件：每个动作都有 Principal、目标 Object、权限边界、资源预算、最大幅度、可逆性分类 +和开销数据；撤销后的旧能力、旧快照与重放提案不能继续有效；Guard 或 authority state 崩溃、 +损坏、卡死和资源耗尽时进入声明的 fail-safe；非法建议不能越过 C Guard。 -## R3：生命周期观测与状态筛选 +## R3：来源记录、恢复与外部验收交接 + +目标：在没有学习策略的条件下，为特权转换建立最小可重建因果链、持久状态和恢复引用，并将 +执行结果交给独立的宿主侧 Acceptance 读回。 + +退出条件：能区分 `ALLOW`、`SUCCEEDED` 与 `VERIFIED`；记录缺失、截断、重排、身份冒用、 +存储失败和相互冲突的事实源不会被判成成功；恢复路径和来源记录都在资源压力下得到验证。 + +## R4：生命周期观测与状态筛选 目标：建立可回放 workload 观测，再比较人工特征、统计选择、Attention 和完整状态输入。 -退出条件：说明筛选后的信息损失、推理成本和可解释性，不能只报告模型准确率。 +退出条件：说明筛选后的信息损失、探针污染、推理成本和可解释性，不能只报告模型准确率； +Attention 不获得执行权。 -## R4：受约束策略学习 +## R5：受约束策略学习 目标：在内核外或隔离边界内，依次比较自适应阈值、模仿学习和受 C Guard 约束的强化学习。 退出条件：在相同 workload 和预算下超过已调优规则基线，并通过非法动作、策略超时、 -奖励投机、饥饿和控制振荡测试。 +奖励投机、饥饿和控制振荡测试。学习策略只能产生与规则基线同类型的 Proposal；不能因模型 +效果更好而扩大 Capability 或修改硬不变量。 -## R5：连续性、检查点与迁移 +## R6：连续性、检查点、迁移与委托 -目标：将决策对象从单机资源预算扩展到 checkpoint、迁移、恢复和放置。 +目标：将决策对象从单机资源预算扩展到 checkpoint、迁移、恢复、放置以及跨 Principal 的 +动态有界委托和撤销。 -退出条件：任务身份和恢复幂等，网络分区下不产生双重执行事实，失败后可以对账和收敛。 +退出条件：任务身份和恢复幂等，委托不扩大原能力，撤销对在途与恢复动作有明确语义，恢复后 +Capability、租户隔离和执行所有权不被静默扩大；网络分区下不产生双重执行事实，失败后可以 +对账和收敛。没有两个真实独立主体参与时，只能验证协议行为，不能把角色模拟标成多人治理 +`Validated`；治理 liveness 需要在真实维护者结构出现后单独过门。 -## R6：多核、多节点与长期稳定性 +## R7：多核、多节点、AI workload 与长期稳定性 目标：在单核最小闭环稳定后逐步验证多核并发，再验证节点失效、状态延迟、策略不可用、 -磁盘或网络压力以及长时间运行。 - -退出条件：硬不变量零违约；所有降级、恢复和残留状态都有可审查证据。 - -## R7：AI workload 专项验证 - -目标：在 FlowKernel target 与 Linux reference lab 使用同预算实验，研究编译测试 Agent、 -模型推理、训练或数据流水线等长周期 workload。 +磁盘或网络压力以及长时间运行；在 FlowKernel target 与 Linux reference lab 使用同预算 +研究编译测试 Agent、模型推理、训练或数据流水线等长周期 workload。 -退出条件：证明生命周期信息带来的收益并非 workload 特制规则造成，且策略开销没有抵消 -收益。 +退出条件：硬不变量零违约；所有降级、恢复和残留状态都有可审查证据；生命周期信息带来的 +收益并非 workload 特制规则造成，且策略、来源记录和验收开销没有抵消收益。 ## 每阶段通用控制变量 @@ -75,3 +90,6 @@ Fast Path 基本运行；非法建议不能越过 C Guard。 5. 新策略必须与简单基线使用相同资源预算和数据集。 6. 结果同时记录成功、失败、回滚和未完成实验。 7. C warning、静态分析告警、sanitizer 宿主测试失败和未定义行为迹象都必须进入失败证据。 +8. 人工批准、Guard 放行、执行成功和独立验收分别记录，不能相互代替。 +9. 一次只验证一个授权或治理变量；单维护者模拟不能冒充真实多人治理。 +10. 新机器或新平台结果追加为新证据线，不覆盖原宿主上的失败、边界或未完成记录。 diff --git a/docs/prior-art.md b/docs/prior-art.md index 0dfe5da..d4faa8f 100644 --- a/docs/prior-art.md +++ b/docs/prior-art.md @@ -4,6 +4,43 @@ 建立基线，不能据此宣称研究问题新颖或方案有效。正式开题前必须补充检索方法、时间范围、 纳入标准和引用版本。 +## 保护、能力与可信边界 + +- [Saltzer 与 Schroeder：The Protection of Information in Computer Systems](https://web.mit.edu/Saltzer/www/publications/protection/)： + 提出 economy of mechanism、fail-safe defaults、complete mediation、separation of privilege、 + least privilege 等经典原则。FlowKernel 应把它们作为可信核心和权限动力学的起点，而不是 + 把“C Guard”当作新发明。 +- [seL4 Capabilities Tutorial](https://docs.sel4.systems/Tutorials/capabilities.html)：能力是指向 + 对象、携带访问权的不可伪造授权载体。它用于校准 `Capability`、Object 与 authority 的词义； + 当前不意味着 FlowKernel 已决定采用 seL4、微内核或 CSpace 设计。 +- [seL4 Capability Distribution Language](https://docs.sel4.systems/projects/capdl/index.html)： + capability distribution 会限制系统未来可达状态，可作为静态权限图和最小系统描述的研究 + 参照。 +- [NIST Separation of Duty](https://csrc.nist.gov/glossary/term/separation_of_duty)：说明职责与访问 + 授权可以被拆分，从而减少单一主体独立滥用系统的风险。FlowKernel 只把它作为未来高风险 + governance transition 的候选原则，不在单维护者阶段伪造多人治理。 + +## Runtime assurance 与不可信策略 + +- [NASA：A Formal Verification Framework for Runtime Assurance](https://ntrs.nasa.gov/citations/20240006522)： + Simplex runtime assurance 允许不可信高级控制器工作，并在安全条件不满足时切换到可信回退 + 控制器。它是“学习策略可失效、确定性 fallback 必须独立存在”的直接参照。 +- FlowKernel 的边界比单一控制器切换更宽：还需要 Principal、Capability、来源记录、资源隔离 + 和外部事实验收。不能因结构相似就宣称已经继承 Simplex 的形式化保证。 + +## 来源记录、供应链与可复现性 + +- [W3C PROV-O](https://www.w3.org/TR/prov-o/)：以 Entity、Activity、Agent 及 derivation、 + attribution、delegation 等关系表达来源。FlowKernel 可以借用词义和最小关系，不预设 RDF、 + 图数据库或完整 PROV 实现。 +- [in-toto Specifications](https://in-toto.io/docs/specs/)：提供软件供应链步骤、材料、产物和 + attestations 的成熟表达。它约束“谁声称做了什么”，但 attestation 仍需身份与验证策略。 +- [SLSA Provenance](https://slsa.dev/spec/v1.2/provenance)：把 provenance 定义为可验证地追踪 + 软件工件从哪里、何时、怎样产生的信息。FlowKernel 需要区分来源记录与业务真值，不能把 + provenance 字段齐全当成事实正确。 +- [Reproducible Builds：Making plans](https://reproducible-builds.org/docs/plans/)：要求固定或记录 + 构建环境、引入环境变化并提供简单的比较协议。它为 R0 干净机器恢复和供应链反查提供基线。 + ## Linux 机制与观测 - [Linux `sched_ext` 文档](https://docs.kernel.org/scheduler/sched-ext.html)：可动态加载 BPF @@ -23,7 +60,7 @@ - [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec)：定义容器 runtime bundle、生命周期和 Linux 隔离接口，是 workload 抽象与运行时边界的基线。 - [CRIU](https://github.com/checkpoint-restore/criu)：提供 Linux 用户空间 checkpoint/restore - 实现。R5 的迁移研究应先验证其适用范围、内核依赖和不可迁移资源，而不是假设任意任务都 + 实现。R6 的迁移研究应先验证其适用范围、内核依赖和不可迁移资源，而不是假设任意任务都 能透明迁移。 ## 集群资源管理 @@ -45,11 +82,27 @@ ## 与 FlowKernel 的差异待证 -当前只能提出三项待检验差异，不能表述为贡献： +当前只能提出五项待检验差异，不能表述为贡献： 1. 将 workload 生命周期、检查点距离和有效进展作为长期策略状态； 2. 将学习建议与拥有最终否决权的确定性执行边界组合； 3. 同时评价连续性、饥饿、恢复和控制开销，而不是只优化平均完成时间。 +4. 让 Human、Agent、Service 和策略源通过同一有界授权语义参与动作，而不共享隐藏 God Mode； +5. 将授权、执行、来源记录和外部事实验收分层，并验证错误影响与工程恢复边界。 R0 开始前，需要建立文献矩阵，逐项记录问题、状态、动作、目标、约束、实验环境和公开 局限。若已有工作覆盖上述差异，应修改研究问题，而不是维护预设的新颖性。 + +## Linux reference lab 的许可证边界 + +FlowKernel 当前仓库使用 Apache-2.0；Linux 内核源码遵循其自己的 GPL-2.0-only 与兼容许可证 +规则。Linux、`sched_ext`、eBPF 和相关实现可以用于运行、调用、测量、阅读与对照，但不能 +因为“只是参考实验”就把源代码无来源复制进 Apache-2.0 core。 + +- [Linux kernel licensing rules](https://docs.kernel.org/process/license-rules.html) 是内核源码 + SPDX 与许可证规则的权威入口； +- [Apache License v2.0 and GPL compatibility](https://www.apache.org/licenses/GPL-compatibility) + 说明 Apache-2.0 与 GPLv2 的兼容性限制。 + +未来每份代码贡献都需要记录原始来源、SPDX 标识和是否复制/修改代码；不确定时停止合入并 +寻求合适的许可证审查。这里记录的是工程风险边界，不是法律意见。 diff --git a/docs/research-questions.md b/docs/research-questions.md index 3787ec1..1e3e775 100644 --- a/docs/research-questions.md +++ b/docs/research-questions.md @@ -40,6 +40,7 @@ - 如何在策略不可用、超时、输出非法或置信度不足时降级？ - 如何证明关键任务不会因奖励函数而饥饿？ - 如何限制动作速率，避免控制器振荡？ +- Guard 自身崩溃、卡死、资源耗尽或状态损坏时，怎样避免它成为新的单点故障？ ## RQ6：FlowKernel 与 Linux 对照如何成立 @@ -67,3 +68,34 @@ - 策略推理时间、非法建议率和 Guard 拒绝率。 任何单一指标的改善都不能自动证明整体策略更优。 + +## RQ9：Principal 与 authority 如何建模 + +- Human、Agent、Service 和策略运行时如何进入同一 Principal 模型，而不抹掉各自的责任差异？ +- Capability 应怎样绑定 Object、动作、范围、资源预算、时限和版本？ +- Capability 粒度过粗会扩大爆炸半径，过细会增加传播、校验与撤销成本；怎样找到可测边界？ +- 委托如何避免静默扩权，撤销如何对缓存、在途动作和恢复任务完整生效？ +- 如何阻止 Agent 借用高权限执行器形成 confused deputy？ +- 哪些动作可以单主体授权，哪些治理变化需要职责分离或多主体确认？ +- break-glass 如何保持显式、限域、限时、可审计和可恢复？ + +## RQ10：执行事实与世界事实如何分开 + +- `ALLOW`、执行器 `SUCCEEDED`、观测结果和 `VERIFIED` 分别由谁产生，怎样避免状态混轴？ +- 一个特权转换最少需要记录哪些 Principal、Capability、Proposal、前后状态和恢复引用？ +- 来源记录怎样发现缺失、截断、重排、身份冒用和存储损坏？ +- provenance、日志和签名各自能证明什么，又不能证明什么？ +- 来源记录与独立读回的 CPU、内存、I/O、时延和长期存储成本会不会抵消策略收益？ +- 外部 Acceptance 如何读取 runtime、artifact、database 或其他事实，却不获得修改被验对象的权力？ +- 事实源冲突、资源不足或结果不可读时，怎样保护 `UNKNOWN` 而不是制造成功？ + +## RQ11：系统自身怎样持续存在 + +- workload portability、runtime portability 和 maintainer portability 的合同怎样分层？ +- 原机器、凭据或托管平台失效后，哪些状态可重建、可重签发、必须备份或可以丢弃？ +- authority root、Guard 和硬不变量的治理变化由谁提出、批准、发布、回滚和复核？ +- 单维护者阶段能验证哪些治理机制，哪些必须等待真实社区参与？ +- 多主体授权怎样既限制单点滥用，又避免审批死锁、无人可恢复和紧急情况长期停摆？ +- checkpoint 与恢复怎样保持原 Capability 和隔离边界，避免“为了恢复”产生静默扩权？ +- 如何证明确定性 fallback、checkpoint、仓库对象图和关键证据在声明的故障模型下可以恢复？ +- 物理机所有者、固件、编译器和托管平台等边界外根权限应如何记录为 failure domain？ diff --git a/docs/threat-model.md b/docs/threat-model.md index 79a8e3b..a6c337d 100644 --- a/docs/threat-model.md +++ b/docs/threat-model.md @@ -9,6 +9,7 @@ - 宿主机和关键 workload 的可用性； - 租户、容器、进程和节点之间的权限与资源隔离； - 策略、模型、配置、观测数据和动作记录的完整性； +- Principal、Capability、委托、撤销和治理变化的完整性； - checkpoint、迁移、恢复和执行所有权的唯一性； - 确定性回退路径和紧急资源的可用性； - 实验原始数据、随机种子和失败证据的可追溯性。 @@ -18,6 +19,8 @@ | 组件 | 默认信任级别 | 约束 | | --- | --- | --- | | workload 与应用进度信号 | 不可信 | 可能错误、过期、伪造或被操纵 | +| Human / maintainer / administrator | 有权但非 Oracle | 可能误判、定义错误目标、越权或凭据被盗 | +| Agent / service principal | 不可信请求方 | 只能在持有的 Capability 范围内请求动作 | | FlowKernel C 可信核心 | 可信计算基 | 必须小、可测试、可在无模型时独立运行 | | 最小架构汇编 | 高风险可信边界 | 只提供 C 无法表达的启动、中断和切换接口 | | 内核与硬件计数器 | 有限可信 | 仍可能延迟、丢失、溢出或被错误解释 | @@ -27,6 +30,9 @@ | 特权执行器 | 高风险可信组件 | 只接受 Guard 许可的 allowlist 动作 | | Linux reference lab | 外部对照环境 | 结果不能直接视为 FlowKernel 内核证据 | | 多节点状态与网络 | 不可信时序 | 允许延迟、重复、分区和重放 | +| 身份、密钥与构建供应链 | 外部高风险边界 | 可能冒用 Principal、替换策略、二进制或 provenance | +| Acceptance / verifier | 独立但非绝对可信 | 可能观察不全、合同错误或与被验对象共享错误前提 | +| 物理机、固件与托管平台所有者 | 声明边界外根权限 | 当前不能由 FlowKernel 消除，只能作为 failure domain 记录 | ## 主要威胁 @@ -42,34 +48,71 @@ 9. **状态陈旧**：多节点决策基于过期状态，造成重复恢复、双重执行或资源超配。 10. **检查点破坏**：不完整、被篡改或不兼容的 checkpoint 被用于迁移和恢复。 11. **资源耗尽**：策略推理、遥测和审计本身耗尽 CPU、内存、I/O 或网络。 +12. **Principal compromise**：维护者、管理员、Agent 或服务凭据被盗，合法身份被用于非法目标。 +13. **Confused deputy**：低权限主体诱导高权限组件代为执行其本无权完成的动作。 +14. **委托与撤销失效**：过期、撤销或泄漏的 Capability 仍可重放，在途动作继续扩大副作用。 +15. **Guard / policy-root tampering**：攻击者不绕过 Guard，而是修改 Guard、硬不变量、 + authority root 或动作 allowlist 本身。 +16. **来源记录篡改**：删除、截断、重排、伪造或替换 action history，使错误行为获得虚假因果链。 +17. **验收污染**：verifier、浏览器控制层、测试环境或共享上下文改变被验事实，或把边界外状态 + 错判为产品缺陷与成功。 +18. **供应链替换**：编译器、链接器、依赖、构建动作、策略 artifact 或发布载体被替换。 +19. **治理接管**：单个高权限主体未经可见流程修改 Guard、发布策略、审计要求或权威历史。 +20. **可信核心单点失效**：Guard 或 authority state 卡死、崩溃、耗尽资源或损坏，使安全与可用性 + 同时依赖一个无法恢复的组件。 +21. **恢复扩权**：checkpoint、灾难恢复或维护者接管路径绕过原 Capability、租户隔离或审计要求。 +22. **治理失活**：职责分离或多人批准形成死锁，导致补丁、撤销、恢复或紧急停机无人能够完成。 ## 硬不变量 以下约束必须由确定性代码执行，不能只写入 reward： -- 动作必须属于 allowlist，并通过身份、范围、参数和版本校验； +- 每个特权动作都必须属于 allowlist，并通过 Principal、Capability、Object、范围、参数、 + 时限、撤销状态和版本校验； +- 作者、管理员、人类审批和模型置信度都不能形成绕过 Guard 的隐藏旁路； - 生命周期转换必须来自当前状态允许的边，并满足唯一所有者与资源后置条件； - 架构汇编不能包含策略分支，C/汇编调用边界必须保存并恢复约定状态； - 任何外部长度、索引、枚举和句柄在使用前完成边界与生命周期校验； -- 每个动作有最大幅度、速率限制、冷却时间和可逆路径； +- 每个动作有最大幅度、速率限制和冷却时间，并被明确分类为可逆、可补偿或不可逆；可逆动作 + 必须有 rollback，不可逆动作必须提高授权门槛并声明 checkpoint、补偿、隔离或人工恢复路径； - 内核、Guard、执行器和关键 workload 保留不可被策略回收的紧急资源； - 最低服务保障和 no-starvation 上界必须可测量； - 策略超时、异常、不可用或置信度不足时自动切回确定性规则； - 迁移前必须验证 checkpoint 完整性、兼容性和恢复所有权； - 多节点执行通过租约、版本和幂等键阻止重复副作用； - 每个建议、拒绝、执行、回滚和恢复动作写入不可混淆的审计记录； +- 来源记录不能被策略源删除或静默回写；高风险特权动作无法持久记录时必须拒绝或进入声明的 + fail-safe 路径； +- Guard、硬不变量、authority root、特权动作集和来源规则的修改必须形成独立、版本化、 + 可恢复的 governance transition； +- break-glass 必须有显式 Principal、理由、范围、到期时间、证据与恢复路径，不能等价于 bypass； +- `ALLOW`、`SUCCEEDED`、AcceptanceVerdict 与 EpistemicStatus 必须保存在不同状态轴； - SysRq、watchdog 或等价紧急停用路径不依赖模型服务。 +这些不变量约束声明范围内的系统主体，不能证明物理机、固件、编译器或托管平台所有者失去 +根权限。外部根权限必须通过可复现构建、独立副本、凭据轮换、供应链来源和恢复演练降低风险， +不能被文档写成已经消失。 + ## 最低安全验证 - 伪造、延迟、缺失和相互冲突的观测； - C 静态分析、未定义行为检查、宿主 sanitizer 测试和模拟器故障注入； - 非法生命周期跳转、重复释放、中断重入和上下文切换寄存器破坏； - 非法、越界、重放和高频动作建议； +- capability 委托、衰减、过期、撤销、缓存失效与 confused deputy； - 模型超时、崩溃、漂移和不稳定输出； - Guard 与执行器重启、磁盘压力和审计写入失败； +- Guard/authority state 损坏、可信核心资源耗尽和 fallback 控制器接管； - 网络分区、租约过期、重复恢复和损坏 checkpoint； - 长时间运行下的饥饿、资源泄漏和控制器振荡； - 一键停用策略层后，默认调度与资源边界能够恢复。 +- compromised maintainer、凭据重放、错误人工批准与 break-glass 滥用； +- Guard、authority root、allowlist 和 provenance schema 的未授权修改； +- 来源记录丢失、截断、重排、冲突、磁盘写入失败与外部读回； +- 构建工具、策略 artifact 和发布坐标被替换后的 fail-closed 行为； +- 干净机器重建、凭据撤销/重签发和仓库主载体不可用时的恢复演练； +- checkpoint 恢复后 Capability、租户边界和执行所有权不被静默扩大； +- 多主体治理在一方缺席、凭据撤销和紧急恢复时的 liveness； +- verifier 共享错误前提、验收工具污染和事实源冲突时保留 `UNKNOWN`。 任何硬不变量违约都使实验失败，不能用平均性能收益抵消。 diff --git a/docs/vision.md b/docs/vision.md index 07fb747..aab44eb 100644 --- a/docs/vision.md +++ b/docs/vision.md @@ -6,29 +6,40 @@ 负载均衡。长周期 Agent、编译、测试、训练和推理 workload 则会暴露另一类问题：两个 资源占用相似的任务，可能分别处于“接近检查点并持续收敛”和“重复失败且没有进展”的状态。 -FlowKernel 的长期目标是构建一个 C-first 实验内核，研究系统能否在不放弃确定性安全边界 -的前提下，将生命周期和长期进展加入资源策略。 +FlowKernel 的长期目标是构建一个 C-first 实验内核，研究系统能否在不放弃确定性权限、 +资源、隔离和恢复边界的前提下，让不完全可靠的策略源参与长期资源与执行决策。 -核心研究问题是： +原始资源研究问题仍然是： > Can an operating system understand not only how much resource a workload > consumes, but also where that workload is in its lifecycle, whether it is > making meaningful progress, and whether preserving its continuity is more > valuable than maximizing short-term utilization? +后续工程实践把它推进为更上游的问题： + +> How can fallible intelligence act without becoming sovereign? + +后一个问题不取消前一个。资源调度提供第一个可控实验对象；Principal、Capability、Guard、 +来源记录、外部验收和恢复边界说明这类策略凭什么获得行动权，以及行动以后什么才有资格成为 +事实。 + ## “AI 操作系统”的含义 -本项目中的 AI Operating System 不是“由模型接管内核”。它表示一个以受限 freestanding C -为可信核心、以显式生命周期状态机组织资源、在慢路径接受受约束策略建议的实验系统： +本项目中的 AI Execution OS 不是“由模型接管内核”。它表示一个以受限 freestanding C 为 +可信核心、以显式状态机组织特权转换、在慢路径接受受约束策略建议的实验系统： ```text -Observe -> Represent -> Propose -> Guard -> Act -> Measure +Principal -> Intent -> Propose -> Authorize -> Act -> Observe -> Accept ``` 系统工程中的许多控制器最终都在遍历有状态实体，根据观测和规则作出动作。`if`、`for` 和 `while` 可以表达控制流，但系统是否可靠取决于状态、所有权、预算、退出条件和失败闭环 是否明确。FlowKernel 研究的是能否让学习策略承担一部分原本由人工阈值和启发式规则完成的 -`Propose`，同时由 C 状态机和 Guard 保留动作边界、安全不变量和执行主权。 +`Propose`，同时由 C 状态机和 Guard 保留动作边界、安全不变量和执行主权。人类审批改变的 +是授权条件，不是事实资格；执行器报告成功后，仍需要独立事实源判断目标是否成立。 + +详细定义见 [执行操作系统宪法](execution-os-constitution.md)。 ## 研究边界 @@ -48,6 +59,22 @@ Observe -> Represent -> Propose -> Guard -> Act -> Measure - 检查点时机、任务放置和迁移建议； - 长期优先级和多目标策略更新。 +Slow Path 不是 RL 专属路径。静态规则、启发式、自适应阈值、RL、LLM 和 Agent 都是候选 +Policy source，并输出同一种有类型、带 Principal、Object、能力范围和有效期的 Proposal。 +若简单规则更好，系统应保留简单规则。 + +### Authority 与事实边界 + +- 人、Agent、服务及策略运行时作为 Principal；规则与模型是由 Principal 使用的版本化 policy + artifact，不因作者身份、模型能力或人工审批获得隐藏旁路； +- Capability 在其权限模型内携带对特定 Object 的有界 authority，Guard 对每次特权转换完整 + 调停； +- C 可信核心决定动作是否获准以及怎样有界执行，不替外部业务世界宣布真值； +- 外部验收读取 runtime、artifact、database、browser 或 verifier 事实，但不直接改写 Guard + 或被验对象； +- 治理权和运行权分开：修改 Guard、硬不变量或 authority root 本身必须形成版本化、可恢复 + 的治理变化。 + ### 调度对象 研究对象从静态任务逐步扩展为具有生命周期、依赖、健康状态、检查点和资源包络的 workload。 @@ -72,8 +99,10 @@ FlowKernel 的成功不以“写出多少内核代码”衡量，而以是否能 2. 定义可观测、可回放的 workload 生命周期； 3. 证明新策略相对同预算传统基线改善了明确指标； 4. 在内存错误、状态错误、奖励投机和模型异常时守住硬不变量； -5. 给出策略收益、推理开销和复杂度成本的完整权衡； -6. 让失败实验同样可以复现并形成结论。 +5. 证明错误影响被限制在授权隔离域内，且确定性 fallback 与恢复路径真实可用； +6. 将特权转换绑定到 Principal、Capability、前后状态和恢复引用，并能交给独立验收读回； +7. 给出策略收益、推理开销和复杂度成本的完整权衡； +8. 让失败、边界和未完成实验同样可以复现并形成结论。 ## 非目标 @@ -81,6 +110,8 @@ FlowKernel 的成功不以“写出多少内核代码”衡量，而以是否能 - 把“使用 C”本身当作内存安全或正确性证明； - 在最小闭环前同时实现驱动生态、文件系统、网络栈、多核和分布式控制； - 用“AI”替代缺失的状态机和安全设计； +- 把人工审批、日志或执行成功当成最终事实证明； +- 在单维护者阶段宣称多主体治理、去中心化控制或社区连续性已经实现； - 只展示吞吐量而忽略饥饿、失败和恢复； - 把单机缩比实验描述为生产集群结论； - 为满足路线图而强行选择强化学习。 diff --git a/scripts/verify-repository.mjs b/scripts/verify-repository.mjs index 2c04af7..0673bf0 100644 --- a/scripts/verify-repository.mjs +++ b/scripts/verify-repository.mjs @@ -10,6 +10,7 @@ const requiredFiles = [ "CONTRIBUTING.md", "SECURITY.md", "docs/conceptual-origin.md", + "docs/execution-os-constitution.md", "docs/c-first-kernel-contract.md", "docs/vision.md", "docs/research-questions.md", @@ -80,6 +81,7 @@ if (!readme.includes("**Evidence state: Planned. Implementation has not started. } for (const link of [ "docs/conceptual-origin.md", + "docs/execution-os-constitution.md", "docs/c-first-kernel-contract.md", "docs/prior-art.md", "docs/threat-model.md",