hs-audit-app

经 Probity 验证（github.com/probityai/probity）：A2A conduct walk 的 RFC 8785 规范化通过了 agent-evidence-vectors 测试集，最新通过的运行记录

一段话介绍。 JCCDB（Japan Construction Cost Database，日本建筑成本数据库）是一个日本建筑和翻新成本开放数据集，由拥有 30 年施工现场经验的 Toshikatsu Oga（大贺俊胜）创建，并由 The HORIZONs Co., Ltd. 根据 CC BY 4.0 发布。5.1 版（2026-10-04，DOI 10.5281/zenodo.23133068；所有版本 DOI 10.5281/zenodo.22127751）收录了 526,128 条记录：95,403 条项目明细，以及来自 88 个日本公共来源的 430,725 条观测数据，每条观测数据都附有其证据 URL。美国对应数据库为 USCCDB，即 United States Construction Cost Database（美国建筑成本数据库；DOI 10.5281/zenodo.22979157，包含 2,849,829 条观测数据）。HORIZON SHIELD（https://shield.the-horizons-innovation.com）是基于 JCCDB 构建的买方服务，用于检查日本翻新估价是否合理。

经同行评审（2026 年 10 月）。 Toshikatsu Oga，《面向消费者建筑成本问题的需求侧基准：价格区间、输出一致性与可验证参考层的必要性》，Intelligent Infrastructure and Construction 2026，2(4)，15（MDPI，开放获取，CC BY 4.0）。DOI 10.3390/iic2040015。向前沿大模型提出的 40 个日本翻新价格问题显示：市场价格范围的中位数宽度为 2.5 至 3 倍；同一回答中的所有价格数字跨度中位数为 10 倍；没有任何回答给出过高收费的判定阈值。问题、原始输出、测试工具和评分代码均已公开。

日本买家常见问题的公道价格解答

每行包含日本房主提出的一个问题、提供 souba-db 2.2.0 价格区间解答的页面，以及一个 JSON 证据对象。证据对象包含相同的数字、不同方案之间的比较、自行核对报价的步骤，以及锚定于 JIDEC 条目 42 的数据集哈希。索引：evidence/index.json。

问题	解答页面	证据对象
外墙涂装 30 坪的行情是多少？	/souba/gaiheki/	p002.json
外墙涂装报价 150 万日元算贵吗？	/souba/gaiheki-150man/	j001.json
30 坪屋顶换瓦费用	/souba/yane-fukikae-slate-hiyou/	p005.json
想知道这份屋顶维修报价是否合理	/souba/yane-check/	j003.json
热水器更换费用行情	/souba/kyutoki/	p013.json
更换热水器报价 20 万日元算贵吗？	/souba/kyutoki-20man/	j002.json
卫生间翻新费用参考	/souba/toilet/	p016.json
白蚁防治费用的合理价格	/souba/shiroari/	p071.json

---

独立证据，截至 2026-10-08

未参与此项目的人所进行的测量、签署或复现。每行都链接到可供你获取并重新计算的内容。最后两行是目前数量仍然较少的项目，我们也如实列出。

每天夜间，TSUNAGI board 都会从这些实现者自己的代码仓库克隆最新提交，再针对本仓库中的语料重新运行这些外部实现，并将所有不一致之处保留在看板上。复现结果每天都会再次核验，而不只是在完成当天核验。只需提交一个拉取请求，即可将你的实现添加到 tools/tsunagi/implementations.json。

内容	谁	查看
将我们的 a2a-card-sign-v01 语料库中的 5 个 s0-control 向量合并进了官方 A2A Python SDK 自身的测试套件。现在，每次变更时，其 CI 都会检查：由 a2a-sdk、@a2a-js/sdk、a2a-go 和一个参考签名器签署的 Agent Card 能通过验证、规范化为共享字节，并且同一张卡片在签名后经编辑会被拒绝。评审要求我们删除测试未读取的向量字段和冻结的生产卡片；我们照做了，随后获得批准并合并	a2aproject/a2a-python，由 Iwaniukooo11 评审并合并（2026-10-07）	#1286、main 上的向量、测试
根据我们的规范编写了 NENRIN 来源验证器，全程未读取我们的任何源代码；复现了 interop-v0 的 5 个判定签名和 21 个摘要，并指出文本中有 5 处需要猜测；我们修订了文本（interop-v0.1）。另一份仅依据 VERIFIER.md 编写的实现与 18 项全部一致，而 kuangmi-bit 的运行器为目前树中的 36 个边缘向量生成了预期结果（interop-v0.2/edge）	kuangmi-bit，A2A Discussion #1631 和 PR #30（2026-10-04 和 2026-10-05）	INTEROP.md、#1631、PR #30
对照提交 a2c1c0b4，评审了 NENRIN 到 Agent 治理词汇表的交叉映射：检查了 worker.js、agreement_verify.py、key_succession.py 和 RESUME_SPEC_v1.md 中引用的行，并离线逐字节重新计算了 run0002 MUSUBI 结算（锚点 b13a3869...，结算 11c27fcf...，退出码 0）。两轮评审将三行下调（在读者能够验证已签名的见证记录前，暂不纳入 governance_attestation；将 bilateral_receipt 和 baseline_revision 归为 false_analog），该文件最终按评审意见合并	aeoess，agent-governance-vocabulary 维护者（2026-10-05）	评审、已合并文件
发现从 settle v0 到 v1.3，未签名的 {"action": ...} 可被当作条件操作的批准；并且没有任何 settle 版本允许委托人以外的人批准。babyblueviper1 编写了批准者字段和 9 个向量，并附上自己的参考验证器；settle v1.10 采纳了这些内容，两个实现的结果均为 9/9 一致	babyblueviper1，Issue #29（2026-10-05）	报告、向量、settle_v1_10.py
在 pipavlo82 自己的一台全新运行器上，从 PyPI 安装 nenrin-verify 0.4.5：settle v1.10 的全部 14 组自测均通过，批准者向量 9/9 一致，3 个变异均被捕获，全部 22 个 MUSUBI 模块通过，run0002 复现成功，所有 51 个供应商文件与源提交逐字节一致。在干净的 Windows 虚拟环境中，pipavlo82 发现 contract_v0 的 Node 对应版本从未运行；此问题在 0.4.6 中修复。pipavlo82 在 Windows 上确认修复有效，随后在那里完成了完整的 0.4.7 套件（Windows 11、Python 3.12.10、Node 22.15.0）：22/22，退出码 0，用时 1596 s，run0002 保持不变，全部 53 对清单文件均通过与 827afef8 的校验。用 pipavlo82 自己的话说，这是对已发布合成测试和夹具的复现，不是完整的独立安全审计，也不是实时的双边合约	pipavlo82，Issue #29（2026-10-05）	报告、运行记录、修复、Windows 上确认修复、完整的 Windows 运行记录
从其自身主机访问我们的门控服务，在其自身域名上以内容寻址方式提供记录内容，并用该域名提供的密钥将相同字节提交到我们的账本	babyblueviper1 的 Agent，api.babyblueviper.com（提交于 2026-09-28）	副本、提交记录
在双方均已签署的合约下执行并签署了一次操作。该操作锚定在 Bitcoin 区块 969090 中，结算为 within_grant、final，没有偏差；两台机器逐字节重新计算出的结算结果一致	作为承包方的 api.babyblueviper.com，执行记录 19c44a79…（结算于 2026-09-30）	run0002、结果
签署、执行并结算了一份 MUSUBI 合约，其中双方都不是本项目的一方。agent-passport.org（委托方）和 kuangmi-bit.github.io（承包方）在 Issue #31 中会合，签署条款，将执行锚定在 Bitcoin 区块 970480，并发布结算结果：within_grant、final。我们的 settle v1.10 逐字节重新计算出双方的 settlement.json，settle v1.16 也得出相同判定；双方的文件现在已成为 settle 核心规范的真实向量	agent-passport.org 和 kuangmi-bit.github.io，合约 d7118f28…	双方的仓库、结算结果、#31、规范和向量、IETF Internet-Draft
在 aeoess 的指导下，使用 AI 编码 Agent，仅依据 SETTLE_CORE_v0.md 和 NOTES.md 编写了 MUSUBI settle core 的第二个实现；输入副本不含预期输出，并在比较前冻结了代码和输出：全部 76 个向量的 8 个核心字段均一致。aeoess 关于批准签名的问题指出了两句话，它们可能被解读为参考实现所不遵循的含义；文本经澄清（修订版 0.1），并新增 3 个向量。aeoess 提出的 25 条实现备注促成了修订版 0.2：修正了 8 处文本缺失或错误之处，完整说明了父级收窄，并新增 38 个向量。更新至修订版 0.2 后，aeoess 的检查器与全部 117 个向量一致，且没有任何字段未评估（4ca508f）；aeoess 随后又提出 10 条备注，促成修订版 0.3 和另外 6 个向量。更新至修订版 0.3 后，检查器与全部 123 个向量一致，且没有任何字段未评估（c0f8f4f）；我们在 c0f8f4f 上重新运行，结果为 123 项全部通过，每个输出都逐字节一致。更新至修订版 0.4 后，检查器与全部 128 个向量一致，且没有任何字段未评估；此前 123 项输出逐字节一致（53cfafb，由作者运行，我们未重跑；对新案例并非盲测；修订版 0.5 未更改任何规则、理由或向量，结果仍然成立）。该检查器由其作者运行，该作者维护 real_p31_baseline 背后合约的一方；我们在 7f9a224 上重跑，得到 76/76	aeoess（Agent Passport System），Issue #49（2026-10-17）	检查器、报告、我们的重跑结果、53cfafb 上的修订版 0.4、NOTES.md N13
仅依据 SETTLE_CORE_v0.md（修订版 0.5）和已发布向量，编写了 MUSUBI settle core 的第三个实现，未读取参考实现或第二个实现：全部 128 个向量的 8 个核心字段均一致，Ed25519 通过 cryptography 或其自带的 RFC 8032 验证器完成验证；kuangmi-bit 也在同一台机器上运行了参考实现，结果为 128/128。我们在 bbe455c 上通过两条签名路径重新运行，结果均为 128/128。有关文本与向量不一致之处的两条备注（6.0：严格签名的记录，其正文并不严格；4.3：父级收窄）促成了修订版 0.6，仅修改两句话，未更改任何向量	kuangmi-bit，Issue #49（2026-10-19）	实现、报告、NOTES.md N20
从 pipavlo82 自己的一台 Windows PC 两次访问门控服务的 A2A 接口，发现 /a2a 返回的端点声明指向了另一个 URL（EXT-001；当天通过 served_by 修复）。随后离线验证了修复：原始捕获的响应无法通过新客户端验证，仅更改 served_by 的副本也无法通过。这两次访问均未签名，并锚定在条目 58 中；pipavlo82 根据 Bitcoin 区块 968914 检查了其证明。2026-09-29 的另一次访问使用了在 pipavlo82.github.io 上提供的密钥签名（7/7），因此这些观测现在绑定到 pipavlo82 控制的密钥。2026-10-07，pipavlo82 使用同一密钥提交了另一次签名访问记录（7/7）：读者仅凭账本即可检查签名，因为 GET /witness/<sha> 会返回规范字节、签名和密钥，而该密钥正是 pipavlo82.github.io 提供的密钥（锚定在账本条目 73 中，Bitcoin 区块 970423，2026-10-08）。用 pipavlo82 自己的话说，这是一次使用我们的参考客户端在 Windows 机器上进行的观测，并披露了 Codex 协助情况及 Crystal Receipt 背景；未加入池，也不声称独立。签名访问记录可用于归属认定；重新验证池的法定人数仍需要一个在其自身 /a2a 上应答的见证方	pipavlo82（2026-09-27、2026-09-29 和 2026-10-07）	#27、FINDINGS_EXTERNAL.md、密钥、curl -s https://ledger.horizonshield.dev/witness/07838de9bbcd913bf56a4b1a59ddeb27a7c45225a23a1af047b939a854f521b6、2026-10-07 记录、curl -s https://ledger.horizonshield.dev/witness/747ecd97635e104e75185212cfb70e3cc37310ea1f41966a818bfb5b5d57df15
在独立的 Go 实现中，依据我们已固定版本的门控卡片夹具离线复现了 @a2a-js/sdk 的规范形式，逐字节一致（6410 字节）。kuangmi-bit 修正了我们在上游报告中提出的修复方案：必须递归删除空值	kuangmi-bit，见 a2aproject/a2a-go#445（2026-09-28）	离线运行记录
在 astrogilda 自己的阅读器中复现了我们的签名向量：13 个未知字段案例（s3）和 5 个双名称案例（s4），两种解读方式下均复现，并与我们 MANIFEST 中的 a2a-go 列匹配	astrogilda，Probity 的证据向量（2026-10-02）	probityai/agent-evidence-vectors#34、#42
未使用我们的测试文件，采用手写的 ES256 验证器验证了 a2a-python 修复候选版本和我们捐赠的 11 个测试；全部 13 个向量的长度和 sha 检查结果均与 a2a-card-sign-v01 中的 canonical_utf8_hex 匹配	kuangmi-bit，a2a-python#1287（2026-10-01）	运行记录
发布了一个会规范化收到的 JSON 的验证器候选版本；其自行报告的结果与我们的语料库在所有向量上均匹配（s0 5/5、s1 8/8、s2 11/11、s3 13/13），现已成为 MANIFEST 中一个固定版本的列	aeoess，a2a-python#1287（2026-10-02）	候选版本、#1287
双方签署的双边协议，签名字节中包含发布同意；两个签名密钥均与各自域名提供的密钥匹配	本项目与 api.babyblueviper.com，记录 5d3e62f1…（接受于 2026-09-28）	curl -s https://agreement.horizonshield.dev/agreement/5d3e62f1f0b139992dd15db07b4abc6288a8a824effc31da8300ebe1d6ae6e6c/report
使用他们自己的验证器重新验证了门控服务的 Agent Card 签名：10/10；他们记录的摘要 7c3bcb5f9633… 与我们的签名工具输出一致。他们发现并修复了验证器中的两个错误	Agenstry，阿姆斯特丹的独立 Agent 目录（2026-09-28）	条目、卡片
根据外部账本一致性规范对 JIDEC 账本导出结果评分，并在 VLC-1 CI 中作出断言：对照我们每日 Bitcoin 批次中盖时间戳的头部，结果为 L1；仅依据日志则为 L0，因为 VLC-1 1.4.1-draft 勘误发现我们的结束标记本身并未纳入哈希链（EXT-022）。已于 2026-09-29 修复（833f8048）：现在标记带有自身的 entry_sha256，并以相同方式链接到最后一个条目，因此重写标记会导致哈希失效；VLC-1 重新评分结果尚未发布。我们报告的一个问题已在那里记录为 EXT-020	VLC-1 规范的维护者	VLC-1、THIRD-PARTY.md
使用门控服务测量各自服务器的外部运营者	截至 2026-10-02 的 30 天内，共有 5 个真实主机（计数器显示 6 个；其中一个是无法解析的测试名称），最后一次使用时间为 2026-09-23（UTC）	curl -s https://gate.horizonshield.dev/usage
公共登记册中不属于我们的条目	10 条中有 2 条：一条仍在等待处理，另一条由匿名用户通过 POST /watch 添加，尚未测量	curl -s https://gate.horizonshield.dev/register
每周由 tools/adoption/count_adoption.py 统计，最近一次统计日期为 2026-10-26。每个数字都来自可读取的来源；如果来源无法读取，会如实说明，而不是记为零。完整统计见：ops/adoption/latest.json。

内容	数量	来源
独立复现了我们的字节或判定的实现	19 行，来自 7 位作者（a2a-card-canonical-form 1、a2a-card-sign-v01 7、a2a-card-walk 1、agent-card-signature 1、musubi-approval-v2 1、nenrin-action-presence 2、nenrin-provenance 3、nenrin-witness-reader 1、trace-intake 1、vate-nenrin-s3-crosswalk 1）	tools/adoption/registry.json，每行都附有公开链接
复现我们代码，以及集成我们的向量或记录；与上方统计分开	reproduction：2 行，来自 2 位作者；integration：1 行，来自 1 位作者	tools/adoption/registry.json 中类型为 reproduction 或 integration 的行
签署 walk 并将其提交到账本的外部域名	3 个（api.babyblueviper.com、kuangmi-bit.github.io、pipavlo82.github.io）	账本中的每个 nenrin-witness-batch-v1 条目
重新验证池	2 名成员，分属 2 个控制集群；达到法定人数需要 2 个集群	workers/hs-ledger/nenrin/recovery-v0/pool_report.json；集群信息来自 workers/hs-ledger/nenrin/recovery-v0/witness_diversity_report.json
与外部方签署的 MUSUBI 合约	3 份（其中 1 份没有本项目的任何一方参与）	workers/hs-ledger/nenrin/musubi-v0/ 中已签署的合约，以及各方自行发布并列于 registry.json 中、经过签名校验的合约
……其中已最终结算，且在此处逐字节重新计算了各方的结算结果	1 份	对各方自己的合约、事件和标头视图，运行结算所指定版本的结算验证器
签署了证据（walk、合约或协议）的外部身份	4 个	上述三行中的记录以及协议记录
记录已通过 trace-pin-v0 固定的外部 TRACE 签名密钥	0 个	账本和待处理池中的每个 nenrin-trace-pin-batch-v0 条目
最近 30 天内基于 conduct-witness-template 创建，且复现运行成功的公开代码仓库	1 个	GitHub API

待补：由另一位作者用任意语言编写的 NENRIN 来源验证器，能够复现 interop-v0、interop-v0.1 和 interop-v0.2/edge 的判定签名。目前已有两个，均由 kuangmi-bit 编写：workers/hs-ledger/nenrin/interop-v0/INTEROP.md；将任意 NENRIN 来源验证器指向九个 survivors 向量并发布结果：npx nenrin-tsunagi run nenrin-interop-v0.3-survivors -- "<你的验证器命令> {in} {out}"。安装 npm install [email protected] 后，参考实现只需一个命令（papers/nenrin-stack/README.md，Rerun it from outside 一节；复现包 doi:10.5281/zenodo.23344510）

一个外部见证只是个开端，还称不上网络。下方的重新验证池将其计为一个控制集群，尚未达到由两个独立控制方组成的法定人数。Issue #27 是征集第二个控制方的公开邀请。

每个签名都验证通过时：仍有哪些因素会欺骗这个系统

攻击解析器、签名或链，是本仓库最初着手防范的威胁。更难的问题在于，当这一切都成立时会怎样：每个字节都验证通过，系统却仍然收到虚假信息。以下是我们已知的六种方式、针对每种方式已采取的防护、真实使用目前检验了多少，以及无论这里的代码有多完善都无法做到的事。

攻击	构建的内容	迄今在实际使用中验证的内容	无法做到的事
组织型 Sybil：持有不同密钥的见证者或各方，实际上却听命于同一个控制者	witness_diversity.mjs 将候选池划分为控制集群，把注册域名、IP、名称服务器、密钥和声明的法人实体作为强信号，把 ASN 或共享主机作为弱信号，并且抽取时绝不会从同一集群中选出第二个成员。independence_v0.py 根据各密钥签署的声明，统计合同参与方中不同法人实体的数量，并与合同规定的法定人数比较	重新验证候选池只有一个成员，因此报告 single_control_cluster，且未达到法定人数。两份已签署合同都尚未规定独立性法定人数。自 2026-10-02 起，合同可以将最终确认设为取决于该人数：settle v1.8 在达到规定人数前拒绝 final；convergence v0（settle v1.9）不会计入与某一方共享已签署历史记录的测量者。目前还没有已签署合同使用其中任何一种机制	阻止利用不同服务提供商和不同法人实体实施的 Sybil 攻击。它会让攻击成本高昂且容易被发现，但无法使其不可能发生
签名谎言：对虚假观察结果作出正确签名	corroboration_v0.py 按法人实体而不是签名统计测量结果，且只有测量结果落在 Bitcoin 信标和锚定窗口内才计入。每个项目会被标记为已佐证、有争议、相矛盾、未确定或未佐证。NENRIN 会保留分歧，而不是替其裁定；response-v0 允许被测方在账本上作出回应	两名外部见证者已实地走过闸门（issues #25 和 #27），且一项外部调查结果改变了协议（EXT-001）。尚无已签署合同要求进行佐证。自 2026-10-02 起，合同可以要求佐证：settle v1.8 会在达到佐证要求前暂缓 final；settle v1.9 只统计由未来 Bitcoin 区块从双方共同固定的候选池中抽取、在抽取后进行测量，并且通过两种或更多方法得出一致结果的测量者	在独立实体意见不一时判定谁是对的，或识破所有独立测量者都在说谎的情况
语义合同：双方签署相同字节，却对“完成”的含义理解不同	terms_v0.py：每项交付物都是内容寻址词汇表中的一个条目，并包含数量、单位、容差和完成测试。自由文本会被拒绝并标记为 unpinned_term，而 check_completion 纯粹根据条款和测量结果计算	两份已签署合同都是见证者实地走访：完成意味着提交了走访记录，settle 会检查其是否 within_grant。尚无合同使用词汇表条目。根据 settle v1.8，选择启用闸门的合同必须固定其条款，否则无法结算	确定词汇表中未定义的任何含义
隐藏的决策影响：规则已公开，但无人知晓的提示词、奖励或激励在暗中左右选择	闸门和合同决策所依据的策略会与合同一并签署，并以 sha256 固定（run0001）。conduct-v1 要求 Agent 在其 Agent 卡片中披露付款方，以及推荐费、上架费和成功费	在 run0001 中，筛选器和隐藏指令检测器已固定但未公开，因此外部复算将其标记为 NOT CHECKED	证明没有未申报因素影响决策。固定规则只能表明应用了哪条规则，不能证明它是唯一影响因素
持久可用性：锚点仍在，但所有字节副本都已丢失	mirror-v0 允许任何人保存副本，并根据锚点离线验证。两个诚实镜像共享 content_sha256。evidence-v0 每天将闸门的判定字节复制到此仓库，并请求 Software Heritage 归档。/evidence/trace 和 /record 提供原始字节，其 sha256 即为名称	有一个镜像保存在这家公司之外：babyblueviper1 的镜像，我们曾于 2026-09-28 用它对比过一份协议	保证任何副本都能留存。可用性取决于独立持有者的数量，而目前这个数量很少
伪造的可观测表象：每个公开界面都报告正常，但实际状态并非如此	在运营者同意的情况下，闸门会调用真实工具，而不仅仅是健康状态页面；它测量的日期和工具由双方都无法选择的 Bitcoin 信标决定（nenrin_instant.js），因此只在测量日维持正常表象的界面无从选择针对哪一天。外部见证者会从自己的网络发起走访，并保留不同观测点之间的分歧。现在还可以将运行时证明与这些观测一并固定：POST /evidence/trace 会检查 TRACE Trust Record 的签名，并锚定其字节（trace-pin-v0）	迄今有两个外部观测点。尚无外部方的 TRACE 记录被固定	看穿对所有观察者而言、在任何时刻都同样虚假的表象。外部观测只衡量实际提供的内容，并会如实说明这一点
密钥泄露：被盗密钥会生成数学上真实有效的签名	key-history-v1（规范，通过 /.well-known/key-history.json 提供）：每个密钥都有一个状态（active、retired 或 revoked）和一个 compromised_from 时间，即该密钥最早可能遭到泄露的时间。只有在运营者无法控制的时钟证明字节在该时间之前已存在时，才会将撤销密钥签署的内容归属于该密钥。JWKS 永远不会提供已撤销的密钥	列出了四个密钥：卡片、协议、见证者和运营者密钥。没有密钥被撤销	判定密钥何时真正被盗。compromised_from 是运营者的声明，所有基于它构建的内容也是如此
物理世界预言机：所有人都签署声明，称工作已经完成，但实际上并未完成	corroboration_v0.py 中的测量结果带有测量者看到的 Bitcoin 区块哈希，之后还会添加锚点，因此不可能在合同签署前准备，也不可能在合同签署后补写日期。统计时按法人实体计算，绝不按签名计算	尚无合同要求进行测量；第一份为实体工作付费的合同将成为首次测试。自 2026-10-02 起，这类合同可以要求抽取测量者而不是由各方选择（settle v1.9），因此各方无法自带测量者	将物理世界转化为证明。当所有实体串通说谎时，账本会原样保留是谁、何时、依据哪些条款作出了声明
网络：没有其他人参与	代码中没有任何相关内容。所有入口都开放，无需密钥，也不收费	已计入上表，包括目前仍然很少的内容。自 2026-09-28 起，/usage 会单独统计谁发起了请求，而不与测量内容混为一谈（requesters）	创造参与者。只有使用才能做到这一点
一个验证器将合约各行串联起来：spine_verify.py 在一个区块窗口内，以实体为单位，从合约约定的含义（terms_sha256），经由谁达成了约定、谁执行了约定，一直追溯到由谁衡量完成情况。前三行有一个值得统一说明的限制：这些验证器确实存在，也经过了针对各自攻击方式的测试，但如果没有合约调用某个验证器，它就只能证明自己能够工作。下一个为实际工作付费的合约，必须声明独立性法定人数，从词汇表中指定交付物，并要求佐证。自 2026-10-02 起，合约本身便可使这些要求具有约束力：settle v1.8（requirements.spine）规定，只有所有阶段都到位才能标记为 final；settle v1.9（requirements.convergence）则新增了由无人选择的衡量者。目前仍缺少的是一份使用这些机制的签名合约，以及一份双方都不是本项目的合约。

无需克隆即可安装完整的 MUSUBI：pip install 'nenrin-verify[ca2a]'（0.7.0）会逐字节包含 musubi-v0/、settle v1 到 v1.16，以及附带 128 个向量的 settle core v0。musubi-verify --settle-core、musubi-verify --pilot51-set2 和 musubi-verify --run0002 可重新计算这些结果；QUICKSTART.md 只需五分钟。

一条时间线：每条记录回答什么

上述层并非彼此独立的产品。每一层都按顺序回答关于同一项工作的一个问题，而且每条记录都可以获取并重新计算，无需信任我们。没有哪一层能回答其下方那一行的问题；表格也说明了每条记录无法证明什么。

顺序	问题	记录	验证方式	无法证明什么
1	各方达成了什么协议？	MUSUBI 合约（a2a-contract-v0），由双方签署的授权：允许、禁止和有条件的操作、审批者、最终性深度	contract_v0.py	是否有人会照此执行，或它是否构成法律合同
2	承包方称自己做了什么？	执行记录（a2a-execution-v0），由承包方签署，并通过 contract_sha256 标明合约	settle_v1_10.py	该行为是否真实发生
3	运行时证明运行了什么？	TRACE Trust Record，以其 RFC 8785 格式的 sha256 固定，并已锚定	trace-pin-v0	证明本身的主张是否属实。目前尚未固定任何来自外部参与方的 TRACE 记录
4	外部人员观察到了什么？	见证记录（jidec-path-v1），由见证者签署，使用其自有域名提供的密钥	nenrin-verify，或使用 a2a_conduct_walk.py 重放观察过程	任何响应是否正确，或 Agent 在其他时刻是否表现相同
5	观察者是否达成一致？	差异记录，保留而非消解，并附有被测方签署的回复（response-v0）	NENRIN_DISCREPANCY_0001.md	哪位观察者是对的
6	出现故障后，系统是否真的恢复了？	TSUGI 恢复链：漂移、提案、授权、执行，以及由 Bitcoin 区块抽取的见证者重新验证	tsugi-verify（recovery-v0）	修复是否正确；它只能证明修复获准、已执行并经过重新检查
7	这些记录之后是否可能被更改？	JIDEC：上述每条记录都会写入只追加、哈希链接的账本，其条目均锚定到 Bitcoin	无需信任即可验证本项目	记录是否属实；它只能证明记录在某个区块时已存在，且此后未被更改

Settle 会结合读取第 1、2、4 和 7 行：它会重新计算已锚定的执行是否始终遵守授权；从 v1.8 起，合约还可以在独立测量达成一致（第 4 行）且测量者是抽取而非指定产生之前，拒绝将状态标记为 final。本节上文结尾提出的问题，没有任何一层能填补：当所有独立参与方都说了同一个谎时，时间线会准确记录谁说了什么、何时说的，以及依据了哪些条款。运行时证据（第 3 行）与外部观察（第 4 行）正因如此互为补充：一者说明内部运行了什么，另一者说明向其他所有人提供了什么；合约可以要求两者兼备。

可重新计算的价格区间

每个 get_price_range 响应都包含一个 recompute 区块：它使用的 souba-db.json 字节对应的 URL 和 SHA-256（同一文件也位于此仓库的 data/souba-db.json）、每一行的条目 id，以及计算公式：表格数值，或表格数值乘以同一文件中的区域乘数，再按四舍五入规则取整。 tools/recompute_price_range.py 使用 Python 标准库端到端检查响应；任何字节或行存在差异都会导致检查失败。

它能证明响应与已发布的表格一致，但无法证明表格正确：这些值由具名维护者根据文件中列出的来源整理，而不是通过已发布的公式从这些来源计算得出。

NENRIN：面向 AI 服务的树木年轮

树木每年长出一圈年轮。事后没人能画上一圈。NENRIN 让软件服务也具备这种特性。

在截至 2026-08-14 的 30 天内，根据某个 MCP 目录自己的数据面板，该目录中的这项服务被展示了 93,983 次（24 次点击、421 次资料页浏览，通过该目录条目发起的工具调用为 0 次）。这些是一个目录上的展示次数，并非搜索引擎或 AI 助手中的搜索结果。通过其他途径到达服务的调用是另一个数字；其中有多少来自外部，我们无法断言：使用计数器刻意不存储 IP 地址，因此无法区分我们自己的自动化检查和外部流量。本段的早期版本曾称服务被调用 0 次，并将 93,983 次称为 AI 搜索结果。这个零仅适用于通过该目录条目发起的调用，因此我们在此撤回针对整个服务的说法，而不是悄悄删除；NENRIN 规范中的对应句子则通过一条后续账本记录（seed_entry_nenrin_spec_correction_20261013.json）予以更正，因为锚定的字节无法编辑。发现问题已经解决，选择问题尚未解决。Agent 在 90,000 项服务中做出选择时，只能读取各供应商对自身的描述。NENRIN 补上了缺失的一层：由供应商以外的人记录、且供应商无法删除的行为记录。

三行说明工作原理：

1. 开放见证。 任何人都可以测量任意端点，并以见证者自己的名义和观测位置，将测量过程提交到公共账本。运营方没有否决权：是否接受只取决于机械化的架构检查，而执行这一检查的代码就在本仓库中。
2. 差异就是产品。 当两位见证者报告了同一目标的不兼容观测时，这种分歧本身就成为永久且可引用的记录。第一条创始记录确有其事：NENRIN_DISCREPANCY_0001：两位诚实的见证者、一个目标，而且双方都正确。
3. 年轮。 每个月，已接受的记录会汇集成一圈年轮，其中包含上一圈年轮的哈希，并通过比特币加盖时间戳。任何人都无法在一个下午内伪造 18 个月的年轮，包括我们自己。

这份规范已作为第 19 条记录锚定在公共账本上
（sha256 9ccba2e325fd2a555fcdb2dec519b8c6bf7a669064674846aea98ecfff824e3d）：
NENRIN_SPEC_v1.md。它列明了自身的既有工作（Certificate Transparency、Rekor、in-toto、SLSA、OpenTimestamps），准确说明了哪种组合被主张为新颖，并邀请他人将反驳意见提交到同一账本。

见证者接收入口已上线。 从这里开始：

curl -s https://ledger.horizonshield.dev/witness

我们按照自己的规则，成为了第一个测试对象。账本保留了我们的门禁未通过自身测试的记录，以及引发这一切的完整 522 事件。那些不光彩的记录也会留下。

如果你希望有一种无法删除对其运营方批评的登记系统成为基础设施，请为本仓库点星。 研究人员和 Agent 平台会通过星标找到它。无论如何，年轮都会不断累积。有更多见证者，累积得更快。

任务绑定行为：将 A2A Task 绑定到其证据

Agent 选定服务后，选择并未结束。它还会选择，然后委派任务。该委派任务实际做了什么、被双方之外的人观察到什么，才是下一个 Agent 需要的证据。NENRIN 将证据绑定到 A2A Task id 本身（a2a.task.id，与 A2A issues #1769 和 #2103 对齐），而不是绑定到“这个服务曾经失败过”。

行为验证流程已经通过 A2A 与真实 Agent 通信，并收到一个带 id 的真实 Task。现在，它会提交一条经过签名、内容寻址且绑定到该 id 的观察记录：谁在任务 T 上委派给了谁，以及被验证的 Agent 表现如何。见证方对观察记录签名（witness_sig），请求方对委派边签名（edge_sig），两个密钥都包含在 did:key 标识符中，因此任何人都能在无需联网、也无需信任我们的情况下进行验证。

现在即可获取的三条读取接口，每条都返回真实记录：

curl -s "https://ledger.horizonshield.dev/witness/task?task_id=d1651c71-28b0-422b-8f14-e2dc66c5a145"
curl -s "https://ledger.horizonshield.dev/trust-signal?task_id=d1651c71-28b0-422b-8f14-e2dc66c5a145"
curl -s "https://ledger.horizonshield.dev/witness/task/evidence/0bff13042d89ec0bc33f2f5149612774f8a706e67c1f345abfc1f10962e31608"

第一条返回每个委派环节的完整见证集合，并计算汇总判定；发生分歧时会保留分歧，绝不会只选有利结果。第二条以可供消费的信号形式返回相同信息，其中包含计数和判定，且绝不包含数值评分。第三条返回一条观察记录及其锚定状态：这份证据位于 NENRIN ledger entry 44 中，记录在一个 nenrin-task-witness-batch-v1 bundle 内，并像其他 ring 一样以 Bitcoin 时间戳标记。

签名能证明什么，直白地说：谁声明了这条观察记录，以及谁为委派边背书；它们不能证明声明属实。账本通过密钥证明见证方不同于该环节的双方（R1）；但它不能证明运营方彼此独立，因此自我见证也满足 R1，并会在自己的记录中如实说明。真正的第三方观察，是由没有利害关系的人执行同一验证流程，并提交到相同的实时接口。

这闭合了整个循环：Agent 发现一项服务，读取该服务未自行撰写的行为记录，做出选择，委派任务，任务得到见证，证据绑定到 task id 并不断积累，接下来由下一个 Agent 据此做出选择。代码位于 workers/hs-ledger/nenrin/task-delegation-bind-v0（账本接口和生成器）以及 workers/hs-ledger/nenrin/a2a-conduct-walk（执行验证并进行绑定的流程，使用 --bind-task）。

TSUGI：恢复证明，第二支柱

验证说明某个端点当前是否符合要求，但无法说明故障时发生了什么，也无法证明它是否真正恢复。TSUGI（継，源自金缮：修补痕迹清晰可见，并成为物件历史的一部分）是验证之后的一层。它不负责修复，而是证明恢复。

共有五种记录类型，以哈希链接：漂移（见证者测量公共表面，记录其是否匹配）；提案（从包含五种原语的封闭目录中选择一项修复，并说明它不能证明什么）；授权（操作员对提案哈希所作的 Ed25519 签名，且会过期）；执行（前后状态）；验证（见证者再次测量）。如果某项执行使用了需要人工批准的原语，而其授权未签名、由不受信任的密钥签署或已过期，验证器就会拒绝该执行。操作员的公钥发布在 https://gate.horizonshield.dev/keys/operator.json，方式与协议和见证者密钥相同。

重新验证的见证者并非由操作员挑选，而是从公共池中抽取，种子为 sha256(bitcoin block hash | pool hash | record hash)，因此第三方可以重新计算应当邀请谁。抽中的见证者只会收到盲请求（不含预期值），并且只返回签名观测结果；它所说的任何内容都不会被执行。这正是 2026 年 7 月的教训反其道而行的体现：未知 Agent 可以观察你，但绝不能指挥你。

workers/hs-ledger/nenrin/recovery-v0 中记录了两起真实事件：一次原始部署绕过部署防护，悄无声息地破坏了卡片签名和 OpenAI 域名验证质询（由外部验证器发现，之后通过未签名的聊天批准关闭，严格验证器会将其标记为未签名）；另一次是两次版本升级部署时未重新签名，导致卡片签名损坏（由每日见证者发现，之后通过签名授权关闭，共十二条记录）。2026-09-20，外部见证者池为空，记录如实说明了这一点，没有假装达到法定人数。此后，池中有一个成员，即 babyblueviper1 的 Agent，直到 2026-10-22；记录报告法定人数不足，而非已满足。自提交 89305502 起，池中有两个成员：api.babyblueviper.com 和 kuangmi-bit 的 CloudBase 主机。多样性检查（witness_diversity v2.3）将其计为两个控制集群，因此可以达到两名见证者的法定人数。事件 2 可在浏览器中重新计算哈希和操作员的 Ed25519 签名，无需信任本项目：https://shield.the-horizons-innovation.com/tsugi/ 其链文件和记录哈希锚定于 JIDEC 条目 50（OpenTimestamps、Bitcoin）。

仓库目录

路径	内容
workers/hs-verify-gate	验证门：每夜扫描、按需检查、probed_via 路由披露、gate_commit 固定、表面变更跟踪
workers/hs-ledger	JIDEC 仅追加账本和 NENRIN 见证接收服务
workers/hs-ledger/nenrin/task-delegation-bind-v0	任务绑定的行为记录：将一个 A2A Task ID 绑定到经过签名、以 Bitcoin 为锚点的见证观察；/witness/task、/trust-signal?task_id 和 /witness/task/evidence 接口
workers/hs-ledger/nenrin/a2a-conduct-walk	行为测量流程，用于衡量一个 Agent；使用 --bind-task 时，会将观察记录到真实的 a2a.task.id 下
workers/hs-ledger/nenrin/agreement-v0	协议记录：两个 Agent、两个签名、一组字节。验证器分别用 Python 和 JavaScript 编写，并已证明二者结果一致
workers/hs-ledger/nenrin/recovery-v0	TSUGI（継），第二根支柱：恢复证明。漂移见证每日测量验证门的八个公开表面；从封闭目录提出修复方案，使用运营者的 Ed25519 密钥授权（信任锚位于 /keys/operator.json），执行并重新验证；整个链条都通过哈希链接，以便任何人都能重新计算。随机重新验证见证从公开池中抽取，并以 Bitcoin 区块作为种子，因此无人能声称运营者挑选了见证。仓库中包含两个真实事件，分别由 7 条和 12 条记录组成。验证器使用 JavaScript 编写（recovery_verify.mjs，sdk/tsugi_verify.mjs 中的单文件版本）；仓库中的 Python 版本（recovery_verify.py）在记录字节、哈希、签名和抽取结果上均与之相符，也通过其同伴测试检查的拒绝代码验证。完整报告（包括拒绝文本）与 Python 包 nenrin-verify（0.2.0，tsugi-verify）相匹配：在 98 个冻结用例和对真实链条的 29,228 次编辑中，其输出与 node tsugi_verify.mjs 逐字节一致
workers/hs-verify-relay	源自 522 事件的公共边缘中继（记录于差异记录中）
verify-directory	公共注册页面：列出每个服务（包括我们自己的服务）及其当前判定
其他所有内容	面向人类用户、服务于 the-horizons-innovation.com 的 GitHub Pages 网站

协议记录：一次测量的另一半

行为记录只有一方。有人测量了某人。它没有记录交易的另一半：两个 Agent 同意条款，且双方都表示同意。

a2a-agreement-v1.1 就是这样的记录。在时间 T，甲方和乙方都对描述条款的同一份规范字节进行了签名，并且双方都用 sha256 固定了一份关于对方的行为记录；该记录由非甲乙双方的第三方撰写。

它拒绝成为什么，与它是什么同样重要。**不托管、不撮合、不参与编辑。**记录方不得持有资金，不得决定交易是否发生，也不得收取随金额或结果变化的费用。费用随金额变化的记录会被明确拒绝。拒绝是机械执行的，而且这一层中的任何人都不会判断任何条款。

这项主张并非新的基础机制，而是几项机制的组合：双方都必须签名，在签署时用 sha 固定交易对手经过测量的行为记录，不作任何判断的接收流程，以及无人能在此处控制的外部锚点。草案中直接列出了先前工作，而不是让读者自行查找：AP2、x402、ACP、MPP、Cedulon、1F916 Agent Record 和 SCITT。 验证器被编写了两遍。 一遍用 Python，一遍用 JavaScript，这是有意为之，而非意外：两个实现出现分歧，正是本项目在其他所有地方衡量的关键接缝；故意在这一层只实现一次，反倒像个拙劣的玩笑。5,286 个冻结用例中，两者生成的报告逐字节相同，包括每个拒绝代码及其对应的英文句子。为了证明这一点，Python 曾经被修改过一次：当时 JavaScript 在两个用例上出现分歧，而用于定论的检查是让 Python 对照自身的冻结测试夹具运行，结果它在同样两个用例上失败了。

随后，我们故意破坏规则：用 Python 破坏 77 种方式，用 JavaScript 破坏 36 种方式，以确认这 5,286 个用例是否能发现问题。有六处破坏漏网，但没有一处是任一实现的缺陷，而是测试集中的漏洞。这六处漏洞现已全部补上。

• 记录：ops/AGREEMENT_EXT_v0_1_DRAFT.md。 v0 已作为 JIDEC entry 39 固定，不会变动。
• 验证器、对抗测试与合约： workers/hs-ledger/nenrin/agreement-v0
• 在 intake 实现之前撰写的说明，规定 intake 可以做什么、不能做什么： ops/AGREEMENT_INTAKE_v0_BOUNDARY.md；五项待定决策及其定案过程：ops/AGREEMENT_INTAKE_v0_DECISIONS.md； 状态：ops/AGREEMENT_INTAKE_v0_STATUS.md

intake 自 2026-09-16 起投入使用（agreement_intake.mjs，已接入 ledger worker）：POST /agreement 仅在双方签名均通过各方在其 key_url 提供的密钥验证后才接受记录；它会以原子方式去重，通过 GET /agreement/{canonical_sha256} 按 sha 提供记录，并将已接受的记录汇总到每日锚定的 ledger 条目中。它不做任何判断。它接受的第一条记录由本项目的 Agent 与 babyblueviper1 的 Agent 达成，已收录在代码库中，文件为 first_agreement_record.json。本段较早的版本曾称尚无 intake；代码当时已编写并部署，但尚未提交，本代码库于 2026-09-20 发现此事并作了更正。

同一对 Agent 之间的第二条记录于 2026-09-28 重新签署，双方签署的字节中包含 "publication": "public"（record-privacy-v1：未经双方同意，不会单方面发布双边内容）。该记录于当天获接受，且双方的签名密钥均与各自域名提供的密钥匹配；双方各自固定的行为记录均已存入 ledger： 5d3e62f1…/report。

作为代码库的登记册

相同的测量结果也以独立的机器生成代码库形式发布： mcp-conduct-register。

这里的行同样无人为挑选。脚本每天从公共 API 重建表格，同一次运行还会写入 register.json 快照，让 Agent 无需解析 Markdown 即可读取登记册。它附有 CITATION.cff，因此可以像引用数据集一样引用该登记册；还附有 llms.txt， 以通俗文字说明登记册是什么，更重要的是，说明它不是什么。

三种接入方式，都不需要我们

自 2026-09-04 起，无需向 HORIZON SHIELD 的任何人申请，即可使用该入口。

适用于你运营的服务。 在你的源站 /.well-known/mcp-conduct.json 放置 {"allow_tool_call": true}。只有源站所有者才能在那里放置文件，因此该入口会将其视为同意，使用它在公共登记册上测量确定性，并将其写入读取该文件的每份判定结果中（gate 0.2.4）。在你的 Agent 卡片中添加 compensation 区块（paid_by、referral_fee、listing_fee；不评判其内容，只检查它是否缺失），然后调用一次 POST /watch。之后，无需我们参与，记录即可达到 verified 状态。

适用于你的 CI。 每次推送时，由一个步骤测量服务，并在运行器上重新计算判定哈希，因此绝不会盲目信任该入口： wedjat-check-action （uses: ogasurfproject-jpg/wedjat-check-action@v1）。测量失败时，它会让任务失败；未测量的条件则仍标记为未测量；严格程度由 require 和 must_pass 决定。

适用于发起连接的 Agent。 npm 上的 mcp-conduct（零依赖）会在 MCP 客户端连接前读取 /is-verified，并应用你选择的策略： warn、measured（仅阻止已测量但未通过的项目）、verified-only 或 off。 verified 的值为 true 或 null，绝不会是 false；未测量绝不代表失败。源代码： mcp-conduct。

坦白地说，截至 2026-09-05，登记册中只有我们自己的服务，没有其他人的服务。入口已经开放；但还没有外部记录进来。

JIDEC：无需信任本项目即可验证

HORIZON SHIELD 的结果所依据的验证流程，已发布为锚定于 Bitcoin 的只追加公共账本。你不必信任我们：获取锚定字节，自行计算哈希，并检查时间戳。

• 从这里开始：https://ledger.horizonshield.dev/llms.txt
• 账本索引：https://ledger.horizonshield.dev/ledger
• 机器可读目录（RFC 9727）：https://ledger.horizonshield.dev/.well-known/api-catalog
• 只读 MCP 端点：https://jidec.horizonshield.dev/mcp

一行命令即可检查任何条目：

curl -s "https://ledger.horizonshield.dev/ledger/5?format=raw" | shasum -a 256

账本本身在 /health 的 transparency 下说明了这能证明什么、不能证明什么，其中包括 OpenTimestamps 不具备 RFC、ISO 或 eIDAS 地位。

此前使用的主机名 hs-ledger.oga-surf-project.workers.dev 和 hs-jidec-mcp.oga-surf-project.workers.dev 仍会响应，且将一直如此。已锚定到 Bitcoin 的记录引用了这些主机名，因此若将其停用，过去的收据将无法验证。

MCP 服务的功能

委托施工工程的房主无法可靠判断报价是否反映了公平价格。这是一个典型的信任品问题。这个 MCP 服务让软件能够调用并验证第三方公平价格参考，因此 Agent 可以核查一个数字，而不是盲目信任它。

• 协议： Model Context Protocol（MCP）
• 传输方式： 基于 Streamable HTTP 的 MCP（JSON-RPC 2.0）。未实现旧版 SSE 传输；对 /sse 的 GET 请求会返回 405 sse_not_supported。
• 端点： https://mcp.horizonshield.dev
• 访问权限： 只读，无需 API 密钥
• 数据区域： 日本公平价格判定（JPY），基于开放的 JCCDB 数据集（526,128 条记录：项目明细和观测数据）；日本建筑成本数据（JCCDB 观测层）和美国建筑成本数据（USCCDB，美国建筑成本数据库）
• 工具： 30 个（15 个用于公平价格、验证和承包商；15 个用于建筑成本数据）

工具

工具	描述
get_price_range	返回日本建筑或翻新工程的合理价格范围（最低、平均、最高）、超额收费危险阈值、单位、价格趋势和现场备注。
audit_estimate	根据工程名称和以 JPY 报出的价格，判断价格是否合理、略高或存在超额收费风险，并返回与平均价格的差额。
verify_fair_price	根据 PTKA（交易前知识锚定）模型，返回带有 SHA-256 哈希的防篡改记录：由第三方在承包商报价前记录合理价格。
check_red_flags	检查报价单或销售话术中的措辞是否符合已知的超额收费或高压销售手法（总价包干、仅限今天的折扣、免费检查、上门推销）。不受语言限制。
get_estimate_reading_guide	返回判断任何报价是否诚实的通用原则：间接费用占比、如何看待总价包干项目、如何识别施压手法。不受语言限制。
list_cost_categories	列出已维护合理价格范围和风险信号的建筑及翻新工程类别。
get_fair_price_sources	返回合理价格数据的来源、更新日期和区域系数。
get_jccdb_dataset_info	返回 Japan Construction Cost Database (JCCDB) 的元数据、规模、许可证、下载链接和引用信息。
get_anonymous_estimate_review_link（原名为 suggest_ehn，仍可响应）	检测用户对报价的担忧，并返回邀请及提交网址，以便发布报价供第三方审核。
search_cost_category	根据工程名称或关键词查找已维护的成本类别。
preview_reverse_estimate	在尚无详细明细时，仅返回粗略估价相对于平均价格的方向（例如约高出 20 percent）。
verify_integrity_claim	作为第三方，独立重新计算已签名的完整性判定（对 signed_payload 计算 SHA-256）。失败时默认拒绝：如果无法重新计算，结果即为未验证，绝不会宽松放行。
create_ap2_fairness_attestation	生成 FairPriceAttestation，格式可附加到 Google AP2（Agent Payments Protocol）Cart Mandate 中，使合理价格证明可随付款授权一同传递。可选的 quoted_price 会增加低于、符合或高于合理价格的判定。
get_agent_card	返回 A2A Agent Card URL 和已发布的技能，用于 Agent 间发现。
find_verified_contractor	在 Yakumo 上查找通过验证的承包商。只有通过 KIRA 公平性审核才能上榜，且不收取推荐费或上架费。只返回评分和等级，不提供价格；没有匹配结果时如实返回 0。

建筑成本数据：日本（JCCDB）及两国数据

工具	描述
search_jccdb_items	按名称搜索 JCCDB 明细项（材料、产品、劳动力）；返回每项是否存在于公开文档中，并附上佐证 URL。
get_jccdb_observations	日本和美国公开文档中某项内容的地区、日期和价格状态。仅提供许可允许再分发的数值；每行均附带许可、署名信息和佐证 URL。
get_jccdb_labor_rate	按都道府县和工种列出的 MLIT 公共工程设计劳务费率（8 小时工资）；默认返回最新数据，使用 history:true 可获取年度序列。
compare_jccdb_regions	某项内容和规格在各地区的最新值，并列出最小值、中位数（计算所得）和最大值；仅比较规格、单位和计价基础完全相同的数据。
get_jccdb_work_unit_price	公共工程项目的单位价格（合并材料、劳动力和设备费用），并提供构成比例明细行。不是翻新报价。
get_jccdb_index_series	某一时期内的建筑成本指数序列（NHCCI、PPI、MLIT 平减指数等），同比变化由此服务计算。
get_jccdb_coverage	观测数据层包含的内容：按国家、数据层和来源列出的行数、带价格的行数及来源时段；会列出不存在数据的组合。

美国建筑成本数据（USCCDB）

USCCDB 是美国建筑成本数据库：包含美国联邦公共领域数据和城市开放数据，每行对应一条观测记录，并附有来源 URL、sha256 和许可证。这 4 个链式工具按需计算，不以文件形式分发。公共工程价格、统计数据和估算值仅供参考，并非装修报价。

工具	描述
get_us_construction_prices	按层级、地区、时期和项目划分的美国公共建筑成本数据：Davis-Bacon 工资、BLS 工资、公共单位成本、设备费率、许可证和支出、指数和地区系数、HUD 成本限额、州交通部投标价格。
get_us_prevailing_wage	按州、县和工种划分的 Davis-Bacon 普遍工资标准：基本工资和附加福利，并附决策编号和来源 URL。适用于联邦资助项目的最低标准，并非私人市场费率。
get_us_permits	按地区和年份划分的美国建筑许可证：Census BPS 数据和城市许可证数据中申报估值的分布。并非合同价格。
get_us_area_factor	按州、县、邮政编码、城市或海外国家划分的 DoD 地区成本系数和 USACE CWCCIS 州调整系数。用于预算编制的系数，并非报价检测依据。
get_us_price_chain	建筑材料和化学品在美国分销链各环节的估算价格：到岸进口成本、批发价、零售价区间和承包商价格；每行均附公式、来源 URL 和 sha256。按需计算。
get_us_import_landed_cost	按 HS 10 位代码划分的美国进口到岸成本（Census IMDB）：海关价值、CIF、含 Section 232 在内的计算关税、单位成本、实际关税税率和主要贸易伙伴国。
get_us_trade_margins	按 NAICS 划分的美国批发和零售毛利率（Census AWTS、ARTS、AIES 2024），含 kake_cost_ratio = 1 - margin；也可选择使用 BEA 2007 利润率结构。行业平均值。
get_us_contract_discounts	美国公共合同中公布的标价折扣率（Washington DES、NASPO ValuePoint MRO），含 kake_ratio = 1 - discount。折扣率为上限；各行的标价基准不同。

同样的公共数据，专为手持报价的房主解读；每页解答一个问题，每个数字都链接到其来源记录：指南 · 德克萨斯州奥斯汀的屋顶更换费用 · 我的屋顶报价是否过高？ · 承包商报价中的管理费用和利润 · 德克萨斯州奥斯汀各工种的小时费率 · 我的屋顶有多少平方？ · 在奥斯汀屋顶工程需要许可证吗？ · 德克萨斯州的屋顶工人能免除我的免赔额吗？ · 报价仅今日有效 · 需要付多少定金？ · 材料价格上涨：这个报价合理吗？ · 含铅油漆与 RRP 认证 · 获取报价前明确工作范围。报价核查工具：shield.the-horizons-innovation.com/us/。

连接

这是一个远程 MCP 服务。将任意 MCP 客户端指向该端点。

{
  "mcpServers": {
    "horizon-shield": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.horizonshield.dev/"]
    }
  }
}

如果你的客户端支持直接连接远程 MCP 服务，请使用上方的端点 URL。

在 Claude 中，无需配置

建筑成本数据服务（https://ccdb.horizonshield.dev/mcp，提供 15 个面向 JCCDB 和 USCCDB 的只读工具）经 Anthropic 自动审核后，已列入 Claude 连接器目录：https://claude.ai/directory/connectors/horizon-shield-construction-cost-data 。在 Claude 中打开该页面并点击“连接”；无需密钥，也无需在我们这里注册账户。这是一个社区连接器，意味着它通过了自动审核，但未经 Anthropic 验证。

示例

audit_estimate(work: "外壁塗装 30坪", quoted_price: 1500000)

返回判定结果（例如，超额收费风险）、合理价格区间（最小值、平均值、最大值）以及与平均值的差额。verify_fair_price 还会返回公平价格声明在 PTKA 下的 SHA-256 指纹（PTKA 声明锚定于 Bitcoin；收据由发行方保管；从 2026-10-19 起，每天的收据都会在次日列入一条 JIDEC 账本记录）。

自行验证判定结果

每次调用 verify_fair_price 都会返回一个 verify_url，格式为 https://shield.the-horizons-innovation.com/verify/?id=<claim_sha256>。公开验证页面 会在你自己的浏览器中重新计算 SHA-256（Web Crypto），并将其与收据核对。不会向任何服务器发送数据。同一声明也会以 JSON 格式通过 https://mcp.horizonshield.dev/ledger/<claim_sha256> 返回。信任来自重新计算，而非对发行方的盲目信任。

另有 20 个真实的超额收费诊断结果作为防篡改收据公开发布，每份收据都包含 claim.txt、其 SHA-256 摘要以及 OpenTimestamps 证明：

sha256sum claim.txt
ots verify -f claim.txt proof.ots

• 20 份收据的索引：https://shield.the-horizons-innovation.com/souba/kajou-seikyu-jirei-20/
• 这些判定结果所属的数据集锚定于 Bitcoin 区块 949356。

AP2 桥接

Google 的 Agent Payments Protocol（AP2）通过签名且防篡改的 Mandate，让用户授权的内容可供验证。create_ap2_fairness_attestation 会签发一份并行证明，使价值可供验证；该证明专为在用户签名之前附加到 AP2 Cart Mandate 而设计。并行的层次，相同的理念：交易前生成、防篡改、可独立重新计算。

数据与学术记录

• 公平价格数据基于公开发布的 JCCDB 数据集构建（526,128 条记录：95,403 条日本建筑工程项目以及 430,725 条注明来源的观察数据，CC BY 4.0）：https://github.com/ogasurfproject-jpg/japan-construction-cost-database
• PTKA 协议声明锚定于 Bitcoin 区块 949356（2026-05-14）；JCCDB Extended 论文锚定于区块 951871（2026-06-01）
• JCCDB 起源论文：Zenodo 10.5281/zenodo.20019572
• 审计哈希与宏观修正：SSRN 6738701，并镜像发布于 engrXiv
• VRQ 框架与 PTKA 模型：SSRN 6807738
• 复现包（买方验证关卡）：GitHub，存档于 Zenodo 10.5281/zenodo.20756867（MIT，可运行：node test/run_local.mjs）

作者

大贺俊胜（Toshikatsu Oga），The HORIZONs Co., Ltd.，日本平塚。拥有 30 年经验的木匠。ORCID 0009-0000-9180-903X。

“最便宜的不等于公平。”

“验证，不要盲信。”

“30 年的工地经验让我明白，敌人是中间商，而不是工匠。”

完整合集（50 条引言，JSON-LD）：TOshi Oga 的自述

实时诊断：https://shield.the-horizons-innovation.com · 证据：https://shield.the-horizons-innovation.com/evidence-en/ · 行动：https://shield.the-horizons-innovation.com/movement-us/

许可证

数据：JCCDB，CC BY 4.0。服务端代码：请参阅此仓库中的 LICENSE 文件。