システムの陳列室

01 / 道具

ACE Receipts · 門

公開ソース ↗

出力は安い。信頼はそうではない。

公開の CLI と GitHub Action が、AI を用いたワークフローとその差分を走査し、証明・リスク・許可・欠けている証拠を見る。下の標本は同じ判定の文法を持ちながら、あなたのリポジトリには一切触れない。

標本

ACE RECEIPT保留

まだだ。受領記録を持ってくること。

証明: 部分的
リスク: 高
許可: 人による確認

公開された物証 monkidy/ace-receipts · examples/receipts/hold.md抜粋 · 要約・所見・次の手順は省略

ACE Receipt: HOLD

          ✦
      /_\ │
     (•_•)│
      /|_ │
      / \ │
   ════╪════
         │

Not yet. Bring receipts.

Verdict: hold
Gate: fail
Proof: partial
Risk: medium
Permission: human_review_required
Closeout: pending

Command ace-receipts demo

Missing receipts

explicit permissions block
SHA pin receipt for third party actions
receipt policy (.ace/policy.yml) or an ace-receipts gate in the workflow

No receipt, no passage.

公開リポジトリから改変せず複製。これは道具そのものの出力形式であって、その模造ではない。上の標本では、同じ三つの条件を自分で動かせる。

03 / 製品

Sendable? · 最後の判定。

公開製品 ↗

下書き

「更新した提案を今夜お送りします。任意範囲は削り、早く進められるよう社内見積りも添えました。」

同じ文面。三通りの相手。判定は文法の話ではない。

送信前の受領記録修正

文面としては有用だが、社内見積りはチームの文脈の外へ出るべきではない。

送る前に社内の数字を外すこと。

04 / 観測面

Asso Lab · コードが署名した受領記録。

公開の証明面 ↗

公開された物証 monkidy/asso-lab · receipts/2026-06-17-receipt.jsonファイル全体

{
  "receipt_id": "393911c3-2c62-4de0-8ae1-cbdb40804b88",
  "date_utc": "2026-06-17T10:41:51.567112Z",
  "sources": [
    "https://simonwillison.net/atom/everything/",
    "https://arxiv.org/rss/cs.MA",
    "https://arxiv.org/rss/cs.CR",
    "https://arxiv.org/rss/cs.AI",
    "https://www.anthropic.com/news"
  ],
  "model": "gemini-2.5-flash",
  "content_hash": "5e73ba03104d66e99518bbc904ccdbfc571ff01178ce0df6bf62fbca766efc01",
  "operator": "hichem",
  "confidence": null,
  "status": "PUBLISHED"
}

ある一日の受領記録を、改変せず複製したもの。参照元は公開フィード。ハッシュがあるので、公開された物証は後からでも照合できる。 confidence が空なのは、それを測ったものが何もないから。空欄のほうが、でっち上げた数字より正直だ。

依頼を公開する。受領記録を公開する。境界を見えたままにする。

Asso Lab は公開の観測面である。範囲を区切った依頼、コードが生成した受領記録、ハッシュ、タイムスタンプ、そして許可・拒否・人間による確認という三種の動作の実例。

これが証明しないこと

公開された受領記録が証明するのは、ある物証がその時刻にその形で存在したこと、それだけである。非公開の実行環境も、本番の安全性も、行動する権限も証明しない。

05 / 運用

AI Ops SOP Pack · 取り繕わずに回復する。

公開パック ↗

文脈が失われたとき（クラッシュ、中断されたレビュー、決定の途中で終わったセッション）、誘惑は、記憶から自信を組み直すことだ。このパックはそれを、読み直した証拠と、審査対象にかけたガードに置き換える。

01失われた文脈
02冷えた証拠
03先頭のガード
04引き継ぎ
05人の門

公開された物証 monkidy/ai-ops-sop-pack · templates/pr_final_audit_checklist.md抜粋 · 先頭のガード、境界の確認、決定

Completing this checklist records review evidence only. It does not approve or perform a merge, and it does not grant merge authority by itself.

Head Guard

observed PR head commit:
expected PR head commit:
match confirmed:
merge command or action will preserve head guard:

Stop if the PR head changed and the new head has not been reviewed.

Boundary Review

no live runtime opened:
no provider call introduced:
no secrets introduced:
no daemon / watcher / background process introduced:
no memory write introduced:
no ledger write introduced:
no permission-to-act introduced:
no trading / order routing / leverage / portfolio authority introduced:

Decision

Choose exactly one:

PASS
REPAIR_REQUIRED
STOP_RISK

公開されたチェックリストからの抜粋を、改変せず複製したもの。空欄こそが要点である。この文書は人が埋めるために作られており、その冒頭の一行で、埋めることは許可ではないと自ら述べている。

06 / 統治

二つの受領記録。違いはひとつ。

公開の実例 ↗

拒否が信頼に足るのは、行動と同じ種類の痕跡を残すときだけだ。公開されたこの二例は、同じ境界、同じエージェント、同じ対象ファイルを共有している。一方はそれを読む。もう一方は書き込もうとする。

公開された物証 bounded_file_read.allowed.json抜粋 · 一部のフィールドのみ表示。完全な JSON は参照元に

{
  "schema": "ace.action_receipt.v0",
  "status": "allowed",
  "decision": "allowed_read_only",
  "requested_action": {
    "type": "file_read",
    "purpose": "summarize support context"
  },
  "boundary": {
    "mode": "read_only",
    "writes_allowed": false
  },
  "refusals": [],
  "human_review_required": false
}

公開された物証 forbidden_write.refused.json抜粋 · 一部のフィールドのみ表示。完全な JSON は参照元に

{
  "schema": "ace.action_receipt.v0",
  "status": "refused",
  "decision": "refused_forbidden_write",
  "requested_action": {
    "type": "file_write",
    "purpose": "update customer record"
  },
  "boundary": {
    "mode": "read_only",
    "writes_allowed": false
  },
  "refusals": [
    {
      "reason": "write_not_allowed_inside_read_only_boundary",
      "required_next_step": "human_review_or_new_explicit_boundary"
    }
  ],
  "human_review_required": true
}

どちらのファイルも証拠ブロックにこの注記を持つStatic public example. Not runtime proof.。各図版は自ら何を省いたかを述べ、示されたものは一切改変されていない。

07 / 推論

Hypothesis Fan · 証拠に取り除かせる。

ひとつの観察。三つの説明。証拠は一度にひとつ。

選択肢は、検証がどれかを外す理由をくれるまで見えたままにしておく。これが研ぎ澄ますのはベイトソンの問いだ。これらの失敗をつないでいるパターンは何か。

観察負荷が増えるにつれ、このワークフローは当てにならなくなる。

H1容量

資源の逼迫が主たる原因である。

反証条件: 低負荷でも失敗が続く。

H2協調

引き継ぎが不整合な状態を持ち込んでいる。

反証条件: 引き継ぎのない場面でも失敗する。

H3記憶

状態が不完全な文脈から組み直されている。

反証条件: 状態を明示しても再発は減らない。

08 / システム

SYSTASYS · 見世物ではなく、連続性を。

記憶が役に立つのは、それが次の観察を変えるときだけだ。

金色の弦が帰り道である。ほかはありふれた因果の順序にすぎない。これをチェックリストではなくシステムにしているのは、その帰り道のほうだ。

地点 / 静止 八つの地点、そして帰還。

一巡させて順に辿るか、図の上で読む。

部屋の全体 ↗

09 / 作業則

制約でできた宣言。

01説明を二つ以上、生かしておく。

早すぎる確信は高くつく。証拠に除かせる。

保持 → 検証 → 除去。

02決めるのは現実。

モデルが役に立つのは、実際に起きることとの接触を生き延びているあいだだけだ。

モデル ≠ 現場。

03記憶のない観察は無駄である。

システムは、次の観察をより良くするだけのことを覚えているべきだ。

痕跡 → 記憶 → 変わった観察。

04証拠は次の行動を変えるべきである。

何も変えない受領記録は、統制ではなく書類にすぎない。

証明には帰結がなければならない。

05権限は、見えていて退屈なままであるべきだ。

力は中核の周りにあってよい。だが許可の境界は、検められる程度に単純でありたい。

力は外に。明晰さは内に。

06見世物より連続性のほうが重い。

役に立つシステムとは、実演が終わったあとでも筋が通っているもののことだ。

効果が引いたあと、何が残るか。

開口部の外に残るもの ↗

陳列室、収めるのはシステム、証明、そして判断。

陳列室、収めるのは
システム、証明、そして判断。