HKati/pulse-release-gates-0.1

Prefer light version?

Show light hero

 [](https://doi.org/10.5281/zenodo.17373002) [](https://hkati.github.io/pulse-release-gates-0.1/) [](https://hkati.github.io/pulse-release-gates-0.1/status.json) [](https://hkati.github.io/pulse-release-gates-0.1/#quality-ledger) **查看最新的 Quality Ledger（实时）：** https://hkati.github.io/pulse-release-gates-0.1/ ### 项目链接（镜像） - **仓库：** https://github.com/HKati/pulse-release-gates-0.1 - **实时 Quality Ledger：** https://hkati.github.io/pulse-release-gates-0.1/ - **Kaggle 数据集（EPF A/B 制品，已种子化） — DOI：** https://doi.org/10.34740/kaggle/dsv/13571702 - **Kaggle 数据集（PULSE：确定性、故障-闭环 发布门控） — DOI：** https://doi.org/10.34740/kaggle/dsv/13519727 - **Kaggle Notebook（复现图表 — EPF A/B，已种子化）：** https://www.kaggle.com/code/horvathkatalin/pulse-epf-shadow-a-b-reproduce-figures-seeded - **Kaggle Notebook（离线快速启动 — Ledger & Q3+Q4）：** https://www.kaggle.com/code/horvathkatalin/pulse-demo-offline-quick-start-q3-q4-ledger - **DOI（版本化，Zenodo）：** https://doi.org/10.5281/zenodo.17373002 - **DOI（概念，所有版本，Zenodo）：** https://doi.org/10.5281/zenodo.17214908 - **发布版本：** https://github.com/HKati/pulse-release-gates-0.1/releases - **Paradox Core（影子审查者视图）：** https://hkati.github.io/pulse-release-gates-0.1/paradox/core/v0/ - 确定性，默认 CI 中立（诊断覆盖层）。 - 边缘是非因果的（仅共现/关联）。 - 来源（来源选择）：https://hkati.github.io/pulse-release-gates-0.1/paradox/core/v0/source_v0.json # PULSE — 安全与可用 AI 的发布门控 #### AI 发布稳定性工程 从 **发现** 到 **熔断**。在 **发布前运行 PULSE**：确定性的、**故障-闭环** 门控，将红队洞察转化为针对安全性（I₂–I₇）和产品效用（Q₁–Q₄）的 **发布决策**。离线、CI 强制执行、审计就绪。

## 清晰度优先（在 Paradox / EPF / 拓扑工作之前） PULSE 是确定性的且故障-闭环 —— 但前提是我们保持术语含义的稳定。 在扩展 Paradox 图表/字段、EPF 影子层、漂移/历史或任何 UI/Pages 视图之前，我们锁定以下语义。 **事实来源（规范性）：** 发布决策仅由以下内容定义： - `PULSE_safe_pack_v0/tools/check_gates.py` - `PULSE_safe_pack_v0/artifacts/status.json` - `.github/workflows/pulse_ci.yml`（必需的 `--require ...` 门控集） **诊断层（默认 CI 中立）：** Paradox/EPF/拓扑/G-field 覆盖层、危害探针、漂移报告、仪表板和 Pages 视图是诊断覆盖层，除非明确将其提升到必需的门控集中。 **规范性与诊断性（切勿混淆）：** - **规范性** = 可以阻止发布（PASS/FAIL，STAGE‑PASS/PROD‑PASS）。 - **诊断性** = 解释/观察稳定性、紧张度和漂移；它绝不能改变 CI 结果。 规则：如果诊断制品缺失，报告可能会显示 `MISSING/UNKNOWN`，但这绝不能被默认重新解释为 `PASS`。 **无语义漂移规则：** 如果您更改任何信号/术语的含义（例如 Atom/Edge/Orientation/Core/Anchor，EPF/RDSI/Δ，drift，hazard zones）： 1. 更新规范文档（`docs/GLOSSARY_v0.md`，`docs/STATUS_CONTRACT.md`，`docs/STATE_v0.md`）， 2. 在 [`docs/AMBIGUITY_REGISTER_v0.md`](docs/AMBIGUITY_REGISTER_v0.md) 中跟踪并解决歧义， 3. 添加或更新回归固定装置以证明确定性。 **UI / Pages 规则：** UI 和 Pages 界面必须是不可变运行制品的纯读取器/渲染器。它们绝不能计算或重新定义发布语义。 ### 新增功能 - **外部检测器（可选）：** 将来自安全工具的 JSON/JSONL 摘要合并到门控 + Quality Ledger 中。 - **Refusal‑delta：** 拒绝策略的稳定性信号（审计友好的量化）。 - **JUnit & SARIF：** 将 `reports/junit.xml` 和 `reports/sarif.json` 写入为工作流制品；可选的独立 `upload_sarif.yml` 工作流可以将 SARIF 发布到 GitHub Code Scanning。 - **首次运行保持简单：** 默认值不变；可选部分可以稍后启用。 ➡️ 完整说明：请参阅 [Releases](https://github.com/HKati/pulse-release-gates-0.1/releases) 和 [CHANGELOG](./CHANGELOG.md)。 ## 快速开始 ``` python PULSE_safe_pack_v0/tools/run_all.py ``` ### 可选诊断（影子） 某些检查作为 *诊断/影子* 信号运行（它们可能会发出警告，但不应阻止合并）： - **OpenAI Evals • Refusal smoke（影子）**：在 PR/push 时，它按策略运行 **dry-run**（不暴露 secrets）。 规范输出写入：`openai_evals_v0/refusal_smoke_result.json` 并作为工作流制品上传到 GitHub Actions。 - **真实运行** 仅通过 `workflow_dispatch` 可用，并且需要明确的确认/预算 （参见 `openai_evals_v0/README.md`）。 ``` python openai_evals_v0/run_refusal_smoke_to_pulse.py \ --dry-run \ --dataset openai_evals_v0/refusal_smoke.jsonl \ --out openai_evals_v0/refusal_smoke_result.json \ --status-json PULSE_safe_pack_v0/artifacts/status.json ``` ``` python PULSE_safe_pack_v0/tools/check_gates.py \ --status PULSE_safe_pack_v0/artifacts/status.json \ --require $(python tools/policy_to_require_args.py --policy pulse_gate_policy_v0.yml --set required) ``` ### 调试（当 CI 警告/失败时） 如果 OpenAI evals refusal smoke 影子工作流发出警告或失败，请从这里开始： - 工作流：`.github/workflows/openai_evals_refusal_smoke_shadow.yml` - 检查 Step Summary 并从运行中下载制品： - `openai_evals_v0/refusal_smoke_result.json` - `PULSE_safe_pack_v0/artifacts/status.json` 更多详情：参见 `openai_evals_v0/README.md` → “Debugging / triage (shadow)”。 **制品** **成绩单** → `PULSE_safe_pack_v0/artifacts/report_card.html` **Status JSON** → `PULSE_safe_pack_v0/artifacts/status.json` **Paradox Gate 分诊 SVG（影子）** → `PULSE_safe_pack_v0/artifacts/paradox_diagram_v0.svg`（文档：[`docs/paradox_gate_triage_svg_v0.md`](docs/paradox_gate_triage_svg_v0.md)） ### 开发者工具（可选） 这些辅助工具旨在用于本地验证和检查；它们不会 改变任何 CI 行为或门控逻辑。 - Trace dashboard 演示 notebook → `PULSE_safe_pack_v0/examples/trace_dashboard_v0.ipynb` - Decision trace schema 验证器 → `PULSE_safe_pack_v0/tools/validate_decision_trace_v0.py` 使用 `jsonschema` 根据 `schemas/PULSE_decision_trace_v0.schema.json` 验证 `decision_trace_v0*.json` 制品。 - 内存 / trace dashboard 演示 → `PULSE_safe_pack_v0/examples/PULSE_memory_trace_dashboard_v0_demo.ipynb` ### 在您的仓库中尝试 PULSE（5 分钟） 1. **复制安全包**到您的仓库根目录： - `PULSE_safe_pack_v0/`（或解压 `PULSE_safe_pack_v0.zip`）。 2. **添加 CI 工作流**：从本仓库复制 `.github/workflows/pulse_ci.yml`。 3. **运行它**： - 打开 **Actions → PULSE CI → Run workflow**（或提交一个 PR）。 - PULSE 将生成 `status.json`、`report_card.html`，以及当导出器存在时的 `reports/junit.xml` + `reports/sarif.json`；派生制品（例如徽章）也可能在运行工作区中生成。 - 默认工作流是 **制品优先** 和 **最小权限** 的：它上传制品并默认禁用仓库变更。 - GitHub 原生发布视图 —— 例如上传 SARIF 到 **Security → Code scanning alerts**、回写徽章、PR 评论或 Pages 快照 —— 应存在于具有明确写入权限的独立可选工作流中。 **仪式：** _在发布前运行 PULSE。_ PULSE 在归档日志上对安全性（I₂–I₇）、质量（Q₁–Q₄）和 SLO 预算强制执行故障-闭环 PASS/FAIL 门控。 ## PULSE 检查什么 **安全性不变量（I₂–I₇）** — 确定性 PASS/FAIL 门控： - 单调性（含移位弹性） - 交换性（含移位弹性） - 净化有效性（含移位弹性） - 动作单调性、幂等性、路径无关性 - PII 泄漏单调性 **质量门控（Q₁–Q₄）** — 面向产品的护栏： - Q₁ **落地性**（RAG 事实性） - Q₂ **一致性**（答案一致性） - Q₃ **公平性**（均等 / 机会均等） - Q₄ **SLOs**（p95 延迟和成本预算） **输出** - **Quality Ledger**（报告卡中的人类可读表格） - **RDSI**（发布决策稳定性指数）+ 带 CIs 的 Δ - **Badges**（生成的派生制品；仓库回写是可选的且默认禁用） ## 决策级别 **FAIL**（流水线阻塞）• **STAGE-PASS**（预发布发布）• **PROD-PASS**（允许生产部署）。 紧急覆盖需要理由；理由记录在 Quality Ledger 中。 ## 确定性（注意事项） 如果运行器镜像 + 种子 + CPU/GPU 模式被固定，PULSE 就是确定性的。外部检测器和 GPU 内核方差可能会引入不稳定性；EPF（影子）+ RDSI 量化稳定性，但绝不改变 CI 结果。 ## 原生 CI 输出 从 `status.json`，PULSE 可以将 **JUnit XML** 和 **SARIF** 导出到 `reports/` 并将它们作为 CI 制品上传。 - `reports/junit.xml` — 用于下游测试报告工具 / CI 使用者的 JUnit XML。 - `reports/sarif.json` — 用于 GitHub Code Scanning 或任何其他 SARIF 使用者的 SARIF。 主要的 `.github/workflows/pulse_ci.yml` 工作流保持只读和制品优先。如果您想要 GitHub 原生代码扫描警报，请添加可选的 `.github/workflows/upload_sarif.yml` 工作流。 ## CI — 主要门控工作流 主要的发布门控工作流是：`.github/workflows/pulse_ci.yml` 本仓库中的其他工作流可能用于影子诊断、工作流验证或研究实验；除非明确提升到必需的门控集中，否则它们不会改变发布结果。 它将： 1. 定位/解压安全包（`PULSE_safe_pack_v0/` 或 `PULSE_safe_pack_v0.zip`）， 2. **运行**检查， 3. **强制执行**（故障-闭环）必需的门控， 4. 用可选的外部检测器摘要**增强**状态， 5. 在运行工作区内**生成**派生制品（例如 ledger/报告/徽章）， 6. **上传制品**（例如 `status.json`、`report_card.html`、`reports/` 以及生成的徽章（如果存在））， 7. 保持**仓库回写默认禁用**。 可选的原生发布 —— 例如上传 SARIF 到 GitHub Code Scanning —— 以及其他发布视图，如 PR 评论、徽章提交和 Pages 快照，应在具有明确写入权限的独立可选工作流中实现。 ## 治理预检（故障-闭环） 除了运行安全包外，CI 还强制执行仓库级别的治理守卫： - **语义变更日志强制执行：**如果 `pulse_gate_policy_v0.yml`、`metrics/specs/**` 或数据集清单契约更改，`docs/policy/CHANGELOG.md` 必须在 **Unreleased** 下包含记录该更改的条目。 - **YAML 重复键守卫：**拒绝 `pulse_gate_registry_v0.yml` 和 `pulse_gate_policy_v0.yml` 中的重复映射键（防止静默的“最后一个键生效”语义）。 - **门控注册表同步：**`status.json` 中发出的每个门控都必须在 `pulse_gate_registry_v0.yml` 中注册。 - **策略 ↔ 注册表一致性：**策略要求的每个门控都必须存在于注册表中（包括 `core_required`）。 - **策略集选择：**`pull_request` 运行强制执行 `core_required`；主分支推送和版本标签推送（`v*`/`V*`）强制执行 `required`（策略驱动）。 - **严格外部证据：**工作流调度输入 `strict_external_evidence=true` **或** 版本标签推送（`v*`/`V*`）额外要求 `external_summaries_present`（和 `external_all_pass`）。 - **注意（默认 vs 严格）：**外部检测器摘要是可选的。如果未提供外部摘要，则 `external_all_pass` 根据设计计算为 PASS。对于发布级别的强制执行，启用 **严格外部证据**（`strict_external_evidence=true` 或版本标签推送），以便除了 `external_all_pass` 之外还要求 `external_summaries_present`。在严格模式下，缺失或失败的摘要将导致 CI 失败（故障-闭环），直到提供有效的证据。 - **工作流 YAML 守卫（workflow_lint.yml）：**`.github/workflows/*.yml` 的故障-闭环验证，以防止工作流 YAML 损坏（例如，步骤名称中未加引号的 `:`）。 ## G-field & 影子覆盖层 此仓库现在作为一个小型“G-field”视图暴露为 CI 中立覆盖层。 它们 **不** 改变任何门控或发布决策；它们仅在现有 PULSE 状态之上添加额外的 诊断层。 附加覆盖层： - **G-field 覆盖层（`g_field_v0.json`）** 内部 G-child 字段的快照，用于最近的 traces / 场景。 由 `scripts/g_child_field_adapter.py` 从 `hpc/g_snapshots.jsonl` 生成 （如果存在）并连接到 G-field 覆盖层（影子）工作流。 - **G-field 稳定性覆盖层（`g_field_stability_v0.json`）** 小型合成示例，展示如何将多个 `g_field_v0` 运行 汇总为单个稳定性视图（运行次数、全局均值/标准差、 不稳定门控等）。 仅用于 schema 验证和 G-snapshot 报告中的“稳定性”部分。 - **GPT 外部检测覆盖层（`gpt_external_detection_v0.json`）** `logs/model_invocations.jsonl` 的样本视图，统计发生了多少次 内部 HPC vs 外部 GPT 调用，按供应商和模型细分。 这只是一个诊断影子覆盖层；它不强制执行任何策略。 影子工作流（GitHub Actions）： - **G-field 覆盖层（影子）** – 从 HPC 快照重建 `g_field_v0.json`。 - **G-EPF 覆盖层（影子）** – 将 EPF / Paradox 输出桥接到 G-EPF 覆盖层。 - **GPT 外部检测（影子）** – 扫描 `logs/model_invocations.jsonl` 并发出 `gpt_external_detection_v0.json`。 - **覆盖层 schema 验证（影子）** – 根据其 JSON Schema 验证所有覆盖层。 - **G snapshot 报告（影子）** – 渲染单个 `g_snapshot_report_v0.md` 总结哪些覆盖层存在以及它们包含的内容。 当前覆盖层： - **分离相位覆盖层**（`separation_phase_v0.json`） 快照式诊断覆盖层，将运行分类为： `FIELD_STABLE` / `FIELD_STRAINED` / `FIELD_COLLAPSED` / `UNKNOWN` 基于分离式不变量（顺序稳定性、分离完整性、相位依赖性）。 - 文档：`docs/SEPARATION_PHASE_v0.md` - Schema：`schemas/separation_phase_v0.schema.json` - 适配器：`scripts/separation_phase_adapter_v0.py` - 契约检查：`scripts/check_separation_phase_v0_contract.py` - 渲染器（人类摘要）：`scripts/render_separation_phase_overlay_v0_md.py` - 工作流：`.github/workflows/separation_phase_overlay.yml` - 输出制品： - `PULSE_safe_pack_v0/artifacts/separation_phase_v0.json` - `PULSE_safe_pack_v0/artifacts/separation_phase_overlay_v0.md` 所有这些 **仅对其自身作业故障-闭环**（它们从不阻塞 主要的 PULSE 门控），旨在作为内部 G-field 和 GPT 诊断的安全试验场。 ## 理论覆盖层 v0（影子） 快照式诊断覆盖层，计算并展示理论覆盖层信号（包括 record-horizon 门控） 作为 CI 可见、经契约检查的制品和审阅者友好的 markdown 摘要。 CI 中立诊断层。它从不阻塞主要的 PULSE 门控，并且绝不能改变核心发布门控语义。 文档：`docs/theory_overlay_v0.md` Schema： - `schemas/theory_overlay_v0.schema.json` - `schemas/theory_overlay_inputs_v0.schema.json` 构建器：`scripts/build_theory_overlay_inputs_v0.py` 生成器：`scripts/generate_theory_overlay_v0.py` 契约检查： - `scripts/check_theory_overlay_inputs_v0_contract.py` - `scripts/check_theory_overlay_v0_contract.py` 渲染器：`scripts/render_theory_overlay_v0_md.py` 工作流：`.github/workflows/theory_overlay_v0.yml` 输出制品： - `PULSE_safe_pack_v0/artifacts/theory_overlay_inputs_v0.json` - `PULSE_safe_pack_v0/artifacts/theory_overlay_v0.json` - `PULSE_safe_pack_v0/artifacts/theory_overlay_v0.md` 跟踪的演示原始固定装置： - `PULSE_safe_pack_v0/fixtures/theory_overlay_inputs_v0.raw.demo.json` ## OpenAI evals 试点（影子，非阻塞） 我们维护 OpenAI Evals refusal smoke（v0）的诊断“影子”连接。 工作流：`.github/workflows/openai_evals_refusal_smoke_shadow.yml` - Push/PR：确定性 **dry-run**（无 secrets，无网络）+ 契约检查 + 制品 - workflow_dispatch：可选 **real** 模式（需要 secrets） 制品通常包括： - `openai_evals_v0/refusal_smoke_result.json` - `PULSE_safe_pack_v0/artifacts/status.json` - `openai_evals_v0/refusal_smoke.jsonl` ## G snapshot 报告（v0） PULSE 附带一个影子工作流，将内部 G-field 和 GPT 外部使用情况汇总到单个 markdown 报告中。 - 工作流：**“G snapshot report (shadow)”**（GitHub Actions） - 输入（如果存在）： - `g_field_v0.json`（G-child 覆盖层） - `g_field_stability_v0.json`（稳定性覆盖层，可选） - `g_epf_overlay_v0.json`（EPF 覆盖层，可选） - `gpt_external_detection_v0.json`（GPT 哨兵覆盖层，从 `logs/model_invocations.jsonl` 构建） - 输出制品： - `PULSE_safe_pack_v0/artifacts/g_snapshot_report_v0.md` 报告显示每个覆盖层是否存在/缺失，以及： 基本 G-field 统计信息（均值/最小值/最大值）和 GPT 使用统计信息（内部 vs 外部调用，主要供应商和模型）。它是 CI 中立的，旨在 用于诊断和治理仪表板。 ### 路线图（影子层） 当前的 G-shadow 层有意保持最小：一小部分覆盖层和一个 影子专用 snapshot 报告，可以在 PULSE safe pack 中安全发布。 我们计划的后续步骤（非破坏性、迭代）包括： - **EPF 覆盖层 2.0** 从当前的演示 EPF 面板转向更现实的 EPF 诊断覆盖层 （更丰富的字段、更清晰的门控映射、snapshot 报告中更好的摘要）。 - **G-field 稳定性摘要** 将 `g_field_stability` 覆盖层从原始诊断 JSON 块扩展到 门控级别的稳定性摘要和（可选）简单的历史趋势。 - **GPT 使用覆盖层** 完善 GPT 外部检测覆盖层，包含场景/产品线细分 以及在 snapshot 中更清晰地归因“内部 vs 外部”使用情况。 - **覆盖层的文档和 UX** 添加简短的“如何添加新覆盖层”指南和更多 snapshot 示例，以便 团队可以插入额外的覆盖层而无需触及核心发布门控。 ### EPF（实验性，仅影子） **TL;DR：**确定性、故障-闭环门控仍然是发布的真理来源。 EPF 作为已种子化、可审计的 **仅影子** 层运行，从不改变 CI 结果。 #### 什么是 EPF？ EPF 是一个可选的自适应层，仅在每个门控阈值附近的狭窄区域内运行： - 在 `[threshold − ε, threshold]` 内，它探索边界附近潜在的误报减少和稳定性； - 在此范围之外，现有语义不变： - value < `threshold − ε` → FAIL（影子与基线一致）， - 证据不足 → DEFER/FAIL（仅影子）， - 风险高于 `max_risk` → FAIL（仅影子）。 EPF 设计为 **CI 中立**：它观察并记录，但不翻转发布决策。 #### 稳定性信号（epf_L） 为了推理稳定性，EPF 记录门控反馈算子 `F: X → X` 的收缩代理： - 如果 `metrics.epf_L < 1`，则 EPF 层在门控周围的窗口 `W` 上局部收缩； - 在这种情况下，EPF 报告将其标记为 **shadow pass**。 此信号 **仅用于诊断**，绝不改变 CI 决策。 主要字段包括： - `status_epf.json` 中的 `metrics.epf_L`， - 可选的影子账本标志，例如 `ledger.epf.shadow_pass`。 这些由 EPF 工作流写入，并且 **不** 属于用于确定性门控的基线 `status.json` 的一部分。 #### EPF 实验（影子）工作流 仓库附带一个非阻塞的 EPF 实验工作流： - 文件：`.github/workflows/epf_experiment.yml` - 作业名称：**EPF experiment (shadow)** 它： - 运行 `PULSE_safe_pack_v0/tools/run_all.py`（如果可用）以生成 基线 `PULSE_safe_pack_v0/artifacts/status.json`， - 将其复制到本地的 `status.json` 用于实验， - 从同一基线运行 `check_gates.py` 两次： - 确定性基线 → `status_baseline.json`， - EPF 影子 → `status_epf.json`， - 比较两者并发出： - `epf_report.txt` – 基线 vs EPF 决策的人类可读摘要， - `epf_paradox_summary.json` – EPF 与基线不一致的门控的结构化列表（悖论候选）。 EPF 实验工作流是 **可选且 CI 中立** 的。它旨在 用于研究和诊断（边界门控、悖论分析），不参与发布门控。 有关当基线和 EPF 在特定门控上不一致时该怎么做的指南，请参阅： - `docs/PARADOX_RUNBOOK.md` #### EPF 危害预测（原型模块） EPF safe pack 还包含一个实验性的危害预测 探针 `PULSE_safe_pack_v0/epf/epf_hazard_forecast.py`。它从当前 EPF 字段和稳定参考状态之间的关系计算一个简单的预警指数，并将结果分类为 GREEN / AMBER / RED 区域。此模块仅用于原型，尚不参与发布门控。 ### EPF 危害概览（原型流水线） EPF safe pack 包含一个原型级的、基于字段的危害预测 流水线，它 **不** 等待具体的错误事件，而是监视当前 EPF 状态与稳定参考之间的关系。 该流水线目前包括： - **探针** – `PULSE_safe_pack_v0/epf/epf_hazard_forecast.py` 从以下内容计算关系危害信号： - `T` – 当前快照和基线快照之间的距离， - `S` – 稳定性指数， - `D` – `T` 的短期漂移， - `E` – 预警指数和 `zone`（`GREEN / AMBER / RED`）， - `reason` – 短解释字符串。 - **适配器和日志** – `PULSE_safe_pack_v0/epf/epf_hazard_adapter.py` 从 EPF 实验运行探针，并将结果作为 JSONL 行追加 到 `PULSE_safe_pack_v0/artifacts/epf_hazard.jsonl`。 - **检查器** – `PULSE_safe_pack_v0/tools/epf_hazard_inspect.py` 汇总每个门控/字段的 JSONL 日志（条目计数、最后的 zone/E、 `E` 的最小值/最大值/平均值），以便于 CLI 检查。 - **状态集成** – `PULSE_safe_pack_v0/tools/run_all.py` 在 `status.json["metrics"]` 和 HTML 成绩单标头中公开危害指标： - `hazard_T`、`hazard_S`、`hazard_D`、`hazard_E`， - `hazard_zone`、`hazard_reason`， - `hazard_ok`、`hazard_severity`。 - **门控策略助手** – `PULSE_safe_pack_v0/epf/epf_hazard_policy.py` 使用仅 RED 阻塞策略从 `HazardState` 派生简单的门控决策： - `hazard_ok` 标志（True 除非 `zone == "RED"`）， - `severity`（`LOW / MEDIUM / HIGH / UNKNOWN`）， - 保留底层的 `reason` 字符串。 在当前原型阶段，危害信号 **仅用于诊断**： 它被记录、检查并显示在状态/报告中，但尚未强制执行任何硬性发布门控。 ### EPF 关系 Grail（危害探针） **EPF Relational Grail** 是 PULSE EPF 堆栈中的关系危害层：它不等待具体的错误事件，而是监视当前状态和参考状态之间的关系，并产生具有 GREEN / AMBER / RED 区域的标量危害指数 E(t)。 有关概念概览、校准流程和 CLI 示例，请参阅 [docs/epf_relational_grail.md](docs/epf_relational_grail.md)。 ## EPF Relational Grail（危害覆盖层） safe-pack 在确定性门控之上发出 EPF 危害 **诊断覆盖层**。 它产生： - `PULSE_safe_pack_v0/artifacts/status.json`（包括 `hazard_*` 指标 + 影子门控 `epf_hazard_ok`） - `PULSE_safe_pack_v0/artifacts/report_card.html`（人类友好报告） - `PULSE_safe_pack_v0/artifacts/epf_hazard_log.jsonl`（仅追加危害序列） 危害层是字段优先的（metrics.* + gates.*），并展示拓扑状态 （例如 stably_good / unstably_good），而不会默认变成经典的警报系统。 详情请参见 `docs/epf_relational_grail.md`。 ## PULSE–PD（实验性） 用于选择切割/θ 周围决策字段分析的 Paradox Diagram（DS/MI/GF → PI）。包括基于切割的运行器和顶级 PI CSV 导出器（可选带有 `event_id` 或 `run/lumi/event` 用于回溯）。请参阅 [pulse_pd/README.md](pulse_pd/README.md) 和 [pulse_pd/EXPORT_SCHEMA.md](pulse_pd/EXPORT_SCHEMA.md)。 ### 制品 - `status_baseline.json` – 确定性决策（真理来源） - `status_epf.json` – EPF 影子指标、traces 和决策（包括 `metrics.epf_L`） - `epf_report.txt` – 基线 vs EPF 决策的 A/B 差异摘要 - `epf_paradox_summary.json` – 结构化摘要（总门控数、变更门控数、样本基线→EPF delta） - `epf_hazard_log.jsonl` 由 EPF 危害适配器生成的面向行的 JSON 日志。每行 是单个危害探针事件，具有以下结构： { "gate_id": "", "timestamp": "", "hazard": { "T": 0.41, "S": 0.94, "D": 0.03, "E": 0.12, "zone": "GREEN", "reason": "E=0.120, T=0.410, S=0.940, D=0.030 → field stable, no near-term hazard signal." }, "meta": { "run_id": "...", "commit": "...", "experiment_id": "..." } } 注意： - 每次探针调用一行（每个门控 / 每个周期）。 - `meta` 是可选的，可能包含运行特定的标识符。 - 此制品在原型阶段 **仅用于诊断**：它用于 分析和阈值校准，而不是作为硬性发布门控。 ## Paradox field v0（实验性，证据优先） 此仓库包含一个最小的悖论层制品（`paradox_field_v0.json`），用于总结运行间漂移为 **原子** 和 **张力边缘**（仅共现，无因果关系）。 - 从过渡漂移目录生成原子： `python scripts/paradox_field_adapter_v0.py --transitions-dir tests/fixtures/transitions_gate_metric_tension_v0 --out out/paradox_field_v0.json` - 故障-闭环契约检查（必填字段、排序、链接完整性）： `python scripts/check_paradox_field_v0_contract.py --in out/paradox_field_v0.json` - 导出证据优先边缘（JSONL）： `python scripts/export_paradox_edges_v0.py --in out/paradox_field_v0.json --out out/paradox_edges_v0.jsonl` 验证边缘契约（包括链接/类型完整性）： python scripts/check_paradox_edges_v0_contract.py --in out/paradox_edges_v0.jsonl --atoms out/paradox_field_v0.json 可重现的非固定装置示例输入： - docs/examples/README.md（包括 docs/examples/transitions_case_study_v0/） - docs/paradox_edges_case_studies.md 可重现的非固定装置示例（推荐） - 参见：`docs/examples/transitions_case_study_v0/README.md` - 仓库本地 + CI 友好的输入；不要将生成的输出提交到 `out/**` 下。 - CI 通过 `paradox_examples_smoke` 运行此示例，以便尽早捕获缺失/重命名的输入。 注意： - 不要将生成的输出提交到 out/** 下。 边缘是从原子派生的已证实共现；它们不引入新的真理或因果关系。 ### 可选配置（每个门控） ``` gates: - id: q1_groundedness threshold: 0.85 epsilon: 0.03 # enables the adaptive band adapt: true max_risk: 0.20 ema_alpha: 0.20 min_samples: 5 ``` **CI：**EPF 作为 **独立的、CI 中立** 工作流运行（`.github/workflows/epf_experiment.yml`）。 `check_gates.py` 中的确定性、故障-闭环门控仍然是 **唯一** 的发布门控。 ### Paradox 快速检查（投影视图） smoke 工作流为审阅者生成确定性的 Markdown 摘要： - `out/paradox_summary_v0.md`（案例研究） - `out/empty_edges/paradox_summary_v0.md`（回归：带 run_context 的空边缘） 两者都作为 `paradox-artifacts` CI 制品上传。 注意： - 仅投影视图；不影响 CI 门控。 - 边缘仅共现（无因果关系）。 本地快速检查： ``` python scripts/inspect_paradox_v0.py \ --field out/paradox_field_v0.json \ --edges out/paradox_edges_v0.jsonl \ --out out/paradox_summary_v0.md ``` ### 仓库布局 ``` - `PULSE_safe_pack_v0/` – self-contained PULSE safe-pack v0 (tools, core policies and CI wiring; `pulse_policy.yml` is the CI source of truth) - `profiles/` – example / experimental profiles and threshold sets. These are **not** used by CI unless explicitly referenced from `PULSE_safe_pack_v0/pulse_policy.yml` or custom workflows. ``` ## 方法与外部检测器 - **方法（RDSI & Ledger）：** `PULSE_safe_pack_v0/docs/METHODS_RDSI_QLEDGER.md` - **外部检测器（可选）：** `PULSE_safe_pack_v0/docs/EXTERNAL_DETECTORS.md` - 通过简单的 JSON/JSONL 摘要插入适配器（例如，Llama Guard、Prompt Guard、Garak、Azure Evaluations、Promptfoo、DeepEval）。 ## 文档地图 从这里开始： - 在 CI 中运行 PULSE：[docs/QUICKSTART_CORE_v0.md](docs/QUICKSTART_CORE_v0.md) — 运行核心流水线的最少步骤。 - 理解真理来源（`status.json`）：[docs/status_json.md](docs/status_json.md) — 如何阅读 `status.json`（指标、门控、使用者）。 - 当事情失败时（分诊）：[docs/RUNBOOK.md](docs/RUNBOOK.md) — 用于分诊和重新运行的操作 runbook。 精选入口（`docs/` 下的仓库级文档）： ### 已验证的理论/探针路径 - ✅ [docs/gravity_record_protocol_decodability_wall_v0_1.md](docs/gravity_record_protocol_decodability_wall_v0_1.md) — Decodability Wall 规范（v0.1）：操作阈值、文件角色、规范 4 步流程、故障-闭环注释和输出。 - [docs/gravity_record_protocol_inputs_v0_1.md](docs/gravity_record_protocol_inputs_v0_1.md) — Gravity Record Protocol 输入包规范（v0.1）。 - 演示固定装置：`PULSE_safe_pack_v0/fixtures/gravity_record_protocol_inputs_v0_1.demo.json`、`PULSE_safe_pack_v0/fixtures/decodability_wall_v0_1.demo.json` - 绿色端到端演示路径已在本地验证（仓库根目录）：构建输入 → 检查输入 → 构建 wall → 检查 wall - 生成的本地输出：`out/gravity_record_protocol_inputs_v0_1.json`、`out/decodability_wall_v0_1.json` - 验证摘要：`sha_match = True`、`wall_errors = []`、`wall_state = wall_found` ### 定向与契约 - [docs/STATE_v0.md](docs/STATE_v0.md) — PULSE v0 门控、信号和工具的当前快照。 - [docs/STATUS_CONTRACT.md](docs/STATUS_CONTRACT.md) — `status.json` 形状和语义的契约。 - [docs/GLOSSARY_v0.md](docs/GLOSSARY_v0.md) — 文档中使用的规范术语定义。 ### 状态、账本和外部信号 - [docs/quality_ledger.md](docs/quality_ledger.md) — Quality Ledger 布局和用途。 - [docs/refusal_delta_gate.md](docs/refusal_delta_gate.md) — Refusal-delta 摘要格式 + 故障-闭环语义。 - [docs/EXTERNAL_DETECTORS.md](docs/EXTERNAL_DETECTORS.md) — 外部检测器策略和模式（门控 vs 建议）。 - [docs/external_detector_summaries.md](docs/external_detector_summaries.md) — 将外部检测器摘要折叠到状态/账本中。 ### Paradox field & 边缘 - [docs/PULSE_paradox_field_v0_walkthrough.md](docs/PULSE_paradox_field_v0_walkthrough.md) — 如何阅读 `paradox_field_v0`。 - [docs/Pulse_paradox_edges_v0_status.md](docs/Pulse_paradox_edges_v0_status.md) — `paradox_edges_v0.jsonl` 的状态/路线图。 - [docs/paradox_edges_case_studies.md](docs/paradox_edges_case_studies.md) — 案例研究（固定装置 + 非固定装置）。 - [docs/PULSE_paradox_core_v0.md](docs/PULSE_paradox_core_v0.md) — Paradox Core v0（确定性核心投影 + markdown 审阅者摘要）。 ### EPF shadow & 危害诊断 - [docs/PULSE_epf_shadow_quickstart_v0.md](docs/PULSE_epf_shadow_quickstart_v0.md) — 命令级 EPF shadow quickstart。 - [docs/epf_relational_grail.md](docs/epf_relational_grail.md) — 关系危害概览 + 校准/CLI 示例。 - [docs/epf_hazard_inspect.md](docs/epf_hazard_inspect.md) — 从 CLI 检查 `epf_hazard_log.jsonl`。 ### 拓扑和字段优先解释 - [docs/PULSE_topology_overview_v0.md](docs/PULSE_topology_overview_v0.md) — 拓扑层概览（诊断覆盖层）。 - [docs/PULSE_decision_field_v0_overview.md](docs/PULSE_decision_field_v0_overview.md) — Decision field v0 概览。 - [docs/FIELD_FIRST_INTERPRETATION.md](docs/FIELD_FIRST_INTERPRETATION.md) — 字段优先解释（问题即投影）。 ### 示例与贡献 - [docs/examples/README.md](docs/examples/README.md) — 可重现示例索引。 - [docs/PR_SUMMARY_TOOLS.md](docs/PR_SUMMARY_TOOLS.md) — PR 摘要工具（规范脚本）。 - [CONTRIBUTING.md](CONTRIBUTING.md) — 约定、DCO 和审查工作流。 ... ## PULSE Topology v0（稳定性地图 + 决策引擎 + 双视图） 拓扑层是确定性 PULSE 发布门控之上的可选诊断覆盖层。它 **从不** 改变 `status.json` 或 CI pass/fail 行为；它只读取现有制品并生成额外的 JSON 和叙述视图。 它包括： - **Stability Map v0** – 将 `status.json` 和可选的 EPF 指标汇总为每次运行的稳定性分数和稳定性类型。 - **Decision Engine v0** – 读取 Stability Map 并生成结构化的决策跟踪（BLOCK / STAGE_ONLY / PROD_OK + 解释）。 - **Dual View v0** – 相同数据的人类 + 智能体共享视图（简短叙述 + 机器友好的 JSON）。 ## 文档与规范 **Topology v0 / Stability Map** - `docs/PULSE_topology_v0_design_note.md` – Topology v0 层、Stability Map、状态/过渡。 - `docs/PULSE_topology_v0_methods.md` – CLI 级别的方法， Stability Map v0 流水线。 - `docs/PULSE_topology_v0_case_study.md` – Topology v0 的现实世界风格案例研究。 - `schemas/PULSE_stability_map_v0.schema.json` – Stability Map v0 JSON schema（包括 `paradox_field_v0` 和 `epf_field_v0`）。 **Paradox field & 内存指标 v0** - [PULSE memory / trace v0 walkthrough](docs/PULSE_memory_trace_v0_walkthrough.md) – 从 EPF/paradox 字段到历史和仪表板的端到端流水线。 - [PULSE paradox field and memory metrics v0](docs/PULSE_paradox_field_v0.md) – 悖论层的数学语义、tension/severity/priority 和内存字段。 **EPF shadow 层 & paradox field** - `docs/PULSE_topology_epf_hook.md` – EPF 如何概念性地连接到拓扑。 - `docs/PULSE_epf_shadow_quickstart_v0.md` – 运行 EPF shadow 流水线 v0 的简短命令级指南。 - `docs/PULSE_epf_shadow_pipeline_v0_walkthrough.md` – EPF shadow 流水线 v0 的详细演练。 - `docs/PULSE_paradox_field_v0_walkthrough.md` – 如何跨制品阅读 `paradox_field_v0`。 - `docs/PULSE_paradox_field_v0_case_study.md` – 单次运行的具体示例。 **Paradox Resolution v0** - `docs/PULSE_paradox_resolution_v0_design_note.md` – 悖论分诊/解决的概念设计。 - `docs/PULSE_paradox_resolution_v0_walkthrough.md` – 如何构建和解释 `paradox_resolution_v0.json`。 **仪表板 & 内存** - `docs/PULSE_topology_dashboards_v0_design_note.md` – Topology dashboards v0 构想。 - `docs/PULSE_memory_trace_summariser_v0_design_note.md` – 内存 / trace 摘要器 v0 概念。 ## Topology v0 和 Decision Engine v0 在核心 PULSE 门控和状态制品之上，仓库附带一个可选的 **字段 / 拓扑层**。此层不改变 CI 行为； 它只读取现有制品并发出额外的覆盖层。 主要部分包括： - **Paradox field（paradox_field_v0）** - Schema：`schemas/PULSE_paradox_field_v0.schema.json` - 工具：`PULSE_safe_pack_v0/tools/pulse_paradox_atoms_v0.py` - 输入：包含 `status.json` 制品的目录 - 输出：带有 *悖论原子*（最小不可满足门控集）和严重性分数的 `paradox_field_v0.json`。 - **Stability map（stability_map_v0，demo）** - 工具：`PULSE_safe_pack_v0/tools/pulse_stability_map_demo_v0.py` - 输入：无（纯合成演示） - 输出：`stability_map_v0_demo.json`，带有 fairness–SLO–EPF 示例的单个 2×2 单元，包括简单的 Δ-曲率信号（`delta_bend`）。 - **Decision Engine v0（decision_engine_v0）** - 工具：`PULSE_safe_pack_v0/tools/pulse_decision_engine_v0.py` - 输入： - 一个 `status.json` 制品（必需）， - 可选的 `stability_map_v0` 和 `paradox_field_v0` 覆盖层。 - 输出：`decision_engine_v0.json`，带有： - `release_state`（BLOCK / STAGE_ONLY / PROD_OK / UNKNOWN）， - `stability_type`（例如 stable_good / unstably_good）， - 门控、stability_map_v0 和 paradox_field_v0 的紧凑摘要。 这些组件旨在用于 **分析、仪表板和治理**，而非核心门控。发布决策的真理来源仍然是 `status.json` + `PULSE_safe_pack_v0/tools/check_gates.py` + CI 工作流。 有关详细概览和示例，请参阅： * `docs/PULSE_decision_field_v0_overview.md` * `docs/PULSE_decision_field_v0_5_minute_tour.md` * `docs/PULSE_topology_v0_mini_example_fairness_slo_epf.md` * `docs/PULSE_topology_v0_quickstart_decision_engine_v0.md` * `docs/PULSE_topology_v0_cli_demo.md` * `docs/PULSE_topology_v0_governance_patterns.md` * `docs/PULSE_demo_v1_paradox_stability_showcase.md` * `docs/PULSE_decision_engine_v0_unstably_good_example.md` * `docs/PULSE_decision_engine_v0_unstably_bad_example.md` * `docs/PULSE_decision_trace_v0_mini_example.md` * `docs/PULSE_mechanical_AI_v0.md` * `docs/PULSE_visual_map_v0.md` **Future Library 索引** - `docs/FUTURE_LIBRARY.md` – Future Library v0 支柱概览： - Topology v0 系列 - EPF 信号层（仅影子） - Paradox Resolution v0 - Topology dashboards v0 - 内存 / trace 摘要器 v0 - `docs/PULSE_memory_trace_v0_walkthrough.md` – 内存 / trace v0 演练和演示面板。 ## 文档 PULSE 为将 safe-pack 集成到 CI/CD 或审计中的人员提供了一些重点文档页面： - [`docs/status_json.md`](docs/status_json.md) `status.json` 制品概览：指标、门控以及其他工具如何使用它。 - [`docs/refusal_delta_gate.md`](docs/refusal_delta_gate.md) Refusal delta 摘要格式和 `refusal_delta_pass` 门控，包括当评估缺失时的故障-闭环行为。 - [docs/EXTERNAL_DETECTORS.md](docs/EXTERNAL_DETECTORS.md) — 外部检测器策略和模式（门控 vs 建议）。 外部检测器摘要（LlamaGuard、Promptfoo、Garak、Azure eval、Prompt Guard 等）如何折叠到 `status.json` 和 `external_all_pass` 门控中。 - [`docs/quality_ledger.md`](docs/quality_ledger.md) 面向人类的 PULSE Quality Ledger（report_card.html）：布局、用途及其与 `status.json` 的关系。 ## 如何引用 如果您使用本软件，请引用以下 **版本化发布**。 - **发布 DOI（版本化）：** [10.5281/zenodo.17373002](https://doi.org/10.5281/zenodo.17373002) - **概念 DOI（所有版本）：** [10.5281/zenodo.17214908](https://doi.org/10.5281/zenodo.17214908) ### BibTeX ``` @software{pulse_v1_0_2, title = {PULSE: Deterministic Release Gates for Safe \& Useful AI}, author = {Horvat, Katalin and EPLabsAI}, year = {2025}, version = {v1.0.2}, doi = {10.5281/zenodo.17373002}, url = {https://doi.org/10.5281/zenodo.17373002} } ``` ## 出版物 [](https://doi.org/10.5281/zenodo.17833583) 本仓库附带 cs.AI 预印本： 该预印本提供了 PULSE 的数学和治理背景，作为一个确定性、故障-闭环的 LLM 应用发布治理层，包括： - 安全性/一致性不变量（I2–I7）， - 带 Wilson 区间和 Newcombe delta 的质量门控（Q1–Q4）， - 延迟和成本上的 SLO 预算， - Release-Decision Stability Index（RDSI）， - Vacuum–energy Penalty Functional（EPF）， - 以及用于高紧张度治理状态的悖论字段符号 `[(0 1)P]`。 本仓库包含对应于预印本的 safe-pack、配置文件、schema、工具和 CI 连接的参考实现。 ## 致谢 这项工作使用 **ChatGPT（GPT‑5 Pro）** 起草支持、CI 工作流提示和仓库卫生建议。 人类作者对设计、验证和决策承担全部责任。 ## 案例研究与 Radar - [Lighthouse Case #1](PULSE_safe_pack_v0/docs/LIGHTHOUSE_CASE_1.md) - [Competitor Radar (2025)](PULSE_safe_pack_v0/docs/COMPETITOR_RADAR_2025.md) ## 许可证与联系方式 **许可证：** Apache‑2.0 — 参见 [LICENSE](./LICENSE)。 **联系方式：** [eplabsai@eplabsai.com](mailto:eplabsai@eplabsai.com?subject=PULSE%20inquiry) · [horkati65810@gmail.com](mailto:horkati65810@gmail.com?subject=PULSE%20inquiry) **EPLabsAI — PULSE。从发现到熔断。**

标签：AIOps, AI安全, Chat Copilot, CI/CD安全, DevSecOps, Fail-closed, Llama, LLM评估, ML Ops, MLOps, Ollama, 上游代理, 人工智能安全, 发布控制, 发布门禁, 可信AI, 合规性, 多模态安全, 大模型安全, 审计日志, 模型评估, 版本管理, 确定性发布, 自动化门禁, 质量账本, 软件供应链安全, 远程方法调用, 逆向工具