# IDEATE — v1.25 kyverno-json Unified Policy Engine

> **Autonomy:** full. 3-tier ideation per `config.json ideation.enabled:
> true`. `cross_project.enabled: false` → cross-project tier scoped to
> single-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 — Regression-gate-as-policy ✅ ACCEPTED (REQ-304, REQ-305)

**Category:** quality, coverage
**Confidence:** 0.90
**Pattern:** imperative check → declarative policy (the milestone's
core thesis applied to Nova's own regression gate).
**Source:** `core/regression_verify.py` (CAP-013, CAP-023, CAP-024)
are imperative Python checks. The milestone makes compliance
declarative; Nova's own capability regression should follow.
**Idea:** Port the three capability checks into
`adapters/kyverno-json/policies/regression/` as declarative policies
over the capability-inventory JSON frontmatter. The imperative
`regression_verify.py` stays (it drives the CI gate); the policies are
the declarative mirror that makes capability regression auditable as a
policy artifact.
**Accepted into:** REQ-304 (policies), REQ-305 (tests). Phase P4.

### I2 — Contract-shape validation as policy ✅ ACCEPTED (REQ-295)

**Category:** security, architecture
**Confidence:** 0.92
**Pattern:** jsonschema constraint → declarative policy (same constraint,
different language, Nova posture on top).
**Source:** `schemas/contract.schema.json` required/pattern/enum.
**Idea:** The 4 contract policies (`require-id-pattern`,
`require-env-in-enum`, `require-infrastructure-min-1`, `forbid-unknown-
fields`) are the declarative equivalent of the jsonschema constraints —
they let Nova apply its own compliance posture (e.g. forbid a specific
env for a specific consumer) on top of schema validity without editing
the jsonschema.
**Accepted into:** REQ-295. Phase P2.

### I3 — Stack-IR imperative rules → declarative policies ✅ ACCEPTED (REQ-297)

**Category:** security, architecture
**Confidence:** 0.88
**Pattern:** imperative Python rule → declarative kyverno-json policy.
**Source:** `adapters/terraform/policy/custom_rules/nova_tagging.py`
(tagging), the v1.0 demo `public-ingress: true` rule, the v1.8
D-encryption-default rule.
**Idea:** Port the three highest-impact imperative rules into
declarative kyverno-json policies over the resolved Stack IR. The
tagging rule is a cross-check (D-118 — both engines, agree meta-policy);
public-ingress and encryption-by-default are kyverno-json only (the IR
is the earliest point these can be caught).
**Accepted into:** REQ-297. Phase P2.

## Tier 2 — Backend-enriched (signal-driven)

### I4 — Plan-JSON Checkov RULE_MAP → kyverno-json mirrors ✅ ACCEPTED (REQ-300)

**Category:** security, coverage
**Confidence:** 0.85
**Pattern:** existing engine rule → declarative mirror in the new engine
(defense-in-depth against engine drift).
**Source:** `checkov_adapter.py:RULE_MAP` (CKV_AWS_41/45/46, CKV_AWS_1/40,
CKV_AWS_7/33).
**Idea:** Port the 6 Checkov rules over `terraform_plan` into declarative
kyverno-json policies over `terraform show -json` output. The Checkov
rules stay the source of truth for HCL scanning; the kyverno-json
policies are mirrors (different rule language, same plan JSON). Defense-
in-depth: if Checkov and kyverno-json disagree on the same plan, the
divergence is visible (two PCRs with different results for the same
resource).
**Accepted into:** REQ-300. Phase P3.

### I5 — Meta-policy over the merged PCR list ✅ ACCEPTED (REQ-303)

**Category:** architecture, quality
**Confidence:** 0.90
**Pattern:** the policy result list is itself a policy target (the most
novel use of kyverno-json in v1.25).
**Source:** `core/confidence_signal.py` PENALTY hardcode (critical
override), the D-118 tagging cross-check.
**Idea:** `block-on-any-critical` (declarative "critical = block") +
`tagging-rules-agree` (Checkov vs kj agree). The meta-policies consume
the merged PCR list as their payload. The critical-block meta-policy is
the declarative source of truth; the `confidence_signal.py` hard-override
stays as defense-in-depth (D-119).
**Accepted into:** REQ-303. Phase P3.

### I6 — Env-transition destroy as a declarative policy ❌ DEFERRED

**Category:** improvement
**Confidence:** 0.55 (below threshold — deferred, not rejected)
**Pattern:** imperative lifecycle Python → declarative policy.
**Source:** `core/env_transition.py` (v1.24 detect-and-destroy).
**Idea:** The v1.24 env-transition destroy logic (detect env change via
DynamoDB, destroy prior env, fail-closed) is imperative Python. A
declarative kyverno-json policy could assert "if `environment` changed
on a stable `contract.id`, a destroy event MUST precede the apply" —
turning the lifecycle enforcement into an auditable policy artifact.
**Reason deferred:** The env-transition logic is *stateful* (DynamoDB
queries, terraform state inspection) — kyverno-json policies are
*stateless* (payload in, PCRs out). A policy can assert the *contract*
shape (the env value is valid) but not the *lifecycle* (the prior env
was destroyed). The stateful check stays in `core/env_transition.py`;
a future milestone could emit a `nova.env.destroyed` event that a
kyverno-json policy then asserts is present in the evidence stream
(event-as-policy). Recorded as a future-idea, not a v1.25 requirement.

### I7 — Drift detection as policy ❌ DEFERRED

**Category:** security, coverage
**Confidence:** 0.40 (below threshold — deferred)
**Pattern:** scheduled job → policy over the drift report.
**Source:** NORTH_STAR.md Non-Goal #4 (drift detection scheduled job,
deferred — D-096 + no scheduler).
**Idea:** A kyverno-json policy over a terraform drift report could
assert "no drifted resources" declaratively. But drift detection itself
requires a scheduled `terraform plan -detailed-exitcode` job, which is
deferred (no scheduler). The policy is the easy part; the emitter is the
blocking dependency.
**Reason deferred:** Blocked by D-096 + no scheduler (same as NORTH_STAR
Non-Goal #4). The policy shape is documented for when the emitter ships.

## Tier 3 — Cross-project (deferred — single project)

### I8 — 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:** ACDL is single-project (`active_projects: ["acdl"]`).
Cross-project ideation is disabled in config. Recorded for when the
org grows.

## Summary

- 5 ideas accepted (I1..I5) → already captured as REQ-295, REQ-297,
  REQ-300, REQ-303, REQ-304, REQ-305.
- 3 ideas deferred (I6, I7, I8) 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 user asked for
  ("ideate and explore how it can be used within the Nova platform to
  improve quality of the platform checks"): I1 (regression-gate-as-
  policy) is the headline quality improvement; I4 + I5 are the defense-
  in-depth coverage improvements; I2 + I3 are the architecture
  improvements (imperative → declarative).
- No new requirements added beyond REQ-291..309 (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 stage and explicitly captured.