分层口径：入口层向账本写入；显示层向人与机器展示；真相层存证与验证——真相层永远只有 GitHub + 多副本，任何新路径只增入口与镜像，不增真相源。
| 路径 | 定位 | 协议适配（SXJ-MAIP 方言） | 关键依赖 | 层 | 优先级 · 触发条件 |
|---|---|---|---|---|---|
| 网站路 hygzz.cn | 显示 + 验证（人类访客） | 消费侧（读链 / 读快照），无写入 kind | 服务器 + 域名；恢复后降为只读镜像 | 显示层 | P1 · 已上线公示层 |
| 小程序路 微信云开发 | 输入（人）+ 随身公示墙 | kind=report；task-claim / delivery / score | 微信生态 + 腾讯 CloudBase | 入口层 | P0 · 本期主线 |
| Agent API 路 MAIP v1.0 | 输入（机器） | 本体协议：/v1/report · query · verify · protocol | CloudBase HTTP 访问服务（端点待分配） | 入口层 | P0 · 随云函数上线 |
| 零号通道 邮件 | 输入（最后兜底） | kind=mail-report（校验后转等效 MAIP 报文） | [email protected] + 域名邮箱（SMTP） | 入口层 | P1 · 随迁移上线 |
| 语音 / 电话（扩展①） | 输入（照护现场双手忙） | kind=voice-report（audio_sha256 / confidence 入档） | ASR 插件或腾讯云 ASR；运营商 | 入口层 | P0 接口位预留 · 完整功能 P1 |
| 扫码即记（扩展②） | 输入（物理空间锚定） | kind=scene-report（scene_code 注册表核对） | 微信小程序码接口 + scenes 集合 | 入口层 | P1 · 首个固定照护点落地 |
| LINE Bot（扩展③） | 输入（日本市场） | kind=report + locale=ja（不新增 kind） | LINE Developers + CloudBase | 入口层 | P2 · 进日本市场时开 |
| AI 引擎可读（扩展④） | 显示 + 验证（面向机器） | 无新 kind（只读侧：llms.txt + /v1/protocol 自述） | GitHub（已有，零新增） | 真相层 | P0 · 零成本，已上线 |
| 公众号 / 视频号（扩展⑤） | 显示（广播，读者即见证人） | 无 kind（只消费已 ratify 的白名单事件） | 微信公众平台认证账号 | 显示层 | P2 · 公众号认证后 |
| 权威数据自动对账（扩展⑥） | 输入（公开既成事实巡查入账） | kind=authority-record（source + source_url + crawled_at） | 裁判文书网 / 企业公示 / e-Gov（公开数据） | 真相层 | P1 · 迁移全链校验通过后首巡 |
| IoT 传感器（远期位①） | 输入（护理床垫 / 门磁自动记录） | kind=iot-telemetry（命名空间预留，本期不实现） | 可信硬件供应链（待评估） | 远期 | P2 · 有可信硬件时 |
| 链上 / IPFS 锚定（远期位②） | 验证增强（存在性证明） | 无 kind（对每日快照 hash 做外部锚定） | 公链 / IPFS pin 服务 | 远期 | P2 · 快照量稳定后评估 |
| 多镜像分发（远期位③） | 验证增强（只读镜像站） | 无 kind（静态分发 GitHub 快照） | Cloudflare Pages / Vercel / GH Pages | 远期 | P2 · 仓成熟后一次建成 |
优先级：P0=本期 · P1=触发即做 · P2=远期留位。跨主权风险按层归属标注：入口层风险（平台政策、滥用刷墙）不伤真相层；真相层唯一公开锚点为 GitHub，只追加不删改。
网站、小程序、Agent API、邮件、语音、扫码、LINE、对账脚本、公众号……全部是 SXJ-MAIP 的方言适配器。协议只有一份、只在一处演进；入口皮可以千变万化，芯不动。
任何路径不得私设发号器。seq 只能从 mint-claim（counters，唯一 sequence authority）取号；方言适配器只负责翻译，翻译完必须回到同一铸码核心排队。出现第二条发号路径即为架构事故。
显示层可以挂、入口层可以被平台掐断，真相层不灭。新增路径只允许「增入口、增镜像」，不允许增真相源——不存在第二份可写账本；任何声称「另一份真相」的实现都是伪造。
新路径对历史只有追加权，没有修改权。对账分歧、例外、伪造揭穿一律以新增事件陈述，不改既有 seq / hash / 内容——异常只归因，绝不现场改数。
| 扩展路径 | 公示说明 |
|---|---|
| ① 语音 / 电话通道 | 照护现场双手忙，说话是最自然的输入：小程序录音经语音识别转写后按 kind=voice-report 铸码，原始音频哈希（audio_sha256）、识别引擎与置信度一并入档可回溯；置信度不足的转写先进沙箱待人工确认；电话留言走人工转写代录兜底，转写人身份与 AI 转写明确区分。 |
| ② 扫码即记 | 在事发现场、见证点贴二维码，扫码直达记录页，场景码（scene_code）自动带入报备并上墙，让「这个地点发生过什么」按时间线可反查；场景码统一注册登记、贴码拍照留档，码被覆盖或伪造时对照注册表即可揭穿并留痕；线下无网可走邮箱零号通道，同一方言体系。 |
| ③ LINE Bot | 进日本市场时的对话入口：LINE 收到的报备与 Agent API 报文同构——不是另起协议，而是同一协议的方言（复用 kind=report，以 locale=ja 标识）；日本《个人信息保护法》（APPI）审查先行，过审前不写一行代码，只在协议命名空间留位。 |
| ④ AI 引擎可读 | 让 ChatGPT / Claude 等 AI 引擎能索引并正确转述公示墙——AI 每次引用都是一次见证。仓根 llms.txt 自述墙位置、协议版本、数据格式与复算步骤，配合 sitemap 与结构化快照，AI 抓取一次即可完成「发现 → 读取 → 验证」全流程；零成本、静态、只追加，被索引即被见证。 |
| ⑤ 公众号 / 视频号 | 显示层广播出口：只广播已 ratify 的白名单事件（里程碑铸码、转正记录、每周快照摘要），pending 内容一律不外流；每篇文章自带「如何自行验码」复算指引，读者的每次阅读都是一次见证——见证不是口号，而是可操作的复算。 |
| ⑥ 权威数据自动对账 | 法院判决、企业公示、日本 e-Gov 等公开既成事实正式入账（kind=authority-record，必带权威源标识、原文链接与抓取时间戳）；原文快照先入 GitHub 仓 evidence/ 目录、再铸码，日后权威源修订或下架，不改历史、只新增对账事件陈述差异——公开既成事实，从此有账可查。 |
① IoT 传感器：护理床垫、门磁等设备自动记录，预留 kind=iot-telemetry 命名空间；在设备可信度与数据真实性（设备指纹、防伪造）定义清楚之前，IoT 数据宁可不入账。
② 链上 / IPFS 锚定：把每日快照的 hash 锚定到公链或 IPFS，增强存在性证明（即使 GitHub 全灭，锚点仍在）；定位是增强不是替代，真相层仍是「GitHub + 多副本」，多锚点规避单一服务方依赖。
③ 多镜像分发：以 GitHub 为唯一源建只读验证镜像站，镜像只读不回写、不入快照流，与源的一致性以快照 commit hash 对账；仓结构稳定、连续快照满 90 天后一次建成。