Spec is intact at 510 lines / 31.4K. Now doing the self-review pass for placeholders, consistency, scope, and ambiguity.

★ Insight ─────────────────────────────────────

• A spec self-review is fundamentally different from a content review — it asks "does the document say enough to implement" rather than
  "is the design right". The four review axes (placeholders, consistency, scope, ambiguity) map to four classes of post-acceptance bugs:
  TODO drift, contradiction-driven rework, scope creep, and "we thought we agreed" reinterpretation.
• The spec uses a deliberate two-tier identity model where templates are content-addressed but instances are chain-bound. This means
  policyTemplateId is reproducible from local files alone — a property the CLI exploits via compute-id for offline scripting and the
  contract exploits via deterministic dedup. Catching where the spec under-specifies this dual semantics is a high-value review target.
• Reference-section accuracy matters more than people credit: when citations drift (off-by-one line numbers, ranges that span a whole
  file), readers lose the ability to verify the spec's claims against the code. Each citation in this spec is a load-bearing claim about
  the existing system.
  ─────────────────────────────────────────────────

Self-review findings

MUST FIX — substantive gaps

A. currentInstanceIds shape for PolicyDataRegistry is undefined (lines 178, 407)
Line 178 says "clients can have multiple policy-data instances per policy" and uses currentInstanceIds (plural). The Solidity
pseudocode at lines 167-176 shows only PolicyRegistry with clientCurrent: mapping(address => bytes32). The PD parallel layout is not
shown. Implementer ambiguity: is it mapping(address => mapping(bytes32 policyId => bytes32[])), or mapping(address => bytes32[]), or
keyed by something else?

B. expireAfter field is referenced but never declared (line 393)

▎ "registry rejects expireAfter == 0 at deployInstance time"

But PolicyInstance struct shape isn't shown anywhere. The implementer cannot tell from the spec whether expireAfter lives on the
instance, on the template, or in params.

C. policyDataTemplateRefs storage is implied but not declared (line 82, 90)
The formula canonical(policyDataTemplateRefs) is part of policyTemplateId. For policy describe to walk the DAG (line 228-231), the
template must store these references on-chain explicitly — but PolicyTemplate struct shape isn't shown.

D. Contract behavior on duplicate registerTemplate is unspecified (lines 190 vs 271)

• Line 271 says the CLI short-circuits before submitting on duplicate
• Line 190 says "the second and third calls succeed even if a different deployer ran the first because the deterministic ID
  short-circuits to a no-op"

But the contract behavior is undefined — does registerTemplate revert on duplicate, no-op, or update? Critical for retry semantics if a
CLI pre-flight is bypassed (admin tool, direct contract interaction).

SHOULD FIX — clarity

E. Hashing parenthetical is confusing (line 89)

▎ "arguments are encoded with abi.encodePacked for hashing only (commitments stored as raw bytes, never abi.encode'd at registry-write
▎ time)"

The "stored as raw bytes" phrase is ambiguous — is it talking about the registry storing bytes32 results, or storing the input
rego_bytes? Re-read suggests it means the on-chain commitment is the 32-byte hash, not abi-encoded. Worth re-stating without the
parenthetical.

F. Namespace tag terminology drifts (lines 109 vs 441)

• Line 109: "Leaf-key prefix bytes are namespace tags (per Sub-A's LeafHeaderV1)"
• Line 441: "header.namespace distinguishes 0x04–0x08"

Sub-A uses leaf_key[0] as the 1-byte namespace prefix. Pick one term and use it consistently — LeafHeaderV1.namespace field vs
leaf_key[0] prefix are not the same shape.

G. show-secrets metadata semantics undefined (line 226)

▎ "show-secrets # show metadata only"

What metadata? Upload timestamp? Schema reference? Envelope size? Encryption epoch? The implementer needs the field list.

H. CID-vs-KZG integrity abstraction unclear (line 396-398)
The spec says "Sub-B replaces IPFS CID integrity verification with EigenDA blob KZG-commitment verification" — but SHA-256 multihash
and KZG pairing are categorically different checks. Is the operator hot path wrapped behind a trait that abstracts both? Or are they
two distinct code paths gated by the feature flag?

I. Off-by-one in code citation (line 504)

▎ "integration-tests/src/multichain_routing.rs:253-260"

Actual range was 253-261. Same kind of issue may be in the secrets.rs:1-120 citation (line 503) — that's a whole-file range, not a
function range.

J. secretsSchema validation locality (lines 449, 462)
Line 449 says validation "runs inside any operator the gateway delegates to" — does "any" mean exactly one, or all decrypters? Given
the shared key model, one is sufficient cryptographically; redundancy is a defense-in-depth choice that should be explicit.

K. Client owner role description misses plural case (line 407)

▎ "Point their client's currentInstanceId to a deployed instance they own"

For PD, it's currentInstanceIds. The role description should accommodate both registries.
NICE TO HAVE — style

L. L4 hit rate qualitative outlier (line 331)
L0–L3 have target percentages or "Tail"; L4 has "Tail emergency" with no target. Would be more uniform to say "fallback only — no SLA"
or pick a numeric target.

M. Single-snapshot mentions only 5 artifacts (line 389)
"rego bytes, WASM bytes, and all three schemas" — but PD instance params are also read at eval time. Implicit but worth listing for
completeness.

N. Multi-chain example forces an order despite "any-order" Q8 lock (lines 297-303)
The example registers PD templates first, then policy templates referencing them. Q8.3 says any-order works thanks to pre-flight. A
one-line note ("Order is illustrative; pre-flight permits any order") would prevent reader confusion.

O. "Off-chain documentation" hand-wave (line 419-420)

▎ "Off-chain documentation can mark templates as discouraged"

What channel? Newton docs site? GitHub README? A specific runbook? Either point to the channel or remove the line.

ALL CLEAR

• No TODO / TBD / XXX markers
• No patterns
• Identity formulas are consistent across §Architecture and §Verifier re-derivation
• Namespace map (0x04–0x08) is consistent across §State-tree namespaces, §Three schemas, §Cross-project integration
• Q-decision table matches the body sections it summarizes
• Scope (in/out/non-goals) is unambiguous
• Risks table covers the major failure surfaces

Recommendation

Substantive fixes A–D should land before user review. The SHOULD-FIX items E–K are individually small but together drive ~15 lines of
edits. NICE-TO-HAVE items L–O are polish.

Want me to apply A–D + E–K now, or stage them for your review pass first?

✻ Worked for 2m 27s

※ recap: Drafting the Sub-project B on-chain policy storage spec; finished writing it to
docs/superpowers/specs/2026-04-22-onchain-policy-storage-design.md and ran a self-review surfacing four substantive gaps. Next action
is your call on whether to apply the fixes now or after your review.

❯ yes for A: currentInstanceIds refers to the "deployed policy data instances" not templates right? conceptually, policy ref (template)
to policy Data refs (template) are mapped, and each poilcy client (address) has policy instance id (policy registry) + policy data
instance ids (policy data registry)? confirm my understanding and correct me if im wrong. B. i need to confirm, but think expire After
is set at the policy/policy data "instance" level? So first, yes, let's apply fixes for A-D + E-K, and for the rest, let's review /
discuss as well

⏺ Confirming your mental model first, then applying fixes.

Your mental model — correct, with one refinement

▎ "currentInstanceIds refers to the 'deployed policy data instances' not templates"

✅ Correct. currentInstanceIds (plural) tracks policy-data instances the client has deployed, not templates.

▎ "conceptually, policy ref (template) to policy Data refs (template) are mapped, and each policy client (address) has policy instance
▎ id (policy registry) + policy data instance ids (policy data registry)"

✅ Correct. The relationship is:

policyTemplate ──declares──→ policyDataTemplateRefs = [pd1, pd2, pd3] (1-to-N at template level)
policyInstance ──references──→ policyTemplate (client deploys 1 policy instance)
policyDataInstance ──references──→ policyDataTemplate (client deploys 1 PDI per referenced PD template)

One refinement on the keying: the per-client PD instance map should be keyed by (client, policyDataTemplateId), not a flat bytes32[]
array. So:

// PolicyRegistry — one policy instance per client
mapping(address client => bytes32 instanceId) public currentPolicyInstance;

// PolicyDataRegistry — one PD instance per (client, PD template) slot
mapping(address client => mapping(bytes32 policyDataTemplateId => bytes32 instanceId))
public currentPolicyDataInstance;

Why mapping not array: the operator's eval loop walks the policy template's policyDataTemplateRefs and asks the registry "for client C,
which PD instance fills slot pd1?". A keyed mapping gives O(1) per slot and decouples client-side instance ordering from policy-author
template-ref ordering. An array would force ordering coupling and make swapping a single PD instance harder.

▎ "expireAfter is set at the policy/policy data 'instance' level"

✅ Correct. It's per-instance because two clients deploying against the same template can choose different validity windows. This
matches today's NewtonPolicy.PolicyConfig.expireAfter.

★ Insight ─────────────────────────────────────

• The template-vs-instance keying decision matters for upgrade ergonomics: mapping-keyed-by-templateId means a client can swap their
  pd1 instance independently of pd2, which lets clients hot-swap a single data domain (e.g., "use a fresh sanctions list") without
  redeploying their policy. Array-keyed would force re-pointing the entire policy any time one PD changes.
• Per-instance expireAfter means challengers must read the instance's value (not the template's) at the dispute block. This bakes into
  the verifier re-derivation flow at G2: the verifier must read both the template (for hash commitments) AND the instance (for
  expireAfter) from the registry at the task's reference block.
• A subtle implication of currentPolicyDataInstance[client][templateId] being a mapping: an operator evaluating client C's policy must
  verify that every PD template the policy requires has a corresponding instance pointed by the client. A missing slot is a deploy-time
  invariant violation that pre-flight (G3) must catch — otherwise eval-time will see a zero-instance lookup and need to fail loudly.
  ─────────────────────────────────────────────────

Now applying fixes A–D + E–K.

All substantive fixes applied. Spec is now 587 lines, internally consistent across struct names and pointer references.

★ Insight ─────────────────────────────────────

• The bigger structural change here was making currentPolicyDataInstance a mapping(address => mapping(bytes32 => bytes32)) instead of
  an array. This bakes a key design property into the data model: clients deploy PD instances against template IDs, and the operator's
  eval loop walks the policy template's policyDataTemplateRefs to look up instances by slot — never by index. That's how schema evolution
  stays clean: rotating one PD template doesn't shift array indices for unrelated PD slots.
• The duplicate-registration revert vs. silent no-op decision is a small choice with a big consequence for tooling. Reverting forces
  every caller (CLI, admin scripts, Foundry deploy) to handle the case explicitly. A silent no-op would let buggy deploy scripts believe
  they registered something fresh when they actually re-keyed against an existing template — a source of "phantom deployment" bugs.
• expireAfter living on the instance, not the template, also means challenger verification at G3 needs to read the instance state at
  the dispute block. The spec's verifier pseudocode already does both reads — but make sure the implementation plan keeps these two reads
  atomic across the same RPC call to avoid race conditions on registry upgrades.
  ─────────────────────────────────────────────────

Summary of fixes applied (A–D + E–K)

┌─────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Fix │ What changed │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ A │ Added full PolicyRegistry and PolicyDataRegistry struct definitions; currentPolicyDataInstance keyed by (client, │
│ │ policyDataTemplateId) mapping │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ B │ expireAfter: uint64 declared on both PolicyInstance and PolicyDataInstance │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ C │ policyDataTemplateRefs: bytes32[] declared on PolicyTemplate (sorted) │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ D │ Added ### Duplicate registration semantics section: TemplateAlreadyRegistered and InstanceAlreadyDeployed reverts; CLI │
│ │ short-circuits via G3 │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ E │ Hashing parenthetical rewritten to clarify raw-vs-hash storage │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ F │ Unified to leaf_key[0] convention; dropped LeafHeaderV1.namespace references │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ G │ show-secrets metadata enumerated: epoch_id, schema ref, ciphertext size, upload timestamp, uploader │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ H │ Added ArtifactVerifier trait abstraction; documented SHA2-256 (IPFS) vs KZG (EigenDA) paths │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ I │ Citation ranges tightened: secrets.rs:65-89, multichain_routing.rs:253-261, added handler/mod.rs:1665-1708 │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ J │ secretsSchema validation runs in single operator (cryptographically sufficient); defense-in-depth multi-validator │
│ │ deferred to Phase 1b │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ K │ Client owner row updated to mention currentPolicyInstance + currentPolicyDataInstance[templateId] + setSecrets │
├─────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ (bonus) │ Narrative pointer language at line 94 updated to match new field names │
└─────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Remaining items for discussion (L–O)

These are smaller-stakes items I held back per your instruction. Each is a one-line decision:

L. L4 cache tier hit rate is qualitative, not numeric

Current: L0=95%+, L1=99%+, L2=99.5%+, L3="Tail", L4="Tail emergency".

Options:

1. Leave qualitative — operationally honest (we don't have measured L4 rates)
2. Specify "fallback only — no SLA" for L3 and L4 — clearer that these are edge cases
3. Pick numbers (e.g., L3 99.99%, L4 99.999%) — gives a target to design against

My take: option 2 — the L4 path is genuinely best-effort, and committing to numbers without measurement is the kind of fiction that
breaks in prod review.

M. Single-snapshot section omits PD instance params

Spec says "rego bytes, WASM bytes, and all three schemas read from the same snapshot". Should also list PD instance params (which are
stored in EigenDA blobs but referenced from the registry — also need to read at the snapshot block).

My take: add it — listing all five artifact classes (rego, WASM, 3 schemas, instance params) makes the invariant exhaustive rather than
approximate.

N. Multi-chain example forces an order despite "any-order" Q8 lock

Example registers PD templates first, then policy templates that reference them. Q8 says any-order works thanks to pre-flight.

Options:

1. Leave as-is and add a one-line note: "Order is illustrative; pre-flight permits any order"
2. Reorder the example to register policy template first to demonstrate the any-order property
3. Both — note + reordered

My take: option 1 — the dependency-first order is the default mental model for the reader, and a single sentence is clearer than
reverse-order pedagogy.

O. "Off-chain documentation" hand-wave for deprecation

Spec says: "Off-chain documentation can mark templates as discouraged." No location specified.

Options:

1. Drop the line entirely — Phase 1 has no deprecation, full stop
2. Point at a real channel (Newton docs site? docs/POLICY_DEPRECATION.md? The runbook?)
3. Keep as-is — leaves room for ad-hoc docs

My take: option 1 — the line is currently a hint at a process that doesn't exist yet, which is exactly the kind of phrase that becomes
a future "we said we'd document this somewhere but didn't" issue.

---

Pick L/M/N/O choices and I'll apply them. Or if you'd rather hold them and review the full spec end-to-end first, I can stage them.

✻ Brewed for 5m 39s

※ recap: Drafted Sub-project B on-chain policy storage spec at docs/superpowers/specs/2026-04-22-onchain-policy-storage-design.md and
just applied substantive fixes A through K from my self-review. Next action is your decision on the four remaining items L through O
before user review.

⏺ ★ Insight ─────────────────────────────────────
Recall search confirmed no prior Sub-B entries — the closest hits are Sub-A "Private Data Storage" memories. Sub-B needs its own memory
file and tagged recall entries; this isn't an update of an existing record. Local memory dir has project_private_data_storage.md for
Sub-A (52.9K, 5 days old), so the natural pattern is a sibling project_onchain_policy_storage.md for Sub-B with a parallel entry in
MEMORY.md.

Session search recovered all Q1-Q10 + G1-G3 context, so nothing was lost to compaction.
─────────────────────────────────────────────────

Preview — what I'll save across all 3 memory systems

Project/Topic: Newton Private Data Storage — Sub-project B (On-chain Policy + Policy Data Migration)

Linear: TBD — no Linear project created yet (Sub-A's Private Storage Layer project covers Sub-A only). Sub-B Linear decomposition is a
follow-up task.

Summary (2-3 sentences)

Completed architectural design and implementation plan for Sub-project B, which migrates policy Rego bytecode + policy-data WASM + 3
schemas from IPFS-only addressing to on-chain commitment + EigenDA bytes (validium pivot). Locked 10 architectural decisions Q1-Q10 plus
3 consistency-dry-run gaps G1-G3 (shared HPKE clarification, ChallengeVerifier re-derivation, CLI pre-flight checks). Final 3,860-line
implementation plan saved with 47 TDD tasks across 6 streams (A:12, B:9, C:9, D:11, E:6, X:4); awaiting execution-mode choice.

Key Decisions

1. Validium pivot LOCKED (Q1) — bytes via EigenDA, only commitments on-chain. State-tree namespaces 0x04-0x08 multiplex through
   leaf_key[0] prefix in Sub-A's unified JMT.
2. Two-tier identity formulas (Q2):
   - policyTemplateId = keccak256(rego ‖ policyParamsSchema ‖ canonical(policyDataTemplateRefs)) (sorted refs)
   - policyDataTemplateId = keccak256(wasm ‖ policyDataParamsSchema ‖ secretsSchema)
   - policyInstanceId = keccak256(chainId ‖ clientAddr ‖ policyTemplateId ‖ paramsHash)
   - policyDataInstanceId = keccak256(0x01 ‖ chainId ‖ clientAddr ‖ policyDataTemplateId ‖ paramsHash) — domain separator byte
3. Three schemas (Q3) — policyParamsSchema (0x05), policyDataParamsSchema (0x07), secretsSchema (0x08); JSON Schema Draft 2020-12.
4. Template/Instance split (Q4) — Templates immutable + content-addressed (Newton-vetted allowlist); instances mutable + client-owned.
   currentPolicyInstance[client] (single) and currentPolicyDataInstance[client][templateId] (per-slot mapping).
5. Three-layer drift defense (Q5) — L1 deploy-time, L2 eval-time (single-snapshot invariant), L3 challenge-time (re-derivation).
6. Five-tier cache (Q6) — L0 enclave RAM, L1 daemon RAM, L2 daemon disk, L3 EigenDA fallback, L4 bootnode fallback.
7. CLI surface (Q7) — policy template/instance, policy-data template/instance, set-secrets, describe, with profile config 4-lane
   resolver.
8. Per-client mapping shape (Q8) — single + per-slot mapping (not array).
9. Duplicate registration (Q9) — TemplateAlreadyRegistered / InstanceAlreadyDeployed reverts; CLI G3 pre-flight short-circuits.
10. Allowlists (Q10) — templateAuthors + instanceDeployers via AllowlistGuard mixin (Safe multisig per chain).
11. G1 (gap fix) — Production reuses ONE shared HPKE keypair via OPERATOR__ENCRYPTION__PRIVATE_KEY; Sub-B only adds secretsSchema
    namespace 0x08.
12. G2 (gap fix) — ChallengeVerifier re-reads on-chain policyTemplateRef / policyDataTemplateRef at task's reference block; never trusts
    challenger-supplied hash.
13. G3 (gap fix) — Every CLI deploy command pre-flights all on-chain assertions before broadcasting any tx.
14. expireAfter per-instance — confirmed at instance level, > 0 enforced at deployInstance.
15. Atomicity — Phase 1 ships any-order (Option B); atomic bundle multicall (Option A) deferred to Phase 2.

Implementation Progress

• Spec: docs/superpowers/specs/2026-04-22-onchain-policy-storage-design.md (586 lines, gitignored, accepted)
• Plan: docs/superpowers/plans/2026-04-22-onchain-policy-storage-plan.md (3,860 lines, 127K, gitignored, complete with self-review)
• 47 TDD tasks across 6 streams:
  • A. Foundation (12 tasks) — namespaces 0x04-0x08, artifact-verifier crate (IPFS+EigenDA), policy-id crate (template/instance ID
    formulas), schema-validator crate
  • B. Contracts (9 tasks) — IPolicyRegistry/IPolicyDataRegistry, AllowlistGuard mixin, ChallengeVerifier G2 re-derivation, deployment +
    bindings
  • C. CLI (9 tasks) — profile config, G3 pre-flight, policy template/instance, policy-data template/instance, set-secrets, describe
  • D. Service refactors (11 tasks) — chainio writers/readers, LayeredArtifactCache, pre-warm subscriber, WASM compile cache, schema
    cache, single-snapshot invariant, gateway secretsSchema validation, challenger G2 binding, data-provider hot path
  • E. E2E (6 tasks) — feature flag, deploy/eval/challenge/secrets-validation scenarios, 14 quickstart policy migration
  • X. Cross-cutting (4 tasks) — metrics, docs, Phase 1.5 IPFS-default-off, Phase 2 IPFS deletion
• Self-review inlined in plan: spec coverage table, placeholder scan, type consistency table, risk callouts (B7 reference-block stashing
  deferred, pre-warm subscriber bootstrapping)

Learnings

• Sub-A primitives reuse pattern — Sub-B reuses every Sub-A primitive unchanged (StateCommitRegistry, IStateRootCommittable, JMT state
  tree, EigenDaClient, BootnodeServer, NamespaceId enum). Net-new is contracts, CLI, and service refactors only — no new infrastructure
  crates.
• ArtifactVerifier trait abstracts SHA2-256 (IPFS) vs KZG (EigenDA) — both return keccak256(bytes) as canonical commitment. Decouples
  on-chain commitment from off-chain availability layer.
• Stream parallelism — Streams A and B are fully independent (no shared symbols), can fan out 2 concurrent subagents in week 1. Stream C
  blocks on A; Stream D blocks on A+B; Stream E blocks on D.
• expireAfter > 0 enforcement — moved from policy implementation to deployInstance revert (ExpireAfterZero); avoids the historical
  AttestationExpired failure mode where expireAfter=0 produced expiration == reference_block DOA attestations.
• Three-layer drift defense lesson generalized — applies to any class of artifact where on-chain commitment must bind cryptographically
  to off-chain bytes. Sub-A applies it to private data; Sub-B applies it to policy artifacts. Both reuse the same ChallengeVerifier
  re-derivation pattern.

Current Issues / Limitations

• B7 reference-block stashing deferred — Phase 1 reads current instance from registries since clients deploy a new instance per config
  change. If a client races setCurrent mid-task, mitigation is task-creation-time instanceId snapshot + verifier reads immutable instance.
  Phase 1.5 hardening.
• Pre-warm subscriber bootstrapping — A new operator joining mid-stream must replay all TemplateRegistered events from genesis via
  from_block backfill before live subscription. May take minutes at high event volume.
• No Linear decomposition yet — 47 tasks not yet captured as Linear issues. Sub-A's pattern was 50 issues across NEWT-1003..1052 created
  post-spec; Sub-B's equivalent is pending.
• docs/superpowers/ is gitignored — both spec and plan are local-only. Cannot be committed; teammates need this memory file + recall
  entries to track Sub-B context.

Remaining TODOs

1. Choose execution mode — Subagent-Driven (recommended for parallel A+B streams) vs Inline. User must pick before plan execution
   begins.
2. Decompose into Linear issues — Sub-A pattern: 47 tasks → ~47 issues with crate-shaped titles, tags, depends-on/blocks, acceptance
   criteria. Mirror NEWT-1003..1052 conventions.
3. Begin Stream A Task A1 — Extend NamespaceId with PolicyRego (0x04), PolicyParamsSchema (0x05), PolicyDataWasm (0x06),
   PolicyDataParamsSchema (0x07), SecretsSchema (0x08).
4. Begin Stream B Task B1 in parallel — IPolicyRegistry interface with BlobReference Solidity type.
5. Phase 1.5 hardening — instanceId snapshot at task creation; switch use_ipfs_resolver default to false.
6. Phase 2 cleanup — delete IPFS resolver code; consider atomic bundle multicall (Option A).

Aligned Directions (discussed, not implemented)

• Sub-A primitive reuse — Sub-B will share Sub-A's StateCommitRegistry, IStateRootCommittable, JMT, EigenDaClient, BootnodeServer,
  NamespaceId infrastructure unchanged.
• Three-layer drift defense as protocol pattern — both Sub-A and Sub-B implement it; future on-chain-bytes work should follow the same
  L1-deploy / L2-eval / L3-challenge pattern.
• Five-tier cache as standard for content-addressed artifacts — LayeredArtifactCache<L0,L1,L2,L3,L4> reusable for any future
  committed-bytes class.

Open Questions

• Linear project name for Sub-B — likely Onchain Policy Storage or similar; not yet created.
• Atomic bundle multicall priority — Phase 2 deferral assumes atomic deploy is not blocking for Phase 1 launches. Re-evaluate after
  first Phase 1 client onboards.
• Quickstart policy migration ordering — 14 quickstart policies; should they migrate one batch or staggered? Sub-A pattern was one batch
  via deploy script.

Relevant Links

• Spec (gitignored): docs/superpowers/specs/2026-04-22-onchain-policy-storage-design.md
• Plan (gitignored): docs/superpowers/plans/2026-04-22-onchain-policy-storage-plan.md
• Sub-A spec (PR #570 merged): docs/PRIVATE_DATA_STORAGE.md
• Sub-A plan (gitignored): docs/superpowers/plans/2026-04-20-private-data-migration-plan.md
• Sub-A memory: project_private_data_storage.md (sibling file in this dir)

---

Anything to add, correct, or remove before I save this across all 3 systems?

✻ Cooked for 3m 5s

25 tasks (17 done, 1 in progress, 7 open)
◼ Transition to writing-plans skill for implementation plan
◻ Propose 2-3 approaches with trade-offs
◻ Present design sections for approval
◻ Apply 10-item delta report (scope C)
◻ Verification pass 2
… +3 pending, 17 completed

Open Questions Q.1–Q.7 in the document need resolution before stream-by-stream execution starts — most notably the JSON Schema
validator library choice (Q.2), quickstart-policy migration ordering (Q.3), and overlap with NEWT-1036 (Q.4). Implementation plan
execution mode (Subagent-Driven vs Inline) is still to be picked. --> Let's actually discuss this and align on this

⏺ Good call — let's actually work through these. Let me re-read the exact Q.1–Q.7 framing from the doc so we discuss what's actually
written, not what I remember.

Searched for 1 pattern, read 1 file (ctrl+o to expand)

⏺ Let's work through them. I'll give my read on each plus the question I'd ask back. We're discussing 8 items total (the deferred Q.0
execution-mode pick + Q.1–Q.7 in the doc).

★ Insight ─────────────────────────────────────

• Q.2, Q.3, and Q.4 are the only blockers. Q.0/Q.1 are workflow choices, Q.5/Q.6 are deferral decisions (default to "no, ship Phase 1"),
  Q.7 is documentation hygiene. The three real blockers all need an answer before stream A starts.
• Two of the three blockers are people-coordinated, not technical. Q.3 is "how does Newton ops sequence the Safe multisig sessions" and
  Q.4 is "when does NEWT-1036's deletion land relative to Sub-B's adds." Those answers come from you/Aaron and the team, not from spec
  analysis. Q.2 is the only one that can be resolved by benchmark.
• AddressesProviderConsumer immutable-caching means Q.4 is more interesting than it looks. If any contract on chain consumes
  IdentityRegistry/ConfidentialDataRegistry IDs from the provider today, it cached those addresses as immutables — so NEWT-1036's deletion
  doesn't hot-swap them. Sub-B's new contracts are net-new consumers with no prior immutable caching, so Q.4 is mostly about ordering
  registrar updates, not hot-swapping live consumers.
  ─────────────────────────────────────────────────

---

Q.0 — Execution mode for the 47-task plan

My recommendation: Subagent-Driven.

47 tasks × ~3-5 steps each won't fit one context window even with checkpoints. The two-stage review (subagent + me) catches drift on
Sub-B's intricate identity formulas (the 0x01 domain-separator byte on policyDataInstanceId, the chainId ‖ clientAddr ordering) — those
are exactly the kinds of details that get fuzzy when context is full. Inline only wins for <10-task plans where ceremony overhead
exceeds the benefit.

Question back: any reason to prefer Inline? (e.g., wanting to watch each task land in real-time, or tighter feedback on early tasks
before parallelizing?)

---

Q.1 — Linear project name

My recommendation: ship the provisional "Onchain Policy Storage."

This is naming bikeshed territory — both "On-chain" and "Onchain" are correct. Newton ops decides; doesn't block code. Mirroring Sub-A's
"Private Data Storage" (no hyphen in URLs) is reasonable.

Question back: want me to also pre-register the 47 Linear issues mirroring NEWT-1003..1052 conventions, or do that later when the plan
is closer to execution?

---

Q.2 — JSON Schema validator library (boon vs jsonschema)

My recommendation: benchmark first; default to jsonschema if inconclusive.

boon is lighter (~150-200KB smaller binary) but newer. jsonschema is mature with broader Draft 2020-12 coverage. The 14 quickstart
schemas are the natural test bed. Concrete proposal:

┌────────────┬───────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────┐
│ Library │ Strengths │ Risks │
├────────────┼───────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
│ boon │ Pure Rust, smaller deps, │ Newer (less battle-tested), some Draft 2020-12 features may be │
│ │ no_std-friendlier │ incomplete │
├────────────┼───────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
│ jsonschema │ Mature, broad coverage, active │ ~400KB heavier, may pull in async runtime indirectly │
│ │ maintenance │ │
└────────────┴───────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────┘

Stream A early: write the 14 quickstart schemas, run both validators, pick whichever passes 100% of the suite with the cleanest API. If
both pass, take boon for the smaller footprint.

Question back: is binary footprint (operator daemon size) actually a constraint we care about right now, or is correctness/maturity the
only axis?

---

Q.3 — Quickstart migration ordering

My recommendation: staged 3 + 5 + 6, NOT one batch.

This is the most consequential ops decision in the list. Reasoning:

• Single batch (14 in one Safe session): faster, but a single hash-mismatch or schema-validation surprise rolls back 14 deploys. The L1
  drift-detection layer (registerTemplate rejects keccak256 mismatch) is new code — not yet field-tested at scale.
• Staged (3 + 5 + 6): first batch should be the simplest policies (single-domain or read-only). If something surfaces, we catch it on 3
  instead of 14. Safe multisig overhead per batch is ~10-20 min — three sessions across a week is cheap insurance.

The G2 ChallengeVerifier re-derivation hook is also new; staging gives Newton ops a real-world signal that on-chain policyTemplateRef
values match what challengers expect before all 14 are exposed.

Question back: which of the 14 quickstart policies are the simplest / most tested today? That informs the first batch.

---

Q.4 — NEWT-1036 overlap

My recommendation: NEWT-1036 lands first, Sub-B's adds land after.

NEWT-1036 (deletes IdentityRegistry + ConfidentialDataRegistry) is independent of Sub-B's net-new PolicyRegistry + PolicyDataRegistry.
They could ship in either order, but landing NEWT-1036 first keeps the provider directory smaller and avoids a transitional window where
the provider has both the deprecated entries and Sub-B's adds.

The immutable-caching concern only matters if there are existing consumers of the deleted IDs — which there will be (the registries'
direct consumers). NEWT-1036 has to handle redeployment of those consumers regardless of Sub-B. Sub-B's consumers are net-new, so they
only see the post-deletion provider state.

Question back: is NEWT-1036 ready to ship, or is its blocker the same as Sub-B's (waiting for Sub-A primitives to soak)? If they're both
gated on the same thing, sequencing them serially is the safer call.

---

Q.5 — Atomic-bundle priority (Phase 2 multicall)

My recommendation: defer to Phase 2 backlog as documented.

The "deploy-then-update-pointer" race window is exactly one block on most chains and only matters if an observer queries
currentPolicyInstance[client] between the two txs. For Phase 1 — where clients control their own deploys — this is acceptable. Pull it
forward only if real-world ops surface frequent friction.

Question back: any known external dependency that observes currentPolicyInstance[client] mid-deploy and would break under the race
window?

---

Q.6 — policyParams on-chain mirror

My recommendation: ship Phase 1 with the on-chain mirror.

The 14 quickstart policyParams payloads are small (likely <1KB each, mostly string addresses + numeric thresholds). On-chain storage
cost is bounded. Moving to EigenDA-backed policyParamsRef adds challenger-side fetch + KZG verification complexity — unjustified at MVP
scale.

Threshold to reconsider: any single policyParams exceeding 8KB, or storage cost on Base/L2s becoming visible in operator economics.

Question back: is there a known upcoming policy with policyParams >2KB? If so, that flips the calculus.

---

Q.7 — Secrets schema ↔ HPKE envelope versioning

My recommendation: keep independent (as Phase 1 ships); document the orthogonality.

Coupling them would force an envelope rotation on every schema update — costly entanglement for no security benefit. The envelope_format
byte (0x03 namespace) describes how bytes are encrypted; the secrets schema (0x08 namespace) describes what fields are in the
plaintext. These are genuinely orthogonal — a _v2 schema with new fields can live under the same SECRETS_ENVELOPE_V1 envelope as long as
the new fields fit in the existing encrypted blob.

The doc already describes the failure mode (WASM eval fails deterministically when a required field is absent) — that's enough.

Question back: none from me on this one. It's a "default to keeping things uncoupled" decision unless someone has a concrete pairing
reason.

---

Summary table

┌─────┬─────────────────────────────────────┬────────────────┬──────────────────────────────────────┐
│ Q │ My pick │ Confidence │ Needs you to confirm? │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.0 │ Subagent-Driven │ High │ Yes │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.1 │ "Onchain Policy Storage" │ Low (bikeshed) │ Yes │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.2 │ Benchmark first; default jsonschema │ Medium │ No (handled in stream A) │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.3 │ Staged 3 + 5 + 6 │ High │ Yes │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.4 │ NEWT-1036 first, Sub-B after │ Medium │ Yes (depends on NEWT-1036 readiness) │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.5 │ Defer to Phase 2 │ High │ Yes (sanity check) │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.6 │ On-chain mirror │ High │ Yes (sanity check) │
├─────┼─────────────────────────────────────┼────────────────┼──────────────────────────────────────┤
│ Q.7 │ Keep independent │ High │ Yes (sanity check) │
└─────┴─────────────────────────────────────┴────────────────┴──────────────────────────────────────┘

What's your read on each? Which of my recommendations are wrong, which want different framing, and which are you fine with as-is?

✻ Crunched for 2m 7s

※ recap: Goal: lock Sub-B (on-chain policy storage) protocol decisions before implementing the 47-task plan. Current task: align on Q.0
execution mode plus Q.1–Q.7 from the doc. Next action: react to my recommendations in the summary table.