docs/protocol-v1.md

# MISAKA PALW Receipt Protocol V1

本書は `runtime-palw` の現行 Rust 実装を wire protocol の正本として記述する。ここにない
production 承認、決済連携、attestation を Receipt から推論してはならない。実装と本書が
一致しない場合は Receipt を発行しない。

## 1. Primitive types

- `Hash32`、commitment、ID、`NetworkId`: 固定 32 byte
- `u16` / `u32` / `u64` / `i64`: big endian。`i64` は two's-complement
- `bool`: `u8(0)` または `u8(1)`
- enum: variant tag `u8` の後に variant 固有 payload
- Ed25519 public key: 32 byte、signature: 64 byte、algorithm tag: `0`
- `Option<T>`: `u8(0)`、または `u8(1) || encode(T)`

`NetworkId` は UTF-8 名ではなく `Hash32` である。consensus encoding へ `usize`、float、map、
JSON text、platform enum、暗黙の default を直接入れない。

Receipt、scheduler message、future beacon、canary precommit、bond/external authority evidenceのEd25519
verificationは`verify_strict`を使う。small-order/weak public keyはworker signer、scheduler、beacon、bond、
external authorityのregistry recordとして拒否し、key IDが一致してもauthorization identityとして扱わない。

## 2. Canonical encoding

```text
LP(x)       = u64be(len(x)) || x
bytes(x)    = LP(x)
string(s)   = LP(utf8(s))
vector(xs)  = u64be(count(xs)) || encode(xs[0]) || ...
```

固定長 hash は LP を付けず 32 byte を直接書く。struct は本書に記した順で field を連結する。
decoder は未知の version/tag、truncated/trailing bytes、invalid UTF-8、非canonical bool/option、
上限超過を拒否し、decode 後の再encodeが入力と一致しなければ拒否する。現行 reader の blob
上限は 64 MiB、item count 上限は 16,777,216 である。

## 3. Domain-separated hash

```text
H(tag, part_0, ..., part_n) = SHA3-256(
    LP("MISAKA/PALW") ||
    LP(utf8(tag)) ||
    u16be(schema_version) ||
    LP(part_0) || ... || LP(part_n)
)
```

part count 自体は入らないが、すべての part が LP されるため partition は曖昧にならない。
raw concatenation と domain の流用は禁止する。core V1 が使用する domain は次のとおり。

```text
model-artifact-leaf/v1    model-artifact-node/v1
model-profile/v1          runtime-class/v1          runtime-manifest/v1
shape-profile/v1          cu-ruleset/v1
job-request/v1            assignment/v1             signer-key/v1
prompt/v1                 output/v1                 owner/v1
job-nullifier/v1          execution-nullifier/v1
schedule-init/v1          schedule-step/v1           schedule-final/v1
gemm-trace-scheme/v1      gemm-trace-init/v1         gemm-trace-step/v1
gemm-trace-final/v1
receipt-body/v1           receipt-id/v1              receipt-signature/v1
replica-match/v1          pair-id/v1
future-beacon/v1          audit-policy/v1
audit-selection/v1        audit-challenge/v1
audit-replay-result/v1    audit-replay-submission/v1
work-ticket/v2            local-maturity-basis/v2    canary/v1
canary-precommit/v1       durable-slash-offense/v2   bond-release/v1
bond-funding-attestation/v1  slash-appeal/v1         slash-decision/v1
slash-default-uphold/v1   external-escrow/v1         external-payment-command/v1
external-funding-attestation/v1  external-demand-weight-grant/v1
external-terminal-confirmation/v1
llama-cuda-dispatch/v1    cuda-kernel-entry/v1
verification-bundle-receipt/v1   verification-bundle-public/v1
verification-bundle-aad/v1       verification-bundle-aead-key/v1
verification-bundle-id/v1
```

`request/v1` は generic helper `commit_request` に残るが、署名済み `JobRequestV1` の ID には
使用しない。job request の唯一の domain は `job-request/v1` である。deterministic policy と
Qwen Metal profile はさらに `lora-set/v1`、`control-vector-set/v1`、
`thinking-policy/v1`、`workspace-policy/v1`、`thread-policy/v1`、
`qwen-native-observer-mapping/v1` 等の artifact domain を runtime identity の内側で使う。

## 4. Artifact and model identity

artifact は slash-separated relative path の辞書順で処理する。空、absolute、末尾 `/`、空要素、
`.`、`..`、backslash、非UTF-8、重複、symlink、非regular file は拒否する。

```text
leaf_i = H(
    "model-artifact-leaf/v1",
    utf8(relative_path_i),
    u64be(file_size_i),
    file_bytes_i
)
```

file は streaming hash するが上式と同じ framing である。各 level の leaf/node が奇数なら
末尾を複製し、`H("model-artifact-node/v1", left, right)` で二分木を作る。artifact は空に
できない。

`ModelProfile` canonical order:

1. `architecture: string`
2. `base_repository: string`
3. `immutable_revision: string`
4. `topology: u8` (`0=Dense`, `1=MixtureOfExperts`)
5. `tokenizer: string`
6. `weight_artifact_root: Hash32`
7. `tokenizer_artifact_root: Hash32`
8. `chat_template_digest: Hash32`
9. `special_tokens_digest: Hash32`
10. `hidden_size: u32`
11. `attention_heads: u32`
12. `kv_heads: u32`
13. `head_dim: u32`
14. `layer_count: u32`
15. `intermediate_size: u32`
16. `rope: string`
17. `rope_theta: u64`
18. `rope_scaling_millionths: u64`
19. `native_context_tokens: u32`
20. `vocabulary: u32`
21. `precision: string`

```text
model_profile_id = H("model-profile/v1", encode(ModelProfile))
```

全 string、artifact hash、次元、RoPE integer parameter は nonzero/nonempty でなければならない。
`hidden_size / attention_heads == head_dim`、`attention_heads % kv_heads == 0` も検査する。
Q4 GGUF は fixed inference artifact であり、学習済み base revision と量子化 artifact の双方を
profile に bind する。

## 5. Runtime class, deterministic policy, and manifest

`BackendKind` canonical encoding:

- `0=CUDA`: `cuda_version, driver_version, cublas_version, sm_architecture`（各 string）、
  `cublas_policy_digest: Hash32`
- `1=Metal`: `metal_version, driver_build, gpu_family, language_version`（各 string）、
  `metallib_digest: Hash32`
- `2=CPU`: `isa_class, blas_version`（各 string）、`affinity_policy_digest: Hash32`

`TraceCapability`: `0=None`, `1=GraphFallback`, `2=KernelSketch`。

`RuntimeClass` canonical order:

1. `backend: BackendKind`
2. `runtime_version: string`
3. `runtime_source_repository: string`
4. `runtime_source_commit: string`
5. `runtime_binary_digest: Hash32`
6. `dirty_patch_digest: Hash32`
7. `operating_system: string`
8. `host_architecture: string`
9. `device_class: string`
10. `accelerator_api: string`
11. `compiler_version: string`
12. `build_flags_digest: Hash32`
13. `kernel_binary_digest: Hash32`
14. `kernel_algorithm_digest: Hash32`
15. `accelerator_count: u32`
16. `tensor_parallel: u32`
17. `split_policy: string`
18. `quantization: string`
19. `kv_cache_precision: string`
20. `flash_attention: bool`
21. `tensor_repack: bool`
22. `context_size: u32`
23. `batch_size: u32`
24. `micro_batch_size: u32`
25. `thread_count: u32`
26. `trace_capability: TraceCapability`
27. `deterministic_policy: DeterministicPolicy`

`DeterministicPolicy` の nested canonical order は
`temperature_millionths:u32, top_p_millionths:u32, top_k:u32, batch_size:u32,
tensor_parallel:u32, parallel_sequences:u32, context_shift_enabled:bool,
speculative_decoding_enabled:bool, dynamic_fit_enabled:bool, random_seed:u64,
kernel_graph_id:Hash32, quantization_artifact_id:Hash32, lora_adapters_digest:Hash32,
control_vectors_digest:Hash32, thinking_policy_digest:Hash32, workspace_policy_digest:Hash32,
thread_policy_digest:Hash32` である。

V1 strict policy は temperature 0、top-p 1,000,000、top-k 0、batch/tensor-parallel/
parallel-sequences各1、context shift/speculative/dynamic fit無効を要求する。

```text
runtime_class_id = H("runtime-class/v1", encode(RuntimeClass))
```

Qwen Metal profile の `kernel_graph_id` は pinned llama.cpp commit、
`qwen_adapter_mapping_id_v1()`、native graph variant、prefill/decode serialization policyを
まとめて hash する。したがって graph-to-CU mapping の変更も runtime class を変更する。

`ShapeProfile` canonical order は `batch_size:u32, max_context_tokens:u32,
max_decode_tokens:u32, max_prefill_tokens:u32`。batch は1、各上限は nonzero、prefill/decode
各上限は context 以下とする。

`RuntimeManifest` canonical order:

1. `manifest_version: u16` (=1)
2. `model_profile: ModelProfile`
3. `runtime_class: RuntimeClass`
4. `shape_profile: ShapeProfile`
5. `model_artifact_digest: Hash32`
6. `model_artifact_size: u64`
7. `runtime_device_digest: Hash32`
8. `loaded_libraries_digest: Hash32`
9. `environment_allowlist_digest: Hash32`
10. `build_provenance_digest: Hash32`
11. `schedule_schema_version: u16` (=1)
12. `trace_schema_version: u16` (=1)
13. `cu_ruleset_id: Hash32`
14. `trace_scheme_id: Hash32`

`model_artifact_digest == model_profile.weight_artifact_root`、batch/context、CU ruleset を相互検査し、
`runtime_manifest_hash = H("runtime-manifest/v1", encode(RuntimeManifest))` とする。

現行Qwen Metal issuanceはtokenizer、observer、host/source identity childのinherited environmentを消去し、
`LANG=C`、`LC_ALL=C`だけを設定する。host/source identity helperはabsolute executable pathを使い、この
exact mapを`environment_allowlist_digest`へbindする。親processの追加environmentはcompute childへ継承しない。

## 6. Scheduler-signed request and assignment

`JobClass`: `0=SelfLocal`, `1=SelfReplicated`, `2=ExternalReplicated`。
`EvidenceLevel`: `0=Wrapper`, `1=RuntimeObserved`, `2=GemmTraced`。replicated class は
`GemmTraced` を要求する。

`ExecutionConstraintsV1` order:

1. `model_profile_id: Hash32`
2. `runtime_class_id: Hash32`
3. `shape_profile_id: Hash32`

`JobRequestV1` canonical order:

1. `version: u16` (=1)
2. `network_id: Hash32`
3. `scheduler_job_id: Hash32`
4. `job_class: JobClass`
5. `prompt_commitment: Hash32`
6. `shared_output_nonce: Hash32`
7. `constraints: ExecutionConstraintsV1`
8. `required_evidence_level: EvidenceLevel`
9. `issued_epoch: u64`
10. `expires_epoch: u64`
11. `external_escrow_reference: Option<Hash32>`

`ExternalReplicated` は nonzero escrow reference が必須、それ以外は `None` が必須。

```text
request_commitment = H("job-request/v1", encode(JobRequestV1))
```

`AssignmentV1` canonical order:

1. `version: u16` (=1)
2. `network_id: Hash32`
3. `request_commitment: Hash32`
4. `scheduler_job_id: Hash32`
5. `job_class: JobClass`
6. `replica_slot: u8`
7. `worker_credential_id: Hash32`
8. `runtime_instance_id: Hash32`
9. `assignment_id: Hash32`
10. `issued_epoch: u64`
11. `expires_epoch: u64`

```text
assignment_commitment = H("assignment/v1", encode(AssignmentV1))
```

assignment は network/request/job/class を request と一致させ、validity interval を request 内へ
包含させる。Self Local は slot 0、replicated は slot 0/1 のみ。

request/assignment envelope は同じ orderを使う。

```text
u16be(envelope_version=1) ||
LP(canonical_body) ||
scheduler_key_id:Hash32 ||
u8(signature_algorithm=0) ||
signature:64-byte
```

signature message はそれぞれ `request_commitment` / `assignment_commitment` そのもの。
`scheduler_key_id = H("signer-key/v1", scheduler_public_key)`。network-scoped registry は key の
valid-from/through、revocation、message epoch、weak-key rejectionを検査し、signatureはstrict Ed25519で
検証する。miner が job ID、nonce、slot、assignment IDを自己生成したものは authorization record に
ならない。現行local Receipt CLIが自己生成するscheduler key/snapshotはfixture boundaryであり、
production scheduler/governance authorizationを表さない。

## 7. Prompt, output, owner, and nullifiers

prompt text は commit しない。tokenizerの正確な prompt token列を次で commit する。

```text
PromptTokens = u64be(count) || concat(u32be(token_id_i))
prompt_commitment = H(
    "prompt/v1", network_id, scheduler_job_id,
    shared_output_nonce, PromptTokens
)
```

`StopReason`:

- `0=EndOfSequence(u32 eos_token_id)`
- `1=LengthLimit`
- `2=ContextLimit`
- `3=StopSequence(Hash32 stop_sequence_digest)`

`Cancelled` variant は存在しない。cancelled execution から Receipt を発行しない。現行request
schemaにはstop-sequence list fieldがないため、`StopSequence` digestが特定requestの設定へbindして
いるかをverifierが別途検査する実装もまだない。

```text
CanonicalOutput =
    u64be(token_count) || concat(u32be(generated_token_id_i)) || encode(stop_reason)

output_commitment = H(
    "output/v1", network_id, job_nullifier,
    shared_output_nonce, CanonicalOutput
)
```

k=2 の両slotは signed request の同じ nonceを使う。nonce、prompt IDs、output IDs、owner salt は
Receipt bodyへ載せず、stateless verifier への private opening とする。

```text
owner_commitment = H(
    "owner/v1", network_id, owner_salt, owner_ed25519_public_key
)

signer_key_id = H("signer-key/v1", owner_ed25519_public_key)

job_nullifier = H(
    "job-nullifier/v1", network_id, scheduler_job_id,
    request_commitment, u8(job_class)
)

execution_nullifier = H(
    "execution-nullifier/v1", job_nullifier, assignment_id,
    u8(replica_slot), worker_credential_id, runtime_instance_id
)
```

owner commitment に worker credential は含めない。registry の `SignerRecord` が public key、
owner commitment、worker credential の対応を供給する。owner salt は registry recordにも含めない。

## 8. Canonical operations and CU

`DType`: `0=Fp32`, `1=Fp16`, `2=Bf16`, `3=Int8`, `4=Int4`。
`QuantizationClass`: `0=None`, `1=Q4K`, `2=Q4KM`, `3=Q5KM`, `4=Q8_0`,
`5=Iq4Xs`, `255=Artifact(Hash32)`。

`GemmShape` order は `m:u32, n:u32, k:u32, batch:u32, dtype:DType,
quantization:QuantizationClass`。

`ComputeOperation` wire tags と payload:

| Tag | Variant | Canonical payload order |
|---:|---|---|
| 0 | `Gemm` | `GemmShape` |
| 1 | `Attention` | `query_tokens:u32, key_value_tokens:u32, heads:u32, head_dim:u32, batch:u32, causal:bool` |
| 2 | `LayerNorm` | `elements:u32, batch:u32` |
| 3 | `RmsNorm` | `elements:u32, batch:u32` |
| 4 | `Rotary` | `tokens:u32, heads:u32, head_dim:u32` |
| 5 | `ExpertRoute` | `tokens:u32, experts:u32, top_k:u32` |
| 6 | `KvCacheRead` | `bytes:u64` |
| 7 | `KvCacheWrite` | `bytes:u64` |
| 8 | `Silu` | `elements:u64` |
| 9 | `ElementwiseMultiply` | `elements:u64` |
| 10 | `Softmax` | `elements:u64` |
| 11 | `ElementwiseAdd` | `elements:u64` |
| 12 | `TensorCopy` | `bytes:u64` |
| 13 | `EmbeddingLookup` | `elements:u64` |

Dense modelでは `ExpertRoute` を拒否する。Qwen adapter mapping V1 は `MUL_MAT`、`RMS_NORM`、
`ROPE`、`SET_ROWS`、`SOFT_MAX`、`GLU`、`MUL`、`CONT`、`ADD`、`GET_ROWS` を上記 operationへ
変換し、`VIEW/RESHAPE/PERMUTE`だけを layout metadata として除外する。その他は fail-closed。

`ComputeUnitRules::v1()` は全variantを integer-only、checked `u128`、明示ceil、minimum 1で
再計算する。ruleset descriptor の hash が `cu_ruleset_id`。observer申告の cost は受け取らない。

## 9. Ordered operation schedule

`ExecutionPhase`: `0=Prefill`、`1=Decode(u32 step)`。
`ScheduledOperation` canonical order:

1. `index: u64`（0から連続）
2. `phase: ExecutionPhase`
3. `layer_id: Option<u32>`（`None` は global LM head 等）
4. `operation: ComputeOperation`

```text
s0 = H("schedule-init/v1", job_nullifier, shape_profile_id, cu_ruleset_id)
si = H("schedule-step/v1", s(i-1), u64be(i), encode(event_i))
schedule_root = H("schedule-final/v1", sn, u64be(event_count))
```

index、chain、decode stepの単調性、model layer range、Dense/MoE制約を verifier が再検査する。
挿入、削除、並べ替えはCU合計が同じでもrootを変える。

## 10. GEMM trace

`TraceEvidenceKind` の wire tag は `0=Absent`, `1=GraphFallback`, `2=KernelSketch`。
`trace_scheme_id_v1` は
`H("gemm-trace-scheme/v1", fixed_scheme_descriptor)` である。

`AccumulatorSketch` は `i64be lane[4]`。`TileIndex` は `m:u32, n:u32, k:u32`。
`GemmTraceEvent` canonical order:

1. `index: u64`
2. `schedule_index: u64`
3. `kernel_sequence: u64`
4. `tile_linear_index: u32`
5. `tile_count: u32`
6. `evidence_kind: TraceEvidenceKind`
7. `phase: ExecutionPhase`
8. `layer_id: Option<u32>`（`None` は global LM head）
9. `kernel_id: Hash32`
10. `shape: GemmShape`
11. `tile: TileIndex`
12. `accumulator_sketch: [i64;4]`

```text
t0 = H("gemm-trace-init/v1", job_nullifier, trace_scheme_id)
ti = H("gemm-trace-step/v1", t(i-1), u64be(i), encode(trace_event_i))
trace_root = H(
    "gemm-trace-final/v1", tn,
    u64be(trace_event_count), u64be(gemm_group_count)
)
```

各scheduled GEMMは1つのcontiguous groupとなる。groupのschedule indexは狭義増加、全event index/
kernel sequenceは0から連続、group内metadataは一致、kernel IDはnonzero、全groupで evidence kindを
混在させない。`GraphFallback` は各GEMM exactly 1 synthetic tile、`KernelSketch` は1個以上の
native tileを許す。trace group数はschedule内GEMM数と一致し、各eventのschedule index、phase、
optional layer、shapeを元scheduleと照合する。

現行 Qwen Metal adapter が発行できる trace は `GraphFallback` だけであり、CUDA claimへ昇格しない。
CUDA C ABIは既存final-output V1 recordに加え、declared origin、accumulator stage/dtype、sketch scheme、
reduction segment、producer variant IDを持つexact 184-byte V2 wire recordを定義する。Rustのstrict
decoder/binderは全unfiltered record streamをexpected launch sequence、schedule、tile/segment order、exact
MMVQ/flash-attention dispatch、CUDA runtime manifestへbindする。raw `ProducerAccumulator`はtransport上の
declared tagにすぎず、`BoundCudaTranscriptV1`はdiagnostic typestateである。
さらにadditive V3は452-byte recordと、FA-off attentionのQK-score MMVF、masked/scaled softmax、
value-aggregation MMVFからなるcanonical 3-sublaunch grouping、strict schedule/runtime binderを実装する。

別のauthority layerはsigned attestationをnetwork/job/execution/assignment、runtime class/manifest、
producer integration、operation schedule、full unfiltered transcriptへexact bindし、public raw constructorを
持たない`AuthorityBoundCudaTranscriptV2`を作る。そこからproducer-accumulator GEMMだけを
`AuthorityBoundCudaReceiptEvidenceV2`へdeterministically射影する。attention
final-output recordはsigned full-transcript commitmentに残すがGEMM evidenceへは昇格しない。

`ComputeReceiptV1`にはauthority provenance commitmentがないため、V1 builderはCUDA
`KernelSketch`の発行を拒否し、workerがV1 bodyを手組み・署名してもverifierが拒否する。standaloneの
true FP32 producer-accumulator採取primitiveはRTX 4060 Ti sm_89でdevice suite 7/7と20/20同一
diagnostic fingerprintを確認した。最終grouped suiteは8/8である。vendored llama.cppのQ4_K/Q6_K MMVQと
FA-off QK/softmax/PV producerも接続済みで、same-backend Qwen 1-token diagnostic E2Eは361/361 record、
3回同一fingerprint、5 work-class rejectionを確認した。ただしproduction Receipt authorityではない。

現行deterministic profileはFA-offで、legacy V2が表すattention dispatchは
`LlamaFlashAttention`だけである。この非互換に対するV3 sublaunch/grouping schema/binderは実装済みだが、
実eager-attention 3-stage hook、361-launch実機E2E、release manifest、Receipt/Bundle/SQLite V2も
実装・検証済みである。live callbackへのauthority-derived canonical expected table接続は未完了である。public headerは
`PALW_CUDA_TRACE_PRODUCTION_CAPABLE=0`、`PALW_CUDA_PRODUCER_VENDOR_RUNTIME_INTEGRATED=0`、
`PALW_CUDA_PRODUCER_RECEIPT_MAPPING_AVAILABLE=0`、`PALW_CUDA_PRODUCER_PRODUCTION_CAPABLE=0`で、production
CMake optionもfailするため、R32は`In progress`でもproduction CUDA `KernelSketch` Receiptを発行してはならない。

## 11. Compute Receipt and signature

`ComputeReceiptV1` は正確に30 fieldで、canonical orderは次のとおり。

1. `receipt_version: u16` (=1)
2. `network_id: Hash32`
3. `request_commitment: Hash32`
4. `scheduler_job_id: Hash32`
5. `signed_assignment_id: Hash32`（assignment body の `assignment_id`）
6. `replica_slot: u8`
7. `model_profile_id: Hash32`
8. `runtime_class_id: Hash32`
9. `runtime_manifest_hash: Hash32`
10. `shape_profile_id: Hash32`
11. `cu_ruleset_id: Hash32`
12. `trace_scheme_id: Hash32`
13. `trace_evidence: TraceEvidenceKind`
14. `operation_schedule_commitment: Hash32`
15. `schedule_event_count: u64`
16. `canonical_compute_units: u64`
17. `prefill_tokens: u32`
18. `decode_tokens: u32`
19. `output_commitment: Hash32`
20. `gemm_trace_root: Hash32`
21. `trace_event_count: u64`
22. `owner_commitment: Hash32`
23. `worker_credential_id: Hash32`
24. `job_nullifier: Hash32`
25. `execution_nullifier: Hash32`
26. `job_class: JobClass`
27. `evidence_level: EvidenceLevel`
28. `timestamp: u64`（informational only）
29. `issued_epoch: u64`
30. `expires_epoch: u64`

body-local evidence invariants:

- `Wrapper`: schedule count、trace count、CUは0、trace kindはAbsent
- `RuntimeObserved`: schedule countとCUはnonzero、trace countは0、trace kindはAbsent
- `GemmTraced`: schedule count、trace count、CUはnonzero、trace kindはnon-Absent
- replicated class: evidence levelはGemmTraced

trace無しでも `gemm_trace_root` は zero ではなく、同jobで初期化した empty trace root である。

```text
body_id = H("receipt-body/v1", network_id, encode(body))
receipt_id = H("receipt-id/v1", network_id, encode(body))
signature_message = H("receipt-signature/v1", network_id, encode(body))
```

`SignedReceiptV1` canonical order:

```text
u16be(envelope_version=1) ||
LP(encode(body)) ||
signer_key_id:Hash32 ||
u8(signature_algorithm=0) ||
ed25519_signature:64-byte
```

現行 `receipt_id` は署名byteを含まず、同じbodyなら同じIDである。signature は worker keyで上記
messageを署名する。verifier は signer registry、scheduler-derived assignment authorization、
manifest、private prompt/output opening、schedule/CU/traceをすべて照合する。signer registryはnonzero
owner/credentialとnon-weak keyだけを受け、Receipt signatureはstrict Ed25519で検証する。

## 12. Stateless verification and durable acceptance

stateless path:

1. signed envelope と body をstrict canonical decode
2. body structure、network、assignment epoch
3. scheduler署名検証済み authorization recordとの全binding
4. worker signer key、owner commitment、credential、Receipt signature
5. model/runtime/manifest/shape/CU/trace identity
6. job/execution nullifier再導出
7. token shape bounds
8. schedule、CU、traceをwitnessから再計算
9. prompt/output private openingとtoken countを再計算

型は `UnverifiedReceipt -> StatelesslyVerifiedReceipt`。その後 `StateStore::accept` が SQLite
transactionで replay/cardinality keyを予約した場合だけ `AcceptedReceipt` になる。Matcher と
canary submission は `AcceptedReceipt` を要求する。first acceptance時のstateless
`verified_at_epoch`をdurable `accepted_at_epoch`として保存する。restart後の`restore_accepted`は新しい
stateless verification epochとoriginal acceptance epochを区別し、canonical signed Receiptとauthorized
runtime instanceがstored rowとexact一致するときだけtypestateを復元する。stored acceptanceはbody
issued/expiry内かつcurrent `verified_at_epoch`以下でなければならず、rollbackを拒否する。

durable storeはapplication ID `PALW`、schema version 4、foreign keys、WAL、`synchronous=FULL`を要求する。
exact table set/column order/foreign-key count/indexに加え、non-internal `sqlite_master`の全
`(type,name,tbl_name,sql)`をcanonical encodeしたSHA3-256 fingerprintをcompiled goldenと照合する。
旧schemaのsilent migrationとobjectを持つunclaimed DBは拒否する。receiptのaccepted epoch、pairのmatched
epoch、signed future beaconのclaimed epoch、audit replayのissued/accepted epochは8-byte big-endian
BLOBとして保存する。beacon verification時のcaller current epochは別columnへ固定せず、restore時の
current `AcceptedReceipt.verified_at_epoch`でregistry validity/revocationとともに再検証する。

## 13. Replica matching

`MatchProjectionV1` canonical order:

1. `job_nullifier`
2. `request_commitment`
3. `job_class`
4. `model_profile_id`
5. `runtime_class_id`
6. `runtime_manifest_hash`
7. `shape_profile_id`
8. `cu_ruleset_id`
9. `canonical_compute_units`
10. `prefill_tokens`
11. `decode_tokens`
12. `operation_schedule_commitment`
13. `schedule_event_count`
14. `output_commitment`
15. `trace_scheme_id`
16. `trace_evidence`
17. `gemm_trace_root`
18. `trace_event_count`

network、scheduler job ID、assignment/slot、owner/credential/runtime instance/execution nullifier、
evidence level、timestamp/epoch、signature はprojectionに入らない。ただしjob nullifierとrequest
commitmentはnetwork-boundであり、durable pair保存時には両memberのnetworkをexplicitに照合する。
2 Receipt は未失効、slot集合`{0,1}`、異なるexecution、signer key、credential、owner、assignment、
runtime instanceでなければならない。pairing `current_epoch`は両bodyのissued epoch、両receiptのoriginal
accepted epochとcurrent stateless verified epoch以上、両expiry以下でなければならない。

```text
match_commitment = H("replica-match/v1", encode(projection))
pair_id = H(
    "pair-id/v1", network_id,
    min(execution_nullifier_a, execution_nullifier_b),
    max(execution_nullifier_a, execution_nullifier_b),
    match_commitment
)
```

`MatchedReplicaPair` はpairing呼出し時の`current_epoch`をprivate `matched_epoch`として保持する。
このepochはprojection/pair IDには入らないが、Self Replicated用のpublic maturity constructorが
`MatureEvidence.mature_epoch`へ封入する。durable pair recordのcanonical bytesには`matched_epoch`を
含め、memberのstored issued/accepted/expiry epochと再照合する。

## 14. Audit, Work Ticket, canary, bond, and external identities

`FutureBeaconV1` canonical orderは`version:u16 (=1), network_id:Hash32, epoch:u64,
value:Hash32`。`beacon_id = H("future-beacon/v1", encode(body))`。signed envelopeは次のorderである。

```text
u16be(envelope_version=1) ||
LP(encode(FutureBeaconV1)) ||
authority_key_id:Hash32 ||
u8(signature_algorithm=0) ||
ed25519_signature:64-byte
```

signature messageは`beacon_id`。network-scoped authority registryはbeacon epochのvalidity、verification
epoch時点のrevocation、key ID、weak keyを検査し、strict Ed25519成功後だけraw constructorを持たない
`VerifiedFutureBeacon`へ昇格する。claimed beacon epochはverification epoch以下でなければならない。

future audit selection:

```text
sample = H(
    "audit-selection/v1", network_id, receipt_id,
    u64be(beacon_epoch), beacon
)
selected iff sample_as_big_endian_u256 < selection_threshold:Hash32

challenge_id = H(
    "audit-challenge/v1", network_id, receipt_id, sample
)
```

`AuditRecord::new`はexact `AcceptedReceipt`を受け、network、receipt ID、body issued epoch、durable
accepted epoch、scheduler job、job nullifier、request commitmentをbindする。beacon epochはissued epochと
accepted epochの両方より後でなければならない。v1 policyはselection threshold `2^252`（一様digestの
1/16）、response window 2 epoch、challenge window 5 epochの固定値で、全値を`audit-policy/v1` IDへ
commitする。

`StateStore::store_audit_selection`はpolicy ID、original issued/accepted epoch、canonical signed beacon、
beacon ID/value/authority key ID、challenge/deadlineまたはnon-selected mature epochを保存する。restore時は
current authority registryでsigned beaconを再検証し、sample/challenge/deadlineを再計算する。

selected replayはdistinctな`StatelesslyVerifiedReceipt`をaudit専用にacceptする。same network/job/requestを
要求し、receipt/execution/assignment/runtime instance/signer key/worker credential/owner commitmentはoriginal
と異ならなければならない。replay issued epochはbeaconより後、durable replay accepted epochはissued/
current stateless verified epoch以上かつdeadline以下である。`VerifiedReplayVerdict`が両
`MatchProjectionV1`を比較してresult commitmentとmatch outcomeを作るため、callerはraw
`projection_matches:bool`を注入できない。

selected pathはaudit replay identityの一回予約、terminal mismatchまたはpass、pass時のSelf Local
maturity sourceを1 SQLite transactionで確定する。non-selected pathもwindow maturityとsourceを1
transactionで確定する。beacon delivery/finality、auditor assignment、model re-execution、opening配送は
このwire/state coreの外部service boundaryである。

`restore_audit`はnon-replay state/terminalをrestoreするが、selected pass/mismatch terminalは
`AuditReplayRequired`で拒否する。この場合は`restore_selected_audit_with_replay`を使い、durable audit
state/challenge、stored canonical replay、全identity/epochを照合する。さらにprojection verdictを再計算し、
match bit、submission commitment、completed epochをstored terminal outcomeへexact比較する。

`WorkTicketV2` のIDを除くcanonical body orderは次のとおり。

1. `version:u16 (=2)`
2. `network_id:Hash32`
3. `source_id:Hash32`
4. `maturity_basis_id:Hash32`
5. `weight_grant_id:Option<Hash32>`
6. `job_class:JobClass`
7. `weight_policy_version:u32`
8. `canonical_compute_units:u64`
9. `weight_bps:u32`
10. `weighted_compute_units:u64`
11. `issued_epoch:u64`

```text
weighted_CU = ceil(CU * weight_bps / 10_000)
ticket_id = H("work-ticket/v2", network_id, encode(ticket_body_without_ticket_id))
```

V1 default weight は Self Local challenge 2,500、audit pass 5,000、replicated 10,000、external
demand bonus最大5,000 bps。これは算術/型変換の実装値であり、production network admission の
証明ではない。

`MatureEvidence` はwire objectではなく、fieldと低水準constructorを非公開にしたtyped gateである。
生成経路、`maturity_basis_id`、`mature_epoch`は次の3つだけ。

- Self Local: exact `AcceptedReceipt + AuditRecord::Mature`。domain `local-maturity-basis/v2`で
  audit basis/epochをbindし、audit stateが保持するmature epochを使う
- Self Replicated: `MatchedReplicaPair`。pair IDをmaturity basis、pairのmatched epochを使う
- External Replicated: authority-verified terminal settlement。confirmation IDをmaturity basis、authority-
  signed grant IDを必須weight grant、confirmation epochをmature epochとして使う

`StateStore::register_mature_evidence(&MatureEvidence)` はstored receipt/pairのnetwork、class、CUとopaque
evidenceを照合し、Self Localではstored durable auditのstate/basis/epochも照合する。External evidenceは
このAPIから拒否し、後述のsettlement transactionだけが登録できる。primary Self Local audit pathと
Self Replicated pathは、source登録と同じtransactionで必要な1件/2件のactive assignment bondを`Mature`
releaseし、`mature_source_assignments`へrelease IDをlinkする。unbonded/不足/terminal lockならtransactionを
rollbackする。ticket issuerもjob classのrequired replica数とlink数を再検査する。
`issue_work_ticket` は `issued_epoch >= mature_epoch` を要求し、SQLite ticket pathも保存epochに対して
同じ条件を検査してから1 sourceをatomicに消費する。既消費sourceの通常pathは`SourceAlreadyConsumed`、
External settlementのexact replayはstored ticketを返す。

canary expected projection commitment:

```text
H("canary/v1", network_id, canary_id, request_commitment,
  u64be(opening_epoch), canary_salt, encode(expected_match_projection))
```

`CanaryPrecommitBodyV1`は `version, network_id, canary_id, scheduler_job_id, request_commitment,
signed_assignment_id, worker_credential_id, expected_commitment, created_epoch, receipt_deadline_epoch,
opening_epoch, opening_deadline_epoch` をcanonical encodeし、
`precommit_id = H("canary-precommit/v1", encode(body))`をschedulerがEd25519署名する。strict envelopeは
body、scheduler key ID、algorithm、signatureを持つ。scheduler registryのnetwork、key validity/revocation、
strict signatureと、exact signed request/assignment/worker bindingを検査した後だけ
`VerifiedCanaryPrecommit`になる。External Replicated canaryはv1で禁止する。

windowは `assignment.issued <= created <= receipt_deadline <= assignment.expires < opening_epoch <=
opening_deadline`。canary markerはReceiptにない。verified precommitはactive bonded assignmentとcanonical
signed envelopeをschema-v4 DBへ保存する。`accept_canary`はbonded normal Receipt acceptanceと
`ReceiptSubmitted`を同じtransactionでcommitする。valid opening passはterminalだけをcommitし、valid
commitmentのprojection mismatchはtyped `CanaryFailure` slashをatomicに適用する。receipt deadline経過は
worker faultでslashし、receipt受理後のopening deadline経過はscheduler faultとしてworkerをslashしない。
passとOpeningMissingではassignment bondをactiveのまま保持する。pending canaryがあるsourceのmaturityは
拒否し、terminal後はmature epochをcanary completion epoch以上へ遅延する。Self Localでは遅延後のepochで
`local-maturity-basis/v2`も再計算する。その後のmaturity transactionがbondを`Mature` releaseしてsourceへ
linkするため、canary terminal単独ではWork Ticketを発行できない。

in-memory helperのslash offense:

```text
Evidence = u64be(unique_sorted_count) || concat(sorted_unique_evidence_id)
offense_id = H(
    "slash-offense/v1", network_id, worker_credential_id,
    assignment_id, u8(reason), u32be(policy_version), Evidence
)
```

reason tagは `1=InvalidManifest`, `2=AuditMismatch`, `3=Equivocation`,
`4=DuplicateExecution`, `5=CanaryFailure`, `6=AuditTimeout`。

durable slashはcaller-selected attachment集合ではなくcrate-private `TypedSlashEvidence`のprimary proofを
authority identityに使う。

```text
offense_id = H(
    "durable-slash-offense/v2", network_id, worker_credential_id,
    assignment_id, u8(reason), primary_proof_id, u32be(policy_version)
)
```

audit mismatch/timeoutとcanary mismatch/receipt timeoutはproof IDをstate transition自身から導出して、
slash claim、derived allocation、assignment remainder、pending appeal bucket、health eventを同じtransactionで
更新する。claimはinitial assignment amountからreason別bpsをceilしたimmutable targetを持つ。v1の
Equivocation追加penaltyは0である。複数claimを単純加算せず、finalized（signed/default uphold）targetの
max-envelopeを先に割り当て、pending claimはそのenvelopeを超えるextensionだけを受ける。同じassignmentへの
late equal/weaker claimのallocationは既存envelopeに覆われるなら0、stronger claimはdeltaだけとなる。
reverse後も全claimから再計算するため、ingestion順序でslash総額は変わらない。standard policyのappeal
windowはdurable `applied_epoch`から100 epoch。nonappealed slashはinclusive deadlineの後だけfinalizeする。
typed proofが示す`fault_event_epoch`とstoreがclaimを受理する`applied_epoch`は別で、
`locked_epoch <= fault_event_epoch <= applied_epoch`とaccount transition epochの単調性を要求する。

partial claimのremainderはactive lockとして残る。pendingまたはuphold/default-final claimを持つassignmentは
maturity/Work Ticketの根拠にならない。全claim解決後、audit mismatch/
timeout terminalはclaimがreverseされても残額を`SlashResolved` releaseする。canary mismatch/receipt-timeout
terminalはmatching `CanaryFailure` claimがuphold/default-finalの場合だけ同releaseを許し、External refundも
release terminalになる。reversed canary claimだけではreleaseしない。未使用または
acceptedだがunpairedのSelf Replicated assignmentだけは、pending canary/slashがなくsigned expiryを過ぎた
場合に`Expired` releaseできる。paired、Self Local、その他used assignmentはこのexpiry bypassを持たない。
pendingで全targetをallocateしたstate 2にもdistinct late claimを保存できるが、fully finalized/exhaustedの
state 3は新claimを拒否する。terminal epoch/proofは全immutable claimをoffense ID順に並べ、各effective epochの
maxと完全なterminal fact setから導出する。audit/canary terminalとExternal prepared/terminal stateは
後出しclaimのcutoffであり、特にExternal `SettlementPrepared`または`RefundPrepared`以後は新しい
non-replay slashを受けない。

bond funding、slash appeal、slash decisionはそれぞれversion 1 canonical bodyとsigned envelopeを持つ。
funding bodyはnetwork/worker/funding event/asset/exact amount/finalized epoch、appeal bodyはnetwork/worker/
offense/assignment/appeal ID/submitted epoch、decision bodyはnetwork/appeal/offense/outcome/decided epochを
bindする。network-scoped bond authority registryはkey validity/revocation、funding/appeal/decision capability、
weak key、strict Ed25519を検査し、raw constructorを持たないverified typestateだけをstoreへ渡す。

appeal submissionはstored pending slashとinclusive appeal deadlineを照合する。signed `submitted_epoch`と
registry verification epochの両方が`applied_epoch..=appeal_deadline`内でなければならず、後者をdurable
`accepted_epoch`として保存する。decision deadlineは`accepted_epoch + 100`である。authority-signed
`Uphold`/`Reverse`はsigned `decided_epoch`とdecision verification/acceptance epochの両方がdeadline以下で
だけ受理し、claim statusを更新してassignment全claimのallocationをatomicに再計算する。期限を過ぎても
decisionがなければ`finalize_stale_slash_appeal(current_epoch > decision_deadline)`がdomain-separated
default decisionを作ってdeterministically upholdする。offenseごとのappealは1件だけで、first stored
signed/default decisionが勝つ。stored canonical appeal/decisionのexact replayは期限後もidempotent、distinct
second appealやconflicting later decisionはfatalである。

`ExternalEscrowTermsV1` canonical order は `version:u16, network_id, escrow_nonce,
funding_authorization_id, prompt_commitment, ExecutionConstraintsV1, required_reward:u64,
demand_bonus_amount:u64, demand_bonus_bps:u32, protocol_fee:u64, failure_reserve:u64,
issued_epoch:u64, expires_epoch:u64`。

```text
escrow_reference = H("external-escrow/v1", encode(terms))
```

external authorityはnetwork-scoped Ed25519 keyにfunding、demand-weight、terminal capabilityを分離する。
key validity/revocation、weak key、strict signatureを検査し、次のraw constructorを持たないtypestateを作る。

- `VerifiedFundingAttestation`: escrow reference、funding authorization ID、asset、exact finalized amount/epoch
- `VerifiedDemandWeightGrant`: escrow/funding attestation、grant/policy/asset、funded bonus amount/bps、
  issued/expiry interval（v1 bonus上限5,000 bps）
- `VerifiedTerminalConfirmation`: escrow、payment command、rail confirmation、asset、exact settlement/refund
  distribution、confirmed epoch

schema-v4 durable external pathはexact funding+grantから`Funded` escrowを作り、scheduler-signed
External request、typed k=2 pair、stable payment commandへ進む。settlement confirmationはcommand/distribution/
pair/asset/epochを照合し、terminal state、maturity source、両worker assignment bondのrelease/link、
`WorkTicketV2` insert、source consumptionを一SQLite transactionでcommitする。refund commandはstate 1..3
（`Funded|Assigned|EvidenceReady`）からterms expiry後に作成でき、pairの有無を問わない。refund confirmationは
terminalとeligible assignment bond releaseを一SQLite transactionでcommitし、maturity/ticketを作らない。
pending slash claimを持つbondは解決までreleaseせず、解決後に残額だけをreleaseできる。exact confirmation replayは
idempotentで、逆terminal、amount、identityのconflictを拒否する。

settlement commandを`SettlementPrepared`へcommitする同じ`BEGIN IMMEDIATE` transactionで、pair両assignmentが
active state 0かつpending/upheld/default-final slash claimなしであることをpreflightする。
`SettlementPrepared`と`RefundPrepared`（state 4/5）はどちらもnon-replayのlate slashを拒否するため、
terminal準備とslashの順序で結果が変わらない。

これはexternal authorityが「rail上のfinality」を正しく署名するというtrust boundaryである。crateは
payment railを操作せず、rail transactionとSQLite commitのdistributed atomicityを主張しない。

## 15. Encrypted verification bundle and restart restoration

`VerificationBundleV1`はcanonical Receiptのprivate openingをrestart後もstrict verifyするためのartifactで、
Receipt wire format自体は変更しない。audit keyはcaller-owned raw 32 bytes、nonzeroで、bundleには含めない。

public sectionのcanonical order:

1. `version:u16 (=1)`
2. `receipt_binding:Hash32`
3. `receipt_id:Hash32`
4. `verification_epoch:u64`
5. scheduler key snapshot: `network_id, verifying_key, valid_from_epoch, valid_through_epoch,
   revoked_at_epoch:Option<u64>`
6. `LP(RuntimeManifest canonical bytes)`
7. `LP(portable ExecutionEvidence canonical bytes)`（schedule/CU/trace witness）

worker public keyはpublic sectionへ置かない。private sectionのcanonical order:

1. `LP("MISAKA/PALW/PRIVATE-OPENING")`, `version:u16 (=1)`, `public_digest:Hash32`
2. `LP(SignedJobRequestV1)`, `LP(SignedAssignmentV1)`
3. worker `verifying_key`, `owner_commitment`, `worker_credential_id`
4. `output_nonce`, `u64be(prompt_token_count)`, `u32be(prompt_token_id_i)*`
5. `LP(CanonicalOutput)`（generated token IDsとstop reason）
6. `owner_salt`

private signing-key seedはどのsectionにもserializeしない。

```text
receipt_binding = H("verification-bundle-receipt/v1", canonical_signed_receipt)
public_digest   = H("verification-bundle-public/v1", canonical_public_section)
aead_key        = H("verification-bundle-aead-key/v1", raw_audit_key)
aad = H(
    "verification-bundle-aad/v1",
    "XCHACHA20-POLY1305;KEY=256;NONCE=192;TAG=128",
    receipt_binding, public_digest, nonce, canonical_public_section
)
```

envelope canonical order:

```text
LP("MISAKA/PALW/VERIFICATION-BUNDLE") ||
u16be(version=1) || u16be(cipher=1) ||
receipt_binding || public_digest || nonce:24-byte ||
LP(canonical_public_section) || LP(XChaCha20-Poly1305 ciphertext_and_tag)
```

nonceはOS CSPRNGのnonzero 192-bit値、AEAD keyは256 bit、tagは128 bit。envelopeは64 MiB、public
sectionは48 MiB、private plaintextは16 MiBを上限とし、strict decode/re-encode、receipt/public binding、
AEAD authenticationを検査する。

```text
bundle_id = H("verification-bundle-id/v1", canonical_complete_envelope)
```

local restart pathはembedded scheduler/worker snapshotsを使ってcomplete stateless verificationを再実行し、
既存schema-v4 DB rowのcanonical Receipt/runtime instance/original acceptance epochへexact restoreする。
missing DB rowを新規acceptしない。これはlocal continuity modeであり、embedded snapshotはthird-party
network authorityではない。

bundle public sectionのhistorical `verification_epoch`はoriginal acceptance時点をbindする。
`verify_bundle_and_restore_at_epoch`はcaller-selected current epochがhistorical値以上であることを要求し、
同じbundle/openingをfresh epochで再検証したうえでoriginal durable acceptance epochを保持してrestoreする。
ただし、このlocal APIはembedded snapshotsを使うためbundle作成後のrevocationを学習できない。future audit
restoreではcurrent epochをbeacon以上にする。rollbackは拒否する。現行
`palw-verify-bundle` CLIはhistorical default pathで、fresh epoch overrideはlibrary APIだけが公開する。

external stateless pathはexpected network、independent scheduler registry、independent signer registry、
approved manifest hashを必須にし、embedded snapshotとのexact equalityも検査する。default APIはhistorical
epoch、`verify_bundle_stateless_at_epoch_with_trust`はrollbackしないcaller-selected fresh epochで検証する。
DB reservationを行わず、network acceptanceを主張しない。production restartではcurrent external trust rootsと
既存DB continuityを同時に検査する`verify_bundle_and_restore_at_epoch_with_trust`を使う。

Receipt CLIは`--prompt-stdin --audit-key-file RAW_32_BYTE_KEY`を必須とし、`--prompt TEXT`を受けない。
key fileはoutput directory外のowner-owned single-link regular file、mode `0400`/`0600`、exact 32 bytesで
なければならない。issuance output directoryは`0700`、Receipt/公開JSON/completion markerは`0644`、
bundle/DBは`0600`。DB WALを`TRUNCATE` checkpointしてmain DBを`fsync`し、各artifactを`fsync`した後、
`misaka.palw.receipt-set.v2` markerへ`receipt_id`、`bundle_id`、公開JSON bytesのSHA-256を記録して最後に
書き、directoryを`fsync`する。local verifier CLIは`--public-json`も必須とし、protected artifactsが同じ
owned `0700` directoryにexpected filename/modeで存在すること、marker、typed公開JSON
`misaka.palw.public-receipt.v2`全体を検査する。
保持する`artifacts`と`observer_summary`はauthenticated bundle manifest/evidenceから再構成してexact照合し、
extra JSON fieldはobjectの全階層で拒否する。
marker-lastはpartial setをcompleteとして受理しないためのgateであり、cross-file atomic transactionでも
authenticity proofでもない。markerはunkeyed plain textなのでsame-owner writerはJSONとmarkerを一緒に
置換できるが、改変JSONはReceipt/bundleとの照合に失敗する。canonical Receipt/authenticated bundleだけが
protocol authorityである。

## 16. Security and issuance boundary

trace root は approved observer が報告したeventへのcommitmentであり、単独のproof of executionでは
ない。intended production safety modelはpinned build、signed assignment、independent replica、future
audit、bond/slashing、durable uniquenessを組み合わせるが、個別primitive/state machineの存在はそれらが
operationally統合済みであることを意味しない。

schema-v4 coreはscheduler-signed canary precommit、authority-signed bond funding/appeal/decision、durable
assignment lock/release/slash/health、authority-signed external funding/grant/terminalを実装する。bonded receipt
acceptance、audit/canaryのtyped slash、maturity時bond release/link、WorkTicketV2 gate、External terminalから
maturity/ticketまでのlocal atomic transactionも実装済みである。

ただしproduction scheduler/network transport、governance-backed scheduler/worker/beacon/bond/external key
distribution、finalized beacon delivery、independent auditor execution/opening delivery、実payment railと
authority serviceはこのrepositoryにない。署名済みfunding/terminalは外部factのauthenticated statementで
あり、crate単体が実collateralやrail movementを独立証明するものではない。railとSQLiteはdistributed
atomic transactionではない。durable slashへ自動接続済みのproofはaudit mismatch/timeoutとcanary
mismatch/receipt timeoutで、invalid-manifest、equivocation、duplicate-executionのproduction proof
constructor/orchestrationは未統合である。legacy in-memory `BondLedger`/`CanaryRecord`/`ExternalEscrow` helperの
raw mutation APIをproduction authority pathとして使ってはならない。

現時点で実モデルReceiptを発行できるのはApple Metal `GraphFallback` runtime classである。CUDAは
RTX 4060 Ti sm_89 / CUDA Toolkit 13.3.1 / nvcc 13.3.73で固定Qwen 37/37 layer offload、graph observer
6/6、standalone true-accumulator primitiveの最終grouped device suite 8/8とproducer 20/20同一fingerprintに
加え、vendored MMVQ/FA-off attention same-backend 1-token diagnostic E2Eで361/361 recordと3回同一
fingerprintを実測済みである。exact entry/cubin/DSO release manifest、Receipt/RuntimeManifest/Request/
Assignment V2、暗号化Bundle V2、SQLite V2も実装・検証済みである。これはproduction `KernelSketch`
acceptanceではなく、authority-derived canonical IDを使うlive callbackとauthority governanceは未完了である。
V1 builder/verifierとproduction macro/CMake gateはfail closedを維持するため、
これらが完了するまでproduction CUDA Receipt/Work Ticketを発行しない。TEE attestationやZK/VCは
実装範囲外である。