GGUF
English
Japanese
misaka-palw
misaka
palw
proof-of-compute
deterministic-inference
integer-quantization
conversational
Instructions to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M # Run inference directly in the terminal: llama cli -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M # Run inference directly in the terminal: llama cli -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M # Run inference directly in the terminal: ./llama-cli -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M # Run inference directly in the terminal: ./build/bin/llama-cli -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Use Docker
docker model run hf.co/Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
- LM Studio
- Jan
- Ollama
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with Ollama:
ollama run hf.co/Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
- Unsloth Desktop
- Pi
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Configure the model in Pi
# Install Pi: npm install -g @earendil-works/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Docker Model Runner
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with Docker Model Runner:
docker model run hf.co/Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
- Lemonade
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Run and chat with the model
lemonade run user.Qwen3.6-35B-A3B-PALW-runtime-Q4_K_M
List all available models
lemonade list
- Hermes Agent
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use Misakachain/Qwen3.6-35B-A3B-PALW-runtime with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "Misakachain/Qwen3.6-35B-A3B-PALW-runtime:Q4_K_M" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
LM Studio gateway backend: palw-gateway crate (sessions/receipts/settlement/search), plugin rev5, launchers + search sidecar, ModelGenesisManifest (mirrors misaka-proof-of-llm 749aabb)
63e35ed verified | # Security Model | |
| ## Protected assets | |
| - model artifact、tokenizer、runtime binary/dylib/source patch の同一性 | |
| - prompt、prompt/generated token IDs、decoded output、owner key、commitment opening、audit key の秘匿性 | |
| - token count、operation schedule、canonical CU、graph/kernel trace の完全性 | |
| - scheduler request/assignment、job/execution nullifier、Receipt の一回性 | |
| - replica、audit、escrow、bond/slashing、Work Ticket の状態遷移 | |
| ## Trust and issuance boundary | |
| 単一の自己申告 Receipt は、悪意ある host に対する独立な暗号学的 proof ではない。本プロトコルは | |
| 次を組み合わせて不正コストを上げる。 | |
| - content-address された model/runtime manifest と Ed25519 scheduler/worker signature | |
| - 同一 runtime class 内の独立 credential/runtime instance による k=2 exact match | |
| - Receipt 発行後の future beacon による再実行 audit | |
| - authority-signed funding、scheduler-signed assignment lock、conserved durable bond accounting、appeal | |
| - scheduler-signed hidden precommitを期限後に開き、worker/scheduler timeoutを分離するdurable canary | |
| - transactional replay、pair、audit、bond/slash/health、maturity、WorkTicketV2、external settlement registry | |
| schema-v4 coreではこれらの多くがSQLite transactionで接続された。bonded Receipt acceptance、audit/canary | |
| slash、maturity時bond release/link、External settlementからticketまでのlocal atomicityを持つ。ただし | |
| production scheduler/auditor/authority/payment service全体をrepository内で実装したわけではない。 | |
| 現行 Metal Self Local path は signed Receipt を発行できるが、evidence は `graph_fallback` であり | |
| CUDA kernel proof ではない。mature weight には future audit または challenge window が必要である。 | |
| 現行CLIはscheduler/worker keyとregistry snapshotをlocalに生成するため、その出力だけからproduction | |
| scheduler authorizationやnetwork admissionを推論してはならない。 | |
| future-audit state、signed beacon provenance、audit replay、passing maturityはSQLiteへdurableに保存する。 | |
| ただしfinalized beaconの取得/governance、独立auditorへのassignment、model re-execution、private opening | |
| deliveryは外部serviceのtrust boundaryである。crate内のlocal authority registryはnetwork consensusや | |
| beacon finalityを実装しない。 | |
| CUDA code はadditive 184-byte V2 codecとstrict full-stream/dispatch/runtime binderを持つが、raw recordの | |
| declared producer originはtransport metadataであってproofではない。authority署名をnetwork/job/execution/ | |
| assignment、runtime class/manifest、producer integration、operation schedule commitment、全scheduled | |
| GEMM/attention coverage、full transcriptへbindし、producer | |
| accumulator GEMMだけをReceipt V2 evidenceへ射影するtypestateも実装した。ただしV1にはこの | |
| provenanceをcommitするfieldがないため、builderとverifierはCUDA `KernelSketch`をともに拒否する。 | |
| この署名は登録authorityによるexact transcript/integrationの承認をauthenticateするが、authorityの正しさや | |
| GPU register由来を単独で暗号学的に証明しない。 | |
| standaloneのproducer-internal FP32 accumulator採取primitiveはWSL2 Ubuntu 24.04上のRTX 4060 Ti(sm_89)、CUDA Toolkit | |
| 13.3.1 / nvcc 13.3.73で最終grouped device suite 8/8とproducer 20/20同一diagnostic fingerprintを通過した。固定Qwenも | |
| 37/37 layer CUDA offloadとgraph observer 6/6同一diagnostic streamを確認済みである。vendored llama.cppの | |
| Q4_K/Q6_K MMVQ producerはV3 full-K pre-epilogue hookへ接続済みで、same-backend 1-token diagnostic | |
| E2Eは253/253 recordを取得する。V3 schema/binderはFA-off eager attentionのcanonical groupingを表現し、 | |
| 3 stageのwork直後collectorとtyped associationも接続済みである。合計361 launchを3回同一fingerprintで | |
| 取得し、5 work classの拒否を確認した。exact symbol/runtime attributes/cubin/DSO release manifest、 | |
| Receipt/RuntimeManifest/Request/Assignment V2、暗号化Bundle V2、SQLite V2も実装・検証済みである。 | |
| ただしlive callbackはauthority-derived canonical physical-layout IDではなくdiagnostic IDを使用するため、 | |
| trace/producer production capability、vendor integration、Receipt mappingの各macroは0、production | |
| CMake optionはconfigure時に失敗する。したがって | |
| R32は`In progress`だがCUDA Receiptは発行不可である。 | |
| host OS、driver、GPU firmware まで敵対的とみなす場合は、TEE attestation または ZK/VC を追加 | |
| しなければならない。この v1 はその主張を行わない。 | |
| ### Consensus 側の三本柱(node ADR-0045 D2 の反映) | |
| node 側 consensus が担う正しさの柱は次の三つで、役割は重複しない。本 crate の Receipt/audit | |
| 機構は第 1 の柱への入力であり、支払いの最終性・遡及の扱いは第 3 の柱の規律に従う。 | |
| | 柱 | 検出するもの | 効果 | 時点 | | |
| |---|---|---|---| | |
| | Audit rounds | 標本化された leaf の再検証不一致 | certificate 拒否(事前)/ FraudEvidence(事後) | batch lifecycle 内 | | |
| | PCPB | ticket と provider の束縛偽装(委譲・横流し) | ticket 無効 = mint 不能(事前) | mint 時 | | |
| | Fraud + slash | 事後に発覚した不正(withhold、虚偽 receipt) | Revoked(**非遡及**)+ bond slash(遡及的担保) | いつでも | | |
| Revoked の非遡及は node 側 SS-04 で確定済み(coinbase 済み provider 支払いは UTXO model 上 | |
| 巻き戻せない;事後抑止は bond slash が担う)。単一 self-reported Receipt が独立証明でないという | |
| 本書の宣言を consensus 側も正とし、参照は双方向に固定される(node `docs/adr/0045`)。 | |
| ## Threat controls | |
| | Threat | Primary controls | Fail condition | | |
| |---|---|---| | |
| | Fake token count | pinned runtime tokenizer IDs、prefill/decode graph step consistency、opening、audit | count/token vector/phase step が不一致 | | |
| | Fake runtime | model/binary/dylib/source/build/host digest、manifest ID、allowlist | digest、class、実行前後 manifest が不一致 | | |
| | Fake output | salted output commitment、signed shared nonce、replica/audit opening | nonce、token、stop reason、再実行 output が不一致 | | |
| | Replay | domain-separated job/execution nullifier、SQLite unique constraint | receipt/nullifier/job slot が既に受理済み | | |
| | Forked runtime | manifest digest、signed assignment、canary、independent runtime instance | 未許可 digest、credential/instance 重複、canary failure | | |
| | Dummy execution | strict non-empty event stream、full event/token coverage、trace、replica/audit | event 欠落、unknown op、required evidence 不足 | | |
| | Schedule rewrite | ordered hash chain、event count、CU、Receipt signature | reorder/insert/delete/shape mutation で chain または CU 不一致 | | |
| | Receipt duplication | receipt/execution/job-slot uniqueness、pair/ticket one-shot state | duplicate accept、pair reuse、二重 ticket 化 | | |
| | Trace forgery | manifest capability、strict graph claim、trace root/count、replica/audit | CUDA claim、scheme、root、count、tile metadata が不一致 | | |
| | Secret leakage | stdin child pipe、output-byte omission、private opening schema、pre-write scan | canonical Receipt に prompt/token/key/nonce/salt bytes が出現 | | |
| | Bundle substitution | receipt/public/AAD binding、XChaCha20-Poly1305 tag、strict decode | receipt/bundle/public digest、nonce、tagが不一致 | | |
| | Incomplete output set | checkpoint/fsync、marker-last、core JSON field cross-check | marker欠落・ID/hash不一致(marker自体はunkeyedでauthenticity controlではない) | | |
| | Local trust escalation | DB exact restoreとexternal anchored stateless pathの分離 | embedded key snapshotだけで第三者authorityを主張 | | |
| | CUDA async failure | permanent poison、committed-count barrier、production gate | poisoned/pending/overflow context または非発行 capability | | |
| | External funding/weight forgery | network-scoped authority capability、signed exact funding/grant、canonical replay ID | key/network/asset/amount/grant/epoch/signature不一致 | | |
| | External double settlement | stable payment command、signed terminal confirmation、single durable terminal | command/distribution/pair/amount/epoch不一致、逆terminal、conflicting replay | | |
| | Canary false slash | scheduler-signed precommit、atomic receipt acceptance、fault-party timeout attribution | precommit/request/assignment/window不一致、opening未到達、scheduler opening timeout | | |
| | Bond funding/slash replay | signed funding event、typed primary proof、conservation reconciliation、appeal state | event/offense/canonical payload conflict、account/assignment/evidence不一致 | | |
| | Dependency/MSRV drift | exact crypto pins、lockfile、Rust 1.85 all-target CI | lock変更、MSRV manifest parse失敗、lint/test failure | | |
| | Premature Work Ticket | opaque maturity basis、required bond release links、WorkTicketV2、atomic one-shot issue | raw claim、epoch前倒し、bond link不足、grant不一致、source再消費 | | |
| ## Cryptographic rules | |
| - hash は SHA3-256 とし、用途ごとの domain separation と version を必須にする。 | |
| - 可変長 field は canonical length-prefix し、曖昧な連結を禁止する。 | |
| - Receipt、manifest、request、assignment、future beacon、canary precommit、bond/external authority | |
| evidence、verification bundle はstrict versioned canonical formだけを署名・hash/AEAD binding対象にする。 | |
| - output nonce、owner salt、private key seed は OS CSPRNG から 32 bytes 生成し、zero を拒否する。 | |
| - replica 用 output nonce は scheduler-signed request で共通指定し、worker による差し替えを防ぐ。 | |
| - prompt commitment も signed shared nonce、network、job、runtime tokenizer IDs に binding する。 | |
| - key ID、algorithmと署名をenvelopeに明記し、public keyはregistryから解決する。Receipt、scheduler | |
| message、future beacon、canary precommit、bond/external authorityのEd25519検証は`verify_strict`を使い、 | |
| small-order/weak public keyを各registryへの登録時と検証時に拒否する。bond authorityはfunding/appeal/ | |
| decision、external authorityはfunding/demand-weight/terminalのcapabilityを分離する。 | |
| - verification bundle はXChaCha20-Poly1305(256-bit derived key、192-bit random nonce、128-bit tag)を | |
| 使い、receipt binding、public digest、nonce、canonical public sectionをAADへbindする。caller-owned | |
| raw audit keyとprivate signing-key seedはbundleへserializeしない。 | |
| - replay/cardinality/terminal transition は process-local set ではなく durable transaction で確定する。 | |
| - MSRV gate、Clippy、test、release build は committed lockfile を使い、open transitive range が | |
| toolchain 非互換 manifest を silent に選ばないようにする。 | |
| ## Privacy rules | |
| canonical Receipt と公開 JSON に prompt、raw output、prompt/generated token IDs、owner public key、 | |
| output nonce、owner salt、private key、accumulator 全体を含めない。公開 JSON は commitment、digest、 | |
| non-secret identifier/counter/protocol label、CU、artifact/observer summary、filename、privacy flagを記録する。 | |
| 後述のlocal verifierがsemanticに照合するのはその一部である。 | |
| Receipt CLI は必須の `--prompt-stdin` を使い、UTF-8/非空/1 MiB 上限を inference 前に検査する。 | |
| `--prompt TEXT` は廃止され、unknown optionとして拒否する。CLIはさらに `--audit-key-file` を必須とし、 | |
| exact 32-byte nonzero key、owner、single link、regular-file、mode `0400`/`0600`、symlink/path race/inode | |
| alias/output directory内配置をfail-closedに検査する。 | |
| Rust adapter は prompt を tokenizer/native child argv、stderr、error text に置かず専用 stdin pipe | |
| で渡す。通常の Receipt 実行は native observer の `--emit-output-bytes` を使わないため decoded | |
| output bytes は IPC result にも含まれない。ただし native JSONL は wrapper 内部で | |
| prompt/generated token IDs を opening として運ぶため、この local pipe と process memory は | |
| trusted privacy boundary である。debug QA で output bytes を明示的に有効化した stream を公開 | |
| ログへ流してはならない。 | |
| verification bundleのpublic sectionにはreceipt binding/ID、verification epoch、scheduler public-key | |
| snapshot、manifest、execution evidenceを置く。worker public keyを含むsigner record、signed | |
| request/assignment、output nonce、prompt/generated token IDs、stop reason、owner saltはencrypted private | |
| sectionだけに置く。private signing-key seedとaudit keyはoutput artifactへ保持/serializeしない。CLI はcanonical bytesの | |
| strict round-tripとprompt/token/key/nonce/salt scanを通過してからだけ`create_new`で書く。audit keyの | |
| rotation/backup、bundle/openingのretention/deletionはcallerの運用責任で、このcrateに自動retention policy | |
| はない。 | |
| tokenizer、observer、host/source identity helperは inherited environment を消去し、`LANG=C` と | |
| `LC_ALL=C`だけを設定する。このallowlistはmanifestへbindされ、host identity helperはabsolute pathで | |
| 起動する。ただしsame-user debugger、process memory reader、malicious host kernelからlocal openingや | |
| audit keyを保護するattestationは提供しない。 | |
| ## Durable-state rules | |
| SQLite store は WAL、`synchronous=FULL`、foreign key、application ID、schema version 4を検証する。 | |
| table/column/foreign-key/index集合に加え、non-internal `sqlite_master` の完全な | |
| `(type,name,tbl_name,sql)`列をcanonical SHA3-256 fingerprintで照合する。旧schemaをsilent migrateせず、 | |
| 既存objectを持つunclaimed DBも拒否する。Receipt ID、execution nullifier、job/replica slot、pair | |
| membership、future audit/replay、bond funding/account/assignment/release/slash/appeal/health、signed canary、 | |
| maturity source/assignment link、Work Ticket v2、external escrow/payment command/terminalをunique constraintと | |
| transactionで守る。 | |
| raw maturity flag を受ける public store API は持たない。original receiptの`accepted_at_epoch`、pairの | |
| `matched_epoch`、signed beaconのclaimed epoch/key ID/canonical envelope、audit replayのissued/accepted | |
| epochを保存し、epoch rollbackを拒否する。beaconを検証したcaller current epochは保存せず、restore時に | |
| current `AcceptedReceipt.verified_at_epoch`とauthority registryから再確立する。selected auditは | |
| audit-specific replay identityの一回予約、typed | |
| projection verdict、terminal state、passing maturity sourceを同一transactionで確定し、non-selected | |
| auditもwindow maturityとsource登録を同一transactionで確定する。bond rowがあるaudit pathとSelf | |
| Replicated pathはmaturityと同じtransactionでrequired assignment bondをrelease/linkする。Work Ticketは | |
| その`mature_epoch`より前には発行できず、job classに必要なrelease link数を満たすsourceだけを一度消費する。 | |
| bond fundingはauthority-verified typestateだけをcreditし、funding event ledgerとaccount buckets、active | |
| assignment remaining、pending/finalized slash、healthをread/transition時にreconcileする。lockはexact | |
| scheduler-signed assignmentにbindする。bonded assignmentのReceiptをgeneric `accept`で受けず、 | |
| `accept_bonded`または`accept_canary`のatomic pathを要求する。audit mismatch/timeoutとcanary mismatch/ | |
| receipt timeoutはtransition自身からtyped primary proofを作り、slash accountingを同じtransactionに含める。 | |
| 各claimはinitial bond基準のimmutable targetを持ち、finalized max-envelopeを優先してpending extensionだけを | |
| allocateする。overlapを加算せず、equal/weaker/strongerの到着順やreverse後にも全claimから再計算する。 | |
| v1のEquivocation追加penaltyは0である。 | |
| authority-verified appealはpending offense/worker/assignment/deadlineへexact bindする。signed submissionと | |
| appeal verification/acceptance epochをappeal window内に要求し、decision windowは後者から開始する。signed | |
| decision epochとdecision verification/acceptance epochもdeadline内でなければならない。期限経過後は | |
| default-uphold、appealがなければappeal deadline後のfinalizationだけを認める。exact canonical replayは | |
| idempotent、同じbusiness IDのconflicting payloadはfatalである。 | |
| pendingまたはuphold/default-final claimを持つassignmentからmaturity/ticketを生成しない。全claim解決後、 | |
| audit mismatch/timeout terminalはclaim reversal時も残額を`SlashResolved` | |
| releaseする。canary fault terminalはmatching claimがuphold/default-finalの場合だけreleaseでき、reversed | |
| canary claim単独では解放しない。External refundもrelease terminalであり、state 1..3からexpiry後にpairの | |
| 有無を問わず確定できる。eligible bond残額はrefund terminalでreleaseするが、pending claimを持つbondは解決まで | |
| lockedに残す。expiry releaseは未使用またはaccepted-unpaired SelfReplicatedだけを許し、pending canary/slash、paired、Self Local、その他used | |
| assignmentを拒否する。`fault_event_epoch`とdurable `applied_epoch`を分離し、terminal epoch/proofは | |
| offense-sortedな完全claim/terminal fact setとmax effective epochからcanonicalに導出する。 | |
| scheduler-signed canary precommitはactive lockとcanonical envelopeを保存する。normal Receipt insertと | |
| `ReceiptSubmitted`はatomicである。pass terminal、mismatch/slash、receipt-missing worker slash、opening- | |
| missing scheduler fault/no-worker-slashをそれぞれ一transactionで確定する。passとopening-missingはbondを | |
| releaseせず、pending canary中のmaturityを拒否する。terminal後のmature epochをcanary completion以後へ | |
| 遅延し、maturity transactionだけが`Mature` release/linkを行う。 | |
| External settlementはauthority-verified funding/grant、scheduler request、k=2 pair、stable command、signed | |
| terminal confirmationを順にbindする。settlement confirmationはterminal、maturity、両worker bond release/ | |
| link、WorkTicketV2を一SQLite transactionでcommitする。refundはterminalとeligible bond releaseをatomicに | |
| commitするが、maturity/ticketを生成せず、pending claimのbondは解決までreleaseしない。 | |
| `SettlementPrepared` transitionは両bondがactiveでpending/upheld/default-final slashなしと同じtransactionで | |
| preflightする。`SettlementPrepared`または`RefundPrepared`以後のnon-replay slashを拒否する。 | |
| restartでは`restore_audit`がselected pass/mismatch terminalを`AuditReplayRequired`で拒否する。 | |
| `restore_selected_audit_with_replay`だけがstored challenge/canonical replayと全identity/epochを再照合し、 | |
| 再計算したmatch bit、submission commitment、completed epochをdurable terminalへexact比較する。 | |
| DB file の possession は signer authorization を代替しない。受理前の stateless verifier が署名、 | |
| request/assignment、manifest/evidence/opening を検証し、その typestate と canonical bytes だけを | |
| store へ渡す。 | |
| 発行時はowned non-symlink output directoryを`0700`に固定し、Receipt/公開JSON/completion markerを | |
| `0644`、暗号化bundle/DBを`0600`にする。DBはWAL `TRUNCATE` checkpoint、connection drop、main-file | |
| `fsync`を完了してからpublic artifactsを書き、各fileを`fsync`した後にmarkerを最後に作ってdirectoryを | |
| `fsync`する。marker v2はreceipt ID、bundle ID、公開JSON SHA-256を記録する。これはcross-file atomic | |
| renameではないためlate failureでpartial setは残り得るが、local verifierは全protected artifactの | |
| same-directory/expected filename/mode/owner/type/link count、exact marker、typed公開JSON | |
| `misaka.palw.public-receipt.v2`全体がsigned Receiptと | |
| authenticated bundle manifest/evidenceへ一致しないsetを拒否する。unknown fieldも全階層で拒否する。 | |
| markerはunkeyed plain textでsignature/AEAD protectionを持たず、same-owner writerは公開JSONとmarkerを | |
| 一緒に置換できる。しかしverifierは保持する`artifacts`と`observer_summary`を含むtyped文書全体を | |
| authenticated dataから再構成してexact照合するため、markerを書き直しても改変JSONは受理されない。 | |
| marker/JSONはcompletenessとhuman-readable projectionのboundaryであり、canonical Receiptとauthenticated | |
| bundleのauthorityを代替しない。 | |
| `verify_bundle_and_restore`はembedded snapshotsで再検証した後、既存DB rowへのexact continuityだけを | |
| 認め、missing rowをinsertしない。第三者用`verify_bundle_stateless_with_trust`は外部scheduler/signer | |
| registry、expected network、approved manifest hashを必須とし、embedded snapshotをauthorityにしない。 | |
| 後者はbundle-bound historical `verification_epoch`でのstateless verificationであり、present-time network | |
| acceptanceやdurable replay reservationではない。 | |
| fresh APIはcaller-selected epochがbundleのhistorical verification epoch以上であることを要求する。 | |
| `verify_bundle_and_restore_at_epoch`はlocal embedded snapshotsでfresh `AcceptedReceipt`を作りoriginal durable | |
| acceptance epochを保持するが、bundle作成後のrevocationは学習できない。 | |
| `verify_bundle_stateless_at_epoch_with_trust`はexternal rootsでfresh stateless typestateを作るがDB continuityを | |
| 検査しない。production restartではcurrent external rootsと既存DB rowを同時に検査する | |
| `verify_bundle_and_restore_at_epoch_with_trust`を使う。future audit restoreではepochをbeacon以上にし、 | |
| present-time network admissionは別途判断する。現行CLIはhistorical default restoreだけを呼び、fresh epochは | |
| library/service APIで指定する。 | |
| ## Residual risks | |
| - greedy decode でも driver/kernel/toolchain 差により bitwise output が変わり得る。 | |
| - Metal graph-level logical-prefix sketch は lossy で、CUDA kernel/accumulator trace より弱い。 | |
| - observer callback の read-only access は timing と synchronization を変え得る。 | |
| - k=2 replica が同一所有者・同一障害 domain なら共謀耐性がない。 | |
| - external registry/finality serviceが供給するfuture beaconが予測・操作可能ならaudit samplingが弱くなる。 | |
| - auditor scheduling、model re-execution、opening deliveryはcrate外であり、durable audit stateだけでは | |
| independent replayの運用を保証しない。 | |
| - bond/external authority registryのproduction governance、key distribution、revocation deliveryはcrate外で、 | |
| 同梱in-memory registryはnetwork consensusではない。 | |
| - signed funding/terminal evidenceはauthorityのstatementをauthenticateするが、実collateralやpayment railを | |
| crateが独立観測したproofではない。rail movementとlocal SQLite commitはdistributed atomicではない。 | |
| - External `SettlementPrepared`/`RefundPrepared`後にauthority confirmationが来ない場合のtimeoutや | |
| superseding terminalはなく、prepared stateのoperational recoveryは外部serviceに依存する。 | |
| - durable canaryはscheduler opening欠落をscheduler faultとしてworker slashから分離するが、production | |
| schedulerのprecommit/opening deliveryとavailabilityはcrate外である。 | |
| - durable slashへ自動接続済みなのはaudit mismatch/timeoutとcanary mismatch/receipt timeoutである。 | |
| invalid-manifest、equivocation、duplicate-executionのproduction typed proof/orchestrationは未統合である。 | |
| - legacy in-memory `BondLedger`、`CanaryRecord`、`ExternalEscrow` helperはraw caller mutationを許すため、 | |
| schema-v4 signed/durable authority pathの代用にしてはならない。 | |
| - `future_audits.state=4`はpublic transitionではdeadlineを保持するが、SQL constraint単独では | |
| `deadline_epoch NOT NULL`を要求しない。constraint-validなDB corruptionはload/release時にfail closedとなるが、 | |
| schema-level hardening余地が残る。 | |
| - CU table は実時間・電力を表さず、versioned governance の対象である。 | |
| - encrypted bundleはaudit keyを取得したsame-user/malicious hostからopeningを守らず、key backup/rotation/ | |
| retentionも自動化しない。 | |
| - CI workflowやRTX実機でのvendored MMVQ diagnostic hook/E2E成功も、FA-off attentionの361-launch実機coverage、 | |
| production-approved kernel manifest identity、authority-bound full-stream verification、Receipt V2を代替せず、 | |
| R32 production acceptance authorityを与えない。 | |
| production scheduler/network transport、governance key distribution、beacon/authority service、payment rail、 | |
| NVIDIA CUDAのfull production issuance pathも未統合である。 | |
| これらは runtime class 分離、independent identity、future beacon finality、versioned CU policy、 | |
| bond/slashing、source統合済みFA-off attention hookの実機full-stream検証、release manifest authorityと | |
| attestation/proof layerで緩和する。 | |