{"kind":"repository","status":200,"org":"cloud-itonami","repo":"cloud-itonami-isic-9101","org-entry":{"org":"cloud-itonami","host":"cloud-itonami.itonami.cloud","status":"live","title":"cloud-itonami","description":"行政・公共制度をソフトウェアとして実装する事業群。ここはその公開サイト面。","files":["index.html"]},"site":{"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"]},"app-url":"https://cloud-itonami.itonami.cloud/cloud-itonami-isic-9101/","repository-url":"https://itonami.cloud/cloud-itonami/cloud-itonami-isic-9101/"}