Auditability

定義

Auditability

Auditability とは、ある process frame、transition、decision、delta、durable item、recovery path に対して、
誰が、何を、どの authority と evidence に基づいて、どの state effect を生じさせたかを、後から再構成・検証できる性質 である。

それは単なる log retention ではなく、
attribution、authority trace、subject trace、evidence trace、state mutation trace、omission trace、invalidation / supersession trace、continuity trace を持つ。

より短く言えば、Auditability とは
「この process の現在の状態と過去の判断が、なぜその形になっているのかを、後から追えること」
である。

PCE 2.0 において auditability は、付随的な監査ログではない。
それは process を governed にし、durable project state を 信頼できる current reality として扱うための基盤である。

もし auditability が弱いなら、たとえ output が良く見えても、

それが誰の判断か分からない
どの evidence に基づくか分からない
何が pending のままか分からない
どの approval が current で、どれが stale か分からない
何が omit されたか分からない
何が supersede / retract されたか分からない

という状態になる。
そのとき process は、後から正しく疑うことも修正することも難しくなる。

なぜ Auditability が必要なのか

PCE 2.0 が auditability を独立に扱う理由は、
process をただ動かすだけでは不十分であり、current truth を後から説明できること が必要だからである。

少なくとも、次の理由がある。

1. current truth は自己説明しない

Durable Project State に item があるだけでは、

なぜそれが current なのか
誰が採用したのか
どの delta から来たのか
何を根拠に promote / merge されたのか
何を supersede したのか

は分からない。

PCE 2.0 では state を current truth として使う以上、その currentness を説明可能にしなければならない。
それを支えるのが auditability である。

2. AI 時代の process は「見かけ上うまくいった」が多い

とくに AI assist や multi-agent flow では、次のようなことが起きやすい。

結果はよさそうだが required approval を飛ばしている
useful-looking だが provenance の弱い summary を使っている
stale context に基づく正解らしい proposal が出る
pending gate を失ったまま later process が続いている

こうした Corrupt Success を止めるには、
後から 何がどう通ったのか、何が飛ばされたのか を辿れる必要がある。

3. rollback / recovery / replan には履歴の意味が必要

異常時や reframe 時には、次を知る必要がある。

どの approval が current でどれが stale か
どの delta が emitted されていたか
どの context selection が使われたか
何が omitted されたか
どの anchor が最後の acceptable state か

これらが追えなければ、rollback も recovery も雑になる。

4. governance は “後から説明できる” ところまで含む

approval point や capability scope が定義されていても、

誰が実際に approve したのか
誰が scope widening を認めたのか
誰が memory write を行ったのか
なぜ escalation されたのか

が追えなければ、governance は名目上のものに留まりやすい。

5. omission も process の一部だから

PCE 2.0 では、Context Selection や Compaction によって active context が作られる。
そのため「何を入れたか」だけでなく、何を入れなかったか も process を形づくる。

auditability がないと、

required evidence を落としたのか
low-salience だから ref に回したのか
governance 上見せなかったのか
stale だから除外したのか

が分からなくなる。

Auditability が答えるべき問い

PCE 2.0 において auditability が十分だと言うためには、少なくとも次の問いに答えられる必要がある。

1. Attribution

誰が何をしたのか
どの actor / bundle が行為したのか
人間か AI か tool か runtime か

2. Authority

その actor はどの authority basis でそれをしたのか
approval / memory write / rollback / escalation の権限はどこから来たのか
retained authority を越えていないか

3. Subject

何が対象だったのか
code patch か
decision delta か
failure memory candidate か
recovery point か
join result か

4. Evidence

どの evidence を見てそう判断したのか
どの refs に基づいたのか
required evidence は揃っていたのか

5. State Effect

その結果、何が current state を変えたのか
pending approval が解けたのか
delta が promote-ready になったのか
canonical item が更新されたのか
old state が invalid になったのか

6. Omission / Exclusion

何が active context から外されたのか
なぜ外されたのか
required information は落ちていないか
by-reference なのか hidden なのか stale なのか

7. Continuity

どの handoff があったのか
どの checkpoint が使われたのか
どの recovery path が取られたのか
pending gate は保たれていたのか

8. Currentness

なぜこの item が current なのか
何を supersede / retract したのか
なぜ古い approval はもう current でないのか

auditability とは、最終的には
「いまなぜこの状態なのか」を答えられること
だと言ってよい。

Auditability は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておく。

1. 単なる Logging ではない

ログは raw events の列である。
Auditability は、そのログや records から governance-relevant な問いに答えられる性質である。
ログが多くても、必要な問いに答えられなければ auditability は低い。

2. 単なる Observability ではない

observability は、主に「いま何が起きているか」を知るための能力である。
auditability は、主に「なぜこうなったか」を後から再構成するための能力である。

3. 単なる Provenance ではない

provenance は lineage を追うのに有用だが、
auditability はそれに加えて

authority
gate resolution
omissions
invalidations
continuity events

まで含む。

4. 単なる Reproducibility ではない

再実行して同じ結果が出るかは重要だが、
auditability は「同じ結果がなぜ current として採用されたか」を問う。
再現可能でも approval や authority が壊れていれば auditability は低い。

5. 単なる Accountability ではない

accountability は「誰が引き受けるか」に近い規範概念である。
auditability は「誰が何をどうしたかを後から説明できるか」という説明可能性の概念である。
前者を支える基盤として後者が必要になる。

6. 単なる Full Retention ではない

すべての transcript、すべての token、すべての raw trace を保存すればよいわけではない。
PCE 2.0 では、必要な情報を traceable に保持しつつ、
適切な redaction・reference・compaction を許す。
重要なのは「全部持つこと」ではなく「必要な問いに答えられること」である。

7. 単なる Blame System ではない

auditability は fault finding のためだけのものではない。
rollback、recovery、memory discipline、governance tuning、process improvement のためにも必要である。

Auditability の中心構造

PCE 2.0 において、ある出来事や item が audit 可能であるとは、概念的には次を満たすことだと書ける。

auditable(x) iff
  attributable(x)
  and subject_known(x)
  and authority_basis_known(x)
  and evidence_traceable(x)
  and state_effect_known(x)
  and invalidation_or_supersession_traceable(x)

ここで重要なのは、
単に「誰がやったか」だけでは足りず、

何を対象にしたか
どの authority だったか
何を根拠にしたか
何が state として変わったか
後で何が無効化 / supersede されたか

まで必要だという点である。

何を audit 対象にするのか

PCE 2.0 では、すべての micro-step を同じ強さで audit する必要はない。
しかし少なくとも governance-relevant event は audit 可能でなければならない。

代表的な audit-relevant event

1. Responsibility-relevant events

bundle assign / delegate / revoke
retained authority changes
capability scope changes

2. Gate-relevant events

approval submission
approve / reject / request changes
evaluation verdict
promotion decision

3. State-changing events

merge
memory write
supersede / retract
rollback
close / abandon / supersede frame

4. Continuity events

handoff
checkpoint
recover
resume
escalation

5. Context-shaping events

context selection
compaction
invalidation of active context
stale verdict invalidation

つまり PCE 2.0 の auditability は、
誰が今何をしたか のログだけではなく、
今後の legal next transition を変える出来事 を特に重く見る。

Auditability の主要ファセット

PCE 2.0 では、Auditability を少なくとも次のファセットに分けて考えるとよい。

1. Action Auditability

誰が何の action をしたかを追えること。

例:

code edit
approval action
promotion decision
rollback order

2. Authority Auditability

その action や decision が、どの authority basis のもとで行われたかを追えること。

例:

reviewer bundle による code approval
memory writer bundle による canonical write
incident owner による rollback authorization

3. Evidence Auditability

どの evidence、どの refs、どの contract が、その judgment を支えたかを追えること。

4. State Mutation Auditability

何が current state を変えたかを追えること。

例:

which delta updated canonical state
which approval unlocked merge
which rollback invalidated prior path

5. Omission Auditability

何を active context から落としたのか、
何を by-reference に回したのか、
何を governance 上見せなかったのかを追えること。

これは PCE 2.0 では特に重要である。
context compilation は omission を伴うため、それ自体が監査対象になる。

6. Continuity Auditability

handoff、checkpoint、recovery、resume の continuity が追えること。

7. Invalidity / Supersession Auditability

何が stale になり、何が superseded され、何が retracted されたかを追えること。

このファセットがないと、current truth と old truth の境界が曖昧になる。

Auditability と Governance Surface の関係

Governance Surface は、process における権限・可視性・評価・昇格・回復条件が、実際にどこに露出するかを表す。
Auditability は、その surface を 後から検証可能にする性質 だと言える。

例

approval surface
→ 誰が approve したかを追える必要がある
capability surface
→ 誰がどの scope で edit したかを追える必要がある
promotion surface
→ どの candidate がどの authority で canonical 化されたかを追える必要がある
recovery surface
→ recover / resume がどの条件で許されたかを追える必要がある

つまり Governance Surface が 現在の統治の面 だとすると、
Auditability は その統治の痕跡が reconstructible である性質 である。

Auditability と Provenance の関係

この二つは近いが同じではない。

Provenance

主に item や output の lineage を追う。

例:

この summary はどの source から来たか
この memory item はどの delta に由来するか

Auditability

それに加えて、

誰がそれを current と採用したか
どの approval / eval / promotion を経たか
何が omitted / invalidated されたか
どの continuity event を経たか

まで扱う。

言い換えると、
provenance は auditability の重要な一部だが、auditability 全体ではない。

Auditability と Context Selection / Compaction の関係

PCE 2.0 の文脈では、
Context Selection や Compaction も監査対象であることが重要である。

なぜか

approval、evaluation、memory promotion の判断は、
active context に何が入っていたかに影響されるからである。

audit 可能であるべきこと

selection purpose は何だったか
mandatory core は何だったか
何を active に選んだか
何を by-reference に回したか
何を omitted したか
omission は stale / irrelevant / hidden / duplicate のどれだったか
freshness / invalidation 条件は何だったか

これは「全部の omitted token を残せ」という意味ではない。
しかし少なくとも、governance-relevant omission は traceable であるべきである。

Auditability と Approval / Evaluation / Memory Writing の関係

Approval

approval が監査可能であるためには、少なくとも次が必要である。

approver
authority basis
subject
evidence bundle
verdict
next transition effect

Evaluation

evaluation が監査可能であるためには、少なくとも次が必要である。

evaluator
subject
contract / criteria
evidence refs
verdict
invalidation conditions

Memory Writing

memory writing が監査可能であるためには、少なくとも次が必要である。

writer
source candidate or delta
target collection / zone / status
eval / approval preconditions
dedup / supersession decision
resulting durable item ref

この三つが weak だと、
Corrupt Success や durable-state pollution が起きやすい。

Auditability と Handoff / Recovery / Rollback の関係

Handoff

handoff では次が追える必要がある。

source / target
transferred / retained responsibilities
evidence bundle
pending gates
expected next action
stale conditions

handoff loss を後から検証するには、handoff 自体が audit 可能でなければならない。

Recovery

recovery では次が追える必要がある。

どの recovery point を使ったか
どの integrity / drift check をしたか
どの context を invalidated したか
どの next transitions を reopened したか

Rollback

rollback では次が追える必要がある。

何を invalid にしたか
どの anchor に戻したか
material rollback か semantic rollback か
post-rollback path は何か

これらはすべて、future process の説明可能性に直結する。

Auditability と Parent-Child / Branch-and-Join の関係

親子や分岐・合流では、
「どこで何が current continuation になったのか」が特に複雑になる。
そのため auditability の要求が強くなる。

Parent-Child で必要なこと

child が何を返したか
親が何を retain していたか
子の local approval を親がどう扱ったか
child failure が親へどう波及したか

Branch-and-Join で必要なこと

どの branch returns を使ったか
どの branch が optional / required だったか
conflict をどう解いたか
選ばれなかった branch をどう扱ったか
join 結果を誰が ratify したか

これが追えないと、later な rollback や learning が非常に難しくなる。

Auditability は “何を記録するか” と “何に答えられるか” の両方で測る

PCE 2.0 では、auditability は二つの側面から見るとよい。

1. Record Availability

必要な records があるか。

例:

approval records
evaluation records
promotion decisions
rollback notes
context selection records

2. Query Answerability

その records を使って、governance-relevant な問いに答えられるか。

例:

なぜこの item が current なのか
なぜ old approval は無効なのか
なぜこの summary が active context に使われたのか
なぜこの memory candidate は canonical ではなく provisional なのか
なぜ recover 後に recompile が必要だったのか

records があっても query answerability が弱ければ、auditability は不十分である。

Auditability と Data Minimization

PCE 2.0 において auditability は full-retention 主義を意味しない。
むしろ、次の緊張関係を扱う必要がある。

全部残す
→ query は答えやすいが、ノイズ・機密・保守コストが大きい
何も残さない
→軽いが、later explanation と correction ができない

したがって auditability は、
必要最小限の traceability を保つ data minimization
として設計されるべきである。

典型手法

raw content は by-reference
summarized claims には provenance refs
sensitive payload は redacted handle
omission class は残すが全文は持たない
supersession relation は残すが old full artifact は external ref にする

つまり auditability は、
保存量の最大化ではなく 説明可能性の最小十分化 と言える。

何を audit record にすべきか

PCE 2.0 では、少なくとも次の kinds の record を持てるとよい。

1. Transition Record

誰が何の遷移を行い、何が変わったか。

2. Approval Record

どの subject を、どの authority で、どの verdict で ratify したか。

3. Evaluation Record

どの subject を、どの contract / criteria で、どの evidence に基づいて判定したか。

4. Promotion / Memory Write Record

何をどの collection に、どの status で、どの rule のもとで書いたか。

5. Context Selection / Compaction Record

何を active にし、何を omit / by-reference にしたか。

6. Handoff Record

誰から誰へ、何を、どの pending gates とともに渡したか。

7. Recovery / Rollback Record

どの anchor / recovery point / invalidation を使って continuity を戻したか。

8. Supersession / Retraction Record

何が current ではなくなり、何がそれを置き換えたか。

Auditability の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

audit_record:
  record_id:
  frame_id:
  kind:
    # transition | approval | evaluation | promotion | memory_write | handoff | recovery | rollback | context_selection | compaction | supersession | retraction
  subject_refs:
  actor_ref:
  bundle_ref:
  authority_basis:
  evidence_refs:
  contract_refs:
  input_refs:
  omissions:
  state_effects:
    lifecycle_changes:
    gate_changes:
    delta_changes:
    durable_state_changes:
    invalidations:
  result:
    verdict:
    resulting_refs:
  freshness:
  timestamp:
  provenance:

query 単位で見るなら、次のような補助構造も有用である。

audit_query_capability:
  frame_ref:
  can_answer:
    - who_did_this
    - under_what_authority
    - based_on_what_evidence
    - what_changed
    - what_was_omitted
    - what_became_invalid
    - why_this_is_current
    - what_was_pending_then
  source_record_refs:

このスキーマで重要なのは、次の点である。

kind ごとに subject と authority がある
evidence refs がある
omissions と invalidations を持てる
lifecycle / gate / delta / durable state の effect を分けて持てる
provenance と timestamp がある

つまり auditability は、
誰が何をしたか だけではなく、
何が current truth になり、何が捨てられ、何が無効になったか
を追える構造を持つべきである。

小さな例

feature.checkout.coupon-combination frame で、code review approval の後に later rollback が入ったケースを考える。

audit_record:
  record_id: audit.approval.code-review.2026-03-09-01
  frame_id: feature.checkout.coupon-combination
  kind: approval
  subject_refs:
    - delta_item.code_patch
  actor_ref: reviewer
  bundle_ref: reviewer_bundle_v1
  authority_basis:
    - approval_authority_for_code_change
  evidence_refs:
    - code_diff_ref
    - ci_report_ref
    - approved_spec_summary_ref
    - rollback_note_ref
  contract_refs:
    - eval.feature.checkout.coupon-combination.artifact.v1
  input_refs:
    - handoff.impl-to-review.v1
  omissions:
    by_reference:
      - full_implementation_trace_ref
  state_effects:
    lifecycle_changes:
      - pending_approval -> completion_ready
    gate_changes:
      - code_review_approval: satisfied
    delta_changes:
      - delta_item.code_patch: approval_attached
    durable_state_changes: []
    invalidations: []
  result:
    verdict: approve
    resulting_refs:
      - review_approval_record_ref
  freshness:
    invalidated_by:
      - code_diff_changes
      - approved_spec_changes
  timestamp: 2026-03-09T10:45:00Z
  provenance:
    source_transition: approve.code-review

後に scope violation が見つかり rollback した場合:

audit_record:
  record_id: audit.rollback.scope-violation.2026-03-09-02
  frame_id: feature.checkout.coupon-combination
  kind: rollback
  subject_refs:
    - delta_item.code_patch
    - review_approval_record_ref
  actor_ref: product_owner
  bundle_ref: product_owner_goal_incident_bundle
  authority_basis:
    - goal_ownership
    - incident_ownership
  evidence_refs:
    - scope_violation_note_ref
    - code_diff_ref
    - approved_spec_summary_ref
  contract_refs: []
  input_refs:
    - escalation.scope-conflict.v1
  omissions: {}
  state_effects:
    lifecycle_changes:
      - completion_ready -> rollback_pending
    gate_changes:
      - code_review_approval: invalidated
    delta_changes:
      - delta_item.code_patch: invalid
    durable_state_changes: []
    invalidations:
      - review_approval_record_ref
      - reviewer_review_context_v1
  result:
    verdict: rollback_ordered
    resulting_refs:
      - rollback_note_ref
      - recovery_point_after_rollback_ref
  freshness: {}
  timestamp: 2026-03-09T11:05:00Z
  provenance:
    source_transition: rollback.scope-violation

この例で重要なのは、後から次の問いに答えられることだ。

なぜ一度 merge-ready になったのか
なぜ later rollback されたのか
どの approval が now-invalid か
何が current truth ではなくなったのか

これが答えられないなら、current state は説明できない。

Auditability の不変条件

PCE 2.0 では、少なくとも次の不変条件を置ける。

1. No governance-relevant mutation without attributable trace

approval、promotion、rollback、resume、retract などの governance-relevant mutation は、誰が何の authority で行ったか追えなければならない。

2. No current truth without explainable lineage

current durable item は、どの delta / eval / approval / write から来たか説明できなければならない。

3. Omission must not be invisible when it affects judgment

selection / compaction の omission が judgment や progression に影響するなら、その omission は traceable でなければならない。

4. Invalidation and supersession must be explicit

old approval、old eval、old memory item、old branch return が current でなくなったなら、その理由が分からなければならない。

5. Auditability does not require storing everything

必要な問いに答えられる限り、by-reference、redaction、summary は許される。
ただし explanation が壊れてはならない。

6. Recovery and rollback must remain auditable

later recovery や rollback が current state を変える以上、その path は traceable でなければならない。

7. Auditability must span actor, gate, and state

誰がやったかだけでなく、どの gate を通り、何の state が変わったかまで追えるべきである。

8. Auditability must survive phase changes

phase が変わっても、old decision の currentness と invalidity を追える必要がある。

いつ Auditability を強めるべきか

次の条件があるなら、auditability の要求を高めるべきである。

1. 高リスク変更

merge failure や rollback cost が高い場合。

2. memory promotion が多い場合

future process への影響が大きく、durable-state pollution のコストが高い。

3. long-running / multi-session process

later reconstruction の必要が高い。

4. multi-actor / multi-branch topology

誰が何を決めたか、どの branch を使ったかが複雑になる。

5. incident-prone process

rollback、replan、resume の traceability が重要になる。

6. policy / compliance sensitivity が高い場合

authority basis、visible/hidden rationale、approval path の説明責任が重くなる。

短く言えば、
risk、durability、multi-actor性、continuity要求が高いほど、auditabilityも強く設計すべき
である。

最低限の自己点検

ある process が auditability を十分に持っているかは、次で点検できる。

誰が何をしたか追えるか
その authority basis を追えるか
何を evidence にして判断したか追えるか
何が current truth になったか追えるか
何が invalid / superseded になったか追えるか
pending gates や continuity events を後から再構成できるか
selection / compaction による omission を説明できるか
rollback / recovery / replan の path を説明できるか
approval / evaluation / memory writing を混同せずに追えるか
すべてを保存せずとも必要な問いに答えられるか

このどれかが欠けるなら、その process はまだ十分に audit 可能ではない。

暫定的なまとめ

Auditability が言っていることは、最終的には次の一文に集約できる。

process を本当に統治するとは、今うまく動いていることだけでは足りない。
誰が、何を、どの authority と evidence で行い、何を current truth として採用し、何を無効化し、何を omit したのかを、後から再構成できてはじめて統治できる。

PCE 2.0 において auditability は、単なる compliance log ではない。
それは、process の current reality を explanation 可能にし、rollback・recovery・memory discipline・governance tuning を可能にする基盤である。

だから Auditability は、単なる「後で見るための記録」ではない。
それは、PCE 2.0 において いまの状態がなぜ current なのかを説明し続けるための governance property である。