@aiquants/enrichment-governance-core

Enterprise Knowledge Governance Core: Canonical Schemas, Merkle Proof Verification, Dry-Run Simulation, and API Client SDK.

概要

本パッケージは、エンタープライズ・ナレッジガバナンス基盤における TypeScript 正準スキーマ、暗号学的マークル引用完全証明 (CitationProof) のクライアント検証エンジン、および Python FastAPI バックエンドへの API クライアント SDK (GovernanceClient, GovernanceAdminClient) を提供する共有ライブラリです。

主な機能

• 正準 Zod スキーマ & 型定義: ガバナンス検索、規程調停回答、意思決定系譜、プロンプト・オントロジー変更ドライランシミュレーション、ナレッジグラフ探索。
• 暗号学的マークル引用完全証明 (Client-Side Verification): SHA-256 プレフィックス付き二分木に基づく Merkle Root の決定論的再計算・照合検証。
• 型安全な API クライアント SDK:
  • GovernanceClient: ガバナンス検索 (/ai/governance/search)、規程回答 (/ai/governance/answer)。
  • GovernanceAdminClient: ドライラン評価 (/ai/governance/simulate)、システムパラメータ・機能フラグ・プロンプトテンプレート管理、ナレッジグラフ探索。
• 文書の権威の規則 (純粋関数): 候補の条件 (isEligibleAuthority)、同順位の群 (equalRankGroups) と組 (tiePairs)、階層から決まる重大度 (SEVERITY_BY_TIER)、100 ns 精度の UTC の時刻 (UtcInstant・offsetIsoOfUtcInstant)、規程区分の正規化 (normalizePolicyCategory)、台帳の状態機械 (DOCUMENT_AUTHORITY_COMMAND_RULES・documentAuthorityCommandBlocker・isDocumentAuthorityCommandAvailable)、命令の検査 (checkDocumentAuthorityCommand)、組の事実とその正準の文字列とハッシュ (policyConflictFactsOf・canonicalPolicyConflictFactsJson・policyConflictFactsHash)。
• 権威台帳と規程衝突の契約: 台帳の行・頁・検索・命令とその拒否、衝突の概況・一覧・詳細・裁定とその拒否、検知の結果の唯一の形 (PolicyConflictDetectionOutcome)、追記だけの記録表の行の姿 (KnowledgeGovernanceEventRecord)。
• 厳格な No-Fallback & SSOT 方針: 暗黙のフォールバック値や曖昧な型キャストを完全排除。

インストール

pnpm add @aiquants/enrichment-governance-core 'zod@^3.25.0'

zod ^3.25.0 は peer dependency (素の zod は範囲外の latest (4.x) を入れる)。

クイックスタート (Quick Start)

1. ガバナンス検索と規程回答

import { GovernanceClient } from "@aiquants/enrichment-governance-core"

const client = new GovernanceClient({
    baseUrl: "https://api.example.com",
    apiKey: process.env.QUANTS_API_KEY,
})

// 規程統合検索
const searchResult = await client.search({ query: "就業規則 育児休業" }, "acme")
console.log(searchResult.hits)

// 権威性連動規程回答
const answerResult = await client.answer({ question: "育児休業の申請期限は何日前ですか？" }, "acme")
console.log(answerResult.answer)

// マークル引用完全証明のクライアント側独立検証
if (answerResult.citationProof) {
    const isValid = client.verifyCitationProof(answerResult.citationProof, {
        expectedTenantId: "acme",
        expectedCitations: answerResult.verifiedCitations,
    })
    console.log(`Citation proof verified: ${isValid}`)
}

2. 管理コンソール・ドライラン事前シミュレーション

import { GovernanceAdminClient } from "@aiquants/enrichment-governance-core"

const adminClient = new GovernanceAdminClient({
    baseUrl: "https://api.example.com",
    apiKey: process.env.QUANTS_API_KEY,
})

// プロンプト変更ドライラン評価
const simResult = await adminClient.simulate(
    {
        promptOverrides: {
            DEFAULT_POLICY_QA: "改訂プロンプトテンプレート...",
        },
        intentTypes: ["SET", "DIFF"],
    },
    "acme",
)
console.log(`Delta groundedness: ${simResult.delta.groundedness}`)

文書の権威と規程衝突

ホストに依らない純粋な規則と契約です。ホストは権威行 (td_document_authority) と文書の行を自分の行スコープで読み、その行をこれらの規則と形へ渡します。誰が何を読めるかは規則が決めず、ホストが両側可読性を当ててから形を組みます。

規則の適合例 (下の 3 つの JSON) はパッケージの fixtures/ に置き、公開する tarball にも含めます。exports は ./fixtures/* を公開するので、JS のホストは import cases from "@aiquants/enrichment-governance-core/fixtures/policy-category-normalization.cases.json" with { type: "json" } で読めます。他の言語の実装 (Python を含む) はリポジトリの packages/enrichment-governance-core/fixtures/ か公開したパッケージの fixtures/ から読みます。

時刻の比較 (100 ns)

時刻は SQL Server の datetime2(7)・datetimeoffset(7) の 100 ns の精度で比べます。JS の Date はミリ秒に丸め、100 ns 違う 2 つの発効日時を同順位と誤るため、規則は固定長の UTC の文字列 UtcInstant (yyyy-mm-dd hh:mi:ss.fffffff、端数は常に 7 桁) で比べます (辞書順が時間順)。

| 関数・スキーマ | 役割 | | --- | --- | | parseUtcInstant(value) / UtcInstantSchema | 様式 121 の UTC の時刻を読む。形が違うか実在しない時刻は RangeError (スキーマは issue) | | utcInstantOfOffsetIso(value) / OffsetIsoInstantSchema | 時差付きの ISO 8601 を UTC へ直す。受けるのは SQL Server の ISO 8601 の datetimeoffset の字面 (yyyy-mm-ddThh:mi:ss[.f] の後に Z か ±hh:mi。秒は必須、時差はコロン付き) だけで、ホストは受けた文字列をそのまま datetimeoffset(7) のパラメータへ束縛できる。端数 8 桁以上・時差 ±14:00 超・書かれた年か UTC の年が 0001〜9999 の外は丸めずに拒む (SQL Server は 0000 年の日付を読めない) | | offsetIsoOfUtcInstant(instant) | UtcInstant を UTC の ISO 8601 (yyyy-mm-ddThh:mi:ss.fffffffZ) で書く。様式 121 の文字列は T も時差も持たず日付の読み手が地方時として読むので、画面が示す UtcInstant (失敗した群の発効日時) はこれを通して書式化する。utcInstantOfOffsetIso で同じ UtcInstant に戻る |

候補の条件と同順位の群

import { equalRankGroups, parseUtcInstant, SEVERITY_BY_TIER, tiePairs } from "@aiquants/enrichment-governance-core"

const asOf = parseUtcInstant("2026-10-01 00:00:00.0000000")
for (const group of equalRankGroups(candidates, asOf, asOf)) {
    for (const [source, target] of tiePairs(group)) {
        // source.metadataId < target.metadataId。重大度は SEVERITY_BY_TIER[source.authorityTier]
    }
}

• isEligibleAuthority(candidate, asOfValid, asOfTx): 承認済み・有効時間内 (validFromUtc <= asOfValid < validUntilUtc)・取引時間内 (txCreatedAtUtc <= asOfTx < txSupersededAtUtc)。候補 (AuthorityCandidateSchema) の 4 つの時刻は様式 121 の UTC の文字列で、接尾辞 Utc が台帳の行の時差付きの ISO の時刻と区別します。
• equalRankGroups: 1 つの主題 (下の「規程区分」) の適格な候補を (階層, UTC の発効日時) で群に分け、2 件以上の群を返します。より上位の候補の有無に依りません (組の状態は組の 2 文書だけで決まる)。各群は metadataId の昇順、群どうしは最小の metadataId の昇順です。同じ文書の版を 2 度含む入力は、適格か否かに依らず RangeError です。
• tiePairs: 群の組を [source, target] (source < target) で、source の昇順、次に target の昇順に返します。順位の混ざった群と同じ文書の版を 2 度含む群は RangeError です。
• 適合例は fixtures/authority-eligibility.cases.json にデータで置き (eligibility・equalRankGroups・equalRankGroupsRejects・tiePairs・tiePairsRejects)、全ての実装 (Python を含む) が同じ JSON を流します。

規程区分

normalizePolicyCategory は NFKC の後に、空白の連なりを 1 つの空白 (U+0020) にし前後の空白を除く正規化をし、整形式の UTF-16 でない入力 (要求の本文の JSON.parse が作りうる対の無いサロゲート) なら他の何よりも先に MALFORMED、正規化の後が 0 符号単位なら EMPTY、51 符号単位以上 (UTF-16 の符号単位、nvarchar(50)) なら TOO_LONG を投げずに返します。PolicyCategorySchema は入力を正規化した値へ直し、拒む区分を欄の道の issue (params.reason) にします。保存した区分は NormalizedPolicyCategorySchema (既に正規化した形) で検めます。

空白は POLICY_CATEGORY_WHITESPACE_CODE_POINTS (Unicode の White_Space 特性と、貼り付けた文の先頭に付きうるバイト順マーク U+FEFF) だけです。それ以外の文字 (Python の str.isspace が空白とする制御文字 U+001C〜U+001F と、U+200B のような見えない書式の文字を含む) は区分の一部です。JavaScript の \s と trim、Python の \s と strip はどれもこの集合と違うので、他の言語の実装は言語の空白の類を使わずにこの集合を使います。台帳の検索語も同じ集合を前後から除きます。例 (拒む例を含む) は fixtures/policy-category-normalization.cases.json に置き、全ての実装 (Python を含む) が同じ JSON を流します。

NFKC は Unicode の版ごとに、後の版が割り当てた符号位置を前の版と違って写します (例えば U+1CCD6 は 16.0 以降 A へ写る)。正規化を定める版は POLICY_CATEGORY_UNICODE_VERSION (今は 17.0、適合例の unicodeVersion と同じ値) で、全ての実装は例を流す前に実行環境の Unicode のデータがその版 (主と副の番号) であることを確かめます (Node の process.versions.unicode、Python の unicodedata.unidata_version)。normalizePolicyCategory は実行環境自身の Unicode のデータを読み、その版を検めません。engines.node (>=18.0.0) を満たす Node でも古い Unicode のデータを持つものがあるので、区分を正規化して保存するホスト (経路) は起動時に実行環境の版を POLICY_CATEGORY_UNICODE_VERSION と突き合わせ (値を写さずにこの定数を読む)、違えば起動しません。画面が示す正規化した値は参考で、保存する値はサーバーの正規化が決めます。別の版へ移すことは実行環境の更新でなく正規化の変更であり、保存した区分のデータ移行を伴います。

主題 (規程衝突を比べる単位) は正規化した文字列そのものです。2 つの区分は正規化した形が符号単位で等しいときだけ同じ主題で、NFKC が残す大文字と小文字・平仮名と片仮名の違い (HR と hr、じんじ と ジンジ) は別の主題です。区分を自分で比べるホスト (SQL の述語・群分け・重複を除いた一覧) もバイナリで比べます (列に Japanese_XJIS_140_BIN2 のようなバイナリの照合順序を付ける)。大文字小文字や仮名の種類を区別しない照合順序は、この契約が分ける 2 つの主題を 1 つにまとめます。

バイナリの照合順序だけでは符号単位の等しさになりません: SQL Server の =・GROUP BY・DISTINCT はバイナリを含む全ての照合順序で末尾の空白を無視します (末尾に空白を 1 つ付けた HR と HR が等しい)。正規化した区分は空白で始まりも終わりもしないので、ホストは保存する区分を全て正規化した形に保ち (書き手は NormalizedPolicyCategorySchema が受ける値だけを書く)、そのときバイナリの = が符号単位の等しさになります。守るのは書き手だけです: len で書いた列の CHECK (例: len(policy_category) > 0) は、len が数えない末尾の空白を捕まえません。

台帳の状態機械

DOCUMENT_AUTHORITY_COMMAND_RULES は各命令が見つけ残す承認状態・状態の他に書く列 (changes。登録と編集が書く列は書式の欄 DocumentAuthorityCommandFieldSchema そのもの。他の列は命令の前の値を保ち、登録の後は空)・状態の外で行かその文書の版が示す前提 (削除は一度も承認していない行だけ、承認取消は他の行を置き換えていない承認だけ、登録と承認は文書の版が現行で未削除のときだけ)・検知を走らせるかの唯一の定義です。記録表の行の検査 (KnowledgeGovernanceEventRecordSchema)・命令の結果の形 (DocumentAuthorityCommandResultSchema)・画面の押せる命令がこれを読みます。

documentAuthorityCommandBlocker(kind, row) は命令を妨げる最初の規則 (STATUS・APPROVED_ONCE・REPLACES_ANOTHER・DOCUMENT_NOT_CURRENT、妨げが無ければ null) を名指し、画面は規則を導き直さずにその文を示します。isDocumentAuthorityCommandAvailable(kind, row) は妨げが無いことです。

記録の姿は文書の状態を持たないので、記録の検査は文書の前提以外の全ての規則を当てます (書かない列を変えた記録・登録の後に承認や取消や後継を持つ記録を拒む)。他の行や操作者を要する前提 (可読・画面が見た row_version・同じ順位の承認済みの行の上限 POLICY_CONFLICT_MAX_TIE_GROUP_SIZE・後継が旧行より後に発効することを含む置き換え先の述語・create が名指す文書が派生でないこと) はホストだけが錠の下で検めるので、押せる命令もなお拒まれえます。

| 命令 | 見つける状態 | 残す状態 | 状態の他に書く列 | 前提 | 検知 | | --- | --- | --- | --- | --- | --- | | create | (行が無い) | DRAFT | 階層・区分・有効時間・置き換える文書 (承認者・取消者・後継は空) | 文書の版が現行で未削除 (非派生と可読はホスト) | しない | | update | DRAFT | DRAFT | 階層・区分・有効時間・置き換える文書 | — | しない | | approve | DRAFT | APPROVED | 承認者 (前の取消者は残す) | 文書の版が現行で未削除 | する | | withdraw | APPROVED | DRAFT | 取消者 (承認者は消さない) | 他の行を置き換えていない | する | | deprecate | APPROVED | DEPRECATED | — | — | する | | delete | DRAFT | (行が無い) | (行を消す) | 一度も承認していない | しない |

事実の正準の文字列とハッシュ

組の事実 (detected_rule_diff) と facts_hash は、ホストが候補を手で写さず自前で直列化せずに次の 3 つで組み書きます。どれも事実を PolicyConflictFactsSchema で検めてから組み、未知の鍵や規則を破る事実は ZodError です (policyConflictFactsOf は順位を共有しない 2 つの候補を RangeError で拒み、候補からは事実が持つ 6 つの項目だけを写すので、区分と共に読んだ検知の行のような他の鍵を持つ候補も渡せます)。

import { canonicalPolicyConflictFactsJson, policyConflictFactsHash, policyConflictFactsOf } from "@aiquants/enrichment-governance-core"

const facts = policyConflictFactsOf(policyCategory, source, target) // tiePairs の組の 2 つの候補から
const detectedRuleDiff = canonicalPolicyConflictFactsJson(facts) // 鍵を辞書順に並べ、文字列の外に空白の無い JSON
const factsHash = policyConflictFactsHash(facts) // その UTF-8 の SHA-256 (64 桁の小文字の 16 進)。SQL は convert(binary(32), @hex, 2)

detected_rule_diff は値を解析した形で保ち読むときに直列化し直す json 型の列なので、保存されるのはこの文字列そのものでなく、それが表す値です。読み手は列の文字列をハッシュせず、値を解析してこの正準の文字列をハッシュします (PolicyConflictDetailSchema がそうします)。事実の整数は全て安全な整数 (Number.MAX_SAFE_INTEGER 以下) で、全ての実装が同じ桁を読み書きします。

正準の文字列を書くのは @aiquants/enrichment-core の canonicalJson (システムの中の正準の JSON の唯一の定義で、どの深さでも鍵を UTF-16 の符号単位の昇順に並べ、文字列の外に空白を置かない) です。本パッケージはその写しを持たず入口から出し直しもしないので、正準の JSON そのものが要る利用者は @aiquants/enrichment-core から取り込みます。

文字列は Python の json.dumps(facts, sort_keys=True, separators=(",", ":"), ensure_ascii=False) とバイト単位で同じです。

逃がすのは引用符・逆斜線・制御文字 U+0000〜U+001F だけで (\b・\t・\n・\f・\r は短い形、他は小文字の \u00xx)、U+007F〜U+009F・<・&・>・非 ASCII はそのまま書きます。区分は空白の集合の外の制御文字 (U+0008 や U+001C) を保つので、他の言語の実装は既定の直列化 (<・&・> を逃がすもの、\b を \u0008 と書くもの) を使わずにこの書き方を再現します。

正しい事実の文字列は全て整形式の UTF-16 (唯一の自由な文である区分が対の無いサロゲートを MALFORMED として拒む) なので、UTF-8 の符号化は 1 つに決まります。黄金の例 (事実 → 文字列 → ハッシュ、と全ての実装が拒む事実 rejects) は fixtures/policy-conflict-facts.cases.json に Python で求めた値で置き、全ての実装が同じ JSON を流します。詳細 (PolicyConflictDetailSchema) は factsHash が示す事実のハッシュであることを検めます。

契約

| 区分 | スキーマ | | --- | --- | | 語彙と幅 (DB の CK と列の幅の写し。一致はホストの試験が DDL を読んで確かめるもの) | ApprovalStatusSchema・PolicyConflictSeveritySchema・PolicyConflictResolutionStatusSchema (UNRESOLVED / RESOLVED / IGNORED)・DocumentAuthorityCommandKindSchema・KnowledgeGovernanceEventSchema・OPERATOR_IDENTIFIER_MAX_LENGTH (100)・POLICY_CATEGORY_MAX_LENGTH (50)・POLICY_CONFLICT_SUMMARY_MAX_LENGTH (1000)・POLICY_CONFLICT_DECISION_REASON_MAX_LENGTH (2000。列 arbitration_decision の幅はこれと同じ nvarchar(2000) でなければならず、ホストの DDL の試験が突き合わせる)・POLICY_CONFLICT_DECISION_REASON_BLANK_CODE_POINTS (理由の空白の文字。タブ・改行・復帰・空白・全角空白)。長さは全て UTF-16 の符号単位 (列の幅と同じ単位) で数えます | | 権威台帳 | DocumentRefSchema・DocumentAuthorityRowSchema (置き換えの鎖は読める先の DocumentRef か null)・DocumentAuthorityPageSchema・DocumentAuthorityPageWithCategoriesSchema・AuthorityCandidatePageSchema・ReplaceableAuthorityPageSchema・各頁の問い合わせ (limit は必須で 1〜50。検索語は区分と同じ空白を前後から除いて 2 文字 (符号位置) 以上 200 符号単位以下の整形式の UTF-16 で、検めた値は前後の空白を除いた文字列。ホストはそれを名前か URI の部分文字列としてそのまま照合し、LIKE の特殊文字 %・_・[ を ESCAPE で逃がす。識別子と件数は全て Number.MAX_SAFE_INTEGER 以下) | | 台帳の命令 | DocumentAuthorityCommandSchema (kind で判別する 6 つの命令。階層と発効日時は必須、失効日時は 100 ns の UTC で発効日時より後、違反は欄の道の issue)。経路と画面は checkDocumentAuthorityCommand(input) で検め、受けた命令 ({ok: true, value}) か拒否 ({ok: false, rejection}) と共に書式の全ての誤りを一度に受け取る (zod は欠けた欄で止まり欄の間の規則を検めないので、この関数がスキーマと同じ規則を与えられたままの値にも当てる): 誤りが全て書式の欄 (DocumentAuthorityCommandFieldSchema) に在れば FIELD_INVALID と、欄ごとに 1 つの理由 (DocumentAuthorityCommandFieldReasonSchema: REQUIRED・MALFORMED・EMPTY・TOO_LONG・NOT_AFTER_VALID_FROM・SELF_REPLACEMENT。区分の理由は PolicyCategoryRejectionSchema を全て含む) を書式の順に、他の誤りを含めば BODY_INVALID。値を持たない欄 (鍵が無いか、null か空の文字列。選んでいない階層や空の日時の入力) は REQUIRED で、空の区分の文字列だけは区分自身の理由 EMPTY。validUntil と replacesMetadataId は null を「無し」として取るので、画面は空の失効日時と置き換え無しに null を送る。各欄はそこに当てはまる理由だけを持ち (DocumentAuthorityCommandFieldErrorSchema)、画面は (欄, 理由) を固定の文へ写す。拒否は台帳の命令の拒否 (下) の本文としてそのまま返せる | | 台帳の命令の結果と拒否 | DocumentAuthorityCommandResultSchema (命令の kind で判別し、ホストは kind をそのまま返す。row は命令の残す承認状態の行で delete の後は null、detection は検知を走らせる approve / withdraw / deprecate だけが持ち create / update / delete は null。検知を走らせる命令は replaced も持ち、他の行を置き換える行 (row.replacesAnother) の承認では承認が残したその行 (失効を承認した行の発効か前の早い失効へ縮め、後継を承認した版にし、行の版が新しい)、他は null。画面は row と同じく replaced も表へ差し替える。どちらの行も命令自身のトランザクションが書いた行で、確定の前にそのトランザクションの中で (か書き込みの OUTPUT から) 読み、検知の後に読み直さない)・DocumentAuthorityCommandRejectionSchema (拒んだ命令の本文。code で判別し自由な文を運ばない: BODY_INVALID・FIELD_INVALID (欄の誤り)・NOT_FOUND・REPLACEMENT_NOT_FOUND・STALE (今の行)・ALREADY_REGISTERED (登録の文書の版が既に持つ行。登録自身のトランザクションで台帳の読み手を通して読み、その文書の版は登録の前提の通り現行で未削除。画面は送った候補を除き、その行を表へ入れる)・RANK_LIMIT_REACHED (操作者の行スコープの有無 rowScopeApplied と、行スコープが無制限の操作者には上限、行スコープ付きには null)・NOT_AFTER_REPLACED・DOCUMENT_NOT_CURRENT (今の行。文書の版がもう現行でないか削除された DRAFT の行で、画面は差し替えた行で承認を示さなくなる)・DEADLOCK・DEPLOYMENT_DISABLED (配備の書き込みの切替が true でない: 偽・未設定・true / false 以外の値。どれかは応答でなくサーバーのログが示す)) | | 規程衝突 | PolicyConflictFactsSchema (組の 2 文書だけの事実。群の大きさを持たない)・PolicyConflictSummarySchema (測定済み / 未測定の件数と、行スコープが無制限の操作者だけの失敗した群。群の発効日時は UtcInstant なので画面は offsetIsoOfUtcInstant を通して示す。未測定の理由は PolicyConflictUnmeasuredReasonSchema (NEVER_DETECTED / DETECTION_INCOMPLETE_FOR_READABLE)、失敗した群の理由は FailedTieGroupReasonSchema (TIE_GROUP_OVER_LIMIT))・PolicyConflictRowSchema・PolicyConflictPageSchema・PolicyConflictPageQuerySchema (頁の問い合わせ: state は必須で PolicyConflictStateSchema (UNRESOLVED_ACTIVE / UNRESOLVED_CLEARED / RESOLVED / IGNORED)、severity と after は任意、limit は必須で 1〜POLICY_CONFLICT_PAGE_LIMIT_MAX (50))・PolicyConflictDetailSchema (factsHash は示す事実のハッシュ。各文書の 3 つの写し (組の行・権威行の横・権威行の中) は全ての項目で等しい)・PolicyConflictDecisionSchema (RESOLVE / IGNORE、理由は前後の空白の文字を除いて 1〜2000 符号単位の整形式の UTF-16 で、対の無いサロゲートは区分と同じく拒む。空白の文字はタブ・改行・復帰・空白・全角空白で CK の集合と同じで、それ以外の見えない文字は理由の一部。経路と画面は checkPolicyConflictDecision(input) で検め、受けた裁定 ({ok: true, value}) か拒否 ({ok: false, rejection}) と共に判断と理由の誤りを一度に受け取る: 誤りが全て書式の欄 (PolicyConflictDecisionFieldSchema: 判断 verdict、理由 reason の順) に在れば FIELD_INVALID と欄の理由 (PolicyConflictDecisionFieldErrorSchema。判断は選んでいない (kind が無いか null か空の文字列、または RESOLVE の prevailingMetadataId がそのどれか) とき REQUIRED だけ。理由は欠けた理由か null は REQUIRED、文字列でないか整形式でない理由は MALFORMED、空白の文字を除くと空 (空の文字列を含む) は EMPTY、2000 符号単位を超えれば TOO_LONG) を、他の誤り (選択肢の外の判断・判断の無い正とする文書・IGNORE の正とする文書を含む) を含めば BODY_INVALID を受け取る。判断を選ぶ前の画面も同じ関数で判断と理由の両方の誤りを示せる)・PolicyConflictDecisionRejectionSchema (拒んだ裁定の本文。code で判別し自由な文を運ばない: BODY_INVALID・FIELD_INVALID (欄の誤り)・ID_MISMATCH・PREVAILING_NOT_IN_PAIR・NOT_FOUND・STALE (今の詳細)・DEADLOCK・DEPLOYMENT_DISABLED (台帳の命令と同じ意味)) | | 検知の要求と結果 | PolicyConflictDetectionRequestSchema (今すぐ検知する要求の本文 {intent: "detect"})・PolicyConflictDetectionRequestRejectionSchema (拒んだ要求の本文。BODY_INVALID か DEPLOYMENT_DISABLED で、台帳の命令と裁定と同じ符号。走った検知は拒まず結果で返す)・PolicyConflictDetectionOutcomeSchema (detected / busy / failed の 3 つだけ。failed は理由の符号 (SUBJECT_WRITE_FAILED は主題のトランザクション、DETECTION_FAILED はそれ以外の段の失敗)・操作者の行スコープの有無 rowScopeApplied・失敗した区分だけを持ち、文を一切運ばない。失敗した区分は主題の失敗を行スコープが無制限の操作者へ示すときちょうど在り、他は null。各形の固定の文は画面が書く) | | 記録表 | KnowledgeGovernanceEventRecordSchema (td_knowledge_governance_event にアプリが書く行の JSON の姿と鍵の列。テナント・行為者・書いた場所はホストが足す。event で判別し、事象ごとに宣言した camelCase の鍵だけをどの深さでも受ける。前の姿の null は create だけ、{deleted: true} は delete の後の姿だけ、命令の前提と書く列は DOCUMENT_AUTHORITY_COMMAND_RULES の通り (書かない列は前後で同じ、登録の後の承認者・取消者・後継は空)、検知の失敗した群は群の文書を持たない)。事象の語彙 KnowledgeGovernanceEventSchema は governance.maintenance も持つが、書くのは利用者が承認した保守の DML だけで、この記録の検査はその事象を持たない |

測れなかった件数は理由を伴う未測定であり、決して 0 ではありません。