# IDEATE — v1.26 Live Pilot Estate Activation > **Autonomy:** full. 3-tier ideation per `config.json ideation.enabled: > true`. `cross_project.enabled: false` → cross-project tier scoped to > multi-project (deferred ideas only, no cross-project candidates > accepted). `confidence_threshold: 0.6`, `max_ideas: 20`. > Categories: security, quality, architecture, coverage, improvement. ## Tier 1 — Mechanical (pattern-driven, codebase-grounded) ### I1 — Outcome-backfill emitter ✅ ACCEPTED (REQ-317) **Category:** quality, coverage **Confidence:** 0.92 **Pattern:** stuck `pending` status → backfilled from a later event (the most direct metric-grounding pattern). **Source:** `core/metrics/decision_ledger.py:210-211` documents the event chain `confidence.computed → ai.decision.made → attestation.recorded → run.completed/failed`. `collector.py:262` inserts `fact_decision.outcome` as `"pending"` — no backfill step wires `run.completed/failed` back into the decision's outcome. The AI Decision Accuracy metric (`trust_snapshot.py:70-85`) reads `decisions WHERE outcome='succeeded' ÷ total` → 0% today (all pending). **Idea:** `core/metrics/outcome_backfill.py` reads run-manifest `completed`/`failed` events and updates `fact_decision.outcome` + `fact_decision.backfilled_at`. The collector invokes backfill after run completion. Grounds AI Decision Accuracy (Post-Pilot target). **Accepted into:** REQ-317. Phase P3. ### I2 — `reason='confidence'` escalation tag ✅ ACCEPTED (REQ-318) **Category:** quality, coverage **Confidence:** 0.90 **Pattern:** boolean field → discriminated field (the metric-numerator precision pattern). **Source:** `core/confidence_signal.py:184` — a `block` band sets `human_override=True`. The Human Escalation Frequency metric (`docs/metrics/human_escalation_frequency.md:11-12`) is defined as `count(runs WHERE hitl_block=1 AND reason='confidence') ÷ total runs`. The `reason='confidence'` discriminator is not stored today. **Idea:** `ai.decision.made` gains `escalation_reason: 'confidence'` when `band == 'block'`. The collector persists it into `fact_run`. Grounds Human Escalation Frequency numerator. **Accepted into:** REQ-318. Phase P3. ### I3 — Env-JSON `state_backend` wiring reconciliation ✅ ACCEPTED (REQ-319) **Category:** architecture, improvement **Confidence:** 0.88 **Pattern:** unused config field → wired config field (the single-source-of-truth pattern). **Source:** `adapters/terraform/adapter.py:116-117` computes the state bucket as `nova-tfstate--us-east-1` from the `AWS_ACCOUNT_ID` env var — **not** from the env JSON's `state_backend.bucket`. The env JSON's `state_backend` field is currently unused by the live apply path. **Idea:** The adapter reads `env.state_backend.bucket` when present (falling back to the computed name for backwards compat). `dev.json` gets the real bucket name. Closes the wiring gap so the pilot's env JSON is the single source of truth. **Accepted into:** REQ-319. Phase P3. ### I4 — Pilot-readiness kyverno-json policy ✅ ACCEPTED (REQ-320) **Category:** security, architecture **Confidence:** 0.85 **Pattern:** runtime guard → declarative policy (the v1.25 thesis applied to pilot onboarding). **Source:** `core/environment_check.py:48-53` emits a stderr warning (non-fatal) when `account_id == "000000000000"` and env != dev. A warning is not a gate. The pilot should fail-closed if someone tries to apply against a placeholder account. **Idea:** A kyverno-json policy over the env JSON asserting `account_id != "000000000000"` before any apply. Declarative fail-closed gate. Extends v1.25's policy engine to the pilot-onboarding domain. **Accepted into:** REQ-320. Phase P3. ## Tier 2 — Backend-enriched (signal-driven) ### I5 — Settlement-finality kyverno-json policy ✅ ACCEPTED (REQ-315) **Category:** security, coverage **Confidence:** 0.82 **Pattern:** domain invariant → declarative policy (the v1.25 thesis applied to the securities domain — the most novel use of kyverno-json in v1.26). **Source:** The pilot's settlement service records matches as transactions on the chain; settlement finality = block commit. The NORTH_STAR Objective #2 (provable trust) says trust should be a policy artifact, not a promise. Today settlement finality is a runtime property of the chain; making it a declarative policy turns it into an auditable gate. **Idea:** A kyverno-json policy over the settlement-service status JSON asserting `all_committed: true` before any promotion (qa→prod). The securities-specific extension of v1.25's policy engine. The policy is skip-when-kj-absent (graceful). **Accepted into:** REQ-315. Phase P3. ### I6 — Pilot-estate regression capability (CAP-025) ✅ ACCEPTED (REQ-316) **Category:** quality, coverage **Confidence:** 0.88 **Pattern:** manual e2e → regression-gated capability (the v1.0 CAP pattern applied to the pilot). **Source:** `core/regression_verify.py` has CAP-013..024 (live-AWS + local tiers). The pilot estate is a new live-AWS capability — "contract resolve → adapter compile → terraform plan → policy scan → confidence signal → attestation → outbox record" against `581513795199`. Without a regression CAP, the pilot could silently decay. **Idea:** CAP-025 (live-pilot-apply) in the regression gate. The round-trip assertion. Grounds the pilot as a maintained capability, not a one-shot demo. **Accepted into:** REQ-316. Phase P3. ### I7 — DynamoDB L1 primitive ✅ ACCEPTED (REQ-322) **Category:** architecture, coverage **Confidence:** 0.95 **Pattern:** missing primitive → authored module (the v1.7 + v1.8 module-build-out pattern). **Source:** RESEARCH §3.4 — no `modules/l1/dynamodb/` exists. The blockchain exchange's ledger table needs it. The adapter is stateless/registry-driven (no `TYPE_MAP`); a new stack type requires a new L1 module, not an adapter change. **Idea:** Author `modules/l1/dynamodb/` (interface.json + terraform/main.tf + README.md + instance.json + registry.json entry). The single platform-side module build-out for the milestone. Follows the `s3`/`rds` primitive template. Encryption + PITR enabled per v1.8 NFR defaults. **Accepted into:** REQ-322. Phase P3. ### I8 — Stale `adapters/README.md` TYPE_MAP references ❌ DEFERRED (scope) **Category:** improvement **Confidence:** 0.70 (above threshold, but scoped into REQ-321) **Pattern:** stale doc → corrected doc. **Source:** `adapters/README.md:49-54` references the deleted `TYPE_MAP`/`INPUT_MAP`/`OUTPUT_MAP` — contradicts `adapter.py:1-11` + `modules/STANDARDS.md:212-214`. **Idea:** Fix the stale references as part of the docs phase. **Reason deferred as a standalone idea:** Already captured in REQ-321 (docs + adapter README). No new requirement needed — the fix lands in P4 docs. ## Tier 3 — Cross-project (deferred — multi-project, but cross-project sharing disabled) ### I9 — Cross-project policy sharing ❌ DEFERRED (config) **Category:** improvement **Confidence:** N/A **Pattern:** policies shared across projects in a multi-project org. **Source:** `config.json ideation.cross_project.enabled: false`. **Idea:** In a multi-project org, kyverno-json policies could be shared across projects (a tagging standard policy applies to all projects). **Reason deferred:** `cross_project.enabled: false`. Even though v1.26 is multi-project (acdl + nova-blockchain-exchange), cross-project *ideation* is disabled in config. Recorded for when the org grows + the flag is enabled. ### I10 — Consumer-repo CI scaffolding as a reusable template ❌ DEFERRED **Category:** improvement **Confidence:** 0.55 (below threshold — deferred, not rejected) **Pattern:** one-off CI → reusable template. **Source:** The consumer repo (`nova-blockchain-exchange`) needs its own CI (`ci.yml` — lint + pytest). If Nova expects many consumers, a reusable consumer-CI template would reduce onboarding friction. **Idea:** A `nova-consumer-template` repo (or a `.github/workflow-templates/` dir) that new consumers instantiate. **Reason deferred:** Nova has 1 consumer today (the pilot). A template is premature abstraction until the 2nd consumer arrives. The pilot's CI is authored directly (REQ-310..312 tests). Recorded for when the 3rd consumer onboards. ## Summary - 7 ideas accepted (I1..I7) → already captured as REQ-315, REQ-316, REQ-317, REQ-318, REQ-319, REQ-320, REQ-322. - 3 ideas deferred (I8 scoped into REQ-321; I9 config-disabled; I10 below threshold) with documented blocking reasons. - 0 ideas rejected (below-threshold ideas are deferred, not rejected — they may activate when their blockers lift). - The accepted ideas are the **quality improvement** the `--ideate` flag drives: I1 + I2 ground the Post-Pilot metrics (outcome backfill + escalation reason); I3 closes the env-JSON wiring gap; I4 + I5 extend v1.25's policy engine to the pilot domain (pilot-readiness + settlement-finality); I6 gates the pilot as a maintained capability; I7 is the single platform-side module build-out. - No new requirements added beyond REQ-310..322 (the accepted ideas are already scoped into the existing requirements). The IDEATE pass validated the requirement set rather than expanding it — the ideas were anticipated in the SPECIFY + RESEARCH stages.