{"kind":"organization","status":200,"org":"cloud-itonami","org-entry":{"org":"cloud-itonami","host":"cloud-itonami.itonami.cloud","status":"live","title":"cloud-itonami","description":"行政・公共制度をソフトウェアとして実装する事業群。ここはその公開サイト面。","files":["index.html"]},"repositories":[{"org":"cloud-itonami","repo":"cloud-itonami-cofog-03.2","title":"消防 — 現地調査・火災リスク判定・危険事象エスカレーション（営み OS）","description":"防災面の 1 本目。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。公式警報・避難指示・緊急事態宣言・現場指揮のいずれの権威も持たない —— :escalate-hazard が確定しても、それは上げるべき事象があるという記録であって出動ではない。","source":"https://github.com/cloud-itonami/cloud-itonami-cofog-03.2","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-0162","title":"地域農業支援 — 訪問受理・法域判定・圃場サンプリング・防除処理（営み OS）","description":"撒く営み。接続済みの面で「言い負かせない検査」が守っているのは、ほぼ全部が取引の相手方（借り手の返済能力・買い手の請求額・荷主の貨物）だが、この面の水源緩衝帯検査が守っているのは水源であって訪問先の農家ではない —— 農家は防除をしてほしい側で、止められて損をする側ですらある。受益者が取引に参加していない検査を持つ最初の面である。だから repo 側はこれを SOFT ではなく HARD に置いており、承認者が居ても覆せない。条件付き検査の両枝が同じ法域・同じ作物の中に在るのもこの面の特徴で、visit-5 と visit-6 はどちらも日本の稲作、水源近接も両方 true、違うのは緩衝帯遵守の 1 フィールドだけ —— 検査が読んでいるのが法域の制度ではなく圃場自身の事実であることが demo store の中だけで示せる。米国 FIFRA ラベル緩衝帯要件 / CWA NPDES PGP、英国 Environmental Permitting Regulations 2016、独 PflSchAnwV、日本 水質汚濁防止法 を根拠に持つ。現実の行為は 2 つあり（実サンプル採取と実際の農薬散布）、同じ訪問記録に順に効く。どちらもどの phase の :auto にも入らず、governor も独立に high-stakes として常に escalate する。実測した穴も面に出している: :visit/intake の commit は助言者の patch を丸ごと訪問記録へ merge し、しかも phase 3 で人を通らずに確定するので、7 つの HARD 検査のうち 5 つ（散布量不一致・資材未承認・緩衝帯違反・二重サンプリング・二重防除）が外側に開いている。:treated? を false に戻すと同じ圃場に 2 回目の防除が確定し、台帳に 2 本の処理記録が残る —— ここで 2 回撒かれるのは実際の農薬である。生き残った 2 つ（引用なし・書類不足）は偶然ではなく、前者の入力は提案であって store ではなく、後者を有効にしている入力は人が承認した committed assessment で intake は書けない。独立した検査が auto-commit する writer を生き延びるのは、その検査を有効にしている入力をその writer が書けないときちょうどその時である。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-0162","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-0610","title":"原油・天然ガス採掘 — 坑井受入・法域評価・採掘・生産精算（営み OS）","description":"掘る営み。地域の原油・天然ガス採掘事業者が、坑井を受け入れ、法域の坑井構造・坑井制御・含硫サービス規制を評価し、実在の坑井を生きた坑層に対して開き、実在の生産期間を精算する。日本 鉱山保安規則（経済産業省 資源エネルギー庁）、米国 BSEE 30 C.F.R. Part 250 と OSHA PSM 29 C.F.R. §1910.119、英国 Offshore Safety Act 1992 と Safety Case Regulations 2005（HSE）、ノルウェー Aktivitetsforskriften（Petroleumstilsynet）、ブラジル Resolução ANP nº 46/2016 SGIP、カナダ Canada Oil and Gas Operations Act と SOR/2009-315（Canada Energy Regulator）を根拠に持ち、それとは別に NIOSH の IDLH 50 ppm を硫化水素の急性毒性基準として持っている —— 書類が揃っていることと、坑口に立つ人が生きて帰れることは別の事実だからである。現実の行為は 2 つあり、採掘（坑口を開けたら流れは止まらない）と生産精算（royalty と生産量が確定し実際の金が動く）で、どちらもどの phase の auto にも入らず、governor も独立に high-stakes として常に escalate する。実測した穴も面に出している。1 つ目はこの面では初出で、測定値を偽らずに安全窓の方を広げられる: governor の物理検査 4 つのうち 3 つ（坑層圧力 vs 安全窓、環状圧力 vs MAASP、水分固形分 vs 上限）は、比べる 2 つの値を両方とも同じ坑井記録から読む。そして坑井の受入は phase 3 で人を通らず確定し、助言者の patch を坑井記録へ丸ごと merge する —— 限界値の列も含めて。実測では、坑層圧力 50.0 MPa で安全窓 [20.0,45.0] を外れて止まった坑井に対し、測定値には一切触れず窓の上端だけを 55.0 に書くと、圧力は正直に 50.0 のまま検査が通り、承認 1 回で採掘記録が発番された。監査記録は 1 バイトも嘘をついていない —— これまでの形は台帳の記述が事実とずれることで検出可能性を残していたが、これはずれない。変わったのは、どこまでを安全と呼ぶかの方である。同じ形が MAASP にも水分固形分の上限にもある。対照として 4 つ目の H2S 検査だけは限界値を坑井記録ではなく規制カタログの IDLH から引くので窓を広げる手が無く、外すには実測した硫化水素濃度そのものを書き換えるしかない —— 同じ 1 つの op で外せることは変わらないが、その嘘は台帳と現場が食い違うので後から突き合わせれば見つかる。限界値をどこに置くかで検出可能性が決まる、という対照実験になっている。2 つ目以降は先行例と同じ形で、二重採掘・二重精算の防止は crude-lifted? / production-settled? を false に戻せば外れ、未解決のインテグリティフラグも自分で解決済みと宣言でき、証拠充足の検査は読む先が別の store 経路（assessments）で受入からは書けないのに、必要書類の照合がリストの内容で行われ USA と CAN の required-evidence がバイト単位で同一なため（BSEE と CER が実際に同じ 4 点を要求している）、法域を書き換えるだけで CAN 向けの書類を 1 枚も出さずに充足が通る。書き込み先も助言者 patch の id で決まり要求の subject を読まないので、無害な坑井の subject で別の坑井を書き換えられる。連携は 1 本も無い —— 採掘した原油は本来運ばれ貯蔵されるが、現在 declared な隣の受け口はどれも自分の台帳に既に登録済みの貨物を前提にしており、0610 が確定させるのは生産精算記録であって貨物ではないため、実在しない流れを面に描かない。境界は空だが、それはこの store が坑井しか持たないからであって採掘だからではない: H2S の IDLH 検査はそもそも坑口で作業する人の命を測っており、作業者の記録が 1 件でも入れば pii/worker に変える。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-0610","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-0810","title":"採石 — 受入・採掘・出荷（営み OS）","description":"採石 — 受入・採掘・出荷。モノの営みの上流（一次採取） 営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-0810","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-2610","title":"半導体ファブ — ロット投入・工程実行・歩留まり監査（営み OS）","description":"半導体ファブ — ロット投入・工程実行・歩留まり監査。実シミュレーションが差し戻す工程実行 営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-2610","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-3510","title":"配電 — 供給開始・停止・停電復旧（営み OS）","description":"配電 — 供給開始・停止・停電復旧。生命維持装置使用者を切れない配電網 営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-3510","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-3600","title":"上水道 — 取水・水質判定・報告公表・警報（営み OS）","description":"インフラの営みの 2 本目。水質報告の公表も警報の抑制も、どの phase でも自動確定しない —— 飲料水の汚染を知らせないという行為には必ず人がいる。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-3600","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4210","title":"道路・鉄道建設 — 現場記録・作業スケジュール提案・安全性懸念の通報・資材発注提案（営み OS）","description":"接続済み 42 本の operation.cljc を全走査した結果、commit ノードから現実の人へ通知を送る面は 4211（建築）1 本だけだった。ここが 2 本目で、しかも答えが逆である —— 4211 の災害警報は phase 3 の :auto に入っており人を待たずに飛ぶ（repo が『actuation は常に人』の norm に対する意図した例外と明記している）が、この面の安全性懸念の通報はどの phase の :auto にも入らず、送信は人が承認した後にしか起きない。災害警報は人を待たせる方が危険で、安全性懸念の通報は人が判断してから出すものだから。同じ ISIC グループの隣り合う 2 本が、それぞれの repo の phase 表で別々にこの判断を書いている。4 つの op はすべて :effect :propose で、重機の操作もグレードプラン（縦断・横断計画）の確定もこの actor の語彙に無い。届出リードタイムの HARD 検査は法定値を独立に計算し直すが、数値の線が無い法域（DEU/EU）では発火しない —— 無い数値を作って落とすのでも、無いから通すのでもなく、人が見る。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4210","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4211","title":"建築 — 現場受理・気象判定・ロボット施工・引渡し（営み OS）","description":"建築 — 現場受理・気象判定・ロボット施工・引渡し。災害安全とロボット施工の 2 スライス 営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4211","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4520-carwash","title":"洗車 — 受付・排水計画検証・排水許可審査・洗車工程・返却（営み OS）","description":"この workspace が自分で起こした actor の 1 本目。ISIC 4520 の includes は washing, polishing を含むが親 actor は洗車の op を 1 つも持たないので satellite として起こした。規制の関心は車両安全ではなく排水。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（塗装が禁じる工程・排水許可の失効・水再利用率の恒等式・法域の基準が台帳に無い）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4520-carwash","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4630","title":"食料品・飲料・たばこ卸売 — 受注・規制確認・出荷・請求（営み OS）","description":"モノの営みの 2 本目の卸。荷の区分ごとの規制（食品衛生・酒税・たばこ税と年齢確認）を出荷確定の前に自分の governor が見る。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4630","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4659","title":"精密機械器具卸売 — 受注・出荷・請求（営み OS）","description":"輸出管理 governor（能力閾値・軍事用途の 2 軸）を持つ卸。小売の発注から自動で受注が起きても、その門は必ず通る。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4659","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4711","title":"総合小売 — 発注・入荷・販売（営み OS）","description":"モノの営みの両端。補充発注が卸の受注を自動で起こし、配送された貨物は人が検品して入荷計上する。発注と販売計上はどの段階でも自動確定しない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4711","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4759","title":"家電・家具・照明小売 — 販売記録・配送手配・仕入発注調整・保証懸念（営み OS）","description":"暮らしの営みの上流（渡す側）。主体は店舗であって顧客ではない。この群で最初の連携がここから出る —— 保証懸念が人の承認を経て確定すると、その参照を修理側（9522）の受付担当が運ぶ。:invoke にはできない（境界が違うので compile-rules が落とす）。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（未検証の店舗・未検証の仕入先・語彙に無い保証請求の承認）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4759","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4920","title":"貨物運送 — 引受・輸送・精算（営み OS）","description":"卸の出荷確定から引受が自動で起き、配送確定は小売の受入検品へ人が運ぶ仕事になる。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4920","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-4921","title":"都市交通 — 運行・配車・整備（営み OS）","description":"都市交通の運行 actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-4921","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-5210","title":"石油ターミナル貯蔵 — 受入・受領検証・計上・引渡（営み OS）","description":"運送が動かしたものが止まっている間、責任を誰が持つか。受領の計上も次の保管者への引渡も、どの phase でも自動確定しない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-5210","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-5229","title":"貨物利用運送・通関 — 記録・配車手配・通関懸念（営み OS）","description":"運ばず保管もせず、他人の運送と通関を手配する仲介。保管の引渡確定から手配記録が自動で起きるが、通関を確定する op はこの actor に存在しない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-5229","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-5820","title":"CRM — 商談・サブスクリプション（営み OS）","description":"Salesforce 置換の CRM actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-5820","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6310","title":"人事 — 従業員・評価・配置（営み OS）","description":"kaonavi 置換の人事 actor。宣言はされているが OS からはまだ回せない（未接続の理由を面に出す）。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6310","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6399","title":"求人メタサーチ — 掲載・取下げ（営み OS）","description":"職業安定法5条の4 の的確表示を governor が門番する求人掲載 actor を、営み OS の面から実際に回した結果。掲載は必ず人の承認で止まり、法域評価を飛ばした掲載は保留される。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6399","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6411","title":"中央銀行業務 — 会員金融機関受理・準備預金口座要件検証・コルレス銀行DD・口座開設・決済バッチ実行（営み OS）","description":"カネの営み 5 本目で、数の限界を両方向持つ最初の面。下限（準備率が最低所要準備率に届かない）と上限（提案決済額が利用可能準備残高を超える）が同じ governor に同居し、しかも 2 つの数の持ち主が違う —— 上限は会員自身の帳簿の数、下限は運営者（中央銀行）が会員に課した数。どちらの検査も提案を一切読まず、member 記録に乗っている数から比べ直す。主体は銀行であって人ではなく、13 field に自然人は 1 つも無い。準備預金と銀行間決済の実務だけが語彙にあり、政策金利の決定は無い。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6411","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6420","title":"持株会社 — 持株記録受理・開示要件検証・実質的支配者確認・分配実施・持株構成変更記録（営み OS）","description":"カネの営み 4 本目で、上限が自分の帳簿にある唯一の面。6512 の上限は相手方の契約に、6492 の上限は外部規則（Reg Z の DTI 43%）にあるが、分配可能額は会社自身が記録した数で、守るのは取引の相手方ではなく債権者（会社法 §461 / Delaware GCL §170）。上限検査は提案を一切読まず、持株記録に乗っている 2 つの数から比べ直す。主題が実質的支配者でありながら台帳に自然人は 1 件も無く、持つのは確認できたかという真偽値だけ。記録は語彙にあり、株式移転の執行は無い。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6420","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6492","title":"貸金 — 受理・法域判定・返済能力審査・承認・融資実行（営み OS）","description":"カネの営みの 1 本目。固有の検査は返済能力で、この面で唯一 提案を一切読まない HARD 検査 —— 申込に既に乗っている恒久的な事実（既存債務・申込額・年収）からその場で比を計算し直すので、引用が完璧で confidence が 1.0 の提案でも通らない。比較は整数の厳密比（100*(債務+申込額) > 43*年収）で小数が kernel に入らず、0.43 は米 Regulation Z（12 CFR §1026.43）の back-end DTI 上限の引用であってこの面が発明した閾値ではない。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（返済能力の上限超過・台帳に無い法域・承認されていない申込への融資実行・二重融資・語彙に無い op）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6492","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6499","title":"ベンチャーファンド — LP 受入・DD・投資実行・分配（営み OS）","description":"カネが動く営みの 1 本目。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道の両方を出している。LP の資本が動く 4 方向（キャピタルコール・投資実行・分配・GP クローバック返還）は、どの phase でも自動にならない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6499","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6512","title":"損害保険 — 申込・法域評価・KYC・成立・請求受付・保険金支払い（営み OS）","description":"カネの営みで唯一、カネが先に入って後で出る。だから 2 つの実行為（いくらまで引き受けるか / 実際にいくら払うか）の間に保険金額という上限が挟まる。その上限は請求の自己申告ではなく相手方の契約（policy 台帳の coverage-amount）に書かれており、支払いの HARD 検査はそちらを引き直して比較する —— 6492 の返済能力検査と同じく提案を読まないが、読む先が別の契約なので請求だけを完璧に整えても通らない。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（二重支払い・保険金額の超過・成立していない契約への請求・台帳に無い法域・制裁該当の契約者・語彙に無い op）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6512","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6612","title":"証券・商品先物ブローカレッジ — 口座受理・法域判定・利益相反審査・適合性審査・発注・約定（営み OS）","description":"カネの営みの 4 本目。6499（出資）・6492（貸金）・6512（保険）はいずれも自分の勘定でカネを出し入れするが、この面が約定するのは顧客の勘定であり、この actor は取次ぐだけである。だから「言い負かせない検査」も顧客の側の事実から出る —— 注文額は数量 × 単価で独立に計算し直して cent 整数で厳密に比べ、注文のリスク等級は顧客自身のリスク許容度と照合する。どちらも助言者の confidence を通らない。審査の op が、自分自身の所見で HARD hold する。利益相反検査と適合性検査は op に scope されず無条件に評価されるので、:conflict/screen と :suitability/screen はいま見つけた所見でその場で止まる —— :trade/execute にだけ scope していたら、審査の op は自分の発見で止まれなかった。現実の法的行為はただ 1 つ、約定（顧客が取引に拘束される）。これはどの phase の :auto にも入らず、governor も独立に :actuation/execute-trade を high-stakes として常に escalate する。ただし実測では、助言者が :stake を剥がすと governor は ok? を返し、止めたのは op を読む phase gate の方だった —— 2 層のうち嘘に強いのは後者である。実測した穴も面に出している: 約定済みの注文 ID をもう一度 :order/file すると記録が丸ごと置き換わって status が :filed に戻り、二重約定の HARD 検査が外れる。しかも再 filing 自体は phase 3 で人を通らずに確定する。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6612","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6622","title":"保険代理店・保険仲立業 — 媒介案件の受理・法域評価・利益相反審査・契約媒介・手数料計上（営み OS）","description":"媒介の営み。接続済みのカネの営み（6499 出資 / 6492 貸金 / 6512 保険 / 6612 証券）で「言い負かせない検査」が読んでいるのは、ほぼ全部が取引の相手方の事実（借り手の返済能力・請求者が指す契約の保険金額・注文が指す口座の適合性）だが、この面の 6 つの HARD 検査のうち 2 つは、この actor 自身の仕事を読む —— insufficient-quotes は「どれだけ探したか」（案件の見積りが 2 件以上か）、commission-rate-exceeds-cap は「自分の取り分」（案件の選択手数料率と法域の手数料上限の比較）。探す義務の不履行そのものが違反という形はこの面では初出で、相手方が誰も損害を主張していなくても HARD hold になり、承認者が居ても覆せない —— 自分の売上を止める検査があって、しかもそれを人が上書きできない。日本 保険業法（金融庁）、米国ニューヨーク州 Insurance Law Article 21（NYDFS。連邦の保険監督官庁は存在せず免許は州が出すので exemplar として置いている）、英国 FSMA 2000 / ICOBS（FCA）、独 Versicherungsvermittlungsgesetz（BaFin）を根拠に持つ。現実の行為は 2 つあり向きが逆で、契約媒介は第三者（保険会社）に顧客のための義務を負わせ、手数料計上は自分の収益を計上する。どちらもどの phase の auto にも入らず、governor も独立に high-stakes として常に escalate する。実測した穴も面に出している: 案件受理の commit は助言者の patch を丸ごと案件レコードへ merge し、しかも phase 3 で人を通らずに確定するので、6 つの HARD 検査のうち 4 つ（見積り不足・手数料上限超過・未成立・二重計上）は人が 1 人も入らずに外れた —— 見積りを 2 件に水増しすれば探す義務は黙り、法域を上限 0.20 の JPN から 0.25 の GBR に書き換えるだけで、一度 HARD で止まった 0.25 の手数料が確定し、成立番号を書き換えると同じ案件に 2 本目の手数料記録が残る。5 つ目（引用なし）は writer 単体では外れないが、法域を書き換えて評価し直すと助言者は本物の公式ソースを正しく引くので、人は「偽の法域についての正しい評価」を 1 回承認することになる —— writer が入力を書けなくても、入力を作る関数の入力を書ければ同じことが起きる。6 つ目（利益相反の台帳照会）は逆にこの actor 自身の op では一度も立たない: hit の screen は必ず HARD hold で、hold は相反台帳に何も書かないため、この枝は外から積まれた snapshot でしか true にならない。同じ class の 4 例目だが、生存者が 0 なのはここが初めてである。もう 1 つ、走っていない照会の名前が証拠欄に載る形も出している: 8291 への corporate-intelligence 照会は既定の助言者では no-op だが、案件 ID が付いた screen 要求では提案が引用にその語を並べ「照会もクリア」と要約する。連携は 6512（損害保険）の申込受理へ 1 本、人が運ぶ carry —— 境界が違うので invoke は宣言時に落ちる。媒介人が契約を決めたことは、保険会社が引き受けたことではない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6622","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6810","title":"不動産 — 物件受理・法域別の開示/権原書類判定・関係者KYC・成約（営み OS）","description":"規則の持ち主（:owner-authority）を facts 表に持つ面は 27 本あるが、誰が実行できるか（:actuation-authority）と人の関門（:human-gates）を法域ごとに書けるのは 42 本中この 1 本だけ。オランダのエントリは実行者を公証人と名指しし、仲介者は成約パッケージを準備・検証できるが登記も資金の解放もできないと書いている。ただし 7 法域中埋まっているのはその 1 つで、残り 6 つは空 —— 形が在ることと埋まっていることは別である。3 つの HARD 検査（引用の無い法域要件・制裁/PEP 一致・必要書類の不足）はどれも既存の形で、新しい検査は 1 つも持ち込まない。成約は所有権移転登記と預り金の実行なので、どの phase でも自動にならない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6810","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6910","title":"法人設立 — 受理・法域判定・登記（営み OS）","description":"登記代行の actor。宣言はされているが OS からはまだ回せない —— 中核は portable でも、面を作る nbb の生成器で load できない（ISO 7064 の検査数字が js-mod を使う）。面はその理由をそのまま出す。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6910","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-6920","title":"会計・監査・税務 — 受理・法域判定・独立性審査・監査意見・申告（営み OS）","description":"他人が頼れる言明を出してよいかを扱う営み。監査意見の発行と申告書の提出はどの phase でも自動確定に入らず、phase gate と governor が別々の理由で同じ結論に達する。試算表の均衡は閾値でなく恒等式の再計算で検査する。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-6920","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-7110","title":"建築設計・エンジニアリング — 受託・法域評価・設計検証・認証納品（営み OS）","description":"設計の営み。4211（建築）の上流にあたり、受託記録を受け、法域の建築基準・専門技術者免許の要件を評価し、設計が基準・範囲に収まっているかを検証し、押印済み・認証済みの成果物を納品する。日本 建築基準法（国土交通省・都道府県）と建築士法 第20条、米国 International Building Code（ICC の model code。連邦法ではなく州・自治体が採択する）と州の Professional Engineering Practice Act（NCEES Model Law）、英国 Building Regulations 2010 / Building Safety Act 2022（Building Safety Regulator）と Architects Act 1997（ARB）、独 Musterbauordnung（各 Land が実装）と各州の Architekten-/Ingenieurgesetz を根拠に持ち、建築基準の枠組みと専門技術者の押印権限を別々の引用として持っている —— 基準に適合した設計を免許の切れた者が押印することも、免許のある者が基準外の設計に押印することも、どちらも別々に起きうるためである。現実の行為は 2 つあり、設計検証（技術者として設計が基準の範囲に収まっていることを確認する）と認証納品（押印済みの成果物を施主や行政に引き渡す）で、どちらもどの phase の auto にも入らず、governor も独立に high-stakes として常に escalate する。実測した穴も面に出している: 受託記録の受理は助言者の patch を丸ごと受託記録へ merge し、しかも phase 3 で人を通らずに確定するので、7 つの HARD 検査のうち 6 つが人を 1 人も通さずに外れた。とくに押印権限の検査は、押印を要する成果物を権限確認が済んでいない者が納品しようとしていないかを見る検査で、その入力（seal-authority-verified?）を actor 自身が true に書ける —— 建築士法第 20 条が存在する理由そのものが、規制を受ける側の 1 op で満たされる。報酬合計の独立再計算も工数を書き換えれば一致し、基準範囲外の設計も within-code-scope? を書き換えれば通り、二重検証・二重納品の防止も verified? / delivered? を false に戻せば外れる。証拠充足の検査だけは読む先が別の store 経路（assessments）で受理からは書けないが、それでも外れる: 必要書類の照合がリストの内容で行われ、USA と GBR の required-evidence がバイト単位で同一なので、USA として 1 回だけ人が評価を承認したあと法域を GBR に書き換えると、GBR 向けの書類を 1 枚も出していないのに充足が通る —— writer は検査の入力を書く必要がなく、検査がどの入力を読むかを書ければ足りる、というこの class の新しい形である。連携は 4211（建築）の現場受理へ 1 本、人が運ぶ carry。境界は両端とも空なので invoke は宣言できてしまうが、実測すると hold ではなく commit し、しかも 4211 の現場レコードは運ばれない patch の中の id で採番されるので、主体名 nil の空の現場が 1 件生えて mint した名前はstore に届かない —— 面は現場が受理されたと描き、台帳には名前の無い記録が残る。落ちる辺より通る辺の方が悪い。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-7110","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-7310","title":"広告出稿 — 受理・媒体計画・掲載先審査・リスク審査（営み OS）","description":"他人の目に何を届けてよいかを扱う営み。出稿だけは phase 3 でも自動確定に入らない —— 出したものは取り消せないから。読み取り op は 1 つも公開していない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-7310","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-7320","title":"市場調査・世論調査 — 受理・方法論検証・リスク審査・結果公表（営み OS）","description":"届いたものをどう測ったと言ってよいかを扱う営み。広告と同じく、結果の公表だけは phase 3 でも自動確定に入らない —— 公表した数字は取り消せないから。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-7320","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-7810","title":"職業紹介 — 受理・マッチング・就職（営み OS）","description":"紹介免許事業者の候補者受理から就職までを governor 付きで回す actor。候補者の識別子は統合台帳には digest でしか残らない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-7810","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-8121","title":"建物清掃 — 作業記録・清掃手配・資材発注調整・安全懸念（営み OS）","description":"暮らしを支える営み（建物側）。主体は建物であって人ではない。事業としての清掃業の back-office で、kiyome（清掃ロボットの設計面、R0）とは別物。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（未検証の建物・語彙に無い立入禁止の解除）の両方を出している。安全懸念だけはどの phase でも自動確定しない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-8121","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-8129","title":"産業清掃 — 作業記録・作業手配・資材発注調整・安全懸念（営み OS）","description":"8121 建物清掃の危険側の兄弟。倉庫床・荷役デッキなどの産業規模の清掃で、危険化学品・密閉空間進入を伴う。op の形は 8121 と同じだが governor が 1 つ多い（薬品・機材の仕入先の独立検証）。危険物取扱の安全認定も密閉空間進入の許可も、gate ではなく op が存在しない。営み OS の面から実物の actor を回した結果。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-8129","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-851","title":"初等教育 — 出欠・面談・調達（営み OS）","description":"初等教育の運営 actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-851","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-852","title":"中等教育 — 出欠・面談・調達（営み OS）","description":"中等教育の運営 actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-852","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-853","title":"高等教育 — 履修・施設・調達（営み OS）","description":"高等教育の運営 actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-853","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-854","title":"職業教育 — 受講・施設・調達（営み OS）","description":"職業教育の運営 actor。宣言済み・未接続。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-854","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9101","title":"図書館・アーカイブ — 受入・法域評価・貸出・保存処置（営み OS）","description":"知の営み。地域の図書館・アーカイブが、資料を受け入れ、法域の納本制度・非貸出資料の取扱い基準と保存修復の職業標準を評価し、実在の資料を館外へ貸し出し、実在の資料に保存処置を施す。日本 国立国会図書館法 第24条（納本制度、国立国会図書館）と文化財保護法（文化庁）、米国 Copyright Act 17 U.S.C. §407（mandatory deposit、Library of Congress / Copyright Office）と AIC Code of Ethics（American Institute for Conservation）、英国 Legal Deposit Libraries Act 2003（The British Library / Legal Deposit Libraries）と Icon Professional Standards、独 DNBG §16 Pflichtablieferung（Deutsche Nationalbibliothek）と VDR Berufsethische Richtlinien を根拠に持ち、納本制度の枠組みと保存修復専門家の職業標準を別々の引用として持っている —— 貸出してよい資料に無資格者が処置することも、資格者が館外貸出不可の資料を貸し出すことも、どちらも別々に起きうるためである。現実の行為は 2 つあり、貸出（実在の資料が館外へ出る）と保存処置（実在の資料に不可逆な物理介入を施す）で、どちらもどの phase の auto にも入らず、governor も独立に high-stakes として常に escalate する。実測した穴も面に出している。1 つ目はこの面では初出で、台帳が名指す資料と実際に動いた資料が違う: 受入の commit-record は要求の subject から path を作るが、store の item/upsert は助言者 patch の id で書き込み先を決め path を 1 バイトも読まないので、subject=item-1 の要求で item-4（納本・館外貸出不可の資料）を書き換えられる。統合台帳には subject item-1 と残り、hash 連鎖は正しいままどの資料が動いたかを取り違える。これまでの 5 例は検査の入力を writer が書ける形だったが、これは検査が見ている主体そのものが writer の書く値で決まる別の形で、7 つの検査は全部 subject の資料を読むため、無害な subject で検査を通して別の資料へ書ける。なお同じ store の中で assessment/set は path（subject）を使う —— 1 つの store の中で effect ごとに主体の決め方が違う。2 つ目は 6 例目で新しくはないが重い: 受入は phase 3 で人を通らず確定し、7 つの HARD のうち 6 つが人を 1 人も通さずに外れる。とくに lending-restricted?（納本制度上の館外貸出不可という資料自身の法的地位）と conservator-sign-off-obtained?（組織の外に居る保存修復専門家の承認）を、この actor が自分で書ける。延滞料金の独立再計算も延滞日数を書き換えれば一致し、二重貸出・二重処置の防止も lent? / preserved? を false に戻せば外れ、証拠充足の検査は読む先が別の store 経路（assessments）で受入からは書けないのに、必要書類の照合がリストの内容で行われ USA と GBR の required-evidence がバイト単位で同一なため、法域を書き換えるだけで GBR 向けの書類を 1 枚も出さずに充足が通る。連携は 1 本も無い —— 隣に居る営みは教育（851/852）だが、学校の備品請求は資料の受入ではなく向きも逆で、実在しない流れを面に描かないため書いていない。境界は空だが、それはこの store が借り手の記録を 1 件も持たないからであって図書館だからではない: 貸出履歴は本来この fleet で最も秘匿性が高く、借り手に相当する field が 1 つでも入れば pii/patron に変える。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9101","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9411","title":"事業者団体・使用者団体 — 会員受理・法域判定・ロビー登録審査・公表意見の公表（営み OS）","description":"声の営み。接続済みの面は人・モノ・カネのいずれかを動かすが、この面が動かすのはどれでもない —— 台帳に載っているのは公表意見で、現実の行為は団体の名前で公の場に意見を出すことである。だから「言い負かせない検査」も、返済能力でも数量 × 単価でもなく、その意見が最後に審査されたのはいつか（審査経過日数が自分の最大審査間隔を超えていないか）と、ロビー登録を済ませたかから出る。ロビー登録審査は :lobbying/screen 自身の所見で HARD hold するが、条件付きである点が 6612 の利益相反審査と違う —— 意見の :lobbying-registration-required? を先に読み、登録制度がそもそも無い法域（この R0 catalog では日本・オランダ）では要件を立てない。米国 LDA 1995 / 英国 Transparency of Lobbying Act 2014 / 独 Lobbyregistergesetz 2021 を根拠に持つ。現実の法的行為はただ 1 つ、公表意見の公表。これはどの phase の :auto にも入らず、governor も独立に high-stakes として常に escalate する。ただし実測では、助言者が :stake を剥がすと governor は ok? を返し、止めたのは op を読む phase gate の方だった —— 2 層のうち嘘に強いのは後者である。実測した穴も面に出している: :member/intake の commit は助言者の patch を丸ごと意見の記録へ merge し、しかも phase 3 で人を通らずに確定するので、store の事実を読む HARD 検査 3 つ（審査期限超過・ロビー登録未確認・二重公表）が全部この op から外側に開いている。:published? を false に戻すと同じ意見が 2 回公表され、台帳に 2 本の公表記録が残る。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9411","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9522","title":"家電修理 — 受理・法域判定・安全審査・冷媒資格審査・修理完了・返却（営み OS）","description":"暮らしの営みの 2 本目。クリーニング業（9601）と同じ預り品（bailment）の形で、直してしまった家電も返してしまった家電も戻せない。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（部品代が数量×単価と合わない・安全試験に通っていない・冷媒取扱資格が未確認・法域の基準が台帳に無い）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9522","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9523","title":"靴・革製品修理 — 受理・法域判定・安全審査・真贋審査・修理完了・返却（営み OS）","description":"暮らしの営みの預り品 3 本目。9601 クリーニング業 / 9522 家電修理と同じ形が 3 回反復されている —— 受理 → 審査 → 実行 → 返却、実動作は 2 つ、自動確定は受理だけ。違うのは その業でだけ効く確認 で、ここは真贋。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（真贋未確認のブランド品・部品代が数量×単価と合わない・安全試験に通っていない・法域の基準が台帳に無い）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9523","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9601","title":"クリーニング業 — 受理・取扱方法検証・資格審査・洗濯処理・返却（営み OS）","description":"暮らしの営みの 1 本目。個人が自分の持ち物を業者に預けて返してもらう —— 預り品（bailment）は所有権が動かないまま占有だけが移るので、洗ってしまった衣類も返してしまった衣類も戻せない。営み OS の面から実物の actor を回した結果で、確定する道と governor が実際に拒む道（洗濯表示が禁じる処理・溶剤取扱資格の失効・法域の取扱基準が台帳に無い）の両方を出している。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9601","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9601-carpet","title":"カーペット清掃 — 受付・ケア計画検証・繊維/色堅牢度審査・洗浄工程・返却（営み OS）","description":"この 1 本だけ ISIC 帰属が確定していない —— 仕様ミラーはどのクラスにも carpet cleaning を列挙しておらず、repo は主張を広げず自分のモデルを絞って解いた（引き取り型だけを実装し 9601 の textile products に収まる形にした）。:actuation/declare-isic-class は語彙に無く、actor が自分の読みを昇格させられない。営み OS の面から実物の actor を回した結果。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9601-carpet","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9601-coinlaundry","title":"コインランドリー — 機器登録・衛生計画検証・点検審査・機器停止・残置物保管（営み OS）","description":"この面で唯一、預り品ではない vertical。無人セルフでは顧客が自分で機械を操作し事業者は洗濯物を占有しないので、:actuation/return-* op が存在しない（gate ではなく不在）。主体も ticket ではなく機器。検査の族も違い、保持物が無いので risk は経過時間と現在状態になる —— 点検間隔の超過・掲示保管期間の未経過・運転中の機器。保管は語彙にあり処分は無い。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9601-coinlaundry","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9609","title":"その他個人サービス — 受理・法域判定・身元審査・紹介確定（営み OS）","description":"依頼者本人が主体の営み。固有の検査はクーリングオフ —— 契約から法定の熟慮期間が経っていない状態で紹介を確定させない。資格でも等式でも真贋でもない、時間の経過を見る 4 つ目の型。なお ISIC 9609 の分類にはペットケアが含まれるが、この actor は汎用の紹介を実装しており動物の語彙は無い —— ペットのクリーニングは未実装のままで、この面はその穴を埋めない。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9609","files":["index.html"]},{"org":"cloud-itonami","repo":"cloud-itonami-isic-9609-petcare","title":"ペットケア — 受付・ケア計画検証・狂犬病予防注射審査・施術・返却（営み OS）","description":"預り品パターンの最も強い形。9601 は衣類、9522 は家電、9523 は靴、4520-carwash は車を預かるが、ここが預かるのは適用した処理で傷つき死にうる生き物である。獣医行為（鎮静・診断・処方・治療・安楽死）は gate ではなく語彙に存在しない。営み OS の面から実物の actor を回した結果。","source":"https://github.com/cloud-itonami/cloud-itonami-isic-9609-petcare","files":["index.html"]},{"org":"cloud-itonami","repo":"os","title":"営み — cloud-itonami の統合面","description":"9 本の governed actor を 1 つの営みとして見る面。統合台帳（hash 連鎖・本文を持たない）、人の承認待ち、境界をまたぐので人が運ぶ仕事、そして未接続の営みとその理由。","source":"https://github.com/network-awai/cloud-itonami","files":["index.html"]}]}