仕様

Faying Protocol/1.0 — §3 Components and Interfaces

プロトコル本文ナビ：章目次 ｜ 前章 §2 アーキテクチャ ｜ 次章 §4 データモデル

§3 Components and Interfaces

プロトコル層には 6 つの中核コンポーネントがある。**Mandate Service（MS）/ Presence Channel（PC）/ Attestation Chain（AC）/ Revocation Registry（RR）/ Liveness Channel（LC）/ Behavior Baseline Service（BBS）**である。各コンポーネントは以下の 3 部分に分けて説明する。

  • 責務：プロトコルにおけるコンポーネントの位置と境界。
  • TypeScript インターフェースの骨格：人間向けビュー（Non-normative）。権威定義は §4 Data Models と §5 Protocol Messages を参照。
  • 不変条件：プロトコル層が常に満たさなければならないハード制約。各不変条件は §Requirements 中の少なくとも 1 つの EARS 細目条項まで追跡できる。

EARS 追跡の説明：本章の各不変条件の後ろに、対応する EARS 細目条項番号を Trace: として列記する（出典は本仕様の要件ベースライン）。形式は R<requirement>.<criterion>.<clause> である。

§3.0 共有型の前方宣言（Non-normative）

本章の TypeScript インターフェースブロックが単独で tsc --noEmit を通過できるよう、下記のコードブロックは本章が参照する補助型を最小骨格の形で前方宣言する。これらの型の権威定義は §4 Data Models を参照のこと。

// §3.0 — Non-normative forward declarations.
// Authoritative definitions live in §4 Data Models.

export type IsoTime = string;
export type MandateId = string;
export type FayID = string;
export type HumanPrimeID = string;
export type DeviceId = string;

export type AuthorizationGrade = "G0" | "G1" | "G2" | "G3" | "G4";

export interface Scope {
  readonly domains: readonly string[];
  readonly actions: readonly string[];
  readonly terminals?: readonly string[];
  readonly budget?: ResourceBudget;
}

export interface ResourceBudget {
  readonly max_calls_per_minute?: number;
  readonly max_bytes_per_call?: number;
}

export interface Grade {
  readonly value: AuthorizationGrade;
  readonly autonomy: number; // 数値が大きいほど自律性が高い（G0 が最低、G4 が最高）
}

export interface PresenceRequirement {
  readonly signal_types: readonly PresenceSignalType[];
  readonly max_staleness_ms: number;
  readonly on_loss: "downgrade" | "suspend";
}

export type PresenceSignalType =
  | "webauthn-uv-fresh"
  | "face-continuous"
  | "fingerprint-tap"
  | "presence-heartbeat-only"
  | "intent-ticket";

export interface SignatureBundle {
  readonly alg: string;
  readonly hash: string;
  readonly sig: Uint8Array;
  readonly chain?: readonly SignatureBundle[];
}

export interface Endorsement {
  readonly enabled: boolean;
  readonly endorsed_scope: Scope;
  readonly endorsed_grade: Grade;
  readonly endorsed_lifetime_ms: number;
  readonly offline_revocation_policy:
    | "stop-and-audit"
    | "stop-only"
    | "graceful-stop";
  readonly start_at?: IsoTime;
}

export interface Mandate {
  readonly mandate_id: MandateId;
  readonly issuer: HumanPrimeID;
  readonly subject: FayID;
  readonly scope: Scope;
  readonly grade: Grade;
  readonly presence_req: PresenceRequirement;
  readonly device_id?: DeviceId;
  readonly not_before: IsoTime;
  readonly not_after: IsoTime;
  readonly parent?: MandateId;
  readonly endorsement?: Endorsement;
  readonly signature_bundle: SignatureBundle;
}

export interface PresenceSignal {
  readonly mandate_id: MandateId;
  readonly signal_type: PresenceSignalType;
  readonly nonce: Uint8Array;
  readonly produced_at: IsoTime;
  readonly device_attestation: Uint8Array;
  readonly challenge?: Uint8Array;
  readonly challenge_response?: Uint8Array;
  readonly signature_bundle: SignatureBundle;
}

export interface PresenceVerdict {
  readonly accepted: boolean;
  readonly verdict: "ok" | "stale" | "replay" | "attestation-invalid";
  readonly recommended_next_grade?: AuthorizationGrade;
}

export interface PresenceAck {
  readonly accepted: boolean;
  readonly mandate_id: MandateId;
  readonly observed_at: IsoTime;
}

export interface PresenceState {
  readonly mandate_id: MandateId;
  readonly last_freshness: IsoTime;
  readonly stale: boolean;
  readonly active_signal_types: readonly PresenceSignalType[];
}

export interface BootstrapRequest {
  readonly subject: FayID;
  readonly scope: Scope;
  readonly grade: Grade;
  readonly presence_req: PresenceRequirement;
  readonly not_before: IsoTime;
  readonly not_after: IsoTime;
  readonly human_witness: Uint8Array; // WebAuthn assertion
  readonly endorsement?: Endorsement;
  readonly faying_request_ref?: string;
}

export interface GradeSwitchRequest {
  readonly mandate_id: MandateId;
  readonly target_grade: Grade;
  readonly current_grade: Grade;
  readonly human_witness?: Uint8Array;
  readonly reason: string;
}

export interface DelegateRequest {
  readonly parent_mandate_id: MandateId;
  readonly child_subject: FayID;
  readonly child_scope: Scope;
  readonly child_grade: Grade;
  readonly device_id?: DeviceId;
  readonly not_before: IsoTime;
  readonly not_after: IsoTime;
}

export type RevokeReason =
  | "human-initiated"
  | "expiry"
  | "task-completed"
  | "human-prime-unreachable"
  | "ego-deviation"
  | "fay-credential-invalid"
  | "human-prime-credential-invalid"
  | "regulatory-order"
  | "terminal-disconnected";

export interface RevokeRequest {
  readonly mandate_id: MandateId;
  readonly reason: RevokeReason;
  readonly cascade: boolean;
  readonly human_witness?: Uint8Array;
}

export interface RevokeReceipt {
  readonly mandate_id: MandateId;
  readonly reason: RevokeReason;
  readonly revoked_at: IsoTime;
  readonly cascade_targets: readonly MandateId[];
  readonly signature_bundle: SignatureBundle;
}

export interface RevocationStatus {
  readonly mandate_id: MandateId;
  readonly revoked: boolean;
  readonly revoked_at?: IsoTime;
  readonly reason?: RevokeReason;
  readonly observed_at: IsoTime;
}

export interface ScopeFilter {
  readonly subjects?: readonly FayID[];
  readonly issuers?: readonly HumanPrimeID[];
}

export interface Subscription {
  readonly subscription_id: string;
  readonly close: () => void;
}

export interface AtomicAction {
  readonly action: string;
  readonly target?: string;
  readonly sensitivity: "low" | "normal" | "high" | "critical";
}

§3.1 Mandate Service（MS）

責務：Human Prime を代表して Mandate のライフサイクル全体を管理する（発行 / 更新 / 降格 / 撤回）。Faying Action の唯一の正当な入口である。

インターフェース（Non-normative）：

export interface MandateService {
  /** Faying Action の唯一の正当な入口 */
  bootstrap(req: BootstrapRequest): Promise<Mandate>;

  /** 在場信号のキャリブレーション。現在の Mandate がなお有効か / 降格すべきかを返す */
  verifyPresence(
    mandateId: MandateId,
    signal: PresenceSignal
  ): Promise<PresenceVerdict>;

  /** グレード切り替え：昇格は HP の見証が必須。降格はプロトコルが自動トリガー可 */
  switchGrade(req: GradeSwitchRequest): Promise<Mandate>;

  /** デバイス横断の派生：親 Mandate から子 Mandate を派生。scope ⊆ 親 scope、grade ≤ 親 grade */
  delegate(req: DelegateRequest): Promise<Mandate>;

  /** 対称的な撤回：到達性は必ず ≥ bootstrap */
  revoke(req: RevokeRequest): Promise<RevokeReceipt>;
}

主要な不変条件：

  • I-MS-1（HP に錨を打った Bootstrap）：bootstrap() のリクエスト側は検証可能な HP attestation（既定の形態は WebAuthn のユーザー在場アサーション）を携えなければならない。「MS が自ら bootstrap を決定する」あるいは IF / SA が HP に代わって認可確認を完了する正当な経路は存在しない。

    • Trace：R1.3.1（HP が能動的に発起するときは検証可能な明確な認可確認を提示）、R1.3.5（IF / MS / SA が HP に代わって Faying の認可確認を完了する経路を提供しない）。

  • I-MS-2（昇格方向での HP 見証の強制）：switchGrade() は target.autonomy > current.autonomy のときに限り、検証可能な human_witness を携えなければならない。欠落または署名検証失敗はすべて E_HUMAN_WITNESS_REQUIRED とし、かつ IF はグレード昇格を自律的に発起してはならない。

    • Trace：R7.1.1（child.scope ⊆ parent.scope の収束——グレード昇降意味論に含意される非拡張制約。降格の単調性原則と整合）、R5.1.1（presence_req に基づく受理前提条件。switchGrade が presence_req フィールドを書き込んだ後に RP が検証する根拠）。
    • 備考：本不変条件は R6.1（昇格には必ず HP の見証）によっても権威的にカバーされる。本章が列挙する EARS 追跡は、本タスクで宣言された Requirement 集合内の関連条項のみを取る。

  • I-MS-3（撤回可視性の予算）：revoke() が RR によって publish されれば、以降すべての RP の query に対し RevocationVisibilityBudget（既定 1s、grade で締める、詳細は §6 / 付録 B）を超えない時間内に必ず revoked を返さなければならない。MS は「楽観的な通過」経路を提供してはならない。

    • Trace：R4.2.1（撤回可視性の予算 ≤ RevocationVisibilityBudget）、R4.2.4（StaleBudget 内に確認できなければ → Default-Deny）。

  • I-MS-4（派生 scope / grade の厳密な収束）：delegate() が発行する子 Mandate は child.scope ⊆ parent.scope ∧ child.grade.autonomy ≤ parent.grade.autonomy を満たさなければならない。いずれの方向の拡張も E_PROTOCOL で拒否し、かつ子 Mandate の signature_bundle.chain は親 Mandate の副署を携えなければならない。

    • Trace：R7.1.1（子 scope ⊆ 親 scope）、R7.1.2（子 autonomy ≤ 親 autonomy）。

§3.2 Presence Channel（PC）

責務：Presence Device が生成した物理的な在場信号を、安全に、低遅延で、リプレイ耐性を保って MS へ届け、MS がそれを現在の Mandate に対する「継続的なキャリブレーション」判定へ変換する。

信号タイプ（§7 グレードと整合）：

タイプ強度適用グレード失敗時の降格経路
webauthn-uv-fresh強G1 Strict失敗 → Suspended
face-continuous強G1 Strict失敗 → G2 Moderate へ降格
fingerprint-tap中G2 Moderate失敗 → G3 Loose へ降格
presence-heartbeat-only弱G3 Loose / G4 Autonomous失敗 → Suspended
intent-ticket単回グレード横断の補足単回消費。主グレードに影響しない

インターフェース（Non-normative）：

export interface PresenceChannel {
  /** PD が発起。MS が検証後、対応する Mandate の PresenceState へ書き込む */
  push(signal: PresenceSignal): Promise<PresenceAck>;

  /** RP が呼び出し前に、現在の Presence が新鮮かを照会する */
  query(mandateId: MandateId): Promise<PresenceState>;
}

主要な不変条件：

  • I-PC-1（信号の三つ組強制 + Mandate 側の新鮮度ウィンドウ）：各 PresenceSignal は nonce + produced_at + device_attestation を明示的に携え、Presence_Device が署名しなければならない。新鮮度ウィンドウは信号自身が持つのではなく、対応する Mandate の presence_req.max_staleness_ms が与える（grade に紐づき、HP が BOOTSTRAP で錨を打ち、LivenessDetectionBudget によって grade ごとに締まる）。produced_at + presence_req.max_staleness_ms < now の信号はすべて stale とみなす。

    • Trace：R5.1.3（nonce / produced_at / device_attestation フィールドの強制）、R5.1.4（PC は検証段階で期限切れ信号を拒否）。

  • I-PC-2（同一 nonce の単回消費）：同一 (subject, nonce) は 2 × max_message_lifetime の TTL ウィンドウ内で最大 1 回しか受理されない。重複消費 → E_REPLAY で拒否。

    • Trace：R5.1.1（last_freshness は新鮮度を満たさねばならない——nonce + タイムスタンプのリプレイ耐性意味論が PC 層で落とし込まれることを含意）、R5.1.3（nonce フィールドはリプレイ耐性のプロトコルレベルの掴みどころ）。

  • I-PC-3（在場新鮮度の自動収束）：PresenceState.last_freshness は now − presence_req.max_staleness_ms 以上でなければならない。満たさないとき PC は次の状態遷移を Degraded(grade')（grade'.autonomy < current.autonomy）または Suspended へ遷移させなければならず、元の grade の維持は禁止、自律性のより高い方向への切り替えも禁止。

    • Trace：R5.1.1（受理前提条件 last_freshness ≥ t − max_staleness_ms）、R12.2.2（ハートビートのポーリング周期ではなく新鮮度を通過の根拠とする）。

§3.3 Attestation Chain（AC）

責務：HP → MS → IF → 派生 IF のすべての発行アクションを、逆方向に追跡可能な署名チェーンとして組織し、任意の Mandate がその認可の由来を独立した第三者によって復元できるようにする。

チェーン構造（概念図）：

Root: HP-Public-Key（自己ホスト / WebAuthn 資格情報に錨を打つ）
  └─ MS-Cert（HP が署名し、MS 公開鍵と権限をバインド）
       └─ Mandate M1（MS が署名）
            ├─ Mandate M2（M1 から派生、MS 副署 + 親 Mandate 副署）
            └─ Mandate M3（M1 から派生）

インターフェース（Non-normative）：

export interface AttestationChain {
  /** 葉から根までの完全なチェーンを検証 */
  verify(mandate: Mandate): Promise<AttestationVerifyResult>;

  /** チェーン上のイベントを 1 件追記（Bootstrap / GradeSwitch / Delegate / Revoke） */
  append(event: AttestationEvent): Promise<void>;

  /** 指定 Mandate の責任引き受け端を復元 */
  resolveAccountableParty(mandateId: MandateId): Promise<HumanPrimeID>;
}

export interface AttestationVerifyResult {
  readonly verified: boolean;
  readonly root: HumanPrimeID;
  readonly invalid_node?: string;
}

export interface AttestationEvent {
  readonly event_type: "bootstrap" | "grade-switch" | "delegate" | "revoke";
  readonly mandate_id: MandateId;
  readonly issuer: HumanPrimeID;
  readonly subject: FayID;
  readonly ts: IsoTime;
  readonly signature_bundle: SignatureBundle;
}

主要な不変条件：

  • I-AC-1（親署名 + validity window の二重制約）：チェーン上の各ノードは必ずその親ノードが署名し、かつ署名タイムスタンプが親ノードの validity window（[parent.not_before, parent.not_after]）内に収まらなければならない。いずれかを満たさなければ E_ATTESTATION_INVALID とし、対応する Mandate の Revoke をトリガーする。

    • Trace：R3.1.2（葉から根まで検証、親ノードの validity window 内のタイムスタンプ）、R3.1.3（いずれかのノードの失効を E_ATTESTATION_INVALID で拒否し Revoke をトリガー）。

  • I-AC-2（チェーンの完全性、一つも欠けてはならない）：チェーン検証は葉から根まですべて通過しなければならない。いずれかのノードの欠落または署名無効は信頼不能とみなし、チェーン全体が verified = false を返す。

    • Trace：R3.1.1（Bootstrap / GradeSwitch / Delegate / Revoke の 4 種イベントはチェーンに入らなければならない）、R3.1.2（チェーン検証はすべてのノードが有効なときに限り verify = true を返す）。

  • I-AC-3（派生収束はチェーン上で逆方向に緩められない）：派生の過程で、子ノードの scope と grade.autonomy は単調に収束しなければならない。scope を緩めたり autonomy を引き上げたりする派生ノードには、正当なチェーン上の署名経路が存在しない。

    • Trace：R7.1.1（子 scope ⊆ 親 scope）、R7.1.2（子 autonomy ≤ 親 autonomy）。

§3.4 Revocation Registry（RR）

責務：リアルタイム撤回状態サービス。「撤回の到達性 ≥ 確立の到達性」という対称性原則の工学的支点を担う。

二重経路設計：

  • pull：RP が呼び出しを受理するたびに短ポーリングを実行する（OCSP-like、stapling を推奨）。
  • push：MS が撤回後、購読済みのすべての RP へプッシュを発する（WebSocket / SSE / MQTT）。
  • 保守的 fallback：RP が StaleBudget（既定 5s、grade で締める）以内に RR 状態を確認できなければ、当該呼び出しを Default-Deny で拒否しなければならない。

インターフェース（Non-normative）：

export interface RevocationRegistry {
  publish(receipt: RevokeReceipt): Promise<void>;
  query(mandateId: MandateId): Promise<RevocationStatus>;
  subscribe(rpId: string, scope: ScopeFilter): Subscription;
}

主要な不変条件：

  • I-RR-1（撤回は発行と同時に可視）：撤回はいったん publish() が完了すれば、以降すべての query() に対し RevocationVisibilityBudget（既定 1s、grade で締める）以内に直ちに revoked = true を返さなければならず、強整合の意味論を呈する。

    • Trace：R4.2.1（RevocationVisibilityBudget 以内に query が revoked を返す）。

  • I-RR-2（到達不能 → Default-Deny）：RR が StaleBudget 内に到達不能なとき、RP は E_RR_UNAVAILABLE で呼び出しを拒否しなければならず、「楽観的な通過」を禁止する。

    • Trace：R2.1.4（StaleBudget 内に到達不能 → Default-Deny + E_RR_UNAVAILABLE）、R4.2.4（RP は状態確認に失敗したとき Default-Deny で処理する）。

意味論の境界：RR 到達不能 ≠ iFay 自身の連絡途絶。RR 到達不能は「Mandate が撤回されたか否かを判定できない」ことのみを表し、E_RR_UNAVAILABLE 拒否をトリガーする。iFay の連絡途絶（Actually-Disconnected / Perceived-Disconnected を含む）は §3.5 Liveness Channel と PresenceState が単独で描く。この 2 種の連絡途絶イベントは互いに代替しない——「iFay はオンラインだが RR が到達不能」「RR はオンラインだが iFay が連絡途絶」という 2 つの直交した組み合わせが存在し、プロトコル層はいずれも Default-Deny に収束させる。

§3.5 Liveness Channel（LC）

責務：低オーバーヘッドのハートビート + 在場新鮮度を組み合わせ、MS / RP / HP の視点における iFay_Instance の「知覚活性」を判定し、「真の活性」と「知覚活性」との間の不一致ウィンドウをプロトコル層の一級市民として明示的に描く。

二重意味論の定義：

  • Actually-Disconnected（真の連絡途絶）：iFay_Instance のプロセス / ネットワーク / デバイスがすでに停止しているか、いかなる外部主体からも到達不能になっている状態。客観的な物理的事実であり、プロトコル層が直接観測することはできない。
  • Perceived-Disconnected（知覚上の連絡途絶）：MS / RP / HP の視点において、直近の Presence_Signal、ハートビート、RR プッシュ状態に基づき、iFay_Instance が連絡途絶したと判定すること。プロトコル層が決定の根拠とできる唯一の意味論。

2 種の不一致ウィンドウ：

  • ウィンドウ A — Actually-Disconnected ∧ Perceived-Connected：iFay は実際にはすでに切れているが、直近の Presence_Signal はなお max_staleness_ms 以内 → ハートビート間隔内の「観測の死角」。
  • ウィンドウ B — Actually-Connected ∧ Perceived-Disconnected：iFay は実際にはオンラインだが、直近の Presence_Signal がすでに max_staleness_ms を超過（ネットワークのジッタ / ハートビートのパケットロス）→ プロトコル層は悲観的推定で収束する。

悲観的推定の原則（統一収束規則）：

プロトコル層は Perceived-Disconnected のみを決定の根拠とする。「真にはオンラインだが連絡途絶と知覚された」いかなる iFay_Instance も、これを理由にプロトコル層の判定結果を免れることはできない。2 種の不一致ウィンドウ内では、プロトコルは「より厳格な側」に従って処理しなければならず、「より緩い状態に従って処理する」正当な経路は存在しない。

インターフェース（Non-normative、§3.2 PC と下層信号を共有）：

export interface LivenessChannel {
  /** 現在の知覚活性スナップショット */
  perceived(mandateId: MandateId): PerceivedLiveness;

  /** 悲観判定を明示的にトリガー（ハートビート喪失を検知したときなど） */
  declareStale(mandateId: MandateId, reason: string): Promise<void>;
}

export interface PerceivedLiveness {
  readonly is_perceived_connected: boolean;
  readonly last_freshness: IsoTime;
  readonly staleness_ms: number;
  readonly decided_by: "presence-signal" | "heartbeat" | "explicit-declare";
}

主要な不変条件：

  • I-LC-1（新鮮度判定、ハートビートのポーリング周期で通過させることを禁止）：知覚上の連絡途絶判定は last_freshness ≥ now − max_staleness_ms に基づかなければならない。「ハートビートのポーリング周期がまだ来ていない」ことを理由に呼び出しを通し続けることを禁止する。

    • Trace：R12.2.2（ハートビートのポーリング周期ではなく新鮮度判定を通過の根拠とする）。

  • I-LC-2（Disconnected へ入る状態機械遷移）：Perceived-Disconnected と判定されたら、次の状態遷移は §4.3 状態機械に従って遷移しなければならない（Active → Disconnected / Active → Suspended、有効な Endorsed_Mandate か否かに依拠）。元の状態を維持したり、より緩い状態へ切り替えたりする正当な経路は存在しない。

    • Trace：R12.1.3（知覚上の連絡途絶のみをプロトコル層判定の根拠とし、プロトコル層の結果を免れさせない）。

  • I-LC-3（回復は必ずトランザクション的照合を経る）：Perceived-Disconnected から Perceived-Connected への回復は、必ず §8.4 再接続照合（Reconciliation）トランザクションを経なければならず、自動回復を禁止する。

    • Trace：R12.1.3（知覚上の連絡途絶の期間中はプロトコル層の結果を免れさせない——「回復には明示的なトランザクション的確認を要する」ことを含意し、R12.4.1 / R12.4.3 の照合トランザクションと整合。本タスクで宣言された Requirement 集合内では 12.1 に錨を打つ）。

§3.6 Behavior Baseline Service（BBS）

責務：各ペア (Human_Prime, iFay_Instance) に対する累積行為プロファイルを維持する。高機微アクションのベースラインからの有意な逸脱を検知し、逸脱時に追加の人類見証をトリガーするために用いる（詳細は §9.10.6 T5 防護）。

インターフェース（Non-normative）：

export interface BehaviorBaselineService {
  /** 新しいアクションサンプルを 1 件累積 */
  record(sample: BehaviorSample): Promise<void>;

  /** 現在のアクションのベースラインに対する逸脱度を評価 */
  evaluate(
    hp: HumanPrimeID,
    fay: FayID,
    action: AtomicAction
  ): BaselineDeviation;

  /** reputation decay（信頼スコアの減衰）を適用 */
  decay(hp: HumanPrimeID, fay: FayID): Promise<void>;
}

export interface BehaviorSample {
  readonly hp: HumanPrimeID;
  readonly fay: FayID;
  readonly action: AtomicAction;
  readonly scope_used: Scope;
  readonly risk_level: "low" | "normal" | "high" | "critical";
  readonly affected_resources: readonly string[];
  readonly ts: IsoTime;
}

export interface BaselineDeviation {
  readonly exceeds_threshold: boolean;
  readonly dimensions: readonly (
    | "risk_level"
    | "scope_used"
    | "affected_resources"
  )[];
  readonly recommended_action:
    | "allow"
    | "require-extra-witness"
    | "downgrade"
    | "suspend";
}

主要な不変条件：

  • I-BBS-1（信頼スコアは必ず減衰し、かつ上限を持つ）：各ペア (HP, IF) の「信頼スコア」は時間とともに必ず減衰し、明示的な上限を持たなければならない。将来の高機微アクションに必要な人類見証の強度を希釈するための無限累積を禁止する。

    • Trace：R13.5.3（Action Reputation Decay：信頼スコアは必ず減衰し、明示的な上限を持つ）。

  • I-BBS-2（ベースライン超過の見証イベントはチェーンに入り + HP ビューへプッシュ）：「ベースライン超過で追加見証をトリガー」する各イベントは Attestation_Chain へ書き込み、Human_Prime ビューチャネルへプッシュしなければならない。追加見証を得る前は E_HUMAN_WITNESS_REQUIRED で当該呼び出しを拒否する。

    • Trace：R13.5.4（「ベースライン超過で追加見証をトリガー」イベントを AC へ書き込み + HP ビューへプッシュ）、R13.5.2（追加見証を得る前は E_HUMAN_WITNESS_REQUIRED で拒否）。

  • I-BBS-3（算出基準の変更も監査イベント）：ベースライン算出基準そのものは、いったん確定すれば Attestation_Chain へ書き込まれる。基準の変更は独立した一類の監査イベントとみなし、プロトコル委員会が既定のプロセスに従って承認する。

    • Trace：R13.5.1（MS が Behavior_Baseline を維持）、R3.1.1（いずれかの監査イベントが処理されるとき AC はその署名ノードを含まねばならない。本章が列挙する EARS 追跡は、本タスクで宣言された Requirement 集合内の関連条項のみを取る）。