Compare commits
5 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Jon Chery
|
5b5e24d535 | ||
|
Jon Chery
|
85c500e45a | ||
|
Jon Chery
|
301aa2c8d8 | ||
|
Jon Chery
|
707a7dbe9b | ||
|
Jon Chery
|
e7866fda84 |
@@ -0,0 +1,66 @@
|
||||
# Nova — The Autonomous Cloud Delivery Platform: Autonomy Defensibility Brief
|
||||
|
||||
> Strategic direction, leadership metrics & unified story
|
||||
> Last refined: v1.21 — reframe from "no-humans" to "autonomous operations"
|
||||
|
||||
## The thesis
|
||||
|
||||
Nova is the autonomous infrastructure layer that lets product teams
|
||||
ship without engaging an operator, and lets executives trust the
|
||||
platform not because it never fails but because every decision is
|
||||
captured, scored, and accountable.
|
||||
|
||||
**Autonomy in operations; human at stage gates.** Normal operations —
|
||||
provisioning, healing, remediation — run without an operator in the
|
||||
loop. Human attestation remains required at stage gates: QA signs off
|
||||
for production, SRE greenlights based on operational readiness. The
|
||||
absence of an operator in the loop is never the absence of a record.
|
||||
|
||||
## Grounded proof (measurable today)
|
||||
|
||||
| Proof | Source | Status |
|
||||
|-------|--------|--------|
|
||||
| Capabilities verified, none broken (live-AWS caps honestly skipped, resources torn down to zero-cost steady state) | regression report | grounded |
|
||||
| Decision Ledger captures 100% of automated decisions with outcome backfill | decision ledger store | grounded |
|
||||
| Attestation coverage: 100% of prod/dr promotions attested by a human | attestation gates + outbox | grounded |
|
||||
| Confidence-gated policy engine (deterministic, not an LLM) — weighted inputs, band outcome | confidence signal | grounded |
|
||||
| Attestation matrix with separation-of-duties on prod | attestation matrix + separation-of-duties | grounded |
|
||||
| Pre-apply cost estimates (offline) | cost adapter | grounded |
|
||||
| Test suite passes | test results | grounded |
|
||||
|
||||
## Deferred proof (measurable when blocking work lifts)
|
||||
|
||||
| Proof | Blocking work | Unblock requirement |
|
||||
|-------|----------------|---------------------|
|
||||
| Touchless resolution rate across production estates | 0 consumers today | Pilot estate activation |
|
||||
| Live infrastructure health (ECS, ALB, RPS) | Live AWS torn down | Live AWS re-provisioning |
|
||||
| Onboarding funnel: requested → granted | Auto-grant not built | Auto-grant implementation |
|
||||
| Drift auto-reversal rate | No drift scheduler | Drift detection scheduler |
|
||||
| Predictive vs reactive ratio | No emitter | ML anomaly-forecasting service |
|
||||
| Tamper-evident ledger checkpoints (S3 Object Lock + JWS) | Audit ledger build-out | Audit ledger build-out |
|
||||
|
||||
## Anti-claims (what Nova is NOT)
|
||||
|
||||
1. **Nova's decisions are NOT made by an LLM.** They are made by a
|
||||
confidence-gated policy engine: deterministic scripts calculate a
|
||||
score, and a band outcome gates the action. The platform functions
|
||||
without AI. The Decision Ledger captures this real decision path —
|
||||
not a fabricated "AI agent." When an LLM planner is added, it will
|
||||
emit richer `alternatives_considered` without schema breakage.
|
||||
2. **Nova does NOT remove humans from accountability.** Only from
|
||||
normal operations. Every stage-gate promotion (qa/prod/dr) requires
|
||||
a human attestation recorded with approver identity,
|
||||
separation-of-duties check, and the evidence matrix.
|
||||
3. **Nova is NOT for legacy, untagged, or freeform infrastructure.** It
|
||||
requires Terraform-managed, policy-aligned, fully-tagged inputs.
|
||||
4. **Nova does NOT fabricate metrics.** Every metric is grounded (cites
|
||||
a source), derived (documented formula), or deferred (cites the
|
||||
blocking work). No fabricated numbers in any deck slide or metrics
|
||||
entry (the "no fabrication" hard constraint).
|
||||
|
||||
## What "won" looks like
|
||||
|
||||
By month 18, Nova is the layer enterprise leadership points to when
|
||||
they say *"we don't have an infrastructure ops team anymore, and the
|
||||
audit trail is stronger than it ever was"* — and it is the layer their
|
||||
AI engineering teams reach for first when an agent needs to deploy.
|
||||
+57
-36
@@ -1,7 +1,7 @@
|
||||
# NORTH_STAR — Nova
|
||||
|
||||
> **Status:** Draft (pending interactive GRILL → final)
|
||||
> **Milestone:** v1.17 — Strategic Direction, Leadership Metrics & Unified Story
|
||||
> **Milestone:** v1.21 — Nova Deck Refinement & Pipeline Hardening
|
||||
> **Owner:** Product Owner
|
||||
> **Purpose:** Durable strategic intent. Read by CIAgent in every future
|
||||
> `/ci-run` so the platform's direction survives across milestones. This
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
## Vision
|
||||
|
||||
> **Infrastructure operations become invisible. Every environment
|
||||
> **Infrastructure operations become visible. Every environment
|
||||
> provisioned, every incident healed, every risk remediated — by an
|
||||
> autonomous system whose trustworthiness is provable, not promised.
|
||||
> Human attestation remains required at stage gates — QA signs off for
|
||||
@@ -22,9 +22,12 @@
|
||||
> operator is never in the loop of normal operations.**
|
||||
|
||||
Nova is the autonomous infrastructure layer that lets product teams ship
|
||||
without engaging an operator, and lets executives trust the AI not because
|
||||
it never fails but because every decision is captured, scored, and
|
||||
accountable.
|
||||
without engaging an operator, and lets executives trust the platform not
|
||||
because it never fails but because every decision is captured, scored,
|
||||
and accountable. The recurring theme across the platform is that
|
||||
**infrastructure operations become visible** — security posture,
|
||||
remediation velocity, reliability, and lead time are surfaced as
|
||||
queryable signals rather than hidden in tribal knowledge.
|
||||
|
||||
---
|
||||
|
||||
@@ -38,46 +41,64 @@ human by design; operational escalations (AI confidence too low to
|
||||
proceed) are the failure mode we drive toward zero. Everything else
|
||||
collapses if autonomy isn't real.
|
||||
|
||||
**2. Establish provable trust in AI decisions.**
|
||||
Build the audit substrate — Decision Ledger, confidence scoring, circuit
|
||||
breakers, blast-radius controls — that turns "autonomous" from a
|
||||
marketing claim into a defensible one. Trust is the moat. Features can be
|
||||
copied; an immutable, queryable decision history cannot.
|
||||
**2. Establish provable trust in automated decisions.**
|
||||
Trust is established by deterministic scripts that calculate a score and
|
||||
a band outcome that gates the action — the platform functions without AI.
|
||||
"AI decisions" are really automated decisions. The audit substrate —
|
||||
Decision Ledger, confidence scoring, circuit breakers, blast-radius
|
||||
controls — turns "autonomous" from a marketing claim into a defensible
|
||||
one. Trust is the moat. Features can be copied; an immutable, queryable
|
||||
decision history cannot.
|
||||
|
||||
**3. Deliver compounding, quantifiable ROI for customers.**
|
||||
Each quarter on Nova must reduce cloud spend, free engineering hours, and
|
||||
avoid downtime measurably. If the CFO can't point to a number that
|
||||
improves quarter-over-quarter, Nova fails its commercial test, regardless
|
||||
of how clever the AI is.
|
||||
Each quarter on Nova must show measurable improvement on four CTO-grade
|
||||
metrics, all of which flow into PowerBI views and are captured by the
|
||||
telemetry pipeline:
|
||||
|
||||
**4. Become the default substrate for agentic infrastructure consumption.**
|
||||
AI agents are already becoming the largest consumers of cloud
|
||||
infrastructure. Nova must be the platform through which those agents
|
||||
declare, deploy, and verify infrastructure — not a vendor scrambling into
|
||||
that market two quarters late.
|
||||
- **Lead Time** — from PR merge to production deployment (downward trend).
|
||||
- **Infrastructure Vulnerability Count** — open findings on deployed
|
||||
resources (downward trend, demonstrating that proactive scanning +
|
||||
remediation keeps up with the AI-era 0-day pace).
|
||||
- **MTTR** — for platform-detected and platform-remediated incidents.
|
||||
- **Cloud Spend Reduction** — on pilot estates vs. the pre-Nova
|
||||
baseline.
|
||||
|
||||
If leadership cannot point to a number that improves quarter-over-quarter
|
||||
on these four axes, Nova fails its commercial test, regardless of how
|
||||
clever the automation is.
|
||||
|
||||
**4. Integrate with externally owned development platforms — regardless of source.**
|
||||
Nova integrates with externally owned PDLC, SDLC, Agentic, and Citizen
|
||||
Developer platforms with no regard for the source of the intent. Nova
|
||||
provides a set of skills and MCP endpoints that help the developer or AI
|
||||
agent make their application production-grade. Regardless of the source,
|
||||
all intents to deploy to production go through the same rigorous
|
||||
controls, quality gates, attestation, and evidence stream. Nova is the
|
||||
layer any of those platforms reach for first when an agent needs to
|
||||
deploy — not a vendor arriving late to that market.
|
||||
|
||||
---
|
||||
|
||||
## Anti-Goals (5 — what Nova is fundamentally NOT)
|
||||
## Anti-Goals (4 — what Nova is fundamentally NOT)
|
||||
|
||||
1. **Not a Terraform, Kubernetes, or hyperscaler competitor.** We
|
||||
orchestrate them. Replacing them is the most expensive possible
|
||||
distraction from the value we create.
|
||||
2. **Not a general-purpose AI agent platform.** We are purpose-built for
|
||||
1. **Not a general-purpose AI agent platform.** We are purpose-built for
|
||||
infrastructure operations. Breadth here produces shallow tools; depth
|
||||
here wins the category.
|
||||
3. **Not a system that removes humans from accountability.** Only from
|
||||
operations. Every AI decision lands in an immutable ledger. Every
|
||||
stage-gate promotion (qa/prod/dr) requires a human attestation recorded
|
||||
with approver identity, separation-of-duties check, and the 8-concern
|
||||
evidence matrix. The absence of an operator is never the absence of a
|
||||
record.
|
||||
4. **Not for legacy, untagged, or freeform infrastructure.** Nova requires
|
||||
Terraform-managed, policy-aligned, fully-tagged inputs. We optimize for
|
||||
the disciplined 95%, not the chaotic 5%.
|
||||
5. **Not sold to operators.** Nova is sold to leadership on outcomes —
|
||||
cost, velocity, risk. Selling to operators inverts the incentive and
|
||||
breaks the autonomy thesis.
|
||||
2. **Not a system that removes humans from accountability.** Only from
|
||||
normal operations. Every automated decision lands in an immutable
|
||||
ledger. Every stage-gate promotion (qa/prod/dr) requires a human
|
||||
attestation recorded with approver identity, separation-of-duties
|
||||
check, and the evidence matrix. The absence of an operator in the
|
||||
loop is never the absence of a record.
|
||||
3. **Not an upstream development platform.** Nova does not own the
|
||||
product backlog, IDE workflows, code authorship, or application
|
||||
business logic. The PDLC is upstream; Nova integrates with it through
|
||||
a validated contract boundary — Nova never penetrates it.
|
||||
4. **Not a replacement for the Product Development Lifecycle (PDLC).**
|
||||
Nova governs infrastructure + delivery only. Product lifecycle
|
||||
decisions (what to build, when to ship, for whom) remain with the
|
||||
product team. Nova makes their intent production-grade; it does not
|
||||
own the intent.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
# Nova — The No-Humans Infrastructure Platform: Thesis Defensibility Brief
|
||||
|
||||
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-213)
|
||||
> Generated: 2026-08-04
|
||||
|
||||
## The thesis
|
||||
|
||||
Nova is the autonomous infrastructure layer that lets product teams
|
||||
ship without engaging an operator, and lets executives trust the AI
|
||||
not because it never fails but because every decision is captured,
|
||||
scored, and accountable.
|
||||
|
||||
**Autonomy in operations; human at stage gates.** The operator is
|
||||
removed from the loop of normal operations. Human attestation remains
|
||||
required at stage gates — QA signs off for production, SRE greenlights
|
||||
based on operational readiness. The absence of an operator is never
|
||||
the absence of a record.
|
||||
|
||||
## Grounded proof (measurable today)
|
||||
|
||||
| Proof | Source | Status |
|
||||
|-------|--------|--------|
|
||||
| 18 capabilities verified, 4 honestly skipped (0 broken) | `REGRESSION_REPORT.json` | grounded |
|
||||
| Decision Ledger captures 100% of AI decisions with outcome backfill | `metrics/decision_ledger.db` | grounded (this milestone) |
|
||||
| Attestation Coverage: 100% of prod/dr promotions attested by a human | `hitl_gates.py` + outbox `approver_*` | grounded |
|
||||
| Confidence-gated policy engine (not an LLM) — 6 weighted inputs, band outcome | `confidence_signal.py` | grounded |
|
||||
| 8-concern attestation matrix with separation-of-duties on prod | `attestation_matrix.py` + `separation_of_duties.py` | grounded |
|
||||
| Pre-apply cost estimates (Infracost, offline) | `infracost_adapter.py` | grounded |
|
||||
| Test suite passes (~656 tests) | `metrics/test-results.xml` | grounded |
|
||||
|
||||
## Deferred proof (measurable when blocking decisions lift)
|
||||
|
||||
| Proof | Blocking Decision | Unblock Requirement |
|
||||
|-------|-------------------|---------------------|
|
||||
| Touchless Resolution Rate ≥99% across production estates | 0 consumers today | Pilot estate activation |
|
||||
| Live infrastructure health (ECS, ALB, RPS) | D-096 | Live AWS re-provisioning |
|
||||
| Onboarding funnel: requested → granted | D-113/D-114/D-119 | Auto-grant implementation |
|
||||
| Drift auto-reversal rate ≥95% | D-096 + no scheduler | Drift detection scheduler |
|
||||
| Predictive vs reactive ratio ≥3:1 | future emitter | ML anomaly-forecasting service |
|
||||
| Tamper-evident ledger checkpoints (S3 Object Lock + JWS) | D-083 | Audit ledger build-out |
|
||||
|
||||
## Anti-claims (what Nova is NOT)
|
||||
|
||||
1. **Nova's "AI" is NOT an LLM planner.** It is a confidence-gated
|
||||
policy engine (confidence_signal + HITL gate). The Decision Ledger
|
||||
captures this real decision path — not a fabricated "AI agent" that
|
||||
doesn't exist yet (D-122). When an LLM planner is added, it will emit
|
||||
richer `alternatives_considered` without schema breakage.
|
||||
2. **Nova does NOT remove humans from accountability.** Only from
|
||||
operations. Every stage-gate promotion (qa/prod/dr) requires a human
|
||||
attestation recorded with approver identity, separation-of-duties
|
||||
check, and the 8-concern evidence matrix (NORTH_STAR Anti-Goal #3).
|
||||
3. **Nova is NOT for legacy, untagged, or freeform infrastructure.** It
|
||||
requires Terraform-managed, policy-aligned, fully-tagged inputs
|
||||
(NORTH_STAR Anti-Goal #4).
|
||||
4. **Nova does NOT fabricate metrics.** Every metric is grounded (cites
|
||||
a source file), derived (documented formula), or deferred (cites a
|
||||
blocking decision ID). No fabricated numbers in any deck slide or
|
||||
METRICS.md entry (the "no fabrication" hard constraint).
|
||||
|
||||
## What "won" looks like
|
||||
|
||||
By month 18, Nova is the layer enterprise leadership points to when
|
||||
they say *"we don't have an infrastructure ops team anymore, and the
|
||||
audit trail is stronger than it ever was"* — and it is the default
|
||||
substrate their AI engineering teams reach for first when an agent needs
|
||||
to deploy.
|
||||
@@ -186,8 +186,37 @@ def is_configured():
|
||||
return bool(os.environ.get("WIZ_API_TOKEN") and os.environ.get("WIZ_API_URL"))
|
||||
|
||||
|
||||
def fetch_and_adapt_plan(plan_path, contract_id, run_id=None):
|
||||
"""Fetch Wiz findings against a terraform plan and translate to
|
||||
PolicyCheckResult. REQ-250 (v1.21): Wiz scans the terraform plan
|
||||
output. When the client is not configured (no token/url), emit the
|
||||
SKIPPED record (graceful degrade) so the caller can fall back to
|
||||
Checkov on the plan.
|
||||
"""
|
||||
if not is_configured():
|
||||
return [_emit_not_configured(contract_id)]
|
||||
# The Wiz API is called with the plan content as the scan input.
|
||||
client = WizClient()
|
||||
issues = client.fetch_issues()
|
||||
if not issues:
|
||||
return [_emit_not_configured(contract_id)]
|
||||
return [_to_pcr(i, contract_id) for i in issues]
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
if len(sys.argv) != 3:
|
||||
print("usage: wiz_adapter.py <wiz_issues.json> <contract-id>", file=sys.stderr)
|
||||
sys.exit(2)
|
||||
print(json.dumps(adapt(sys.argv[1], sys.argv[2]), indent=2))
|
||||
import argparse
|
||||
parser = argparse.ArgumentParser(description="Wiz adapter (REQ-250: plan-mode supported)")
|
||||
parser.add_argument("wiz_json", nargs="?", help="wiz_issues.json (legacy positional mode)")
|
||||
parser.add_argument("contract_id_pos", nargs="?", help="contract-id (legacy positional mode)")
|
||||
parser.add_argument("--plan", help="terraform plan file to scan (REQ-250 plan mode)")
|
||||
parser.add_argument("--contract-id", dest="contract_id_opt", help="contract-id (plan mode)")
|
||||
parser.add_argument("--run-id", help="run-id for the plan scan (plan mode)")
|
||||
args = parser.parse_args()
|
||||
if args.plan:
|
||||
cid = args.contract_id_opt or ""
|
||||
out = fetch_and_adapt_plan(args.plan, cid, run_id=args.run_id)
|
||||
print(json.dumps(out, indent=2))
|
||||
elif args.wiz_json and args.contract_id_pos:
|
||||
print(json.dumps(adapt(args.wiz_json, args.contract_id_pos), indent=2))
|
||||
else:
|
||||
parser.error("either --plan <file> --contract-id <id> OR <wiz_issues.json> <contract-id>")
|
||||
@@ -593,32 +593,30 @@ def _check_cap_023_metrics_collector() -> Tuple[Status, str]:
|
||||
|
||||
|
||||
def _check_cap_024_deck_structure() -> Tuple[Status, str]:
|
||||
"""CAP-024: unified deck structure (v1.17).
|
||||
"""CAP-024: unified deck structure (v1.17 + v1.21 refinement).
|
||||
|
||||
Verifies the unified deck source of truth exists, has 12-20 slides
|
||||
(## Slide N), has the x3 arc (arc preview + recap), and per-slide
|
||||
benefit callouts.
|
||||
Verifies the unified deck source of truth exists, has 18 main slides
|
||||
(## Slide N) + 1 appendix, has the recap+ask closing, and per-slide
|
||||
benefit callouts. v1.21 renamed the deck + restructured to a 4-beat arc.
|
||||
"""
|
||||
import os
|
||||
deck_path = os.path.join(os.path.dirname(os.path.dirname(os.path.abspath(__file__))),
|
||||
"docs", "presentations", "nova-no-humans-platform.md")
|
||||
"docs", "presentations", "nova-autonomous-cloud-delivery.md")
|
||||
if not os.path.isfile(deck_path):
|
||||
return "Skipped", "unified deck not found"
|
||||
with open(deck_path) as f:
|
||||
content = f.read()
|
||||
slide_count = content.count("## Slide ")
|
||||
if slide_count < 12 or slide_count > 20:
|
||||
return "Broken", f"deck has {slide_count} slides (expected 12-20)"
|
||||
has_arc_preview = "Arc Preview" in content
|
||||
if slide_count < 18 or slide_count > 19:
|
||||
return "Broken", f"deck has {slide_count} main slides (expected 18-19)"
|
||||
has_recap = "Recap + Ask" in content
|
||||
has_benefit = content.count("Benefit:") >= 10
|
||||
if not (has_arc_preview and has_recap and has_benefit):
|
||||
if not (has_recap and has_benefit):
|
||||
missing = []
|
||||
if not has_arc_preview: missing.append("arc preview")
|
||||
if not has_recap: missing.append("recap+ask")
|
||||
if not has_benefit: missing.append("per-slide benefit callouts")
|
||||
return "Broken", f"deck missing: {missing}"
|
||||
return "Verified", f"deck has {slide_count} slides, x3 arc present, per-slide benefits present"
|
||||
return "Verified", f"deck has {slide_count} slides, recap+ask present, per-slide benefits present"
|
||||
|
||||
|
||||
# Registry: ordered, each entry is (capability_id, name, tier, check_fn).
|
||||
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
# Nova Onboarding — No-Humans Request Path (v1.16, REQ-182..184)
|
||||
# Nova Onboarding — Autonomous Request Path (v1.16, REQ-182..184)
|
||||
|
||||
The v1.16 milestone implements the **request path** of the no-humans
|
||||
The v1.16 milestone implements the **request path** of the autonomous
|
||||
onboarding flow (D-113). A consumer can submit an onboarding request
|
||||
without contacting the platform team; the platform generates an
|
||||
environment binding + (in a future milestone) provisions the AWS resources.
|
||||
|
||||
+69
-160
@@ -13,17 +13,18 @@ every deck and a presenter-ready cue sheet for delivery.
|
||||
|
||||
```
|
||||
Step 1: full markdown Step 2: Marp deck Step 3: HTML + PPTX Step 4: Talking points
|
||||
(source of truth) ──► (lean, 10 slides) ──► (rendered) ──► (presenter cues)
|
||||
(source of truth) ──► (lean, 19 slides) ──► (rendered) ──► (presenter cues)
|
||||
*.md *-marp.md *.html / *.pptx *-talking-points.md
|
||||
+ speaker notes + embedded PNG diagrams + 3-6 bullets per slide
|
||||
+ mermaid code blocks + Marp frontmatter + key takeaway per slide
|
||||
+ maturity badges + indexed by Marp slide #
|
||||
+ no speaker notes + content distilled from Step 1
|
||||
+ no speaker notes + indexed by Marp slide #
|
||||
+ no maturity badges + content distilled from Step 1
|
||||
+ no version in footer
|
||||
```
|
||||
|
||||
### Step 1 — Full markdown (source of truth)
|
||||
|
||||
**File convention:** `<deck-name>.md` (e.g. `nova-no-humans-platform.md`).
|
||||
**File convention:** `<deck-name>.md` (e.g. `nova-autonomous-cloud-delivery.md`).
|
||||
|
||||
Write the complete deck as a standard markdown file. This is the **source of
|
||||
truth** — it contains:
|
||||
@@ -34,9 +35,9 @@ truth** — it contains:
|
||||
the "who cares and why," and the honesty caveats.
|
||||
- Mermaid diagrams as ```` ```mermaid ```` fenced code blocks (these render
|
||||
on GitHub/Pages but not in Marp — Step 2 converts them to images).
|
||||
- An honest "shipped vs. planned" framing: every "available today" claim is
|
||||
grounded in shipped/verified work; every "planned" item is explicitly
|
||||
marked.
|
||||
- An honest "shipped vs. deferred" framing: every "available today" claim is
|
||||
grounded in shipped/verified work; every "deferred" item is explicitly
|
||||
marked with the blocking work in plain language.
|
||||
|
||||
**Why this file is the source of truth:** it is reviewable in any markdown
|
||||
viewer, diffs cleanly in git, and carries the full reasoning (speaker notes)
|
||||
@@ -45,13 +46,13 @@ fact is wrong, fix it here and re-run Steps 2 and 3.
|
||||
|
||||
### Step 2 — Marp deck synthesis
|
||||
|
||||
**File convention:** `<deck-name>-marp.md` (e.g. `nova-no-humans-platform-marp.md`).
|
||||
**File convention:** `<deck-name>-marp.md` (e.g. `nova-autonomous-cloud-delivery-marp.md`).
|
||||
|
||||
Synthesize the full markdown into a lean Marp deck:
|
||||
|
||||
- **Marp frontmatter** at the top: `marp: true`, `theme: default`,
|
||||
- **Marp frontmatter** at the top: `marp: true`, `theme: nova-sp`,
|
||||
`paginate: true`, `size: 16x9`, a header/footer, and an inline `style:`
|
||||
block for fonts, colors, tables, badges.
|
||||
block for fonts, colors, tables.
|
||||
- **No speaker notes.** The Marp deck is what the audience sees; the
|
||||
speaker notes live only in the Step 1 source of truth.
|
||||
- **Mermaid diagrams → PNG images.** Marp does not render mermaid fenced
|
||||
@@ -60,8 +61,10 @@ Synthesize the full markdown into a lean Marp deck:
|
||||
and embed it with ``.
|
||||
- **`<!-- _class: title -->` + `<!-- _paginate: false -->`** on title and
|
||||
closing slides for the dark-background title style.
|
||||
- **Maturity badges** using inline spans:
|
||||
`<span class="badge planned">Planned</span>`
|
||||
- **No maturity badges.** The deck no longer uses `<span class="badge">`
|
||||
spans. Deferred items are named in plain language with their blocking
|
||||
work, not tagged with a badge.
|
||||
- **No version in the footer.** The footer carries the deck title only.
|
||||
- **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the
|
||||
leadership-relevant selling points.
|
||||
|
||||
@@ -69,10 +72,8 @@ Synthesize the full markdown into a lean Marp deck:
|
||||
|
||||
Both formats are derived from the Marp deck. **HTML is committed to the repo**
|
||||
(viewable in any browser, self-contained with base64-embedded images). **PPTX
|
||||
is uploaded to the release** as a downloadable attachment (binary, not
|
||||
committed to git).
|
||||
|
||||
#### HTML export (committed to repo)
|
||||
is also committed to the repo** as a first-class binary artifact and is
|
||||
attached to the phase's release via `scripts/attach_release_asset.py`.
|
||||
|
||||
```bash
|
||||
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
|
||||
@@ -81,135 +82,67 @@ CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
|
||||
-o docs/presentations/<deck-name>.html
|
||||
```
|
||||
|
||||
HTML export inlines images as base64 data URIs — no `--allow-local-files`
|
||||
needed for self-contained output, but it's required when the Marp deck
|
||||
references local PNG assets. The resulting HTML is a single self-contained
|
||||
file that renders the full deck with the S&P Global Energy theme.
|
||||
|
||||
**Re-render the HTML whenever the Marp source changes.** The HTML files are
|
||||
committed artifacts, not generated on-the-fly — they must be re-rendered and
|
||||
re-committed when the Marp deck is updated.
|
||||
|
||||
#### PPTX export (uploaded to release)
|
||||
|
||||
```bash
|
||||
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
|
||||
npx --yes @marp-team/marp-cli@latest --allow-local-files \
|
||||
docs/presentations/<deck-name>-marp.md \
|
||||
-o <output-path>.pptx
|
||||
```
|
||||
|
||||
The `--allow-local-files` flag is **required** for PPTX export so the local
|
||||
PNG diagrams are embedded in the file. As of v1.18 (REQ-228, D-141), PPTX
|
||||
files **are committed to the repo** as first-class binary artifacts (no LFS)
|
||||
and are also attached to the phase's release via
|
||||
`scripts/attach_release_asset.py`. The render + commit + attach pipeline is
|
||||
automated by `scripts/render_deck.sh`.
|
||||
HTML export inlines images as base64 data URIs. PPTX export requires
|
||||
`--allow-local-files` so the local PNG diagrams are embedded in the file.
|
||||
The render + commit + attach pipeline is automated by `scripts/render_deck.sh`
|
||||
and `scripts/render_slides.sh`.
|
||||
|
||||
### Step 4 — Talking points (presenter cues)
|
||||
|
||||
**File convention:** `<deck-name>-talking-points.md` (e.g.
|
||||
`nova-no-humans-platform-talking-points.md`).
|
||||
`nova-autonomous-cloud-delivery-talking-points.md`).
|
||||
|
||||
Distill the source of truth (Step 1) into presenter-ready cues, indexed by
|
||||
the Marp deck (Step 2) slide structure:
|
||||
|
||||
- **One section per Marp slide** — `## Slide N — Title`, matching the Marp
|
||||
deck's 11 main + Appendix TOC + appendix slide structure exactly. The Marp deck
|
||||
provides the indexing and context (what the audience sees); the source
|
||||
markdown provides the content (the speaker notes, the detail, the nuance).
|
||||
deck's 18 main + 1 appendix slide structure exactly.
|
||||
- **3-6 talking point bullets per slide** — punchy, actionable cues distilled
|
||||
from the source markdown's speaker notes. NOT the speaker notes verbatim
|
||||
(those are too long and too contextual). These are prompts: "Land this
|
||||
point," "Contrast with X," "Be honest about Y."
|
||||
from the source markdown's speaker notes.
|
||||
- **Key takeaway per slide** — the one memorable thing the audience should
|
||||
walk away with from that slide.
|
||||
- **No content duplication** — the talking points reference the Marp slides
|
||||
for visual context and the source markdown for full detail. They don't
|
||||
repeat either; they bridge them.
|
||||
|
||||
**Why this file exists:** a presenter needs a cue sheet they can glance at
|
||||
during delivery — not the full speaker notes (too long), not the Marp slides
|
||||
(no detail). The talking points file is the middle layer: what to say, in
|
||||
what order, with what emphasis, per slide.
|
||||
|
||||
**When to update:** re-distill the talking points whenever the Marp deck
|
||||
structure changes (slides added, removed, merged, or re-ordered) or whenever
|
||||
the source markdown's speaker notes are updated. The talking points are a
|
||||
*derived artifact* — if a fact is wrong, fix it in the source markdown (Step 1)
|
||||
and re-distill.
|
||||
for visual context and the source markdown for full detail.
|
||||
|
||||
## Directory layout
|
||||
|
||||
```
|
||||
docs/presentations/
|
||||
├── README.md ← this file
|
||||
├── nova-no-humans-platform.md ← Step 1: full source of truth (19 main slides + speaker notes)
|
||||
├── nova-no-humans-platform-marp.md ← Step 2: Marp deck (19 main + 2 appendix = 21 slides)
|
||||
├── nova-no-humans-platform.html ← Step 3: rendered HTML (committed, S&P-themed)
|
||||
├── nova-no-humans-platform.pptx ← Step 3: rendered PPTX (committed, S&P-themed)
|
||||
├── nova-no-humans-platform-talking-points.md ← Step 4: presenter cues (21 sections)
|
||||
├── nova-autonomous-cloud-delivery.md ← Step 1: full source of truth (18 main slides + speaker notes)
|
||||
├── nova-autonomous-cloud-delivery-marp.md ← Step 2: Marp deck (18 main + 1 appendix = 19 slides)
|
||||
├── nova-autonomous-cloud-delivery.html ← Step 3: rendered HTML (committed, S&P-themed)
|
||||
├── nova-autonomous-cloud-delivery.pptx ← Step 3: rendered PPTX (committed, S&P-themed)
|
||||
├── nova-autonomous-cloud-delivery-talking-points.md ← Step 4: presenter cues (19 sections)
|
||||
└── assets/
|
||||
├── nova-sp-theme.css ← S&P Global Energy Marp theme (all slide chrome)
|
||||
├── puppeteer-config.json ← no-sandbox config for mmdc
|
||||
├── mmd/ ← mermaid source files (Step 2 input)
|
||||
│ ├── sp-theme.json ← S&P Red/Black/White theme (mermaid-cli --configFile)
|
||||
│ ├── platform-architecture.mmd
|
||||
│ ├── road-to-north-star.mmd
|
||||
│ └── ... (per-slide .mmd files)
|
||||
└── png/ ← rendered mermaid PNGs (committed, S&P-themed)
|
||||
└── png/ ← rendered PNGs (embedded in Marp)
|
||||
├── platform-works-01-contract-driven.png
|
||||
├── platform-works-02-frictions.png
|
||||
├── platform-works-02-end-to-end-flow.png
|
||||
├── platform-works-03-north-star.png
|
||||
├── platform-works-03-scope-boundary.png
|
||||
├── platform-works-04-confidence-signal.png
|
||||
├── platform-works-05-attestation-flow.png
|
||||
├── platform-works-07-zero-trust.png
|
||||
├── developer-experience-01b-scope-boundary.png
|
||||
├── developer-experience-02-what-dev-does.png
|
||||
├── developer-experience-03-no-cloning.png
|
||||
├── developer-experience-04-promotion-journey.png
|
||||
├── developer-experience-05-catalog.png
|
||||
├── developer-experience-07-decommission.png
|
||||
├── developer-experience-08-semver.png
|
||||
├── platform-architecture.png ← shared high-level logical architecture (both decks)
|
||||
└── road-to-north-star.png
|
||||
```
|
||||
|
||||
## Conventions
|
||||
|
||||
### Appendix structure
|
||||
|
||||
Each Marp deck has **11 main slides + an Appendix TOC + appendix slides**. The
|
||||
main 11 are the presentation; the appendix is for deep dives and Q&A backup.
|
||||
The platform-works deck has 8 appendix slides (A1–A8); the developer-experience
|
||||
deck has 7 appendix slides (A1–A7). Both include an Appendix TOC slide.
|
||||
Each Marp deck has **18 main slides + 1 appendix slide**. The main 18 are the
|
||||
presentation; the appendix is for Q&A backup.
|
||||
|
||||
- **Main slides** (1-11): the story arc, high-impact, minimal text,
|
||||
visual-heavy. These are what the audience sees during the talk.
|
||||
- **Appendix slides** (TOC + A1..An): detail-heavy slides moved out of the
|
||||
main 10 to preserve the narrative flow. The appendix starts with a TOC
|
||||
slide listing the contents, followed by detail slides and a glossary.
|
||||
- **The Road to the North Star** is a required appendix slide in both decks
|
||||
— a phased timeline from v1.0 demo to the North Star, annotated as
|
||||
"proposed phasing, not formally planned."
|
||||
- **The Glossary** is a required appendix slide in both decks — defines
|
||||
acronyms (OIDC, ABAC, CMK, CMDB, RPO, HITL, VCS, NFR) for the audience.
|
||||
- **Main slides** (1-18): the story arc — Problem → Solution → Proof →
|
||||
Roadmap + Ask. These are what the audience sees during the talk.
|
||||
- **Appendix slide** (A1): the Metrics Glossary — detail-heavy reference for
|
||||
Q&A.
|
||||
|
||||
### Maturity framing
|
||||
### Honesty framing
|
||||
|
||||
Every capability claim in a deck is tagged with a `Planned` badge when the item is on the roadmap but not yet implemented:
|
||||
|
||||
| Badge | Meaning |
|
||||
|---|---|
|
||||
| `Planned` | On the roadmap, not yet implemented |
|
||||
|
||||
This is non-negotiable for a leadership audience: never present a roadmap
|
||||
item as a current capability, and never bury a tested capability's
|
||||
availability. When in doubt, check `.ciagent/ROADMAP.md` and the milestone
|
||||
status in `.ciagent/PROJECT.md`.
|
||||
Every capability claim in the deck is grounded, derived, or honestly
|
||||
deferred with its blocking work named in plain language. Internal provenance
|
||||
(decision IDs, requirement IDs, internal file paths) is kept out of the
|
||||
audience-facing slides — those live in the `.ciagent/` files only. When in
|
||||
doubt, check `.ciagent/ROADMAP.md` and the milestone status in
|
||||
`.ciagent/PROJECT.md`.
|
||||
|
||||
### Audience
|
||||
|
||||
@@ -221,8 +154,10 @@ Head of Infrastructure, Head of DevOps. The framing rules:
|
||||
"composition."
|
||||
- **Selling points forward.** Each slide leads with the leadership-relevant
|
||||
outcome; the mechanism follows.
|
||||
- **Zero-trust, security, observability, auditability, DX, citizen
|
||||
developer** are the themes — not implementation details.
|
||||
- **Security, remediation velocity, reliability, lead time, observability,
|
||||
citizen developer** are the themes — not implementation details.
|
||||
- **"Infrastructure operations become visible"** is the recurring theme across
|
||||
the deck.
|
||||
|
||||
### Diagrams
|
||||
|
||||
@@ -232,8 +167,7 @@ style (renders on GitHub/Pages). For the Marp deck (Step 2):
|
||||
1. Extract the mermaid block into `assets/mmd/<deck>-<slide>-<name>.mmd`.
|
||||
2. Use **horizontal layouts** (`flowchart LR`) or **subgraph row-wrapping**
|
||||
for wide diagrams so the PNG fits a 16:9 slide without shrinking to
|
||||
illegibility. A 9-node sequential `flowchart TD` renders as a tall thin
|
||||
strip — restructure it as 2-row subgraphs or `flowchart LR`.
|
||||
illegibility.
|
||||
3. Render with a 2x scale factor and transparent background for crisp slides.
|
||||
4. Embed with `` (or `h:320` for tall images).
|
||||
|
||||
@@ -261,42 +195,16 @@ for f in mmd/*.mmd; do
|
||||
done
|
||||
```
|
||||
|
||||
The `puppeteer-config.json` passes `--no-sandbox` to the headless browser
|
||||
(required when running as root in this environment). The `--configFile
|
||||
mmd/sp-theme.json` applies the S&P Global Red/Black/White theme (dark
|
||||
`#1B1B1B` accent nodes with `#D6002A` red borders, white supporting nodes,
|
||||
`#F0F0F0` subgraph backgrounds). Each `.mmd` file also carries the same
|
||||
theme inline via a `%%{init:...}%%` block so it renders correctly even
|
||||
without the `--configFile` flag.
|
||||
|
||||
### Export a Marp deck to HTML (committed to repo)
|
||||
### Render a Marp deck to HTML + PPTX (committed artifacts)
|
||||
|
||||
```bash
|
||||
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
|
||||
npx --yes @marp-team/marp-cli@latest --allow-local-files \
|
||||
docs/presentations/<deck-name>-marp.md \
|
||||
-o docs/presentations/<deck-name>.html
|
||||
bash scripts/render_slides.sh nova-autonomous-cloud-delivery
|
||||
```
|
||||
|
||||
HTML export inlines images as base64 data URIs. The `--allow-local-files`
|
||||
flag is needed when the Marp deck references local PNG assets (like the
|
||||
diagram images in `assets/png/`). The resulting HTML is self-contained.
|
||||
|
||||
**The HTML files are committed artifacts** — re-render and re-commit whenever
|
||||
the Marp source changes.
|
||||
|
||||
### Export a Marp deck to PPTX (uploaded to release)
|
||||
|
||||
```bash
|
||||
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
|
||||
npx --yes @marp-team/marp-cli@latest --allow-local-files \
|
||||
docs/presentations/<deck-name>-marp.md \
|
||||
-o <output-path>.pptx
|
||||
```
|
||||
|
||||
`--allow-local-files` is **required** for PPTX so local PNG diagrams are
|
||||
embedded in the file. PPTX files are not committed to git — upload them as
|
||||
attachments to the release.
|
||||
This renders all mermaid PNGs, the HTML, and the PPTX, and stages them for
|
||||
commit. The `--allow-local-files` flag is required so local PNG diagrams are
|
||||
embedded. Both HTML and PPTX are committed to the repo; the PPTX is also
|
||||
attached to the phase's release.
|
||||
|
||||
## Adding a new presentation
|
||||
|
||||
@@ -306,16 +214,14 @@ attachments to the release.
|
||||
2. **Extract any mermaid diagrams** into `assets/mmd/<deck-name>-<slide>-<name>.mmd`
|
||||
and render them to `assets/png/` (command above).
|
||||
3. **Synthesize the Marp deck** as `<deck-name>-marp.md` with frontmatter,
|
||||
no speaker notes, embedded PNGs, and maturity badges.
|
||||
4. **Render to HTML** with `--allow-local-files` and commit the HTML to
|
||||
`docs/presentations/<deck-name>.html`.
|
||||
5. **Render to PPTX** with `--allow-local-files` and upload to the release
|
||||
release (do not commit PPTX to git).
|
||||
6. **Distill the talking points** as `<deck-name>-talking-points.md` — one
|
||||
no speaker notes, embedded PNGs, and no badges.
|
||||
4. **Render to HTML + PPTX** via `scripts/render_slides.sh <deck-name>` and
|
||||
commit both to `docs/presentations/`.
|
||||
5. **Distill the talking points** as `<deck-name>-talking-points.md` — one
|
||||
section per Marp slide, 3-6 talking point bullets + key takeaway, content
|
||||
distilled from the source markdown (Step 1), indexed by the Marp deck
|
||||
(Step 2) slide structure.
|
||||
7. **Verify** the PPTX slide count and that media files are embedded:
|
||||
6. **Verify** the PPTX slide count and that media files are embedded:
|
||||
```bash
|
||||
python3 -c "
|
||||
import zipfile, re
|
||||
@@ -330,11 +236,14 @@ attachments to the release.
|
||||
|
||||
| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML + PPTX (Step 3) | Talking points (Step 4) | Slides | Audience |
|
||||
|---|---|---|---|---|---|---|
|
||||
| Nova — The No-Humans Infrastructure Platform | `nova-no-humans-platform.md` | `nova-no-humans-platform-marp.md` | `nova-no-humans-platform.html` + `.pptx` (committed + release-attached) | `nova-no-humans-platform-talking-points.md` | 19 main + 2 appendix (21) | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
| Nova — The Autonomous Cloud Delivery Platform | `nova-autonomous-cloud-delivery.md` | `nova-autonomous-cloud-delivery-marp.md` | `nova-autonomous-cloud-delivery.html` + `.pptx` (committed + release-attached) | `nova-autonomous-cloud-delivery-talking-points.md` | 18 main + 1 appendix (19) | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
|
||||
> **v1.18 (D-130):** the two legacy decks (How the Platform Works + The
|
||||
> Developer Experience) were consolidated into a single unified narrative
|
||||
> deck with a 5-act arc (Problem → Vision → How → Proof → Roadmap). v1.18
|
||||
> (REQ-226) adds 3 slides (17 Scope, 18 RACI, 19 Atelier) → 21 total. The
|
||||
> S&P Global Energy theme is restored (REQ-214, P1). PPTX is committed to
|
||||
> git + attached to the release (REQ-228, D-141).
|
||||
> **v1.21:** the deck was renamed from "No-Humans Infrastructure Platform"
|
||||
> to "Autonomous Cloud Delivery Platform" (professional framing; conveys
|
||||
> autonomy without the provocative wording). The narrative restructured to
|
||||
> a 4-beat arc (Problem → Solution → Proof → Roadmap + Ask). Internal
|
||||
> provenance (decision IDs, requirement IDs, file paths) removed from
|
||||
> audience-facing slides. Maturity badges removed. The RACI matrix expanded
|
||||
> to four roles (Quality Engineering + SRE). The Atelier slide split into
|
||||
> two. The pipeline hardened: Checkov on static code before the plan;
|
||||
> Wiz-or-Checkov on the plan (never both).
|
||||
@@ -0,0 +1,19 @@
|
||||
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#1B1B1B", "primaryBorderColor": "#D6002A", "primaryTextColor": "#fff", "secondaryColor": "#fff", "secondaryBorderColor": "#D6002A", "secondaryTextColor": "#1B1B1B", "tertiaryColor": "#F0F0F0", "clusterBkg": "#F0F0F0", "lineColor": "#1B1B1B", "fontFamily": "\"Akkurat Pro\", \"Helvetica Neue\", \"Arial\", sans-serif"}}}%%
|
||||
|
||||
flowchart LR
|
||||
A["Contract"] --> B["Resolver"]
|
||||
B --> C["Adapter"]
|
||||
C --> D["Checkov<br/>(static code)"]
|
||||
D --> E["Terraform<br/>plan"]
|
||||
E --> F["Wiz<br/>(on plan)"]
|
||||
F --> G["Confidence<br/>signal"]
|
||||
G --> H{"Stage<br/>gate"}
|
||||
H -->|"dev: autonomous"| I["Apply"]
|
||||
H -->|"qa/prod/dr: attested"| I
|
||||
I --> J["Evidence +<br/>Ledger"]
|
||||
classDef accent fill:#1B1B1B,color:#fff,stroke:#D6002A,stroke-width:2px
|
||||
classDef supporting fill:#fff,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
|
||||
classDef decision fill:#D6002A,color:#fff,stroke:#1B1B1B,stroke-width:2px
|
||||
class D,E,F,G,J accent
|
||||
class H decision
|
||||
class A,B,C,I supporting
|
||||
@@ -0,0 +1,17 @@
|
||||
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#1B1B1B", "primaryBorderColor": "#D6002A", "primaryTextColor": "#fff", "secondaryColor": "#fff", "secondaryBorderColor": "#D6002A", "secondaryTextColor": "#1B1B1B", "tertiaryColor": "#F0F0F0", "clusterBkg": "#F0F0F0", "lineColor": "#1B1B1B", "fontFamily": "\"Akkurat Pro\", \"Helvetica Neue\", \"Arial\", sans-serif"}}}%%
|
||||
|
||||
flowchart TB
|
||||
A["Platform<br/>components"] --> B["CloudEvents<br/>envelope"]
|
||||
B --> C["Event log"]
|
||||
B --> D["Decision<br/>ledger"]
|
||||
B --> E["Run records"]
|
||||
C --> F["Collector"]
|
||||
D --> F
|
||||
E --> F
|
||||
F --> G["Cold store"]
|
||||
G --> H["PowerBI<br/>views"]
|
||||
H --> I["Live ops<br/>dashboard"]
|
||||
classDef accent fill:#1B1B1B,color:#fff,stroke:#D6002A,stroke-width:2px
|
||||
classDef supporting fill:#fff,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
|
||||
class B,F,G,H,I accent
|
||||
class A,C,D,E supporting
|
||||
@@ -40,10 +40,14 @@ section.title {
|
||||
section.title h1 { color: var(--sp-white); }
|
||||
section.title h2 { color: var(--sp-white); }
|
||||
|
||||
/* Tables — grey header with red underline */
|
||||
table { font-size: 18px; width: 100%; border-collapse: collapse; }
|
||||
/* Tables — grey header with red underline, explicit white body for readability on any background */
|
||||
table { font-size: 18px; width: 100%; border-collapse: collapse; background: var(--sp-white); }
|
||||
th { background: var(--sp-grey); border-bottom: 2px solid var(--sp-red); padding: 6px 10px; text-align: left; }
|
||||
td { border-bottom: 1px solid var(--sp-grey); padding: 6px 10px; }
|
||||
td { background: var(--sp-white); color: var(--sp-black); border-bottom: 1px solid var(--sp-grey); padding: 6px 10px; }
|
||||
/* Ensure tables on dark/title slides remain readable: white card with a subtle border */
|
||||
section.title table, section table { background: var(--sp-white); }
|
||||
section.title td, section td { background: var(--sp-white); color: var(--sp-black); }
|
||||
section.title th, section th { background: var(--sp-grey); color: var(--sp-black); }
|
||||
|
||||
/* Blockquotes — red left border */
|
||||
blockquote { border-left: 4px solid var(--sp-red); color: var(--sp-dark-grey); font-size: 20px; padding-left: 12px; }
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
@@ -0,0 +1,327 @@
|
||||
---
|
||||
marp: true
|
||||
theme: nova-sp
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: 'Nova — The Autonomous Cloud Delivery Platform'
|
||||
footer: 'Nova — The Autonomous Cloud Delivery Platform'
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Nova — The Autonomous Cloud Delivery Platform
|
||||
|
||||
**Shifting from Operational Overhead to Strategic Value**
|
||||
|
||||
Product Development & Citizen Developer Overview
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — The Problem
|
||||
|
||||
**Product teams now own their cloud infrastructure — but ownership without discipline is destroying value.**
|
||||
|
||||
- **No lifecycle planning.** Resources are authored for creation, not for patching, decommissioning, or rollback — so changes are destructive.
|
||||
- **Proactive scanning is not part of authoring.** AI-frontier models exploit zero-days at a rapid pace; teams cannot keep up by reacting. Modules must be scanned as code and at runtime — and remediated at the pace the threat moves.
|
||||
- **Bandwidth gaps in infrastructure operations.** Time spent on remediation + the push for innovation leaves operations chronically under-resourced; detections are missed, incidents grow.
|
||||
- **Tribal knowledge and the rockstar-operator problem.** Operations depend on a handful of administrators; when they leave, the knowledge leaves with them. The platform should encode the discipline, not the person.
|
||||
|
||||
Every hour a developer spends writing, deploying, fixing, or remediating infrastructure is an hour not spent releasing features to production.
|
||||
|
||||
**Benefit:** the answer is an autonomous cloud delivery platform that encodes discipline as policy, scans proactively, remediates rapidly, and makes operations visible to leadership rather than hidden in tribal knowledge.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Nova's Vision
|
||||
|
||||
> **Infrastructure operations become visible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates; the operator is never in the loop of normal operations.**
|
||||
|
||||
- **Visibility is the recurring theme** — security posture, remediation velocity, reliability, and lead time as queryable signals
|
||||
- **Provable, not promised** — trust established by deterministic scripts that calculate a score; the platform functions without AI
|
||||
- **Autonomy in operations, human at stage gates** — QA signs off for production; SRE greenlights operational readiness
|
||||
|
||||
**Benefit:** the destination is autonomous operations with provable trust — security, remediation velocity, reliability, and lead time made visible to leadership, not promised to them.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Strategic Objectives + Anti-Goals
|
||||
|
||||
**4 Strategic Objectives:**
|
||||
1. **Zero-touch operations** — autonomy as the default, not the demo; stage-gate attestation (QA, SRE) remains human by design
|
||||
2. **Provable trust in automated decisions** — deterministic scripts calculate a score; the platform functions without AI; Decision Ledger, confidence scoring, circuit breakers, blast-radius controls
|
||||
3. **Compounding, quantifiable ROI** — four CTO-grade metrics, all flowing into PowerBI:
|
||||
- **Lead Time** (PR → Production) · **Infrastructure Vulnerability Count** (trend) · **MTTR** · **Cloud Spend Reduction**
|
||||
4. **Integrate with externally owned development platforms — regardless of source** — PDLC, SDLC, Agentic, or Citizen Developer; Nova provides skills + MCP endpoints; all prod intents go through the same controls and quality gates
|
||||
|
||||
**4 Anti-Goals (what Nova is NOT):**
|
||||
1. Not a general-purpose AI agent platform
|
||||
2. Not a system that removes humans from accountability — only from normal operations
|
||||
3. Not an upstream development platform (no product backlogs, IDE, code authorship)
|
||||
4. Not a replacement for the Product Development Lifecycle (PDLC)
|
||||
|
||||
**Benefit:** the scope is explicit — Nova governs infrastructure and delivery, integrates with any upstream source through one validated contract, and measures success on four metrics a CTO can repeat back.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Scope: Downstream of PDLC
|
||||
|
||||
**Nova governs infrastructure and delivery. The PDLC is upstream — Nova never penetrates it. Integration is through one validated contract.**
|
||||
|
||||
- **The PDLC is upstream:** product backlog, code authorship (AI agent, IDE, agentic SDLC), sprint planning, application business logic
|
||||
- **Nova is downstream:** contract ingestion → submission-readiness gate → policy enforcement → cloud resource lifecycle → environment progression (dev → qa → prod → dr) → immutable audit + attestation
|
||||
- **The integration point is one contract** — any upstream source (AI agent, agentic SDLC, dev platform) produces submissions subject to the same compliance standards
|
||||
- **Nova validates the submission, not the author** — the audit trail, the policy envelope, and the evidence stream are the same regardless of source
|
||||
|
||||
**Benefit:** a clean scope boundary — Nova is purpose-built for infrastructure operations and integrates with any upstream source through one validated contract, so the platform team's surface area stays bounded.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — RACI: Who Owns What
|
||||
|
||||
**Four roles, one matrix — citizen developer owns FRs + UAT, platform owns NFRs + infra, quality engineering owns the gate evidence, SRE owns operational readiness.**
|
||||
|
||||
| Work Category | Citizen Dev | Platform | Quality Eng | SRE |
|
||||
|---|---|---|---|---|
|
||||
| Functional Requirements | **R/A** | C | I | I |
|
||||
| User Acceptance Testing | **R/A** | C | I | I |
|
||||
| Non-Functional Requirements | I | **R/A** | C | C |
|
||||
| Infrastructure (cloud, state, IAM) | I | **R/A** | I | C |
|
||||
| QA (policy, confidence, schema) | C | R | **R/A** | I |
|
||||
| Production deployment to cloud | I | **R/A** | C | C |
|
||||
| Quality attestation (QA sign-off) | **A** | R | **R** | I |
|
||||
| Production readiness (SRE sign-off) | **A** | R | C | **R** |
|
||||
|
||||
**R**=Responsible · **A**=Accountable (sign-off) · **C**=Consulted · **I**=Informed. Production readiness is co-owned: the platform runs attestations agentically; the citizen developer authorizes the promotion at the stage gate.
|
||||
|
||||
**Benefit:** every party knows what they bring, what the platform provides, what quality engineering guards, and where SRE signs off — accountability is explicit, never diffuse.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — The Platform Pipeline
|
||||
|
||||
**How intent becomes verified infrastructure — fail-fast policy scanning before the plan, runtime scanning after it.**
|
||||
|
||||
|
||||
|
||||
- **Contract → resolver → adapter → Checkov on static code (before plan) → terraform plan → Wiz on the plan → confidence signal → stage gate → apply → evidence + ledger**
|
||||
- **Fail-fast, quick feedback** — Checkov runs on the authored Terraform code before `terraform plan` so developers get immediate policy feedback
|
||||
- **Wiz on the plan when configured; Checkov as a drop-in otherwise** — Wiz scans the plan output; when Wiz credentials are absent, Checkov runs against the plan. **Wiz and Checkov are never both run on the plan.**
|
||||
- **Dev is autonomous** (no stage gate); **qa/prod/dr require human attestation** (QA for quality, SRE for production readiness)
|
||||
|
||||
**Benefit:** two layers of scanning, zero operator involvement in normal operations — fast deterministic feedback at authoring time and a runtime scan on the resolved plan.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The Decision Ledger
|
||||
|
||||
**Every automated decision is captured, immutable, queryable — and accountable.**
|
||||
|
||||
- **What is captured:** the chosen action, the confidence score, the alternatives considered, whether a human overrode it, and the outcome (backfilled once the apply completes). Every stage-gate attestation (QA, SRE) is captured with approver identity and the evidence presented.
|
||||
- **"AI decisions" are really automated decisions** — made by deterministic scripts that calculate a score and a band; the platform functions without AI. When an LLM planner is added later, it will emit richer alternatives without breaking the schema.
|
||||
- **The value is accountability, not the storage engine** — the ledger is append-only and tamper-evident; every decision is queryable for auditing, traceable to an outcome, and impossible to rewrite after the fact.
|
||||
|
||||
**Benefit:** "autonomous" is defensible because every decision is immutable, queryable, and accountable — and the audience knows exactly what "automated" means here: deterministic scoring, not a black-box LLM.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — The Attestation Matrix
|
||||
|
||||
**The designed controls that keep humans at stage gates — structured, freshness-validated, separation-of-duties-enforced.**
|
||||
|
||||
| Concern | Env | Freshness | Description |
|
||||
|---------|-----|-----------|-------------|
|
||||
| Functional correctness | qa | 24h | The application behaves as specified; evidence accepted from the consumer's UAT. |
|
||||
| Performance baseline | qa | 7d | The deployment meets its performance envelope vs. the agreed baseline. |
|
||||
| Security posture | qa | 24h | The deployment's security findings have been reviewed and accepted. |
|
||||
| Operational readiness | prod | 30d | SRE confirms the deployment is operable: runbooks, dashboards, on-call. |
|
||||
| Incident response | prod | 90d | The on-call path has been exercised; a working incident-response plan exists. |
|
||||
| Capacity & cost | prod | 30d | Capacity headroom and monthly cost are within the agreed envelope. |
|
||||
| Resilience: DR drill | prod | 180d | A DR drill has been run and recovery met the RTO. |
|
||||
| Resilience: chaos | prod | 90d | A chaos exercise has been run and the deployment absorbed the failure. |
|
||||
| Resilience: backup | prod | 30d | Backups are restorable and tested within the freshness window. |
|
||||
| DR region deploy | dr | 180d | The DR region can be deployed and is reachable. |
|
||||
|
||||
Separation-of-duties on prod: the approver cannot be the same person who built the deployment.
|
||||
|
||||
**Benefit:** the gate model is explicit — autonomy in operations, human in accountability, by design. The matrix is what makes autonomous operations safe enough to trust in production.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Telemetry & Live Ops
|
||||
|
||||
**Every metric in this deck is traceable to a real emitted signal — the live-ops dashboard makes operations visible in PowerBI.**
|
||||
|
||||
|
||||
|
||||
- **Platform components → CloudEvents envelope → event log + decision ledger + run records → collector → cold store → PowerBI views → live ops dashboard**
|
||||
- **The live ops dashboard (PowerBI)** surfaces the four CTO-grade metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend) alongside trust metrics (Decision Ledger coverage, Attestation coverage) and efficiency metrics (touchless resolution, escalation frequency)
|
||||
- **Deliberately minimal** — Nova-native envelopes; no Kafka, no Prometheus, no ClickHouse. The cold store handles batch and historical analysis; the live-ops surface is built in PowerBI on the exported views
|
||||
- **Every number is traceable to a signal** — when a CFO asks "where does this number come from?", the answer is a query against the cold store, not a Slack thread
|
||||
|
||||
**Benefit:** the architecture is the trust substrate — leadership sees the same numbers the platform produces, in PowerBI, with full traceability. Operations become visible.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Decision Ledger + Attestation Coverage
|
||||
|
||||
**By design, no change reaches production without a ledger entry and a human attestation — both queryable for auditing, with full traceability.**
|
||||
|
||||
- **Decision Ledger coverage: 100%** — every platform run emits a decision record with outcome backfill; no automated decision is ever lost
|
||||
- **Attestation coverage: 100%** — every prod/dr promotion is attested by a human (QA for quality, SRE for production readiness), recorded with approver identity, separation-of-duties check, and the evidence matrix
|
||||
- **No change to production without both** — the ledger entry and the human attestation are mandatory, enforced by the pipeline, not by policy
|
||||
- **Easily queried for auditing** — queryable by run, by environment, by approver, and by outcome; the audit trail is a query, not a forensic exercise
|
||||
- **Full traceability** — a production change is traceable from the contract that declared intent, through the policy scan, the confidence score, the attestation, to the applied outcome
|
||||
|
||||
**Benefit:** trust is provable — not a marketing claim, a queryable record. An auditor answers "who approved this, when, on what evidence?" in one query; a CTO answers "how many of last quarter's prod changes were touchless?" in one query.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — Cost & ROI
|
||||
|
||||
**The ROI formula and the cost estimates — grounded, with the production denominator honestly flagged.**
|
||||
|
||||
- **Cost estimates are pre-apply and offline** — the platform reads the terraform plan and estimates cost before anything is applied; a cost regression is caught before the spend happens
|
||||
- **The ROI formula:**
|
||||
`Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
|
||||
- **The four CTO-grade metrics are the ROI proof:** Lead Time (PR → Prod), Infrastructure Vulnerability Count (trend), MTTR, Cloud Spend Reduction — all flow into PowerBI
|
||||
- **Honest caveat:** derived metrics are computed on internal runs today; the production-denominator activates when a pilot estate runs. The formula is grounded; the production numbers are not yet.
|
||||
|
||||
**Benefit:** the ROI is not a black box — the formula is shown, the four metrics are committed, and the production-denominator caveat is stated up front. The CFO sees exactly what is real today and what activates with a pilot.
|
||||
|
||||
---
|
||||
|
||||
## Slide 12 — What's Deferred — and Why
|
||||
|
||||
**Honesty about what is not measured yet — and the blocking work for each.**
|
||||
|
||||
To be clear: these deferrals are *measurement infrastructure*, not the autonomy itself. The platform runs without an operator in the loop of normal operations. What is deferred is the evidence pipeline for certain metrics — not the autonomy.
|
||||
|
||||
| # | Deferred metric | Blocking work |
|
||||
|---|-----------------|---------------|
|
||||
| 1 | Live infrastructure health | Live AWS re-provisioning (currently torn down to zero-cost steady state) |
|
||||
| 2 | Live outbox write rate | Live AWS re-provisioning |
|
||||
| 3 | Tamper-evident ledger checkpoints | Audit-ledger build-out (Object Lock + signed checkpoints) |
|
||||
| 4 | Onboarding funnel (requested → granted) | Auto-grant implementation |
|
||||
| 5 | Drift auto-reversal | Drift-detection scheduler (not yet built) |
|
||||
| 6 | Live cost reconciliation | Live AWS re-provisioning + actual-spend feed |
|
||||
| 7 | SLA / unplanned downtime | Live AWS re-provisioning |
|
||||
| 8 | Predictive vs reactive ratio | ML anomaly-forecasting service (not yet built) |
|
||||
|
||||
**Benefit:** the boundaries are explicit — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented with the work that unblocks each one.
|
||||
|
||||
---
|
||||
|
||||
## Slide 13 — Roadmap to the North Star
|
||||
|
||||
**The path from the grounded metrics to the 12–18 month targets — each deferred metric has an unblock path and a timeframe.**
|
||||
|
||||
| Timeframe | Work | Unblocks |
|
||||
|-----------|------|----------|
|
||||
| Near-term | Live AWS re-provisioning | Live infra health, outbox write rate, live cost reconciliation, SLA |
|
||||
| Near-term | Auto-grant implementation | Onboarding funnel (requested → granted) |
|
||||
| Mid-term | Drift-detection scheduler | Drift auto-reversal |
|
||||
| Mid-term | Audit-ledger build-out (Object Lock + signed checkpoints) | Tamper-evident ledger checkpoints |
|
||||
| Mid-term | Hot-path activation (batch → near-real-time) | Live-ops dashboard freshness |
|
||||
| Longer-term | ML anomaly-forecasting service | Predictive vs reactive ratio |
|
||||
|
||||
Re-evaluation triggers: each blocking piece of work lifts on its own schedule; the metrics layer evolves as each one lands.
|
||||
|
||||
**Benefit:** every deferred metric has an unblock path — nothing is hand-waved; everything has a plan and a timeframe.
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — 12-Month Product Roadmap
|
||||
|
||||
**The product arc from pilot activation to integration — four quarters, four outcomes.**
|
||||
|
||||
| Quarter | Theme | Board-level outcome |
|
||||
|---------|-------|---------------------|
|
||||
| **Q1** | Pilot Activation | Nova runs a real customer estate end-to-end, autonomously, with a measurable zero-touch rate. |
|
||||
| **Q2** | Provable Trust | Every automated decision lands in a tamper-evident ledger; the CFO sees real cloud-spend reconciliation. |
|
||||
| **Q3** | Compounding ROI | Quarter-over-quarter cloud spend drops; drift is detected and reversed without a human. |
|
||||
| **Q4** | Integration & Predictive | AI agents deploy through Nova by default; the ML anomaly-forecasting service goes live. |
|
||||
|
||||
Grounded in the four strategic objectives (autonomy, provable trust, ROI, integration) and the deferred-metric unblock paths.
|
||||
|
||||
**Benefit:** the 12-month product arc — each quarter activates a strategic objective and its corresponding board-level metric, from pilot activation through integration leadership.
|
||||
|
||||
---
|
||||
|
||||
## Slide 15 — Quarter-by-Quarter Outcomes
|
||||
|
||||
| Quarter | Product theme | Key deliverable | Target metric | Grounding |
|
||||
|---------|---------------|-----------------|---------------|-----------|
|
||||
| **Q1** | Pilot Activation | Re-provision live AWS; activate first pilot estate; onboarding auto-grant | Touchless ≥ 99% · Escalation < 0.1% · Accuracy ≥ 99.5% | Objective #1 — autonomy as the default |
|
||||
| **Q2** | Provable Trust | Tamper-evident ledger (Object Lock + signed checkpoints); daily checkpoints; live cost reconciliation | Decision Ledger Coverage 100% · Cost Savings ≥ 25% | Objective #2 — trust is the moat |
|
||||
| **Q3** | Compounding ROI + Drift | Drift-detection scheduler; auto-reversal; pre-apply → actual-spend reconciliation on the pilot estate | Drift Auto-Reversal ≥ 95% · Spend Reduction ≥ 25% | Objective #3 — CFO-pointable numbers |
|
||||
| **Q4** | Integration + Predictive | ML anomaly-forecasting; AI-agent intent surface; multi-cloud (Azure/GCP) preview | Predictive:Reactive ≥ 3:1 · AI-Agent Intent Share (first measurement) | Objective #4 — default substrate for agents |
|
||||
|
||||
**Month-18 destination:** *"Nova is the layer enterprise leadership points to when they say 'we don't have an infrastructure ops team anymore, and the audit trail is stronger than it ever was.'"*
|
||||
|
||||
**Benefit:** each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from "honestly deferred" to "shipped and measured."
|
||||
|
||||
---
|
||||
|
||||
## Slide 16 — Production-Grade Guidance via Atelier (1/2)
|
||||
|
||||
**Nova instructs the citizen developer's AI agent on production-grade engineering — a set of skills and an MCP server.**
|
||||
|
||||
- **Skills** — markdown files keyed to production-grade engineering domains (API, security, data, testing, observability, errors, DevOps, infrastructure-as-code, compliance); the skills extend the baseline catalog with Nova-specific production-grade principles
|
||||
- **MCP server** — a plugin-registry, stdio server exposing four tools: `lookup_principle`, `list_domains`, `matrix_lookup`, `validate_against_principles`. The developer's AI agent (or any agentic SDLC platform) calls these tools to look up the principles that apply to its submission
|
||||
- **The integration point is the same regardless of source** — whether the submission comes from an AI coding agent, an agentic SDLC platform, or a traditional IDE, the same skills and MCP server apply. This is how Nova makes the citizen developer production-grade without owning the PDLC
|
||||
|
||||
**Benefit:** the citizen developer's AI agent is not unguided — Nova provides production-grade engineering principles as skills and as an MCP surface, so submissions arrive at the contract boundary already aligned with the platform's standards.
|
||||
|
||||
---
|
||||
|
||||
## Slide 17 — Production-Grade Guidance via Atelier (2/2)
|
||||
|
||||
**Agentic validation catches engineering-discipline gaps that deterministic scanners miss — and the validation is reproducible.**
|
||||
|
||||
- **Beyond deterministic scanners** — Wiz, Checkmarx, and Mend check policy and secrets; they do not check engineering discipline. The Atelier MCP server catches correctness, clarity, and observability gaps that deterministic tools cannot: "is this service observable?", "is this error path handled?", "is this API contract clear?"
|
||||
- **Agentic validation, not a second policy engine** — the MCP server gives the AI agent the principles to validate against; the agent does the validation. The agent reasons about the submission against the principles, not a second static scan
|
||||
- **Vendored for audit reproducibility** — Atelier is vendored at a pinned tag. A validation result is replayable against the exact principles that produced it, so an audit can reproduce a validation months later, not just trust a log line
|
||||
|
||||
**Benefit:** the citizen developer's submission is checked for engineering discipline, not just policy compliance — and the check is reproducible for audit. That is what makes the submission production-grade, regardless of which upstream platform produced it.
|
||||
|
||||
---
|
||||
|
||||
## Slide 18 — Recap + Ask
|
||||
|
||||
**The 4-beat recap + the business decision.**
|
||||
|
||||
**Recap:**
|
||||
- **Problem:** product teams own infrastructure without the discipline and lifecycle planning it requires; bandwidth gaps and tribal knowledge leave operations exposed
|
||||
- **Solution:** autonomous cloud delivery — operations become visible, trust is provable (deterministic scoring), humans at stage gates
|
||||
- **Proof:** 100% ledger coverage, 100% attestation coverage, grounded ROI formula, four CTO-grade metrics flowing into PowerBI
|
||||
- **Roadmap:** deferred metrics have unblock paths; the 12-month product arc activates one strategic objective per quarter
|
||||
|
||||
**The ask:** "Approve a pilot estate to activate the production-denominator metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend), and approve the tamper-evident ledger build-out to move from the local hash-chain to S3 Object Lock + signed checkpoints. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
|
||||
|
||||
**Benefit:** a clear business decision — approve a pilot and the ledger build-out — with the confidence that every claim in this deck is grounded, derived, or honestly deferred.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
## Appendix A1 — Metrics Glossary
|
||||
|
||||
| KPI | Definition | Status |
|
||||
|-----|-----------|--------|
|
||||
| Touchless Resolution Rate | runs without operational stage-gate block ÷ total | partial (Post-Pilot) |
|
||||
| Human Escalation Frequency | operational stage-gate blocks ÷ total | partial (Post-Pilot) |
|
||||
| Automated Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
|
||||
| MTTR (p95) | apply.failed → successful retry | grounded |
|
||||
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
|
||||
| Provisioning Lead Time | run.completed − run.started | grounded |
|
||||
| Deployment Frequency | count(run.completed) per day | grounded |
|
||||
| Cost Savings (pre-apply) | sum(delta_usd where delta < 0) | partial (live reconciliation deferred) |
|
||||
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
|
||||
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
|
||||
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
|
||||
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
|
||||
| Policy Compliance Rate | 1 − failed_assets ÷ total | grounded |
|
||||
|
||||
**Benefit:** a reference for every metric mentioned in the deck.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Nova — The Autonomous Cloud Delivery Platform: Talking Points
|
||||
|
||||
> Step 4 of the 4-step deck process. Presenter cues distilled from the
|
||||
> source of truth (`nova-autonomous-cloud-delivery.md`). 3-6 bullets per
|
||||
> slide + key takeaway. Indexed by Marp slide #.
|
||||
> v1.21 — REQ-245
|
||||
|
||||
---
|
||||
|
||||
### Slide 1 — The Problem
|
||||
- Open with the shift: "you build it, you run it" put Terraform into product teams — ownership without discipline is destroying value
|
||||
- Land the lifecycle-planning gap: resources authored for creation, not for patching/rollback → destructive changes
|
||||
- Land the urgency: AI-era 0-day pace demands proactive scanning as code + at runtime, remediated at threat pace
|
||||
- Call out tribal knowledge / the rockstar-operator problem — the platform should encode the discipline, not the person
|
||||
- Do NOT frame this as "humans are the problem" — the problem is ownership without the discipline and tooling
|
||||
- **Key takeaway:** the problem is infrastructure ownership without discipline; the answer is an autonomous platform that encodes the discipline
|
||||
|
||||
### Slide 2 — Nova's Vision
|
||||
- Read the vision verbatim — "infrastructure operations become visible" is the operative phrase
|
||||
- Emphasize "provable, not promised" — trust established by deterministic scripts; the platform functions without AI
|
||||
- State the attestation model up front: QA for production, SRE for operational readiness
|
||||
- **Key takeaway:** autonomous operations with provable trust — security, remediation velocity, reliability, lead time made visible, not promised
|
||||
|
||||
### Slide 3 — Strategic Objectives + Anti-Goals
|
||||
- Objective #2 is the one to land carefully: trust = deterministic scoring, not an LLM; the platform functions without AI
|
||||
- Objective #3: four CTO-grade metrics (Lead Time, Vuln Count, MTTR, Spend) — all flow into PowerBI
|
||||
- Objective #4 is the integration thesis: Nova integrates with any upstream source; provides skills + MCP; all prod intents go through the same controls
|
||||
- Anti-goals #3 and #4 protect the scope: not an upstream dev platform, not a PDLC replacement
|
||||
- **Key takeaway:** purpose-built for infra ops, integrates with any source through one contract, measures success on four CTO metrics
|
||||
|
||||
### Slide 4 — Scope: Downstream of PDLC
|
||||
- Nova governs infra + delivery only; the PDLC (backlog, code authorship, IDE) is upstream — Nova never penetrates it
|
||||
- Integration is only through the validated contract boundary
|
||||
- Any upstream source (AI agent, agentic SDLC, dev platform) produces submissions subject to the same compliance standards
|
||||
- Nova validates the submission, not the author
|
||||
- **Key takeaway:** Nova is purpose-built for infrastructure operations; the scope boundary is clean and bounded
|
||||
|
||||
### Slide 5 — RACI: Who Owns What
|
||||
- Four roles now: Citizen Developer, Platform, Quality Engineering, SRE
|
||||
- Quality attestation is owned by Quality Engineering (not the Platform); Production readiness is owned by SRE
|
||||
- The Platform runs the checks agentically but is never the Accountable party for the gate — that separation keeps the platform honest
|
||||
- Production readiness is co-owned: the platform runs attestations; the citizen developer authorizes the promotion at the stage gate
|
||||
- **Key takeaway:** you bring FRs + UAT; Nova provides NFRs + infra; QE guards the gate evidence; SRE signs off on production readiness
|
||||
|
||||
### Slide 6 — The Platform Pipeline
|
||||
- Walk the pipeline left-to-right: contract → resolver → adapter → Checkov (static) → plan → Wiz (on plan) → confidence → gate → apply
|
||||
- Two-stage scan: Checkov on static code BEFORE the plan (fail-fast dev feedback); Wiz on the plan (or Checkov as drop-in if no Wiz creds)
|
||||
- Never both Wiz + Checkov on the plan — avoid duplicate noise
|
||||
- Dev is autonomous; qa/prod/dr require attestation (QA for quality, SRE for production readiness)
|
||||
- **Key takeaway:** two layers of scanning, zero operator involvement in normal operations
|
||||
|
||||
### Slide 7 — The Decision Ledger
|
||||
- "AI decisions" are really automated decisions — deterministic scripts calculate a score; the platform functions without AI
|
||||
- Do not dwell on the storage substrate — the value is accountability (immutable, queryable, traceable to outcome), not the database
|
||||
- Every stage-gate attestation is captured with approver identity and the evidence presented
|
||||
- When an LLM planner is added later, it emits richer alternatives without breaking the schema
|
||||
- **Key takeaway:** autonomous is defensible because every decision is immutable, queryable, accountable — and "automated" means deterministic scoring, not a black-box LLM
|
||||
|
||||
### Slide 8 — The Attestation Matrix
|
||||
- The matrix is not a rubber stamp — structured, freshness-validated, separation-of-duties-enforced
|
||||
- Each concern now has a plain-language description of what is being attested (the old "operator-supplied" label is gone)
|
||||
- SoD on prod: the approver can't be the same person who built it
|
||||
- **Key takeaway:** autonomy in operations, human in accountability, by design — the matrix is what makes autonomous operations safe enough to trust in production
|
||||
|
||||
### Slide 9 — Telemetry & Live Ops
|
||||
- Deliberately minimal: Nova-native CloudEvents; no Kafka/Prometheus/ClickHouse
|
||||
- The live-ops dashboard is built in PowerBI on top of the exported views — leadership sees the same numbers the platform produces
|
||||
- Every number in the Proof slides is traceable to a signal — "where does this number come from?" → a query against the cold store
|
||||
- This is where the "infrastructure operations become visible" theme lands concretely
|
||||
- **Key takeaway:** the architecture is the trust substrate — operations become visible in PowerBI, with full traceability
|
||||
|
||||
### Slide 10 — Decision Ledger + Attestation Coverage
|
||||
- Both 100% — no automated decision is ever lost; no prod/dr promotion lands without a human sign-off
|
||||
- The mandatory-by-design point: the ledger entry + the human attestation are a gate, not a best-effort feature
|
||||
- Easily queried: by run, by environment, by approver, by outcome — the audit trail is a query, not a forensic exercise
|
||||
- **Key takeaway:** trust is provable — not a marketing claim, a queryable record; no change to production without both the ledger entry and the human attestation
|
||||
|
||||
### Slide 11 — Cost & ROI
|
||||
- The ROI formula is shown inline — not hidden in a footnote
|
||||
- The four CTO-grade metrics are the ROI proof — Lead Time, Vuln Count, MTTR, Cloud Spend
|
||||
- The N=0 caveat is stated explicitly: the formula is grounded; the production numbers activate with a pilot
|
||||
- **Key takeaway:** the ROI is not a black box — the formula is shown, the four metrics are committed, the production-denominator caveat is up front
|
||||
|
||||
### Slide 12 — What's Deferred — and Why
|
||||
- The preempt is critical: these deferrals are measurement infrastructure, not autonomy — the platform IS autonomous in operations
|
||||
- The blocking work is named in plain language (no decision IDs) — "live AWS re-provisioning", "drift-detection scheduler", "ML service"
|
||||
- Showing this to leadership demonstrates honesty, not weakness
|
||||
- **Key takeaway:** the autonomy is real; the measurement gaps are documented with the work that unblocks each one
|
||||
|
||||
### Slide 13 — Roadmap to the North Star
|
||||
- Each deferred metric has an unblock path and a timeframe — near-term, mid-term, longer-term
|
||||
- No status column: most of it is not implemented yet, so status would be noise
|
||||
- Re-evaluation triggers: each blocking piece of work lifts on its own schedule
|
||||
- **Key takeaway:** every deferred metric has a plan and a timeframe — nothing is hand-waved
|
||||
|
||||
### Slide 14 — 12-Month Product Roadmap
|
||||
- This is the *product* roadmap, forward-looking only
|
||||
- Q1 Pilot Activation → Q2 Provable Trust → Q3 Compounding ROI → Q4 Integration & Predictive
|
||||
- Each quarter activates one strategic objective from the North Star
|
||||
- **Key takeaway:** the 12-month product arc — each quarter activates a strategic objective and its board-level metric
|
||||
|
||||
### Slide 15 — Quarter-by-Quarter Outcomes
|
||||
- Q1: three post-pilot metrics go live (Touchless ≥99%, Escalation <0.1%, Accuracy ≥99.5%) — denominator activates with the pilot
|
||||
- Q2: Decision Ledger Coverage was already grounded — tamper-evidence is the Q2 upgrade (local hash-chain → Object Lock + signed checkpoints)
|
||||
- Q3: Drift Auto-Reversal ≥95% unblocks when the drift scheduler ships; Spend Reduction ≥25% measured against the pilot baseline
|
||||
- Q4: Predictive:Reactive ≥3:1 requires the ML forecasting service; AI-Agent Intent Share is a first measurement (aspirational-metric)
|
||||
- **Key takeaway:** each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from deferred to shipped
|
||||
|
||||
### Slide 16 — Production-Grade Guidance via Atelier (1/2)
|
||||
- Nova instructs the citizen developer's AI agent via skills (markdown, keyed to engineering domains) + an MCP server (4 tools, plugin-registry, stdio)
|
||||
- The integration point is the same regardless of source — AI agent, agentic SDLC, traditional IDE all get the same skills + MCP
|
||||
- This is how Nova makes the citizen developer production-grade without owning the PDLC
|
||||
- **Key takeaway:** the citizen developer's AI agent is not unguided — Nova provides engineering principles as skills + MCP
|
||||
|
||||
### Slide 17 — Production-Grade Guidance via Atelier (2/2)
|
||||
- The value is the gap deterministic scanners leave: engineering discipline (Wiz/Checkmarx/Mend check policy/secrets, not discipline)
|
||||
- The MCP server catches "is this service observable?", "is this error path handled?", "is this API contract clear?"
|
||||
- Vendored at a pinned tag → audit reproducibility — a validation result is replayable months later
|
||||
- **Key takeaway:** submissions are checked for engineering discipline, not just policy compliance — and the check is reproducible for audit
|
||||
|
||||
### Slide 18 — Recap + Ask
|
||||
- Recap the 4-beat arc so the audience leaves with the structure
|
||||
- The ask is a business decision: approve a pilot estate + the tamper-evident ledger build-out
|
||||
- "Pipeline-ready" → "production-proven" is the value proposition
|
||||
- **Key takeaway:** approve a pilot + the ledger build-out to move from pipeline-ready to production-proven
|
||||
|
||||
### Appendix A1 — Metrics Glossary
|
||||
- Reference for every metric mentioned in the deck
|
||||
- Use if the audience asks "what does X mean?"
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,713 @@
|
||||
# Nova — The Autonomous Cloud Delivery Platform
|
||||
|
||||
> **Source of truth** (Step 1 of the 4-step deck process).
|
||||
> Unified narrative deck. 4-beat arc: Problem → Solution → Proof →
|
||||
> Roadmap + Ask. x3 structure at deck level (opening = the problem + the
|
||||
> arc, body = tell them, closing = recap + ask) AND per slide (opens with
|
||||
> what it covers, delivers, closes with a benefit callout written for a
|
||||
> tech-leadership audience).
|
||||
>
|
||||
> **Honesty model:** every metric cited is grounded (cites a source),
|
||||
> derived (documented formula), or deferred (cites the blocking work).
|
||||
> No fabricated numbers. Internal provenance (decision IDs, requirement
|
||||
> IDs, internal file paths) is kept out of the audience-facing slides —
|
||||
> those live in the appendix and the `.ciagent/` files only.
|
||||
>
|
||||
> v1.21 — Deck Refinement & Pipeline Hardening
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — The Problem
|
||||
|
||||
**Product teams now own their cloud infrastructure — but ownership without
|
||||
discipline is destroying value.**
|
||||
|
||||
The broad shift to "you build it, you run it" put Terraform into the hands
|
||||
of product teams. The intention was right: teams that own their stack ship
|
||||
faster. The reality is that infrastructure-as-code is a different craft
|
||||
from software development, and the engineering standards that teams apply
|
||||
to application code are rarely applied to the infrastructure that carries
|
||||
it.
|
||||
|
||||
- **No lifecycle planning.** Resources are authored for creation, not for
|
||||
patching, decommissioning, or rollback. When a change is needed, the
|
||||
change is destructive — because no one planned the lifecycle.
|
||||
- **Proactive scanning is not part of authoring.** In a year where
|
||||
AI-frontier models discover and exploit zero-day vulnerabilities at a
|
||||
rapid pace, teams cannot keep up by reacting. Infrastructure modules
|
||||
must be scanned as code and at runtime, post-deployment — and remediated
|
||||
at the pace the threat moves, not the pace a sprint allows.
|
||||
- **Bandwidth gaps in infrastructure operations.** An unusual amount of
|
||||
time is spent on remediation, the push for innovation does not pause,
|
||||
and the result is that operational work is chronically under-resourced.
|
||||
Gaps open. Detections are missed. Incidents grow.
|
||||
- **Tribal knowledge and the rockstar-operator problem.** Operations
|
||||
depend on a handful of administrators who hold the infrastructure in
|
||||
their heads. When they leave, the knowledge leaves with them. The
|
||||
platform should encode the discipline, not the person.
|
||||
|
||||
Every hour a developer spends writing, deploying, fixing, or remediating
|
||||
infrastructure is an hour not spent releasing features to production and
|
||||
generating value.
|
||||
|
||||
> **Benefit:** the rest of this deck shows the answer — an autonomous
|
||||
> cloud delivery platform that encodes infrastructure discipline as
|
||||
> policy, scans proactively, remediates rapidly, and makes operations
|
||||
> visible to leadership rather than hidden in tribal knowledge.
|
||||
|
||||
> **Speaker notes:** Do not frame this as "humans are the problem." The
|
||||
> problem is that ownership was granted without the discipline, tooling,
|
||||
> and lifecycle planning that infrastructure requires. The operator is
|
||||
> not the bottleneck because operators exist — the bottleneck is that
|
||||
> operations depend on a few individuals instead of an encoded system.
|
||||
|
||||
> **Transition:** "Here is the destination Nova is building toward."
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Nova's Vision
|
||||
|
||||
**Infrastructure operations become visible. Every environment provisioned,
|
||||
every incident healed, every risk remediated — by an autonomous system
|
||||
whose trustworthiness is provable, not promised. Human attestation remains
|
||||
required at stage gates; the operator is never in the loop of normal
|
||||
operations.**
|
||||
|
||||
- **Visibility is the recurring theme.** Security posture, remediation
|
||||
velocity, reliability, and lead time are surfaced as queryable signals —
|
||||
not hidden in a person's head or a Slack thread.
|
||||
- **Provable, not promised.** Trust is established by deterministic
|
||||
scripts that calculate a score and gate the action. The platform
|
||||
functions without AI. "AI decisions" are really automated decisions.
|
||||
- **Autonomy in operations, human at stage gates.** QA signs off for
|
||||
production; SRE greenlights based on operational readiness. The
|
||||
absence of an operator in the loop is never the absence of a record.
|
||||
|
||||
> **Benefit:** the destination is autonomous operations with provable
|
||||
> trust — security, remediation velocity, reliability, and lead time made
|
||||
> visible to leadership, not promised to them.
|
||||
|
||||
> **Speaker notes:** "Visible" is the operative word. The vision is not
|
||||
> just that operations run without an operator — it is that operations
|
||||
> become observable, queryable, and accountable. That is what makes the
|
||||
> trust defensible.
|
||||
|
||||
> **Transition:** "The vision is ambitious — here are the strategic
|
||||
> objectives that make it concrete, and the anti-goals that keep it
|
||||
> focused."
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Strategic Objectives + Anti-Goals
|
||||
|
||||
**Four objectives Nova is building toward; four anti-goals that keep it
|
||||
focused.**
|
||||
|
||||
**4 Strategic Objectives:**
|
||||
1. **Demonstrate production-grade zero-touch operations** — autonomy as
|
||||
the default, not the demo. Stage-gate attestation (QA, SRE) remains
|
||||
human by design.
|
||||
2. **Establish provable trust in automated decisions** — deterministic
|
||||
scripts calculate a score; a band outcome gates the action. The
|
||||
platform functions without AI. The Decision Ledger, confidence
|
||||
scoring, circuit breakers, and blast-radius controls make
|
||||
"autonomous" a defensible claim, not a marketing one.
|
||||
3. **Deliver compounding, quantifiable ROI** — measured on four CTO-grade
|
||||
metrics, all flowing into PowerBI:
|
||||
- **Lead Time** (PR → Production) — downward trend.
|
||||
- **Infrastructure Vulnerability Count** — downward trend
|
||||
(proactive scanning keeps up with the AI-era 0-day pace).
|
||||
- **MTTR** — for platform-detected and platform-remediated incidents.
|
||||
- **Cloud Spend Reduction** — on pilot estates vs. the pre-Nova
|
||||
baseline.
|
||||
4. **Integrate with externally owned development platforms — regardless
|
||||
of source.** Nova integrates with externally owned PDLC, SDLC,
|
||||
Agentic, and Citizen Developer platforms. Nova provides skills and
|
||||
MCP endpoints that help the developer or AI agent make their
|
||||
application production-grade. Regardless of the source, all intents
|
||||
to deploy to production go through the same rigorous controls,
|
||||
quality gates, attestation, and evidence stream.
|
||||
|
||||
**4 Anti-Goals (what Nova is NOT):**
|
||||
1. Not a general-purpose AI agent platform.
|
||||
2. Not a system that removes humans from accountability — only from
|
||||
normal operations.
|
||||
3. Not an upstream development platform (no product backlogs, IDE, code
|
||||
authorship).
|
||||
4. Not a replacement for the Product Development Lifecycle (PDLC).
|
||||
|
||||
> **Benefit:** the scope is explicit — Nova governs infrastructure and
|
||||
> delivery, integrates with any upstream source through one validated
|
||||
> contract, and measures success on four metrics a CTO can repeat back.
|
||||
|
||||
> **Speaker notes:** Objective #2 is the one to land carefully: trust is
|
||||
> established by deterministic scoring, not by an LLM. The platform
|
||||
> functions without AI. Anti-goals #3 and #4 protect the scope boundary —
|
||||
> Nova will not become an IDE or a product-planning tool.
|
||||
|
||||
> **Transition:** "The scope boundary is explicit — here is exactly
|
||||
> where Nova sits relative to the product development lifecycle."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Scope: Downstream of PDLC
|
||||
|
||||
**Nova governs infrastructure and delivery. The PDLC is upstream — Nova
|
||||
never penetrates it. Integration is through one validated contract.**
|
||||
|
||||
- **The PDLC is upstream:** product backlog, code authorship (AI agent,
|
||||
IDE, agentic SDLC), sprint planning, application business logic.
|
||||
- **Nova is downstream:** contract ingestion → submission-readiness gate
|
||||
→ policy enforcement → cloud resource lifecycle → environment
|
||||
progression (dev → qa → prod → dr) → immutable audit + attestation.
|
||||
- **The integration point is one contract.** The citizen developer's AI
|
||||
coding agent, an upstream agentic SDLC platform, or any development
|
||||
platform may all produce submissions — the source does not matter
|
||||
because all are subject to the same compliance standards.
|
||||
- **Nova validates the submission, not the author.** The audit trail is
|
||||
the same; the policy envelope is the same; the evidence stream is the
|
||||
same.
|
||||
|
||||
> **Benefit:** a clean scope boundary — Nova is purpose-built for
|
||||
> infrastructure operations and integrates with any upstream source
|
||||
> through one validated contract, so the platform team's surface area
|
||||
> stays bounded.
|
||||
|
||||
> **Speaker notes:** This slide protects the scope. The moment Nova
|
||||
> starts owning the PDLC, it loses focus. The contract boundary is what
|
||||
> keeps Nova deep on infrastructure and delivery rather than shallow on
|
||||
> everything.
|
||||
|
||||
> **Transition:** "With the scope clear, here is who owns what across the
|
||||
> delivery lifecycle."
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — RACI: Who Owns What
|
||||
|
||||
**Four roles, one matrix — the citizen developer owns FRs + UAT, the
|
||||
platform owns NFRs + infra, quality engineering owns the gate evidence,
|
||||
and SRE owns operational readiness.**
|
||||
|
||||
| Work Category | Citizen Dev | Platform | Quality Eng | SRE |
|
||||
|---|---|---|---|---|
|
||||
| Functional Requirements | **R/A** | C | I | I |
|
||||
| User Acceptance Testing | **R/A** | C | I | I |
|
||||
| Non-Functional Requirements | I | **R/A** | C | C |
|
||||
| Infrastructure (cloud, state, IAM) | I | **R/A** | I | C |
|
||||
| QA (policy, confidence, schema) | C | R | **R/A** | I |
|
||||
| Production deployment to cloud | I | **R/A** | C | C |
|
||||
| Quality attestation (QA sign-off) | **A** | R | **R** | I |
|
||||
| Production readiness (SRE sign-off) | **A** | R | C | **R** |
|
||||
|
||||
**R** = Responsible · **A** = Accountable (sign-off) · **C** = Consulted · **I** = Informed.
|
||||
|
||||
- **Compliance-standard equivalence:** FRs + UAT may come from any
|
||||
upstream source (AI agent, agentic SDLC, dev platform) — all pass the
|
||||
same submission-readiness gate.
|
||||
- **Production readiness is co-owned:** the platform runs the
|
||||
attestations agentically; the citizen developer authorizes the
|
||||
promotion at the stage gate.
|
||||
|
||||
> **Benefit:** every party knows what they bring, what the platform
|
||||
> provides, what quality engineering guards, and where SRE signs off —
|
||||
> accountability is explicit, never diffuse.
|
||||
|
||||
> **Speaker notes:** Quality attestation is now owned by Quality
|
||||
> Engineering (not the Platform), and Production readiness is owned by
|
||||
> SRE. The Platform runs the checks agentically but is never the
|
||||
> Accountable party for the gate — that separation keeps the platform
|
||||
> honest.
|
||||
|
||||
> **Transition:** "With ownership clear, here is how the pipeline
|
||||
> enforces it."
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — The Platform Pipeline
|
||||
|
||||
**How intent becomes verified infrastructure — with fail-fast policy
|
||||
scanning before the plan and runtime scanning after it.**
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Contract] --> B[Resolver]
|
||||
B --> C[Adapter]
|
||||
C --> D["Checkov (static code)"]
|
||||
D --> E[Terraform Plan]
|
||||
E --> F["Wiz (on plan)"]
|
||||
F --> G[Confidence Signal]
|
||||
G --> H{Stage Gate}
|
||||
H -->|dev: autonomous| I[Apply]
|
||||
H -->|qa/prod/dr: attested| I
|
||||
I --> J[Evidence + Ledger]
|
||||
```
|
||||
|
||||
- **Contract → resolver → adapter → Checkov on static code (before the
|
||||
plan) → terraform plan → Wiz on the plan → confidence signal → stage
|
||||
gate → apply → evidence + ledger.**
|
||||
- **Fail-fast, quick feedback.** Checkov runs on the authored Terraform
|
||||
code before `terraform plan` so developers get immediate policy
|
||||
feedback, not a delayed plan-stage failure.
|
||||
- **Wiz on the plan when configured; Checkov as a drop-in otherwise.**
|
||||
Wiz scans the terraform plan output. When Wiz credentials are not
|
||||
available, Checkov runs against the plan as a drop-in replacement. Wiz
|
||||
and Checkov are never both run on the plan.
|
||||
- **Dev is autonomous** (no stage gate); **qa/prod/dr require human
|
||||
attestation** (QA for quality, SRE for production readiness).
|
||||
|
||||
> **Benefit:** the pipeline gives developers fast, deterministic feedback
|
||||
> on policy at authoring time and gives the platform a runtime scan on the
|
||||
> resolved plan — two layers of scanning, zero operator involvement in
|
||||
> normal operations.
|
||||
|
||||
> **Speaker notes:** The two-stage scan is the key design: static code
|
||||
> scanning catches policy violations before the cost of a plan; runtime
|
||||
> plan scanning catches what the static code cannot (resolved values,
|
||||
cross-resource issues). The platform picks the runtime scanner based on
|
||||
configuration — never both, to avoid duplicate noise.
|
||||
|
||||
> **Transition:** "The pipeline produces decisions — here is how every
|
||||
> decision is captured and made accountable."
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The Decision Ledger
|
||||
|
||||
**Every automated decision is captured, immutable, queryable — and
|
||||
accountable.**
|
||||
|
||||
- **What is captured:** every action the platform takes — the chosen
|
||||
action, the confidence score, the alternatives considered, whether a
|
||||
human overrode it, and the outcome (backfilled once the apply
|
||||
completes). Every stage-gate attestation (QA sign-off, SRE
|
||||
production-readiness sign-off) is captured with approver identity and
|
||||
the evidence that was presented.
|
||||
- **"AI decisions" are really automated decisions.** The decisions are
|
||||
made by deterministic scripts that calculate a score and a band; the
|
||||
platform functions without AI. The ledger captures the real decision
|
||||
path — not a fabricated "AI agent." When an LLM planner is added later,
|
||||
it will emit richer alternatives without breaking the schema.
|
||||
- **The value is accountability, not the storage engine.** The ledger is
|
||||
an append-only, tamper-evident record. The point is not which database
|
||||
it lives in — the point is that every decision is queryable for
|
||||
auditing, traceable to an outcome, and impossible to rewrite after the
|
||||
fact.
|
||||
|
||||
> **Benefit:** "autonomous" is defensible because every decision the
|
||||
> platform makes is immutable, queryable, and accountable — and the
|
||||
> audience knows exactly what "automated" means here: deterministic
|
||||
> scoring, not a black-box LLM.
|
||||
|
||||
> **Speaker notes:** Do not dwell on the storage substrate. The audience
|
||||
> cares that the ledger is append-only, queryable, and tied to outcomes —
|
||||
> not that it is a hash-chain in a SQLite file. The D-122 honesty point
|
||||
> is restated without the decision ID: the platform's decisions are
|
||||
> deterministic; the ledger captures that real path.
|
||||
|
||||
> **Transition:** "Decisions are captured — here is how stage-gate
|
||||
> attestation keeps humans in accountability."
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — The Attestation Matrix
|
||||
|
||||
**The designed controls that keep humans at stage gates — structured,
|
||||
freshness-validated, and separation-of-duties-enforced.**
|
||||
|
||||
| Concern | Env | Freshness | Description |
|
||||
|---------|-----|-----------|-------------|
|
||||
| Functional correctness | qa | 24h | The application behaves as specified; evidence accepted from the consumer's UAT. |
|
||||
| Performance baseline | qa | 7d | The deployment meets its performance envelope vs. the agreed baseline. |
|
||||
| Security posture | qa | 24h | The deployment's security findings have been reviewed and accepted. |
|
||||
| Operational readiness | prod | 30d | SRE confirms the deployment is operable: runbooks, dashboards, on-call coverage. |
|
||||
| Incident response | prod | 90d | The on-call path has been exercised; the deployment has a working incident-response plan. |
|
||||
| Capacity & cost | prod | 30d | Capacity headroom and monthly cost are within the agreed envelope. |
|
||||
| Resilience: DR drill | prod | 180d | A DR drill has been run and the deployment recovered within the RTO. |
|
||||
| Resilience: chaos | prod | 90d | A chaos exercise has been run and the deployment absorbed the failure. |
|
||||
| Resilience: backup | prod | 30d | Backups are restorable and have been tested within the freshness window. |
|
||||
| DR region deploy | dr | 180d | The DR region can be deployed and the deployment is reachable from it. |
|
||||
|
||||
- Each concern has a freshness window — evidence older than the window
|
||||
does not satisfy the gate.
|
||||
- **Separation-of-duties on prod:** the approver cannot be the same
|
||||
person who built the deployment.
|
||||
- Concerns that are offline-testable run for real; concerns that require
|
||||
external evidence accept signed artifacts.
|
||||
|
||||
> **Benefit:** the gate model is explicit — autonomy in operations,
|
||||
> human in accountability, by design. The matrix is what makes autonomous
|
||||
> operations safe enough to trust in production.
|
||||
|
||||
> **Speaker notes:** The matrix is not a rubber stamp. Each concern has a
|
||||
> freshness window, a description, and a separation-of-duties rule. The
|
||||
> "operator-supplied" label from the prior deck was dropped — every
|
||||
> concern now has a plain-language description of what is being attested.
|
||||
|
||||
> **Transition:** "You've seen how Nova works — the pipeline, the ledger,
|
||||
> the attestation gates. Here is how Nova instruments itself so that
|
||||
> every claim in this deck is traceable to a real signal."
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Telemetry & Live Ops
|
||||
|
||||
**Every metric in this deck is traceable to a real emitted signal — and
|
||||
the live-ops dashboard makes operations visible in PowerBI.**
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
A[Platform components] --> B[CloudEvents envelope]
|
||||
B --> C[Event log]
|
||||
B --> D[Decision ledger]
|
||||
B --> E[Run records]
|
||||
C --> F[Collector]
|
||||
D --> F
|
||||
E --> F
|
||||
F --> G[Cold store]
|
||||
G --> H[PowerBI views]
|
||||
H --> I[Live ops dashboard]
|
||||
```
|
||||
|
||||
- **Platform components emit a CloudEvents envelope** → event log,
|
||||
decision ledger, and run records → collector → cold store → PowerBI
|
||||
views → **live ops dashboard.**
|
||||
- **The live ops dashboard (PowerBI)** surfaces the four CTO-grade
|
||||
metrics — Lead Time, Infrastructure Vulnerability Count, MTTR, Cloud
|
||||
Spend — alongside the trust metrics (Decision Ledger coverage,
|
||||
Attestation coverage) and the efficiency metrics (touchless
|
||||
resolution, escalation frequency).
|
||||
- **The architecture is deliberately minimal.** Nova-native envelopes;
|
||||
no Kafka, no Prometheus, no ClickHouse. The cold store is sufficient
|
||||
for batch and historical analysis; the live-ops surface is built in
|
||||
PowerBI on top of the exported views.
|
||||
- **Every number in the Proof slides is traceable to a signal.** When a
|
||||
CFO asks "where does this number come from?", the answer is a query
|
||||
against the cold store, not a Slack thread.
|
||||
|
||||
> **Benefit:** the architecture is the trust substrate — leadership sees
|
||||
> the same numbers the platform produces, in PowerBI, with full
|
||||
> traceability to the emitted signal. Operations become visible.
|
||||
|
||||
> **Speaker notes:** The value is not the plumbing — it is that the
|
||||
> platform's metrics surface in a tool leadership already uses (PowerBI),
|
||||
> and every number is traceable. The live-ops dashboard is where the
|
||||
> "infrastructure operations become visible" theme lands concretely.
|
||||
|
||||
> **Transition:** "The architecture is sound — here is the measured
|
||||
> proof."
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Decision Ledger + Attestation Coverage
|
||||
|
||||
**By design, no change reaches production without a ledger entry and a
|
||||
human attestation — both queryable for auditing, with full
|
||||
traceability.**
|
||||
|
||||
- **Decision Ledger coverage: 100%.** Every platform run emits a
|
||||
decision record with outcome backfill. No automated decision is ever
|
||||
lost.
|
||||
- **Attestation coverage: 100%.** Every prod/dr promotion is attested by
|
||||
a human — QA for quality, SRE for production readiness — recorded with
|
||||
approver identity, separation-of-duties check, and the evidence matrix.
|
||||
- **No change to production without both.** The ledger entry and the
|
||||
human attestation are mandatory, not optional. This is enforced by the
|
||||
pipeline, not by policy.
|
||||
- **Easily queried for auditing.** The ledger and the attestation
|
||||
records are queryable by run, by environment, by approver, and by
|
||||
outcome — the audit trail is a query, not a forensic exercise.
|
||||
- **Full traceability.** A production change is traceable from the
|
||||
contract that declared intent, through the policy scan, the confidence
|
||||
score, the attestation, to the applied outcome. Nothing is opaque.
|
||||
|
||||
> **Benefit:** trust is provable — not a marketing claim, a queryable
|
||||
> record. An auditor can answer "who approved this, when, on what
|
||||
> evidence?" in one query; a CTO can answer "how many of last quarter's
|
||||
> prod changes were touchless?" in one query.
|
||||
|
||||
> **Speaker notes:** The mandatory-by-design point is the one to land.
|
||||
> The ledger + attestation are not a best-effort feature; they are a
|
||||
> gate. No change reaches production without both. That is what makes
|
||||
> the 100% numbers credible — they are enforced, not aspirational.
|
||||
|
||||
> **Transition:** "Trust is provable — here is the cost side of the ROI."
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — Cost & ROI
|
||||
|
||||
**The ROI formula and the cost estimates — grounded, with the production
|
||||
denominator honestly flagged.**
|
||||
|
||||
- **Cost estimates are pre-apply and offline.** The platform reads the
|
||||
terraform plan and estimates cost before anything is applied — so a
|
||||
regression in cost is caught before the spend happens, not after.
|
||||
- **The ROI formula:**
|
||||
`Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
|
||||
- **The four CTO-grade metrics (from Slide 3) are the ROI proof:**
|
||||
Lead Time (PR → Prod), Infrastructure Vulnerability Count (trend), MTTR,
|
||||
Cloud Spend Reduction. All flow into PowerBI.
|
||||
- **Honest caveat:** the derived metrics are computed on internal runs
|
||||
today; the production-denominator activates when a pilot estate runs.
|
||||
The formula is grounded; the production numbers are not yet.
|
||||
|
||||
> **Benefit:** the ROI is not a black box — the formula is shown, the
|
||||
> four metrics are committed, and the production-denominator caveat is
|
||||
> stated up front. The CFO can see exactly what is real today and what
|
||||
> activates with a pilot.
|
||||
|
||||
> **Speaker notes:** The formula is shown inline, not hidden. The
|
||||
> "no fabrication" constraint in action: show the formula, show the
|
||||
> caveat, do not pretend the production numbers exist.
|
||||
|
||||
> **Transition:** "The proof is grounded — here is what is honestly
|
||||
> deferred, and why."
|
||||
|
||||
---
|
||||
|
||||
## Slide 12 — What's Deferred — and Why
|
||||
|
||||
**Honesty about what is not measured yet — and the blocking work for
|
||||
each.**
|
||||
|
||||
To be clear: these deferrals are measurement infrastructure, not the
|
||||
autonomy itself. The platform runs without an operator in the loop of
|
||||
normal operations. What is deferred is the evidence pipeline for certain
|
||||
metrics — not the autonomy.
|
||||
|
||||
| # | Deferred metric | Blocking work |
|
||||
|---|-----------------|---------------|
|
||||
| 1 | Live infrastructure health | Live AWS re-provisioning (currently torn down to a zero-cost steady state) |
|
||||
| 2 | Live outbox write rate | Live AWS re-provisioning |
|
||||
| 3 | Tamper-evident ledger checkpoints | Audit-ledger build-out (S3 Object Lock + signed checkpoints) |
|
||||
| 4 | Onboarding funnel (requested → granted) | Auto-grant implementation |
|
||||
| 5 | Drift auto-reversal | Drift-detection scheduler (not yet built) |
|
||||
| 6 | Live cost reconciliation | Live AWS re-provisioning + actual-spend feed |
|
||||
| 7 | SLA / unplanned downtime | Live AWS re-provisioning |
|
||||
| 8 | Predictive vs reactive ratio | ML anomaly-forecasting service (not yet built) |
|
||||
|
||||
> **Benefit:** the boundaries are explicit — what Nova measures today,
|
||||
> and exactly what blocks the rest. The autonomy is real; the measurement
|
||||
> gaps are documented with the work that unblocks each one.
|
||||
|
||||
> **Speaker notes:** The preempt is critical: these deferrals are
|
||||
> measurement infrastructure, not autonomy. The platform runs without an
|
||||
> operator in the loop. What is deferred is the evidence pipeline for
|
||||
> live-infra health, drift, predictive remediation — not the autonomy
|
||||
> itself.
|
||||
|
||||
> **Transition:** "The proof is honest — here is the roadmap from here to
|
||||
> the targets."
|
||||
|
||||
---
|
||||
|
||||
## Slide 13 — Roadmap to the North Star
|
||||
|
||||
**The path from the grounded metrics to the 12–18 month targets — each
|
||||
deferred metric has an unblock path and a candidate milestone.**
|
||||
|
||||
| Timeframe | Work | Unblocks |
|
||||
|-----------|------|----------|
|
||||
| Near-term | Live AWS re-provisioning | Live infra health, live outbox write rate, live cost reconciliation, SLA |
|
||||
| Near-term | Auto-grant implementation | Onboarding funnel (requested → granted) |
|
||||
| Mid-term | Drift-detection scheduler | Drift auto-reversal |
|
||||
| Mid-term | Audit-ledger build-out (Object Lock + signed checkpoints) | Tamper-evident ledger checkpoints |
|
||||
| Mid-term | Hot-path activation (live-ops dashboard goes from batch to near-real-time) | Live-ops dashboard freshness |
|
||||
| Longer-term | ML anomaly-forecasting service | Predictive vs reactive ratio |
|
||||
|
||||
- Each deferred metric has a specific unblock requirement and a
|
||||
candidate future milestone.
|
||||
- Re-evaluation triggers: each blocking piece of work lifts on its own
|
||||
schedule; the metrics layer evolves as each one lands.
|
||||
|
||||
> **Benefit:** every deferred metric has an unblock path — nothing is
|
||||
> hand-waved; everything has a plan and a timeframe.
|
||||
|
||||
> **Speaker notes:** This is the bridge from "honestly deferred" to
|
||||
> "here is how we get there." The roadmap uses timeframes, not status —
|
||||
> most of it is not implemented yet, so a status column would be noise.
|
||||
|
||||
> **Transition:** "The unblock path is clear — here is the 12-month
|
||||
> product arc."
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — 12-Month Product Roadmap
|
||||
|
||||
**The product arc from pilot activation to integration — four quarters,
|
||||
four outcomes.**
|
||||
|
||||
| Quarter | Theme | Board-level outcome |
|
||||
|---------|-------|---------------------|
|
||||
| **Q1** | Pilot Activation | Nova runs a real customer estate end-to-end, autonomously, with a measurable zero-touch rate. |
|
||||
| **Q2** | Provable Trust | Every automated decision lands in a tamper-evident ledger; the CFO sees real cloud-spend reconciliation. |
|
||||
| **Q3** | Compounding ROI | Quarter-over-quarter cloud spend drops; drift is detected and reversed without a human. |
|
||||
| **Q4** | Integration & Predictive | AI agents deploy through Nova by default; the ML anomaly-forecasting service goes live. |
|
||||
|
||||
Grounded in the four strategic objectives (autonomy, provable trust, ROI,
|
||||
integration) and the deferred-metric unblock paths.
|
||||
|
||||
> **Benefit:** the 12-month product arc — each quarter activates a
|
||||
> strategic objective and its corresponding board-level metric, from
|
||||
> pilot activation through integration leadership.
|
||||
|
||||
> **Speaker notes:** The roadmap is organized by product outcome, not
|
||||
> by technical milestone. Each quarter activates one strategic
|
||||
> objective from the North Star.
|
||||
|
||||
> **Transition:** "Here is the quarter-by-quarter detail."
|
||||
|
||||
---
|
||||
|
||||
## Slide 15 — Quarter-by-Quarter Outcomes
|
||||
|
||||
| Quarter | Product theme | Key deliverable | Target metric | Grounding |
|
||||
|---------|---------------|-----------------|---------------|-----------|
|
||||
| **Q1** | Pilot Activation | Re-provision live AWS; activate first pilot estate; onboarding auto-grant | Touchless ≥ 99% · Escalation < 0.1% · Accuracy ≥ 99.5% | Objective #1 — autonomy as the default |
|
||||
| **Q2** | Provable Trust | Tamper-evident ledger (Object Lock + signed checkpoints); daily checkpoints; live cost reconciliation | Decision Ledger Coverage 100% · Cost Savings ≥ 25% | Objective #2 — trust is the moat |
|
||||
| **Q3** | Compounding ROI + Drift | Drift-detection scheduler; auto-reversal; pre-apply → actual-spend reconciliation on the pilot estate | Drift Auto-Reversal ≥ 95% · Spend Reduction ≥ 25% | Objective #3 — CFO-pointable numbers |
|
||||
| **Q4** | Integration + Predictive | ML anomaly-forecasting; AI-agent intent surface; multi-cloud (Azure/GCP) preview | Predictive:Reactive ≥ 3:1 · AI-Agent Intent Share (first measurement) | Objective #4 — default substrate for agents |
|
||||
|
||||
**Month-18 destination:** *"Nova is the layer enterprise leadership
|
||||
points to when they say 'we don't have an infrastructure ops team
|
||||
anymore, and the audit trail is stronger than it ever was.'"*
|
||||
|
||||
> **Benefit:** each quarter has a concrete deliverable, a target metric
|
||||
> grounded in a strategic objective, and a path from "honestly deferred"
|
||||
> to "shipped and measured."
|
||||
|
||||
> **Speaker notes:** Q1–Q3 are committed (grounded pipeline + known
|
||||
> unblock paths). Q4 targets are committed-deliverable,
|
||||
> aspirational-metric — the ML service ships, the intent-share number is
|
||||
> a first measurement (we do not control adoption rate).
|
||||
|
||||
> **Transition:** "Production-grade guidance is how Nova helps the
|
||||
> citizen developer's AI agent meet the bar — here is the first half."
|
||||
|
||||
---
|
||||
|
||||
## Slide 16 — Production-Grade Guidance via Atelier (1/2)
|
||||
|
||||
**Nova instructs the citizen developer's AI agent on production-grade
|
||||
engineering — a set of skills and an MCP server.**
|
||||
|
||||
- **Skills** — markdown files keyed to production-grade engineering
|
||||
domains (API, security, data, testing, observability, errors, DevOps,
|
||||
infrastructure-as-code, compliance). The skills extend the baseline
|
||||
catalog with Nova-specific production-grade principles.
|
||||
- **MCP server** — a plugin-registry, stdio server exposing four tools:
|
||||
`lookup_principle`, `list_domains`, `matrix_lookup`, and
|
||||
`validate_against_principles`. The developer's AI agent (or any
|
||||
agentic SDLC platform) calls these tools to look up the principles
|
||||
that apply to its submission.
|
||||
- **The integration point is the same regardless of source.** Whether
|
||||
the submission comes from an AI coding agent, an agentic SDLC
|
||||
platform, or a traditional IDE, the same skills and MCP server apply.
|
||||
This is how Nova makes the citizen developer production-grade without
|
||||
owning the PDLC.
|
||||
|
||||
> **Benefit:** the citizen developer's AI agent is not unguided — Nova
|
||||
> provides production-grade engineering principles as skills and as an
|
||||
> MCP surface, so submissions arrive at the contract boundary already
|
||||
> aligned with the platform's standards.
|
||||
|
||||
> **Speaker notes:** This is the first half of the Atelier story — the
|
||||
> surface (skills + MCP). The next slide is what the surface catches
|
||||
> that deterministic scanners cannot.
|
||||
|
||||
> **Transition:** "Here is what that guidance catches that deterministic
|
||||
> scanners cannot."
|
||||
|
||||
---
|
||||
|
||||
## Slide 17 — Production-Grade Guidance via Atelier (2/2)
|
||||
|
||||
**Agentic validation catches engineering-discipline gaps that deterministic
|
||||
scanners miss — and the validation is reproducible.**
|
||||
|
||||
- **Beyond deterministic scanners.** Wiz, Checkmarx, and Mend check
|
||||
policy and secrets — they do not check engineering discipline. The
|
||||
Atelier MCP server catches correctness, clarity, and observability gaps
|
||||
that deterministic tools cannot: "is this service observable?",
|
||||
"is this error path handled?", "is this API contract clear?"
|
||||
- **Agentic validation, not a second policy engine.** The MCP server
|
||||
gives the AI agent the principles to validate against; the agent does
|
||||
the validation. This is agentic validation — the agent reasons about
|
||||
the submission against the principles, not a second static scan.
|
||||
- **Vendored for audit reproducibility.** Atelier is vendored at a
|
||||
pinned tag. A validation result is replayable against the exact
|
||||
principles that produced it — so an audit can reproduce a validation
|
||||
months later, not just trust a log line.
|
||||
|
||||
> **Benefit:** the citizen developer's submission is checked for
|
||||
> engineering discipline, not just policy compliance — and the check is
|
||||
> reproducible for audit. That is what makes the submission
|
||||
> production-grade, regardless of which upstream platform produced it.
|
||||
|
||||
> **Speaker notes:** The value is the gap deterministic scanners leave:
|
||||
engineering discipline. Policy scanners catch "is this S3 bucket
|
||||
public?"; the MCP server catches "is this service observable if that
|
||||
bucket fails?". The vendoring point is audit reproducibility — the
|
||||
validation is not a black box.
|
||||
|
||||
> **Transition:** "You've seen the problem, the solution, and the proof.
|
||||
> Here is the recap and the ask."
|
||||
|
||||
---
|
||||
|
||||
## Slide 18 — Recap + Ask
|
||||
|
||||
**The 4-beat recap + the business decision.**
|
||||
|
||||
**Recap:**
|
||||
- **Problem:** product teams own infrastructure without the discipline
|
||||
and lifecycle planning it requires; bandwidth gaps and tribal
|
||||
knowledge leave operations exposed.
|
||||
- **Solution:** autonomous cloud delivery — operations become visible,
|
||||
trust is provable (deterministic scoring), humans at stage gates.
|
||||
- **Proof:** 100% ledger coverage, 100% attestation coverage, grounded
|
||||
ROI formula, four CTO-grade metrics flowing into PowerBI.
|
||||
- **Roadmap:** deferred metrics have unblock paths; the 12-month product
|
||||
arc activates one strategic objective per quarter.
|
||||
|
||||
**The ask:** "Approve a pilot estate to activate the production-denominator
|
||||
metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend), and approve
|
||||
the tamper-evident ledger build-out to move from the local hash-chain to
|
||||
S3 Object Lock + signed checkpoints. These two decisions move Nova from
|
||||
'pipeline-ready' to 'production-proven.'"
|
||||
|
||||
> **Benefit:** a clear business decision — approve a pilot and the ledger
|
||||
> build-out — with the confidence that every claim in this deck is
|
||||
> grounded, derived, or honestly deferred.
|
||||
|
||||
> **Speaker notes:** The ask is a business decision, not insider
|
||||
> language. "Approve a pilot estate" is a C-suite decision. "Approve the
|
||||
> ledger build-out" is a budget decision. The recap reinforces the 4-beat
|
||||
> arc — the audience leaves with the structure, not a pile of facts.
|
||||
|
||||
---
|
||||
|
||||
## Appendix A1 — Metrics Glossary
|
||||
|
||||
| KPI | Definition | Status |
|
||||
|-----|-----------|--------|
|
||||
| Touchless Resolution Rate | runs without operational stage-gate block ÷ total | partial (Post-Pilot) |
|
||||
| Human Escalation Frequency | operational stage-gate blocks ÷ total | partial (Post-Pilot) |
|
||||
| Automated Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
|
||||
| MTTR (p95) | apply.failed → successful retry | grounded |
|
||||
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
|
||||
| Provisioning Lead Time | run.completed − run.started | grounded |
|
||||
| Deployment Frequency | count(run.completed) per day | grounded |
|
||||
| Cost Savings (pre-apply) | sum(delta_usd where delta < 0) | partial (live reconciliation deferred) |
|
||||
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
|
||||
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
|
||||
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
|
||||
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
|
||||
| Policy Compliance Rate | 1 − failed_assets ÷ total | grounded |
|
||||
|
||||
> **Benefit:** a reference for every metric mentioned in the deck.
|
||||
|
||||
---
|
||||
|
||||
> **End of deck.** 18 main slides + 1 appendix slide = 19 total.
|
||||
Binary file not shown.
@@ -1,403 +0,0 @@
|
||||
---
|
||||
marp: true
|
||||
theme: nova-sp
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: 'Nova — The No-Humans Infrastructure Platform'
|
||||
footer: 'Act %{page}/5 — v1.20'
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Nova — The No-Humans Infrastructure Platform
|
||||
|
||||
**Shifting from Operational Overhead to Strategic Value**
|
||||
|
||||
v1.18 — Citizen Developer & Production-Grade Guidance
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Arc Preview
|
||||
|
||||
**This deck proves Nova is the no-humans infrastructure platform — and shows you the metrics that make the claim defensible.**
|
||||
|
||||
**Today:** 18 capabilities verified, 0 consumer estates in production.
|
||||
|
||||
**The 5-act arc:**
|
||||
1. **Problem** — why the operator is the bottleneck
|
||||
2. **Vision** — Nova's strategic direction (NORTH_STAR)
|
||||
3. **How** — the pipeline, Decision Ledger, attestation gates
|
||||
4. **Proof** — grounded metrics that make the claim defensible
|
||||
5. **Roadmap** — deferred metrics with unblock paths + the ask + scope + RACI
|
||||
|
||||
**Benefit:** you leave knowing which claims are proven today, which are pipeline-ready, and which are deferred with a documented unblock path — no marketing, just grounded evidence.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — The No-Humans Imperative
|
||||
|
||||
**Why the operator is the bottleneck — and why removing them from operations (not accountability) is the imperative.**
|
||||
|
||||
- **The cost of humans-in-the-loop:** L1/L2 ops hours, escalation latency, the trust gap
|
||||
- **The operator is the bottleneck:** provisioning takes days, not minutes
|
||||
- **The attestation model:** autonomy in operations, human at stage gates
|
||||
- Cites `docs/NO_HUMANS_THESIS.md`
|
||||
|
||||
**Benefit:** you now know the problem framing — autonomy in operations, human at stage gates, is the path forward.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Nova's Vision
|
||||
|
||||
> **Infrastructure operations become invisible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates — QA signs off for production, SRE greenlights based on operational readiness — but the operator is never in the loop of normal operations.**
|
||||
|
||||
- Autonomy in operations, not in accountability
|
||||
- Cites `docs/NO_HUMANS_THESIS.md`
|
||||
|
||||
**Benefit:** you now know the destination — invisible operations with provable trust, not promised trust.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Strategic Objectives + Anti-Goals
|
||||
|
||||
**4 Strategic Objectives:**
|
||||
1. **Zero-touch operations** — autonomy as the default, not the demo
|
||||
2. **Provable trust in AI decisions** — Decision Ledger, confidence scoring, circuit breakers
|
||||
3. **Compounding, quantifiable ROI** — each quarter must reduce spend, free hours, avoid downtime
|
||||
4. **Default substrate for agentic consumption** — the platform AI agents reach for first
|
||||
|
||||
**5 Anti-Goals (what Nova is NOT):**
|
||||
1. Not a hyperscaler competitor
|
||||
2. Not a general-purpose AI platform
|
||||
3. Not removing humans from accountability
|
||||
4. Not for legacy, untagged, or freeform infrastructure
|
||||
5. Not sold to operators
|
||||
|
||||
**Benefit:** you now know the scope boundaries — Nova is purpose-built for infrastructure operations, sold to leadership on outcomes.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — 12–18 Month Targets
|
||||
|
||||
**Current-milestone targets (grounded/derived):**
|
||||
|
||||
| Domain | Target | Status |
|
||||
|---|---|---|
|
||||
| MTTR (p95) | < 60s | grounded |
|
||||
| Cloud Spend Reduction | ≥ 25% | partial (CUR deferred D-096) |
|
||||
| L1/L2 Ops Hours Avoided | ≥ 70% | derived (N internal runs) |
|
||||
| Platform ROI | ≥ 250% | derived (formula; N=0 caveat) |
|
||||
| Decision Ledger Coverage | 100% | grounded |
|
||||
| Attestation Coverage | 100% | grounded |
|
||||
|
||||
**Post-Pilot targets (pipeline grounded; 0 consumers today):**
|
||||
|
||||
| Domain | Target | Status |
|
||||
|---|---|---|
|
||||
| Touchless Resolution Rate | ≥ 99% | partial |
|
||||
| Human Escalation Frequency | < 0.1% | partial |
|
||||
| AI Decision Accuracy | ≥ 99.5% | partial |
|
||||
|
||||
**Deferred:** Predictive vs Reactive ≥3:1 <span class="badge planned">Planned</span> · Drift Auto-Reversal ≥95% <span class="badge planned">Planned</span>
|
||||
|
||||
**Benefit:** you now know the destination numbers — and which are measurable today vs deferred honestly.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — The Platform Pipeline
|
||||
|
||||
**How intent becomes verified infrastructure without an operator.**
|
||||
|
||||
Contract → Resolver → Adapter → Terraform Plan → Checkov (Policy) → Confidence Signal → HITL Gate → Apply → Evidence
|
||||
|
||||
- Dev: autonomous (no HITL gate)
|
||||
- qa/prod/dr: attested (human sign-off required)
|
||||
- Grounded in `run_platform.sh` + `contract_resolver.py` + `confidence_signal.py`
|
||||
|
||||
**Benefit:** you now know the path from intent to evidence — and where the human appears (stage gates only).
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The Decision Ledger
|
||||
|
||||
**Every AI decision captured with confidence, alternatives, and outcome.**
|
||||
|
||||
- `outbox_writer.py` → SQLite append-only hash-chain table
|
||||
- `ai.decision.made`: decision_id=run_id, chosen_action=band, confidence=score, alternatives=perInput, human_override=HITL block
|
||||
- `attestation.recorded`: qa/prod/dr sign-offs
|
||||
- D-121, D-122, D-132. Honors D-083 (no S3 Object Lock/JWS — local hash-chain)
|
||||
|
||||
**D-122 honesty:** Nova's "AI" is the confidence-gated policy engine (confidence_signal + HITL gate), not an LLM planner. The Decision Ledger captures this real decision path — not a fabricated "AI agent."
|
||||
|
||||
**Benefit:** you now know why 'autonomous' is defensible — every decision is immutable, queryable, and accountable. And you know exactly what 'AI' means here: a confidence-gated policy engine, not a black-box LLM.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — The 8-Concern Attestation Matrix
|
||||
|
||||
**Designed controls that keep humans at stage gates.**
|
||||
|
||||
| Concern | Env | Freshness | Type |
|
||||
|---------|-----|-----------|------|
|
||||
| functional_correctness | qa | 24h | operator-supplied |
|
||||
| performance_baseline | qa | 7d | operator-supplied |
|
||||
| security_posture | qa | 24h | operator-supplied |
|
||||
| operational_readiness | prod | 30d | operator-supplied |
|
||||
| incident_response | prod | 90d | operator-supplied |
|
||||
| capacity_cost | prod | 30d | operator-supplied |
|
||||
| resilience_dr_drill | prod | 180d | operator-supplied |
|
||||
| dr_region_deploy | dr | 180d | operator-supplied |
|
||||
|
||||
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence
|
||||
- Separation-of-duties on prod
|
||||
- Grounded in `attestation_matrix.py` + `hitl_gates.py`
|
||||
|
||||
**Benefit:** you now know the gate model — autonomy in operations, human in accountability, by design.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Telemetry Architecture
|
||||
|
||||
**How Nova instruments itself — CloudEvents envelope, cold store, PowerBI export.**
|
||||
|
||||
Platform → CloudEvents 1.0 → `metrics/events.jsonl` + `metrics/decision_ledger.db` + `metrics/runs/` → Collector → `metrics/nova_metrics.db` (SQLite cold store) → `metrics/powerbi/` (CSV/JSON) → PowerBI
|
||||
|
||||
- D-120 (Nova-native), D-125 (hybrid), D-126 (cold-only)
|
||||
- <span class="badge planned">Planned</span>: Hot-path (live ops dashboard) — D-126
|
||||
|
||||
**Benefit:** you now know that every metric in this deck is traceable to a real emitted event — the architecture IS the trust substrate. When a CFO asks 'where does this number come from?', the answer is a file path, not a Slack thread.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Capability Health + Confidence Distribution
|
||||
|
||||
**Grounded proof: capability health and confidence distribution from real runs.**
|
||||
|
||||
| Status | Count |
|
||||
|--------|-------|
|
||||
| Verified | 18 |
|
||||
| Skipped | 4 |
|
||||
| Broken | 0 |
|
||||
| Decayed | 0 |
|
||||
|
||||
- 4 Skipped = live-AWS caps (CAP-013..016), honestly skipped (D-096 teardown), not a failure
|
||||
- Source: `.ciagent/REGRESSION_REPORT.json`
|
||||
|
||||
**Benefit:** you now know the platform is verified — 18 capabilities pass, 4 are honestly skipped, 0 broken.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — Decision Ledger + Attestation Coverage
|
||||
|
||||
**Trust metrics — both 100%.**
|
||||
|
||||
- **Decision Ledger Coverage:** 100% of platform runs emit `ai.decision.made` with outcome backfill
|
||||
- **Attestation Coverage:** 100% of prod/dr promotions attested by a human
|
||||
- **AI Decision Accuracy:** decisions not followed by apply.failed/incident within 5min
|
||||
- Trust snapshot: `metrics/TRUST_SNAPSHOT.md` with chain-integrity verdict
|
||||
- <span class="badge planned">Planned</span>: Tamper-Evident Ledger Checkpoints (D-083)
|
||||
|
||||
**Benefit:** you now know the trust is provable — not a marketing claim, a queryable record.
|
||||
|
||||
---
|
||||
|
||||
## Slide 12 — Zero-Touch Efficiency
|
||||
|
||||
**Touchless resolution, human escalation, and MTTR.**
|
||||
|
||||
- **Touchless Resolution Rate:** runs without operational HITL block ÷ total (attestation gates excluded)
|
||||
- **Human Escalation Frequency:** operational HITL blocks only (confidence-driven; attestation sign-offs excluded)
|
||||
- **MTTR (platform-run):** apply.failed → successful retry (D-131)
|
||||
|
||||
**Post-Pilot caveat:** computed on N internal runs today; production-denominator activates when a pilot estate runs.
|
||||
|
||||
**Benefit:** you now know the zero-touch efficiency is measurable — the pipeline works today on internal runs, and the denominator expands to production estates when a pilot activates.
|
||||
|
||||
---
|
||||
|
||||
## Slide 13 — Cost & ROI
|
||||
|
||||
**Cost estimates and the ROI formula — with honest caveats.**
|
||||
|
||||
- **Cost Estimates via Infracost:** pre-apply, grounded (reads plan JSON, offline)
|
||||
- **ROI formula:** `Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
|
||||
- **N=0 caveat:** "Computed on N internal runs today; production-denominator activates post-pilot. The formula is grounded; the production numbers are not yet."
|
||||
- <span class="badge planned">Planned</span>: Live CUR Reconciliation (D-096)
|
||||
|
||||
**Benefit:** you now know the ROI formula — and you know it's computed on internal runs today, not fabricated production numbers.
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — What's Deferred — and Why
|
||||
|
||||
**Honesty about what isn't measured yet.**
|
||||
|
||||
**To be clear:** these deferrals are *measurement infrastructure*, not whether the platform runs without humans. The platform IS autonomous in operations. What's deferred is the *evidence pipeline* for certain metrics — not the autonomy itself.
|
||||
|
||||
| # | Deferred Metric | Blocking Decision |
|
||||
|---|----------------|-------------------|
|
||||
| 1 | Live Infrastructure Health | D-096 |
|
||||
| 2 | Live Outbox Write Rate | D-096 |
|
||||
| 3 | Tamper-Evident Ledger Checkpoints | D-083 |
|
||||
| 4 | Onboarding Funnel (granted) | D-113/D-114/D-119 |
|
||||
| 5 | Drift Auto-Reversal | D-096 + no scheduler |
|
||||
| 6 | Live CUR Reconciliation | D-096 |
|
||||
| 7 | SLA / Unplanned Downtime | D-096 |
|
||||
| 8 | Predictive vs Reactive | future emitter |
|
||||
|
||||
**Benefit:** you now know the boundaries — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented.
|
||||
|
||||
---
|
||||
|
||||
## Slide 15 — Roadmap to the North Star
|
||||
|
||||
**The path from v1.17's grounded metrics to the 12–18 month targets.**
|
||||
|
||||
- Each deferred metric → blocking decision → unblock requirement → candidate milestone
|
||||
- Hot-path activation (post-D-096, Nova-native only, D-120)
|
||||
- Re-evaluation triggers: D-096 lift, D-083 lift, onboarding-grant lift
|
||||
|
||||
From `docs/METRICS_DEFERRED_ROADMAP.md`.
|
||||
|
||||
**Benefit:** you now know the path — every deferred metric has an unblock requirement and a candidate milestone. Nothing is hand-waved; everything has a plan.
|
||||
|
||||
---
|
||||
|
||||
## Slide 16 — Recap + Ask
|
||||
|
||||
**The 5-act recap + the business decision.**
|
||||
|
||||
**Recap:**
|
||||
- **Problem:** operator is the bottleneck; autonomy in operations, human at stage gates
|
||||
- **Vision:** invisible operations with provable trust (NORTH_STAR)
|
||||
- **How:** pipeline + Decision Ledger + 8-concern attestation matrix
|
||||
- **Proof:** 18V+4S, 100% ledger coverage, 100% attestation, grounded ROI formula
|
||||
- **Roadmap:** deferred metrics have unblock paths
|
||||
|
||||
**The ask:** "Approve a pilot estate to activate the production-denominator metrics (Touchless Resolution, Human Escalation, AI Decision Accuracy), and approve the tamper-evident ledger build-out (D-083 lift) to move from local hash-chain to S3 Object Lock + JWS. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
|
||||
|
||||
**Benefit:** you leave with a clear business decision to make — approve a pilot + the ledger build-out — and the confidence that every claim in this deck is grounded, derived, or honestly deferred.
|
||||
|
||||
---
|
||||
|
||||
## Slide 17 — Scope: Downstream of PDLC
|
||||
|
||||
**Nova governs infrastructure + delivery. The PDLC (product backlog, code authorship, IDE) is upstream — Nova never penetrates it.**
|
||||
|
||||
- **The PDLC is upstream:** product backlog, code authorship (AI agent / IDE / agentic SDLC), sprint planning, application business logic
|
||||
- **Nova is downstream:** contract ingestion → submission-readiness gate → policy → cloud lifecycle → environment progression → audit + attestation
|
||||
- **Integration is only through the contract boundary:** the citizen developer's AI coding agent, an upstream agentic SDLC, or any dev platform may all produce submissions — the source does not matter as all are subject to the same compliance standards
|
||||
- Nova validates the submission, not the author
|
||||
- Cites `docs/scope.md` + `PROJECT.md` § Scope
|
||||
|
||||
**Benefit:** you now know the scope boundary — Nova is purpose-built for infrastructure operations, not product development; integration is through one validated contract.
|
||||
|
||||
---
|
||||
|
||||
## Slide 18 — RACI: Who Owns What
|
||||
|
||||
**Three roles, one matrix — the citizen developer owns FRs + UAT, the platform owns NFRs + infra + QA + prod deploy, release management is co-owned.**
|
||||
|
||||
| Work Category | Citizen Dev | Platform | Release Mgmt |
|
||||
|---|---|---|---|
|
||||
| Functional Requirements (FRs) | **R/A** | C | I |
|
||||
| User Acceptance Testing (UAT) | **R/A** | C | I |
|
||||
| Non-Functional Requirements (NFRs) | I | **R/A** | C |
|
||||
| Infrastructure (cloud, state, IAM) | I | **R/A** | C |
|
||||
| QA (policy, confidence, schema) | C | **R/A** | I |
|
||||
| Production deployment to cloud | I | **R/A** | C |
|
||||
| Release attestation (QA + SRE) | **A** | R | **R** |
|
||||
|
||||
- **Compliance-standard equivalence:** FRs + UAT may come from any upstream source (AI agent, agentic SDLC, dev platform) — all pass the same submission-readiness gate
|
||||
- **Release co-ownership:** the platform runs the attestations agentically; the citizen developer oversees and triggers the actual release (human at the stage gate)
|
||||
- Cites `docs/raci.md` + `PROJECT.md` § RACI Matrix
|
||||
|
||||
**Benefit:** you now know exactly what you bring (FRs + UAT), what Nova provides (NFRs + infra + QA + prod deploy), and what you co-own (the release attestation).
|
||||
|
||||
---
|
||||
|
||||
## Slide 19 — Production-Grade Guidance via Atelier
|
||||
|
||||
**Nova instructs the citizen developer's AI agent on production-grade engineering — skills + an MCP server with agentic validation beyond deterministic scanners.**
|
||||
|
||||
- **Skills (9):** markdown files under `skills/` keyed to Atelier domain paths (api, security, data, testing, observability, errors, devops, infrastructure-as-code, compliance) — extending the BA.A 5-skill catalog
|
||||
- **MCP server:** `mcp/atelier/server.py` (plugin-registry, stdio) — 4 tools: `lookup_principle`, `list_domains`, `matrix_lookup`, `validate_against_principles`
|
||||
- **Agentic validation:** catches C1 correctness + C2 clarity + C7 observability gaps that Wiz/Checkmarx/Mend cannot — deterministic tools check policy/secrets; the MCP server checks engineering discipline
|
||||
- **Vendored Atelier** (pinned tag v0.3.6): audit reproducibility — a validation result is replayable against the exact principles that produced it
|
||||
- Cites `docs/skills.md` + `mcp/atelier/README.md`
|
||||
|
||||
**Benefit:** you now know the citizen developer is not unguided — Nova provides production-grade engineering principles via skills + an MCP server, so the AI agent's submissions meet the same standards regardless of upstream source.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
## Appendix A1 — Metrics Glossary
|
||||
|
||||
| KPI | Definition | Status |
|
||||
|-----|-----------|--------|
|
||||
| Touchless Resolution Rate | runs without operational HITL block ÷ total | partial (Post-Pilot) |
|
||||
| Human Escalation Frequency | operational HITL blocks ÷ total | partial (Post-Pilot) |
|
||||
| AI Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
|
||||
| MTTR (p95) | apply.failed → successful retry | grounded |
|
||||
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
|
||||
| Provisioning Lead Time | run.completed − run.started | grounded |
|
||||
| Deployment Frequency | count(run.completed) per day | grounded |
|
||||
| Cost Savings (Infracost) | sum(delta_usd where delta < 0) | partial (CUR deferred) |
|
||||
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
|
||||
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
|
||||
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
|
||||
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
|
||||
| Policy Compliance Rate | 1 − failed_assets ÷ total | grounded |
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
## Appendix A2 — Operating Model & Cost
|
||||
|
||||
- **Cost figures** from `COST.md`: $0.001883 over 8 days, ~$0.007/month, S3-dominated, zero BAU compute
|
||||
- **Zero-cost steady state:** all resources torn down post-v1.11 (D-096); the platform runs offline
|
||||
- References the pre-mortem (`PRE_MORTEM.md`: v1.10 decay root cause + structural mitigations)
|
||||
|
||||
**Benefit:** you now know the operating cost is negligible — and the structural mitigation that prevents decay.
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
## Slide 20 — 12-Month Product Roadmap
|
||||
|
||||
**The product arc from pilot activation to agentic substrate — four quarters, four outcomes.**
|
||||
|
||||
| Quarter | Theme | Board-level outcome |
|
||||
|---------|-------|---------------------|
|
||||
| **Q1** | <span class="badge planned">Pilot Activation</span> | Nova runs a real customer estate end-to-end, autonomously, with a measurable zero-touch rate |
|
||||
| **Q2** | <span class="badge planned">Provable Trust</span> | Every AI decision lands in a tamper-evident ledger; CFO sees real cloud-spend reconciliation |
|
||||
| **Q3** | <span class="badge planned">Compounding ROI</span> | Quarter-over-quarter cloud spend drops; drift is detected and reversed without a human |
|
||||
| **Q4** | <span class="badge planned">Agentic Substrate</span> | AI agents deploy through Nova by default; Nova is the substrate, not a vendor arriving late |
|
||||
|
||||
**Grounded in:** the 4 strategic objectives (autonomy, provable trust, ROI, agentic substrate) + the deferred-metric unblock paths.
|
||||
|
||||
**Benefit:** you now know the 12-month product arc — each quarter activates a strategic objective and its corresponding board-level metric, from pilot activation through agentic substrate leadership.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
## Slide 21 — Quarter-by-Quarter Outcomes
|
||||
|
||||
| Quarter | Product theme | Key deliverable | Target metric | Grounding |
|
||||
|---------|--------------|-----------------|---------------|-----------|
|
||||
| **Q1** | Pilot Activation | Re-provision live AWS; activate first pilot estate; onboarding auto-grant | Touchless Resolution ≥ 99% · Escalation < 0.1% · AI Accuracy ≥ 99.5% | Strategic Objective #1 — autonomy as the default |
|
||||
| **Q2** | Provable Trust | Tamper-evident ledger (Object Lock + JWS); daily checkpoints; live cost reconciliation (CUR) | Decision Ledger Coverage 100% · Cost Savings ≥ 25% | Strategic Objective #2 — trust is the moat |
|
||||
| **Q3** | Compounding ROI + Drift | Drift detection scheduler; auto-reversal; Infracost→CUR reconciliation on pilot estate | Drift Auto-Reversal ≥ 95% · Spend Reduction ≥ 25% | Strategic Objective #3 — CFO-pointable numbers |
|
||||
| **Q4** | Agentic Substrate + Predictive | ML anomaly-forecasting; AI-agent intent surface; multi-cloud (Azure/GCP) preview | Predictive:Reactive ≥ 3:1 · AI-Agent Intent Share ≥ 40% (first measurement) | Strategic Objective #4 — default substrate for agents |
|
||||
|
||||
**Month-18 destination:** *"Nova is the layer enterprise leadership points to when they say 'we don't have an infrastructure ops team anymore, and the audit trail is stronger than it ever was.'"*
|
||||
|
||||
**Benefit:** you now know the quarter-by-quarter detail — each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from "honestly deferred" to "shipped and measured."
|
||||
@@ -1,164 +0,0 @@
|
||||
# Nova — The No-Humans Infrastructure Platform: Talking Points
|
||||
|
||||
> Step 4 of the 4-step deck process. Presenter cues distilled from the
|
||||
> source of truth (`nova-no-humans-platform.md`). 3-6 bullets per slide
|
||||
> + key takeaway. Indexed by Marp slide #.
|
||||
> v1.17 — REQ-196, REQ-197
|
||||
|
||||
---
|
||||
|
||||
### Slide 1 — Arc Preview
|
||||
- Open with the stake line: "18 capabilities verified, 0 consumer estates in production"
|
||||
- Preview the 5-act arc so the audience knows the structure
|
||||
- Set the honesty frame: "this is an evidence deck, not a hype deck"
|
||||
- **Key takeaway:** you'll leave knowing what's proven, what's pipeline-ready, and what's deferred
|
||||
|
||||
### Slide 2 — The No-Humans Imperative
|
||||
- The operator is the bottleneck: days vs. minutes for provisioning
|
||||
- Key reframing: "no-humans" = no human in normal operations; stage-gate attestation is human by design
|
||||
- Cite the no-humans thesis doc
|
||||
- **Key takeaway:** autonomy in operations, human at stage gates
|
||||
|
||||
### Slide 3 — Nova's Vision
|
||||
- Read the vision statement verbatim — it's precise
|
||||
- Emphasize "provable, not promised" — the difference between marketing and defensible
|
||||
- State the attestation model up front to prevent mishearing
|
||||
- **Key takeaway:** invisible operations with provable trust
|
||||
|
||||
### Slide 4 — Strategic Objectives + Anti-Goals
|
||||
- The 4 objectives are the "what"; the 5 anti-goals are the "what NOT"
|
||||
- Anti-goal #3 (not removing humans from accountability) reinforces slide 3
|
||||
- Anti-goal #5 (not sold to operators) explains why this deck is for leadership
|
||||
- **Key takeaway:** purpose-built for infra ops, sold to leadership on outcomes
|
||||
|
||||
### Slide 5 — 12–18 Month Targets
|
||||
- The three-section split (current / post-pilot / deferred) IS the honesty model
|
||||
- "Partial" means the pipeline works but the denominator is zero (0 consumers)
|
||||
- The Post-Pilot targets are committed; the numbers fill when a pilot runs
|
||||
- **Key takeaway:** which numbers are real today vs. deferred honestly
|
||||
|
||||
### Slide 6 — The Platform Pipeline
|
||||
- Walk the pipeline left-to-right: contract → resolver → adapter → plan → policy → confidence → gate → apply
|
||||
- Key insight: dev is autonomous; qa/prod/dr require attestation
|
||||
- The confidence signal is the "AI" — 6-input weighted score, not an LLM
|
||||
- **Key takeaway:** the path from intent to evidence, with humans at stage gates only
|
||||
|
||||
### Slide 7 — The Decision Ledger
|
||||
- The D-122 honesty sentence is critical: "Nova's AI is the confidence-gated policy engine, not an LLM"
|
||||
- The ledger is the moat: features can be copied, an immutable decision history cannot
|
||||
- Every decision has outcome backfill from apply.completed
|
||||
- **Key takeaway:** autonomous is defensible because every decision is immutable, queryable, accountable
|
||||
|
||||
### Slide 8 — The 8-Concern Attestation Matrix
|
||||
- The matrix is not a rubber stamp — it's structured, freshness-validated, SoD-enforced
|
||||
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence
|
||||
- SoD on prod: the approver can't be the same person who built it
|
||||
- **Key takeaway:** autonomy in operations, human in accountability, by design
|
||||
|
||||
### Slide 9 — Telemetry Architecture
|
||||
- Deliberately minimal (Nova-native, no Kafka/Prometheus/ClickHouse)
|
||||
- Every number in the Proof act is traceable to a file path
|
||||
- The hot path is deferred (D-126) — cold store is sufficient for batch
|
||||
- **Key takeaway:** the architecture IS the trust substrate — "where does this number come from?" → file path
|
||||
|
||||
### Slide 10 — Capability Health
|
||||
- 18V+4S is the single most important proof point
|
||||
- The 4 Skipped are live-AWS caps — honestly skipped (D-096), not broken
|
||||
- When live AWS is re-provisioned, they reactivate
|
||||
- **Key takeaway:** the platform works, and we're honest about what we can't test
|
||||
|
||||
### Slide 11 — Decision Ledger + Attestation Coverage
|
||||
- Both 100% — no AI decision is ever lost; no prod/dr promotion lands without a human sign-off
|
||||
- The trust snapshot has a chain-integrity verdict (the ledger hasn't been tampered with)
|
||||
- D-083 (S3 Object Lock + JWS) is the next step for the ledger
|
||||
- **Key takeaway:** trust is provable — not a marketing claim, a queryable record
|
||||
|
||||
### Slide 12 — Zero-Touch Efficiency
|
||||
- The Post-Pilot caveat is the honesty model: pipeline works, denominator is zero
|
||||
- This is NOT a fabricated "99% touchless" claim
|
||||
- The numbers fill when a pilot runs
|
||||
- **Key takeaway:** the measurement works; the numbers activate with a pilot
|
||||
|
||||
### Slide 13 — Cost & ROI
|
||||
- The ROI formula is shown inline — not hidden in a footnote
|
||||
- The N=0 caveat is stated explicitly
|
||||
- This is the "no fabrication" constraint in action
|
||||
- **Key takeaway:** the formula is ready; the production denominator activates with a pilot
|
||||
|
||||
### Slide 14 — What's Deferred — and Why
|
||||
- The preempt is critical: deferrals are measurement infrastructure, not autonomy
|
||||
- The platform IS autonomous in operations; what's deferred is the evidence pipeline
|
||||
- Showing this to leadership demonstrates honesty, not weakness
|
||||
- **Key takeaway:** the autonomy is real; the measurement gaps are documented
|
||||
|
||||
### Slide 15 — Roadmap to the North Star
|
||||
- Every deferred metric has a specific unblock requirement and a candidate milestone
|
||||
- The re-evaluation triggers ensure the metrics layer evolves
|
||||
- Nothing is hand-waved; everything has a plan
|
||||
- **Key takeaway:** the path from "honestly deferred" to "here's how we get there"
|
||||
|
||||
### Slide 16 — Recap + Ask
|
||||
- Recap the 5-act arc so the audience leaves with the structure
|
||||
- The ask is a business decision: approve a pilot + the ledger build-out
|
||||
- "Pipeline-ready" → "production-proven" is the value proposition
|
||||
- **Key takeaway:** approve a pilot + the ledger build-out to move from pipeline-ready to production-proven
|
||||
|
||||
### Slide 17 — Scope: Downstream of PDLC
|
||||
- Nova governs infra + delivery only; the PDLC (product backlog, code authorship, IDE) is upstream
|
||||
- Integration is only through the validated contract boundary
|
||||
- Any upstream source (AI agent, agentic SDLC, dev platform) may produce submissions — all subject to the same compliance standards
|
||||
- Nova validates the submission, not the author
|
||||
- **Key takeaway:** Nova is purpose-built for infrastructure operations, not product development; the scope boundary is clean
|
||||
|
||||
### Slide 18 — RACI: Who Owns What
|
||||
- Citizen Developer owns FRs + UAT (via any upstream source — AI agent, SDLC, dev platform — all pass the same gate)
|
||||
- Platform owns NFRs + infra + QA + prod deploy
|
||||
- Release Management is co-owned: platform runs attestations agentically, citizen developer oversees + triggers the release (human at stage gate)
|
||||
- The compliance-standard equivalence is the key: the source does not matter; the submission does
|
||||
- **Key takeaway:** you bring FRs + UAT; Nova provides NFRs + infra + QA + prod deploy; the release is co-owned with you at the stage gate
|
||||
|
||||
### Slide 19 — Production-Grade Guidance via Atelier
|
||||
- Nova instructs the citizen developer's AI agent via skills (9 markdown files) + an MCP server (4 tools, plugin-registry, stdio)
|
||||
- The MCP server provides agentic validation beyond deterministic scanners — catches correctness, clarity, observability gaps that Wiz/Checkmarx/Mend cannot
|
||||
- Atelier is vendored (pinned tag) for audit reproducibility — a validation result is replayable
|
||||
- This is how Nova ensures the citizen developer's submissions meet production-grade standards regardless of upstream source
|
||||
- **Key takeaway:** the citizen developer is not unguided — Nova provides engineering principles via skills + MCP, so every submission meets the same standards
|
||||
|
||||
### Appendix A1 — Metrics Glossary
|
||||
- Reference for every metric mentioned in the deck
|
||||
- Use if the audience asks "what does X mean?"
|
||||
|
||||
### Appendix A2 — Operating Model & Cost
|
||||
- The operating cost is negligible (~$0.007/month)
|
||||
- The zero-cost steady state (D-096 teardown) is the structural mitigation
|
||||
- References the pre-mortem for the decay-prevention story
|
||||
---
|
||||
|
||||
## Slide 20 — 12-Month Product Roadmap
|
||||
|
||||
**Key takeaway:** The next 12 months have a clear product arc — pilot activation → provable trust → compounding ROI → agentic substrate. Each quarter activates one strategic objective.
|
||||
|
||||
- This is the *product* roadmap, not the technical roadmap. The technical milestones (v1.0–v1.19) are behind us; this is forward-looking.
|
||||
- Q1 (Pilot Activation): re-provision live AWS, activate the first pilot estate, light up the three post-pilot metrics. Onboarding auto-grant ships.
|
||||
- Q2 (Provable Trust): tamper-evident ledger (Object Lock + JWS), daily checkpoints, live cost reconciliation. Trust is the moat — features can be copied; an immutable decision history cannot.
|
||||
- Q3 (Compounding ROI + Drift): drift detection + auto-reversal, Infracost→CUR reconciliation on the pilot estate. This is the quarter the CFO points to a number that improves quarter-over-quarter.
|
||||
- Q4 (Agentic Substrate + Predictive): ML anomaly-forecasting, AI-agent intent surface, multi-cloud preview. The Future Horizon target moves from aspiration to first measurement.
|
||||
- The roadmap is grounded in the four strategic objectives from the North Star — autonomy, provable trust, ROI, agentic substrate — and the deferred-metric unblock paths from Slide 15.
|
||||
|
||||
**If asked "what about multi-cloud?"**: Q4 preview. AWS-only through Q3; Azure/GCP enters preview in Q4. We optimize for depth first, breadth second.
|
||||
|
||||
**If asked "what about the ML service?"**: Q4. The predictive-vs-reactive ≥3:1 target requires an ML anomaly-forecasting emitter — the most technically ambitious deliverable on the roadmap.
|
||||
|
||||
---
|
||||
|
||||
## Slide 21 — Quarter-by-Quarter Outcomes
|
||||
|
||||
**Key takeaway:** Each quarter has a concrete deliverable, a target metric, and a strategic-objective grounding. Nothing is hand-waved.
|
||||
|
||||
- Q1: three post-pilot metrics go live (Touchless ≥99%, Escalation <0.1%, Accuracy ≥99.5%). The measurement pipeline is already grounded; the denominator activates when the pilot estate runs.
|
||||
- Q2: Decision Ledger Coverage was already grounded — the *tamper-evidence* is the Q2 upgrade (SQLite hash-chain → S3 Object Lock + JWS). Cost Savings ≥25% becomes CFO-grade with live CUR reconciliation.
|
||||
- Q3: Drift Auto-Reversal ≥95% unblocks when the drift scheduler ships. Spend Reduction ≥25% is the same target, now measured against the pilot baseline.
|
||||
- Q4: Predictive:Reactive ≥3:1 requires the ML forecasting service. AI-Agent Intent Share ≥40% moves from aspiration to first measurement.
|
||||
- The month-18 destination: "Nova is the layer enterprise leadership points to when they say 'we don't have an infrastructure ops team anymore, and the audit trail is stronger than it ever was.'"
|
||||
|
||||
**If asked "are these committed or aspirational?"**: Q1–Q3 are committed (grounded pipeline + known unblock paths). Q4 targets are committed-deliverable, aspirational-metric — the ML service ships, the ≥40% intent share is first measurement (we don't control adoption rate).
|
||||
File diff suppressed because one or more lines are too long
@@ -1,453 +0,0 @@
|
||||
# Nova — The No-Humans Infrastructure Platform
|
||||
|
||||
> **Source of truth** (Step 1 of the 4-step deck process).
|
||||
> Unified narrative deck merging `how-the-platform-works` + `the-developer-experience`.
|
||||
> 5-act arc: Problem → Vision → How → Proof → Roadmap.
|
||||
> x3 structure at deck level (opening = arc preview, body = tell them, closing = recap + ask)
|
||||
> AND per slide (opens with what it covers, delivers, closes with benefit callout).
|
||||
> Act indicator in the Marp footer: `Act N/5: <act name>`.
|
||||
>
|
||||
> **Honesty model:** every metric cited is grounded (cites a source file),
|
||||
> derived (documented formula), or deferred (cites a blocking decision ID).
|
||||
> No fabricated numbers. Deferred metrics marked `<span class="badge planned">Planned</span>`.
|
||||
>
|
||||
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-196, REQ-197)
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Arc Preview (the "what I'm going to tell you" deck-level opening)
|
||||
|
||||
This deck proves Nova is the no-humans infrastructure platform — and shows you the metrics that make the claim defensible.
|
||||
|
||||
**Today:** 18 capabilities verified, 0 consumer estates in production. This deck shows what's proven, what's pipeline-ready, and what's honestly deferred.
|
||||
|
||||
The 5-act arc:
|
||||
1. **Problem** — why the operator is the bottleneck
|
||||
2. **Vision** — Nova's strategic direction (NORTH_STAR)
|
||||
3. **How** — the pipeline, Decision Ledger, attestation gates
|
||||
4. **Proof** — grounded metrics that make the claim defensible
|
||||
5. **Roadmap** — deferred metrics with unblock paths + the ask
|
||||
|
||||
> **Benefit:** you leave this deck knowing which claims are proven today, which are pipeline-ready, and which are deferred with a documented unblock path — no marketing, just grounded evidence.
|
||||
|
||||
> **Speaker notes:** The stake line (18V + 0 consumers) sets the honesty frame. The audience knows from slide 1 that this is not a hype deck — it's an evidence deck. The arc preview orients them for the next 15 slides.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — The No-Humans Imperative
|
||||
|
||||
This slide shows why the operator is the bottleneck — and why removing them from operations (not accountability) is the imperative.
|
||||
|
||||
- **The cost of humans-in-the-loop:** L1/L2 ops hours, escalation latency, the trust gap (autonomous claims without proof)
|
||||
- **The operator is the bottleneck:** provisioning takes days, not minutes; escalations pile up; the trust gap means "autonomous" is a marketing claim, not a defensible one
|
||||
- **The attestation model:** autonomy in operations, human at stage gates — not "no humans ever"
|
||||
- Cites `docs/NO_HUMANS_THESIS.md` (the thesis, grounded proof, deferred proof, anti-claims)
|
||||
|
||||
> **Benefit:** you now know the problem framing — autonomy in operations, human at stage gates, is the path forward.
|
||||
|
||||
> **Speaker notes:** The key reframing: "no-humans" means no human in the loop of *normal operations*. Stage-gate attestation (QA for production, SRE for operational readiness) remains human by design. This is not about removing humans from accountability — only from operations.
|
||||
|
||||
> **Transition:** "Having defined the problem, here is Nova's strategic direction toward solving it."
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Nova's Vision
|
||||
|
||||
This slide states Nova's vision — infrastructure operations become invisible, with provable trust.
|
||||
|
||||
> **Infrastructure operations become invisible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates — QA signs off for production, SRE greenlights based on operational readiness — but the operator is never in the loop of normal operations.**
|
||||
|
||||
- The attestation model: human attestation required at stage gates (QA for production, SRE for operational readiness); autonomy in operations, not in accountability
|
||||
- Cites `docs/NO_HUMANS_THESIS.md` (the thesis, grounded proof, deferred proof, anti-claims incl. D-122 honesty)
|
||||
|
||||
> **Benefit:** you now know the destination — invisible operations with provable trust, not promised trust. And you know the attestation model: humans at stage gates, not in the ops loop.
|
||||
|
||||
> **Speaker notes:** The vision is ambitious but precise. "Provable, not promised" is the key phrase — it's the difference between a marketing claim and a defensible one. The attestation clarification is stated up front so the audience doesn't mishear "no-humans" as "no accountability."
|
||||
|
||||
> **Transition:** "The vision is ambitious — here are the 4 strategic objectives that make it concrete."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Strategic Objectives + Anti-Goals
|
||||
|
||||
This slide pairs what Nova is building toward (4 objectives) with what Nova refuses to build (5 anti-goals).
|
||||
|
||||
**4 Strategic Objectives:**
|
||||
1. **Demonstrate production-grade zero-touch operations** — autonomy as the default, not the demo
|
||||
2. **Establish provable trust in AI decisions** — Decision Ledger, confidence scoring, circuit breakers, blast-radius controls
|
||||
3. **Deliver compounding, quantifiable ROI** — each quarter must reduce spend, free hours, avoid downtime measurably
|
||||
4. **Become the default substrate for agentic infrastructure consumption** — the platform AI agents reach for first
|
||||
|
||||
**5 Anti-Goals (what Nova is NOT):**
|
||||
1. Not a Terraform, Kubernetes, or hyperscaler competitor
|
||||
2. Not a general-purpose AI agent platform
|
||||
3. Not a system that removes humans from accountability
|
||||
4. Not for legacy, untagged, or freeform infrastructure
|
||||
5. Not sold to operators
|
||||
|
||||
From `NORTH_STAR.md`.
|
||||
|
||||
> **Benefit:** you now know the scope boundaries — Nova is purpose-built for infrastructure operations, sold to leadership on outcomes, and explicitly not a general-purpose AI platform or a hyperscaler competitor.
|
||||
|
||||
> **Speaker notes:** The anti-goals are as important as the objectives. They tell the audience what Nova will NOT be distracted by. Anti-goal #3 (not removing humans from accountability) reinforces the attestation model from slide 3.
|
||||
|
||||
> **Transition:** "The objectives are committed to measurable targets — here is the 12–18 month scorecard, with honest grounding status."
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — 12–18 Month Targets (the scorecard)
|
||||
|
||||
This slide shows the committed targets — numbers a board member can repeat back — with their grounding status.
|
||||
|
||||
**Current-milestone targets (grounded or derived this milestone):**
|
||||
|
||||
| Domain | Target | Status |
|
||||
|---|---|---|
|
||||
| MTTR (p95) | < 60 seconds | grounded (platform-run) |
|
||||
| Cloud Spend Reduction | ≥ 25% on pilot estates | partial (Infracost grounded; CUR deferred D-096) |
|
||||
| L1/L2 Ops Hours Avoided | ≥ 70% of pre-Nova FTE | derived (N internal runs; prod activates post-pilot) |
|
||||
| Platform ROI | ≥ 250% annually | derived (formula; N internal runs caveat) |
|
||||
| Decision Ledger Coverage | 100% of AI actions | grounded (this milestone builds it) |
|
||||
| Attestation Coverage | 100% of prod/dr promotions | grounded |
|
||||
|
||||
**Post-Pilot targets (pipeline grounded; denominator activates with a pilot estate):**
|
||||
|
||||
| Domain | Target | Status |
|
||||
|---|---|---|
|
||||
| Touchless Resolution Rate | ≥ 99% | partial (pipeline grounded; 0 consumers today) |
|
||||
| Human Escalation Frequency | < 0.1% | partial (pipeline grounded; 0 consumers today) |
|
||||
| AI Decision Accuracy | ≥ 99.5% | partial (pipeline grounded; 0 consumers today) |
|
||||
|
||||
**Deferred targets:** Predictive vs Reactive ≥3:1 <span class="badge planned">Planned</span> · Drift Auto-Reversal ≥95% <span class="badge planned">Planned</span>
|
||||
|
||||
> **Benefit:** you now know the destination numbers — and which ones are measurable today vs deferred honestly. The Post-Pilot targets are committed; the pipeline works; the numbers fill when a pilot estate runs.
|
||||
|
||||
> **Speaker notes:** The three-section split (current / post-pilot / deferred) is the honesty model. The "partial" status means the measurement pipeline is grounded but the denominator is zero (0 consumers). This is the same honesty as Cloud Spend (Infracost grounded, CUR deferred). A board member can see exactly which numbers are real today and which are waiting for a pilot.
|
||||
|
||||
> **Transition:** "The targets are committed — here is how Nova works to achieve them."
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — The Platform Pipeline
|
||||
|
||||
This slide shows the contract-to-evidence pipeline — how intent becomes verified infrastructure without an operator.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Contract] --> B[Resolver]
|
||||
B --> C[Adapter]
|
||||
C --> D[Terraform Plan]
|
||||
D --> E[Checkov Policy]
|
||||
E --> F[Confidence Signal]
|
||||
F --> G{HITL Gate}
|
||||
G -->|dev: autonomous| H[Apply]
|
||||
G -->|qa/prod/dr: attested| H
|
||||
H --> I[Evidence + Outbox]
|
||||
```
|
||||
|
||||
- Contract → resolver → adapter → terraform plan → Checkov (policy) → confidence signal → HITL gate (dev autonomous; qa/prod/dr attested) → apply → evidence
|
||||
- Grounded in `scripts/run_platform.sh` + `core/contract_resolver.py` + `adapters/terraform/adapter.py` + `core/confidence_signal.py`
|
||||
|
||||
> **Benefit:** you now know the path from intent to evidence — and where the human appears (stage gates only, not in the ops loop).
|
||||
|
||||
> **Speaker notes:** The pipeline is the engine. The key insight: dev is autonomous (no HITL gate); qa/prod/dr require human attestation. The confidence signal is the "AI" — it's a 6-input weighted score, not an LLM. The HITL gate is where the human appears, but only for qa/prod/dr, not for dev.
|
||||
|
||||
> **Transition:** "The pipeline produces decisions — here is how every decision is captured and made accountable."
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The Decision Ledger
|
||||
|
||||
This slide shows the Decision Ledger — every AI decision captured with confidence, alternatives, and outcome.
|
||||
|
||||
- **Architecture:** `outbox_writer.py` extended → SQLite append-only hash-chain table
|
||||
- **`ai.decision.made` events:** decision_id=run_id, chosen_action=band, confidence=score, alternatives=perInput, human_override=HITL block, outcome backfilled from apply.completed
|
||||
- **`attestation.recorded` events:** qa/prod/dr sign-offs (approver, env, concerns, result)
|
||||
- D-121, D-122, D-132. Honors D-083 (no S3 Object Lock/JWS — local hash-chain this milestone)
|
||||
|
||||
**D-122 honesty:** Nova's "AI" is the confidence-gated policy engine (confidence_signal + HITL gate), not an LLM planner. The Decision Ledger captures this real decision path — not a fabricated "AI agent" that doesn't exist yet.
|
||||
|
||||
> **Benefit:** you now know why 'autonomous' is defensible — every decision is immutable, queryable, and accountable. And you know exactly what 'AI' means here: a confidence-gated policy engine, not a black-box LLM.
|
||||
|
||||
> **Speaker notes:** The D-122 honesty sentence is critical. If the audience walks away thinking Nova has an LLM planner, we've violated the "no fabrication" constraint. The Decision Ledger is the trust substrate (NORTH_STAR Objective #2) — it's the moat. Features can be copied; an immutable, queryable decision history cannot.
|
||||
|
||||
> **Transition:** "Decisions are captured — here is how stage-gate attestation keeps humans in accountability."
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — The 8-Concern Attestation Matrix
|
||||
|
||||
This slide shows the 8-concern attestation matrix — the designed controls that keep humans at stage gates.
|
||||
|
||||
| Concern | Env | Freshness | Type |
|
||||
|---------|-----|-----------|------|
|
||||
| functional_correctness | qa | 24h | operator-supplied |
|
||||
| performance_baseline | qa | 7d | operator-supplied |
|
||||
| security_posture | qa | 24h | operator-supplied |
|
||||
| contract_nfrs | qa/prod/dr | — | offline-testable |
|
||||
| operational_readiness | prod | 30d | operator-supplied |
|
||||
| incident_response | prod | 90d | operator-supplied |
|
||||
| capacity_cost | prod | 30d | operator-supplied |
|
||||
| resilience_dr_drill | prod | 180d | operator-supplied |
|
||||
| resilience_chaos | prod | 90d | operator-supplied |
|
||||
| resilience_backup | prod | 30d | operator-supplied |
|
||||
| dr_region_deploy | dr | 180d | operator-supplied |
|
||||
|
||||
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence artifacts
|
||||
- Separation-of-duties on prod (the approver can't be the same person who built it)
|
||||
- Grounded in `core/attestation_matrix.py` + `core/hitl_gates.py`
|
||||
|
||||
> **Benefit:** you now know the gate model — autonomy in operations, human in accountability, by design. The 8-concern matrix is what makes "no-humans in ops" safe.
|
||||
|
||||
> **Speaker notes:** The attestation matrix is the human-in-the-loop safeguard. It's not a rubber stamp — it's a structured, freshness-validated, separation-of-duties-enforced gate. This is what Anti-Goal #3 means: "not a system that removes humans from accountability."
|
||||
|
||||
> **Transition:** "You've now seen how Nova works — the pipeline, the Decision Ledger, the attestation gates. But 'how it works' is not 'proof it works.' The next four slides show the measured evidence: capability health, trust metrics, efficiency, and cost — every number grounded in a real file, not a marketing claim."
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Telemetry Architecture
|
||||
|
||||
This slide shows how Nova instruments itself — the CloudEvents envelope, the cold store, and the PowerBI export.
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
A[Platform components] --> B[CloudEvents 1.0 envelope]
|
||||
B --> C[metrics/events.jsonl]
|
||||
B --> D[metrics/decision_ledger.db]
|
||||
B --> E[metrics/runs/]
|
||||
C --> F[Collector]
|
||||
D --> F
|
||||
E --> F
|
||||
F --> G[metrics/nova_metrics.db]
|
||||
G --> H[metrics/powerbi/]
|
||||
H --> I[PowerBI dashboards]
|
||||
```
|
||||
|
||||
- Platform components → CloudEvents 1.0 envelope → `metrics/events.jsonl` + `metrics/runs/` + `metrics/decision_ledger.db` → collector → `metrics/nova_metrics.db` (SQLite cold store) → `metrics/powerbi/` (CSV/JSON views) → PowerBI
|
||||
- D-120 (Nova-native), D-125 (hybrid events/files), D-126 (cold-only)
|
||||
- <span class="badge planned">Planned</span>: Hot-path (live ops dashboard) — D-126
|
||||
|
||||
> **Benefit:** you now know that every metric in this deck is traceable to a real emitted event — the architecture IS the trust substrate. When a CFO asks 'where does this number come from?', the answer is a file path, not a Slack thread.
|
||||
|
||||
> **Speaker notes:** The architecture is deliberately minimal (Nova-native, no Kafka/Prometheus/ClickHouse). The hot path is deferred (D-126) — the cold store is sufficient for batch/historical analysis. The key point: every number in the Proof act is traceable to a file path. This is the "no fabrication" constraint made architectural.
|
||||
|
||||
> **Transition:** "The architecture is sound — here is the measured proof."
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Capability Health + Confidence Distribution
|
||||
|
||||
This slide shows the grounded proof: capability health and confidence distribution from real runs.
|
||||
|
||||
**Capability Health:** 18 Verified + 4 Skipped (post-D-096 teardown) from `.ciagent/REGRESSION_REPORT.json`
|
||||
|
||||
| Status | Count |
|
||||
|--------|-------|
|
||||
| Verified | 18 |
|
||||
| Skipped | 4 |
|
||||
| Broken | 0 |
|
||||
| Decayed | 0 |
|
||||
|
||||
- The 4 Skipped are live-AWS capabilities (CAP-013..016) — honestly skipped because resources are torn down (D-096), not a failure
|
||||
- Confidence distribution: from `metrics/nova_metrics.db` `fact_confidence` — score histogram, band breakdown (pass/halt)
|
||||
|
||||
> **Benefit:** you now know the platform is verified — 18 capabilities pass, 4 are honestly skipped, 0 broken. The honesty model (Skipped ≠ failure) is what makes the Verified count credible.
|
||||
|
||||
> **Speaker notes:** The 18V+4S number is the single most important proof point. It says "the platform works, and we're honest about what we can't test." The 4 Skipped are live-AWS capabilities — they're skipped because the live AWS resources are torn down (D-096), not because they're broken. When live AWS is re-provisioned, they reactivate.
|
||||
|
||||
> **Transition:** "Capability health is necessary — here is the trust substrate that makes autonomy defensible."
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — Decision Ledger + Attestation Coverage
|
||||
|
||||
This slide shows the trust metrics — Decision Ledger coverage and attestation coverage, both 100%.
|
||||
|
||||
- **Decision Ledger Coverage:** 100% of platform runs emit `ai.decision.made` with outcome backfill (source: `metrics/decision_ledger.db`)
|
||||
- **Attestation Coverage:** 100% of prod/dr promotions attested by a human (source: `hitl_gates.py` + outbox `approver_*` attributes)
|
||||
- **AI Decision Accuracy:** decisions not followed by apply.failed/incident within 5min
|
||||
- The trust-snapshot report (`metrics/TRUST_SNAPSHOT.md`) with chain-integrity verdict
|
||||
- <span class="badge planned">Planned</span>: Tamper-Evident Ledger Checkpoints (D-083)
|
||||
|
||||
> **Benefit:** you now know the trust is provable — not a marketing claim, a queryable record. The Decision Ledger is the moat; features can be copied, an immutable decision history cannot.
|
||||
|
||||
> **Speaker notes:** The trust metrics are the "provably trustworthy" proof. Decision Ledger Coverage = 100% means no AI decision is ever lost. Attestation Coverage = 100% means no prod/dr promotion lands without a human sign-off. The chain-integrity verdict (from the trust snapshot) proves the ledger hasn't been tampered with.
|
||||
|
||||
> **Transition:** "Trust is provable — here is the operational efficiency that makes the ROI real."
|
||||
|
||||
---
|
||||
|
||||
## Slide 12 — Zero-Touch Efficiency
|
||||
|
||||
This slide shows the zero-touch efficiency metrics — touchless resolution, human escalation, and MTTR.
|
||||
|
||||
- **Touchless Resolution Rate:** runs without operational HITL block ÷ total (attestation gates excluded)
|
||||
- **Human Escalation Frequency:** operational HITL blocks only (confidence-driven; attestation sign-offs excluded)
|
||||
- **MTTR (platform-run):** apply.failed → successful retry (D-131)
|
||||
|
||||
**Post-Pilot caveat:** these three metrics are computed on N internal runs today; the production-denominator activates when a pilot estate runs (see NORTH_STAR Post-Pilot Targets section).
|
||||
|
||||
> **Benefit:** you now know the zero-touch efficiency is measurable — the pipeline works today on internal runs, and the denominator expands to production estates when a pilot activates.
|
||||
|
||||
> **Speaker notes:** The Post-Pilot caveat is the honesty model. The pipeline is grounded (it works); the denominator is zero (0 consumers). This is not a fabricated "99% touchless" claim — it's "the measurement works, and the numbers fill when a pilot runs."
|
||||
|
||||
> **Transition:** "Efficiency is half the ROI story — here is the cost side."
|
||||
|
||||
---
|
||||
|
||||
## Slide 13 — Cost & ROI
|
||||
|
||||
This slide shows the cost estimates and the ROI formula — with honest caveats about the current denominator.
|
||||
|
||||
- **Cost Estimates via Infracost:** pre-apply, grounded (reads plan JSON, offline)
|
||||
- **ROI formula (shown inline):** `Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
|
||||
- **N=0 caveat:** "These derived metrics are computed on N internal runs today; the production-denominator activates post-pilot. The formula is grounded; the production numbers are not yet."
|
||||
- **FTE Hours Saved** (derived), **Platform ROI** (derived formula)
|
||||
- <span class="badge planned">Planned</span>: Live CUR Reconciliation (D-096), Drift Auto-Reversal (D-096)
|
||||
|
||||
> **Benefit:** you now know the ROI formula — and you know it's computed on internal runs today, not fabricated production numbers. The formula is ready; the production denominator activates with a pilot.
|
||||
|
||||
> **Speaker notes:** The ROI formula is shown inline — not hidden in a footnote. The N=0 caveat is stated explicitly. This is the "no fabrication" constraint in action: we show the formula, we show the caveat, we don't pretend the production numbers exist.
|
||||
|
||||
> **Transition:** "The proof is grounded — here is what is honestly deferred."
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — What's Deferred — and Why
|
||||
|
||||
This slide pairs each deferred metric with its blocking decision — honesty about what isn't measured yet.
|
||||
|
||||
**To be clear:** these deferrals are *measurement infrastructure*, not whether the platform runs without humans. The platform IS autonomous in operations. What's deferred is the *evidence pipeline* for certain metrics — not the autonomy itself.
|
||||
|
||||
| # | Deferred Metric | Blocking Decision |
|
||||
|---|----------------|-------------------|
|
||||
| 1 | Live Infrastructure Health | D-096 |
|
||||
| 2 | Live Outbox Write Rate | D-096 |
|
||||
| 3 | Tamper-Evident Ledger Checkpoints | D-083 |
|
||||
| 4 | Onboarding Funnel (granted) | D-113/D-114/D-119 |
|
||||
| 5 | Drift Auto-Reversal | D-096 + no scheduler |
|
||||
| 6 | Live CUR Reconciliation | D-096 |
|
||||
| 7 | SLA / Unplanned Downtime | D-096 |
|
||||
| 8 | Predictive vs Reactive | future emitter |
|
||||
|
||||
From `docs/METRICS_DEFERRED_ROADMAP.md`.
|
||||
|
||||
> **Benefit:** you now know the boundaries — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented.
|
||||
|
||||
> **Speaker notes:** The preempt is critical: these deferrals are measurement infrastructure, not autonomy. The platform runs without humans in operations. What's deferred is the evidence pipeline for live-infra health, drift detection, predictive remediation — not the autonomy itself. Showing this slide to leadership demonstrates honesty, not weakness.
|
||||
|
||||
> **Transition:** "The proof is honest — here is the roadmap from here to the 12–18 month targets."
|
||||
|
||||
---
|
||||
|
||||
## Slide 15 — Roadmap to the North Star
|
||||
|
||||
This slide shows the path from v1.17's grounded metrics to the 12–18 month targets — the unblock path for each deferred metric.
|
||||
|
||||
- Each deferred metric → blocking decision → unblock requirement → candidate milestone
|
||||
- The hot-path activation section (post-D-096, Nova-native only, D-120)
|
||||
- Re-evaluation triggers: D-096 lift, D-083 lift, onboarding-grant lift
|
||||
|
||||
From `docs/METRICS_DEFERRED_ROADMAP.md`.
|
||||
|
||||
> **Benefit:** you now know the path — every deferred metric has an unblock requirement and a candidate milestone. Nothing is hand-waved; everything has a plan.
|
||||
|
||||
> **Speaker notes:** The roadmap is the bridge from "honestly deferred" to "here's how we get there." Each deferred metric has a specific unblock requirement and a candidate future milestone. The re-evaluation triggers ensure the metrics layer evolves when the blocking decisions lift.
|
||||
|
||||
> **Transition:** "The roadmap is clear — here is the recap and the ask."
|
||||
|
||||
---
|
||||
|
||||
## Slide 16 — Recap + Ask (the "what I told you" deck-level closing)
|
||||
|
||||
This slide recaps the 5 acts and states the ask.
|
||||
|
||||
**Recap:**
|
||||
- **Problem:** the operator is the bottleneck; autonomy in operations, human at stage gates
|
||||
- **Vision:** invisible operations with provable trust (NORTH_STAR)
|
||||
- **How:** pipeline + Decision Ledger + 8-concern attestation matrix
|
||||
- **Proof:** 18V+4S, 100% ledger coverage, 100% attestation, grounded ROI formula
|
||||
- **Roadmap:** deferred metrics have unblock paths
|
||||
|
||||
**The ask:** "The ask is a business decision: approve a pilot estate to activate the production-denominator metrics (Touchless Resolution, Human Escalation, AI Decision Accuracy), and approve the tamper-evident ledger build-out (D-083 lift) to move from local hash-chain to S3 Object Lock + JWS. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
|
||||
|
||||
> **Benefit:** you leave with a clear business decision to make — approve a pilot + the ledger build-out — and the confidence that every claim in this deck is grounded, derived, or honestly deferred.
|
||||
|
||||
> **Speaker notes:** The ask is a business decision, not insider language. "Approve a pilot estate" is something a C-suite can decide. "Approve the ledger build-out" is a budget decision. The recap reinforces the 5-act arc — the audience leaves with the structure, not a pile of facts.
|
||||
|
||||
---
|
||||
|
||||
## Appendix Slide A1 — Metrics Glossary
|
||||
|
||||
This appendix defines every KPI in one line with its grounding badge.
|
||||
|
||||
| KPI | Definition | Status |
|
||||
|-----|-----------|--------|
|
||||
| Touchless Resolution Rate | runs without operational HITL block ÷ total | partial (Post-Pilot) |
|
||||
| Human Escalation Frequency | operational HITL blocks ÷ total | partial (Post-Pilot) |
|
||||
| AI Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
|
||||
| MTTR (p95) | apply.failed → successful retry | grounded |
|
||||
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
|
||||
| Provisioning Lead Time | run.completed − run.started | grounded |
|
||||
| Deployment Frequency | count(run.completed) per day | grounded |
|
||||
| Cost Savings (Infracost) | sum(delta_usd where delta < 0) | partial (CUR deferred) |
|
||||
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
|
||||
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
|
||||
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
|
||||
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
|
||||
| Policy Compliance Rate | 1 − failed_assets ÷ total | grounded |
|
||||
|
||||
> **Benefit:** you now have a reference for every metric mentioned in the deck.
|
||||
|
||||
---
|
||||
|
||||
## Appendix Slide A2 — Operating Model & Cost
|
||||
|
||||
This appendix shows the real cost figures + the zero-cost steady state.
|
||||
|
||||
- **Cost figures** from `COST.md`: $0.001883 over 8 days, ~$0.007/month, S3-dominated, zero BAU compute
|
||||
- **Zero-cost steady state:** all resources torn down post-v1.11 (D-096); the platform runs offline
|
||||
- References the pre-mortem (`PRE_MORTEM.md`: v1.10 decay root cause + four forward failure modes + structural mitigations)
|
||||
|
||||
> **Benefit:** you now know the operating cost is negligible — and the structural mitigation that prevents decay.
|
||||
|
||||
---
|
||||
|
||||
> **End of deck.** 16 main slides + 2 appendix slides = 18 total.
|
||||
> Both old decks (`how-the-platform-works` + `the-developer-experience`) are retired (D-130).
|
||||
---
|
||||
|
||||
## Slide 20 — 12-Month Product Roadmap
|
||||
|
||||
**The product arc from pilot activation to agentic substrate — four quarters, four outcomes.**
|
||||
|
||||
This slide shows the 12-month product roadmap — the forward-looking product-outcome arc. It is distinct from Slide 15 (the deferred-metric unblock paths), which explains *why* metrics are deferred and *how* they unblock. This slide shows *what's coming, when* — organized by quarter and board-level outcome.
|
||||
|
||||
**Speaker notes:**
|
||||
|
||||
- The roadmap is organized by product outcome, not by technical milestone. Each quarter activates one strategic objective from the North Star.
|
||||
- Q1 is pilot activation — re-provision live AWS, light up the first pilot estate, and activate the three post-pilot denominator metrics (Touchless Resolution Rate, Human Escalation Frequency, AI Decision Accuracy). The onboarding auto-grant ships, so consumers can self-provision without platform-team intervention.
|
||||
- Q2 is provable trust — the audit substrate goes from a SQLite hash-chain to a tamper-evident ledger (S3 Object Lock + JWS daily checkpoints). Live cost reconciliation (CUR) goes live so the CFO sees real cloud-spend data, not just pre-apply Infracost estimates.
|
||||
- Q3 is compounding ROI + drift — drift detection ships (the scheduler that was deferred), drift auto-reversal activates (≥95% within one detection cycle), and the ≥25% spend-reduction target is measured against the pilot estate's 12-month pre-Nova baseline. This is the quarter the CFO points to a number that improves quarter-over-quarter.
|
||||
- Q4 is agentic substrate + predictive — the ML anomaly-forecasting service ships (predictive-vs-reactive ≥3:1), the AI-agent intent consumption surface goes live, and multi-cloud (Azure/GCP) enters preview. The Future Horizon target (AI-Agent Intent Share ≥40%) moves from aspiration to first measurement.
|
||||
|
||||
**The month-18 destination:** *"Nova is the layer enterprise leadership points to when they say 'we don't have an infrastructure ops team anymore, and the audit trail is stronger than it ever was' — and it is the default substrate their AI engineering teams reach for first when an agent needs to deploy."*
|
||||
|
||||
> **Benefit:** you now know the 12-month product arc — each quarter activates a strategic objective and its corresponding board-level metric, from pilot activation through agentic substrate leadership.
|
||||
|
||||
---
|
||||
|
||||
## Slide 21 — Quarter-by-Quarter Outcomes
|
||||
|
||||
This slide is the detail table behind Slide 20 — the concrete deliverable, target metric, and strategic-objective grounding for each quarter.
|
||||
|
||||
**Speaker notes:**
|
||||
|
||||
- Each row has a product theme (the narrative), a key deliverable (what ships), a target metric (the board-level number), and a grounding (which strategic objective it activates).
|
||||
- Q1's three target metrics (Touchless ≥99%, Escalation <0.1%, Accuracy ≥99.5%) are the post-pilot metrics from the North Star — their measurement pipeline is grounded this milestone, but the denominator is zero until a pilot estate activates. Q1 is when the denominator goes live.
|
||||
- Q2's Decision Ledger Coverage (100%) is already grounded; the *tamper-evidence* is the Q2 upgrade. Cost Savings ≥25% is the Infracost-grounded target — Q2 is when actual-spend reconciliation (CUR) makes it CFO-grade.
|
||||
- Q3's Drift Auto-Reversal ≥95% is the deferred metric that unblocks when the drift detection scheduler ships. Spend Reduction ≥25% is the same target, now measured against the pilot baseline (not just estimated).
|
||||
- Q4's Predictive:Reactive ≥3:1 requires the ML forecasting service — the most technically ambitious deliverable. AI-Agent Intent Share ≥40% is the Future Horizon target — it moves from aspiration to first measurement when the agentic consumption surface goes live.
|
||||
- The roadmap does NOT duplicate the 19 completed technical milestones (v1.0–v1.19) — it is forward-looking only. It does NOT duplicate Slide 15's deferred-metric unblock paths — it uses them as the mechanism, but the audience sees the product arc, not the decision IDs.
|
||||
|
||||
> **Benefit:** you now know the quarter-by-quarter detail — each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from "honestly deferred" to "shipped and measured."
|
||||
Binary file not shown.
+45
-32
@@ -1,12 +1,12 @@
|
||||
# RACI — Who Owns What
|
||||
|
||||
> D-139). This page is the citizen-developer-facing copy.
|
||||
> This page is the citizen-developer-facing copy.
|
||||
|
||||
Nova's delivery lifecycle has three roles. This page clarifies who owns
|
||||
Nova's delivery lifecycle has four roles. This page clarifies who owns
|
||||
what — so the citizen developer knows what they bring, what the platform
|
||||
provides, and what is co-owned.
|
||||
provides, what quality engineering guards, and what is co-owned with SRE.
|
||||
|
||||
## The Three Roles
|
||||
## The Four Roles
|
||||
|
||||
### Citizen Developer (CD)
|
||||
|
||||
@@ -14,40 +14,49 @@ That's you — the consumer (technical developer L3A or non-technical L3B).
|
||||
You are **Responsible** for all **Functional Requirements (FRs)** and
|
||||
**User Acceptance Testing (UAT)**. You produce the FRs + UAT via your AI
|
||||
coding agent, an upstream agentic SDLC platform, or any upstream
|
||||
development platform. **The source does not matter** — all are subject
|
||||
to the same compliance standards (the submission-readiness gate, the
|
||||
development platform. **The source does not matter** — all are subject to
|
||||
the same compliance standards (the submission-readiness gate, the
|
||||
contract schema, the policy envelope, the immutable audit stream). Nova
|
||||
validates the submission, not the author.
|
||||
|
||||
### Platform (Nova)
|
||||
|
||||
Nova is **Responsible** for all **Non-Functional Requirements (NFRs)**,
|
||||
**Infrastructure** (cloud resource lifecycle, state, IAM), **QA** (the
|
||||
platform-side quality checks: policy enforcement, confidence scoring,
|
||||
schema validation), and **Production deployments to cloud** (the apply
|
||||
path, the pipeline, the release mechanics).
|
||||
**Infrastructure** (cloud resource lifecycle, state, IAM), and
|
||||
**Production deployments to cloud** (the apply path, the pipeline, the
|
||||
release mechanics).
|
||||
|
||||
### Release Management (RM) — co-owned
|
||||
### Quality Engineering (QE)
|
||||
|
||||
The release is **co-owned**. The platform performs the QA + SRE
|
||||
attestations agentically (it runs the confidence signal, the policy
|
||||
checks, the separation-of-duties). The citizen developer **oversees and
|
||||
triggers** the actual release — the human attestation at the stage gate
|
||||
is your authorization. The platform runs the checks; you authorize the
|
||||
promotion. This is the "autonomy in operations, human at stage gates"
|
||||
model.
|
||||
Quality Engineering is **Responsible** for the platform-side quality
|
||||
checks: policy enforcement, confidence scoring, schema validation, and
|
||||
the functional/contract/non-functional evidence that feeds attestation.
|
||||
QE owns the **quality** of what the platform produces — the gate
|
||||
evidence, not the gate decision.
|
||||
|
||||
### SRE — co-owned with you
|
||||
|
||||
Production readiness is **co-owned**. SRE owns operational readiness:
|
||||
the operational attestation (incident response, capacity, resilience,
|
||||
DR). The platform performs the QA + SRE attestations agentically (it
|
||||
runs the confidence signal, the policy checks, the
|
||||
separation-of-duties). The citizen developer **oversees and triggers**
|
||||
the actual release — the human attestation at the stage gate is your
|
||||
authorization. The platform runs the checks; you authorize the promotion.
|
||||
This is the "autonomy in operations, human at stage gates" model.
|
||||
|
||||
## The Matrix
|
||||
|
||||
| Work Category | Citizen Developer | Platform | Release Management |
|
||||
|---|---|---|---|
|
||||
| **Functional Requirements (FRs)** | **R/A** | C | I |
|
||||
| **User Acceptance Testing (UAT)** | **R/A** | C | I |
|
||||
| **Non-Functional Requirements (NFRs)** | I | **R/A** | C |
|
||||
| **Infrastructure (cloud, state, IAM)** | I | **R/A** | C |
|
||||
| **QA (policy, confidence, schema checks)** | C | **R/A** | I |
|
||||
| **Production deployment to cloud** | I | **R/A** | C |
|
||||
| **Release attestation (QA + SRE sign-off)** | **A** | R | **R** |
|
||||
| Work Category | Citizen Developer | Platform | Quality Engineering | SRE |
|
||||
|---|---|---|---|---|
|
||||
| **Functional Requirements (FRs)** | **R/A** | C | I | I |
|
||||
| **User Acceptance Testing (UAT)** | **R/A** | C | I | I |
|
||||
| **Non-Functional Requirements (NFRs)** | I | **R/A** | C | C |
|
||||
| **Infrastructure (cloud, state, IAM)** | I | **R/A** | I | C |
|
||||
| **QA (policy, confidence, schema checks)** | C | R | **R/A** | I |
|
||||
| **Production deployment to cloud** | I | **R/A** | C | C |
|
||||
| **Quality attestation (QA sign-off)** | **A** | R | **R** | I |
|
||||
| **Production readiness (SRE sign-off)** | **A** | R | C | **R** |
|
||||
|
||||
**Key:** **R** = Responsible (does the work) · **A** = Accountable (owns
|
||||
the outcome, sign-off) · **C** = Consulted · **I** = Informed.
|
||||
@@ -63,11 +72,15 @@ the outcome, sign-off) · **C** = Consulted · **I** = Informed.
|
||||
- The NFRs (security, observability, compliance — baked into the
|
||||
pipeline, not your concern).
|
||||
- The infrastructure (cloud resources, state management, IAM scoping).
|
||||
- The QA (policy enforcement, confidence scoring, schema validation).
|
||||
- The production deployment (the apply path, the pipeline, the release).
|
||||
|
||||
**You co-own the release:**
|
||||
- Nova runs the attestations (QA confidence, SRE operational readiness).
|
||||
**Quality Engineering guards:**
|
||||
- The policy enforcement, confidence scoring, schema validation.
|
||||
- The quality attestation evidence that feeds the stage gates.
|
||||
|
||||
**You co-own production readiness with SRE:**
|
||||
- Nova + SRE run the attestations (QA quality sign-off, SRE operational
|
||||
readiness).
|
||||
- You authorize the promotion at the stage gate. No promotion happens
|
||||
without your recorded attestation.
|
||||
|
||||
@@ -78,7 +91,7 @@ agentic SDLC platform, or a traditional IDE. Nova does not
|
||||
differentiate. All submissions pass through the same gate
|
||||
(`schemas/submission-readiness.schema.json`): tags, environment
|
||||
metadata, policy preconditions, profile markers. The compliance
|
||||
standards are the same regardless of how the code was authored. This
|
||||
is by design: the audit trail is the same, the policy envelope is the
|
||||
standards are the same regardless of how the code was authored. This is
|
||||
by design: the audit trail is the same, the policy envelope is the
|
||||
same, the evidence stream is the same. The source does not matter; the
|
||||
submission does.
|
||||
+6
-1
@@ -14,7 +14,12 @@ PDLC includes:
|
||||
- IDE workflows / developer experience
|
||||
|
||||
Nova never penetrates the PDLC. Nova's domain is **infrastructure +
|
||||
delivery only**.
|
||||
delivery only**. Nova integrates with externally owned PDLC, SDLC,
|
||||
Agentic, and Citizen Developer platforms with no regard for the source
|
||||
of the intent: Nova provides a set of skills and MCP endpoints that help
|
||||
the developer or AI agent make their application production-grade, and
|
||||
all intents to deploy to production go through the same rigorous
|
||||
controls, quality gates, attestation, and evidence stream.
|
||||
|
||||
## What Nova Does
|
||||
|
||||
|
||||
+19
-6
@@ -1,11 +1,19 @@
|
||||
# Nova Central Deployment Pipeline Contract (v1.8)
|
||||
# Nova Central Deployment Pipeline Contract (v1.8 + v1.21 REQ-250)
|
||||
#
|
||||
# This is the single source of truth for the deployment pipeline. It
|
||||
# declares the stages that run when a consumer submits a contract:
|
||||
# validate-contract -> resolve-stack -> terraform-plan -> checkov ->
|
||||
# validate-contract -> resolve-stack -> checkov-static (fail-fast) ->
|
||||
# terraform-plan -> runtime-policy-scan (Wiz-or-Checkov, never both) ->
|
||||
# confidence -> apply (dev only) -> publish-outputs -> deploy-uptime ->
|
||||
# comment-outputs
|
||||
#
|
||||
# REQ-250 (v1.21): the policy scan is two-stage. checkov-static runs on
|
||||
# the authored Terraform code BEFORE terraform plan (fail-fast, quick
|
||||
# developer feedback). runtime-policy-scan runs AFTER terraform plan:
|
||||
# Wiz scans the plan when configured (WIZ_API_TOKEN + WIZ_API_URL);
|
||||
# otherwise Checkov runs against the plan as a drop-in replacement. Wiz
|
||||
# and Checkov are NEVER both run on the plan.
|
||||
#
|
||||
# Decommission mode (mode: decommission) runs a different set of stages:
|
||||
# validate-change-request -> disable-deletion-protection (HITL SRE) ->
|
||||
# zero-counts (HITL SRE) -> confirm-decommission
|
||||
@@ -36,15 +44,20 @@ stages:
|
||||
command: python3 core/contract_resolver.py contracts/static-assets.yaml /tmp/acdl-stack.json
|
||||
required: true
|
||||
|
||||
- name: checkov-static
|
||||
description: Run Checkov on the authored Terraform code (fail-fast, before terraform plan) — REQ-250
|
||||
command: bash scripts/run_codegen.sh --check-only
|
||||
required: true
|
||||
|
||||
- name: terraform-plan
|
||||
description: Compile the stack to Terraform and run terraform plan
|
||||
command: bash scripts/run_platform.sh --plan-only contracts/static-assets.yaml
|
||||
required: true
|
||||
|
||||
- name: checkov
|
||||
description: Run Checkov policy checks on the emitted Terraform
|
||||
command: bash scripts/run_platform.sh --check-only
|
||||
required: false
|
||||
- name: runtime-policy-scan
|
||||
description: Run Wiz against the plan when configured, else Checkov against the plan (never both) — REQ-250
|
||||
command: bash scripts/run_postapply.sh contracts/static-assets.yaml --quiet
|
||||
required: true
|
||||
|
||||
- name: confidence
|
||||
description: Compute the confidence signal from policy + validation inputs
|
||||
|
||||
@@ -8,7 +8,7 @@ multipart form: name=<filename>, attachment=<file bytes>
|
||||
|
||||
Usage:
|
||||
python3 scripts/attach_release_asset.py <file-path> <release-id>
|
||||
python3 scripts/attach_release_asset.py docs/presentations/nova-no-humans-platform.pptx 522
|
||||
python3 scripts/attach_release_asset.py docs/presentations/nova-autonomous-cloud-delivery.pptx 522
|
||||
|
||||
Token resolution: reads NOVA_GITEA_TOKEN (or ACDL_GITEA_TOKEN) from .env.secrets
|
||||
/ .env, matching the ship_phase.sh pattern. Never uses shell env tokens.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
#
|
||||
# Usage:
|
||||
# bash scripts/render_deck.sh <deck-name>
|
||||
# bash scripts/render_deck.sh nova-no-humans-platform
|
||||
# bash scripts/render_deck.sh nova-autonomous-cloud-delivery
|
||||
#
|
||||
# Renders:
|
||||
# docs/presentations/<deck-name>-marp.md → docs/presentations/<deck-name>.html (committed)
|
||||
|
||||
@@ -6,12 +6,12 @@
|
||||
#
|
||||
# Usage:
|
||||
# bash scripts/render_slides.sh [deck-name]
|
||||
# bash scripts/render_slides.sh nova-no-humans-platform
|
||||
# bash scripts/render_slides.sh nova-autonomous-cloud-delivery
|
||||
#
|
||||
# If no deck name is given, defaults to nova-no-humans-platform.
|
||||
# If no deck name is given, defaults to nova-autonomous-cloud-delivery.
|
||||
set -euo pipefail
|
||||
|
||||
DECK="${1:-nova-no-humans-platform}"
|
||||
DECK="${1:-nova-autonomous-cloud-delivery}"
|
||||
cd "$(git rev-parse --show-toplevel)"
|
||||
|
||||
MMD_DIR="docs/presentations/assets/mmd"
|
||||
|
||||
@@ -101,6 +101,20 @@ adapter.compile(stack, '$TF_DIR')
|
||||
print('adapter: main.tf + terraform.tf + providers.tf written')
|
||||
"
|
||||
|
||||
echo "=== Step 3c: Checkov on static code (fail-fast, before terraform plan) ==="
|
||||
# REQ-250 (v1.21): Checkov runs on the authored Terraform code BEFORE
|
||||
# terraform plan so developers get immediate policy feedback, not a
|
||||
# delayed plan-stage failure. The runtime plan scan (Wiz-or-Checkov)
|
||||
# runs after the plan in run_postapply.sh Step 5.
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -d "$TF_DIR" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov-static.json"
|
||||
else
|
||||
checkov -d "$TF_DIR" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov-static.json" 2> "$WORK/checkov-static.err"
|
||||
fi
|
||||
[ -s "$WORK/checkov-static.json" ] || { echo "FAIL: checkov (static) produced no output" >&2; exit 1; }
|
||||
echo ""
|
||||
echo "checkov (static) summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov-static.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
|
||||
if [ "$CHECK_ONLY" = "1" ]; then
|
||||
echo ""
|
||||
echo "=== Step 3b: validate adapter output structure (offline) ==="
|
||||
|
||||
+43
-12
@@ -312,6 +312,20 @@ if [ -z "${AWS_ACCESS_KEY_ID:-}" ] || [ -z "${AWS_SECRET_ACCESS_KEY:-}" ]; then
|
||||
export AWS_DEFAULT_REGION="$AWS_DEFAULT_REGION"
|
||||
fi
|
||||
|
||||
echo "=== Step 3c: Checkov on static code (fail-fast, before terraform plan) ==="
|
||||
# REQ-250 (v1.21): Checkov runs on the authored Terraform code BEFORE
|
||||
# terraform plan so developers get immediate policy feedback, not a
|
||||
# delayed plan-stage failure. The runtime plan scan (Wiz-or-Checkov)
|
||||
# runs after the plan (Step 5).
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -d "$TF_DIR" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov-static.json"
|
||||
else
|
||||
checkov -d "$TF_DIR" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov-static.json" 2> "$WORK/checkov-static.err"
|
||||
fi
|
||||
[ -s "$WORK/checkov-static.json" ] || fail "checkov (static) produced no output"
|
||||
echo ""
|
||||
echo "checkov (static) summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov-static.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
|
||||
echo "=== Step 4: terraform init + validate + plan -lock=false (real AWS) ==="
|
||||
cd "$TF_DIR"
|
||||
|
||||
@@ -380,19 +394,36 @@ if [ "$DESTROY_ONLY" = "1" ]; then
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "=== Step 5: run Checkov on $TF_DIR/main.tf ==="
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -f "$TF_DIR/main.tf" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov.json"
|
||||
echo "=== Step 5: runtime policy scan on the terraform plan (Wiz-or-Checkov, never both) ==="
|
||||
# REQ-250 (v1.21): after terraform plan, run Wiz against the plan when
|
||||
# configured; otherwise run Checkov against the plan as a drop-in
|
||||
# replacement. Wiz and Checkov are NEVER both run on the plan.
|
||||
RUNTIME_SCAN_ENGINE=""
|
||||
if [ -n "${WIZ_API_TOKEN:-}" ] || [ -n "${WIZ_API_URL:-}" ]; then
|
||||
RUNTIME_SCAN_ENGINE="wiz"
|
||||
echo "--- Wiz configured (WIZ_API_TOKEN + WIZ_API_URL) → Wiz on the plan ---"
|
||||
python3 adapters/wiz/wiz_adapter.py --plan "$TF_DIR/tfplan" --contract-id "$CONTRACT_ID" --run-id "${CONTRACT_ID}" > "$WORK/pcr.json" 2> "$WORK/wiz.err" || {
|
||||
echo "WARNING: Wiz scan failed; falling back to Checkov on the plan" >&2
|
||||
RUNTIME_SCAN_ENGINE="checkov-plan"
|
||||
}
|
||||
else
|
||||
checkov -f "$TF_DIR/main.tf" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov.json" 2> "$WORK/checkov.err"
|
||||
RUNTIME_SCAN_ENGINE="checkov-plan"
|
||||
fi
|
||||
[ -s "$WORK/checkov.json" ] || fail "checkov produced no output"
|
||||
echo ""
|
||||
echo "checkov summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
|
||||
echo ""
|
||||
echo "=== Step 6: Checkov adapter -> PolicyCheckResult (compliance details) ==="
|
||||
python3 adapters/terraform/policy/checkov_adapter.py "$WORK/checkov.json" "$CONTRACT_ID" > "$WORK/pcr.json" || fail "checkov adapter failed"
|
||||
if [ "$RUNTIME_SCAN_ENGINE" = "checkov-plan" ]; then
|
||||
echo "--- Wiz not configured → Checkov on the plan (drop-in replacement) ---"
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -f "$TF_DIR/tfplan" --framework terraform_plan -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov-plan.json"
|
||||
else
|
||||
checkov -f "$TF_DIR/tfplan" --framework terraform_plan -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov-plan.json" 2> "$WORK/checkov-plan.err"
|
||||
fi
|
||||
[ -s "$WORK/checkov-plan.json" ] || fail "checkov (plan) produced no output"
|
||||
echo ""
|
||||
echo "checkov (plan) summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov-plan.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
echo ""
|
||||
echo "=== Step 6: Checkov (plan) adapter -> PolicyCheckResult ==="
|
||||
python3 adapters/terraform/policy/checkov_adapter.py "$WORK/checkov-plan.json" "$CONTRACT_ID" > "$WORK/pcr.json" || fail "checkov (plan) adapter failed"
|
||||
fi
|
||||
echo "runtime scan engine: $RUNTIME_SCAN_ENGINE"
|
||||
python3 -c "
|
||||
import json
|
||||
pcrs = json.load(open('$WORK/pcr.json'))
|
||||
@@ -494,5 +525,5 @@ source "$ROOT/scripts/run_uptime.sh"
|
||||
|
||||
echo ""
|
||||
echo "=== PLATFORM E2E OK ==="
|
||||
echo "contract -> resolver -> stack -> terraform plan -> Checkov -> confidence ($BAND) -> outbox -> outputs"
|
||||
echo "contract -> resolver -> stack -> Checkov(static) -> terraform plan -> Wiz-or-Checkov(plan) -> confidence ($BAND) -> outbox -> outputs"
|
||||
exit 0
|
||||
+33
-14
@@ -2,8 +2,9 @@
|
||||
# scripts/run_postapply.sh — post-Terraform steps for the Nova platform pipeline.
|
||||
#
|
||||
# Performs steps 5–9 of run_platform.sh (after terraform apply/destroy):
|
||||
# 5. Checkov policy scan on the emitted main.tf
|
||||
# 6. Checkov adapter → PolicyCheckResult (compliance details)
|
||||
# 3c. Checkov policy scan on static code (fail-fast, in run_codegen.sh)
|
||||
# 5. Runtime policy scan on the terraform plan (Wiz-or-Checkov, never both)
|
||||
# 6. Policy scan adapter → PolicyCheckResult (compliance details)
|
||||
# 7. Confidence signal compute
|
||||
# 7b. HITL attestation gate (qa/prod/dr only)
|
||||
# 8. Write evidence event to DynamoDB outbox
|
||||
@@ -92,19 +93,37 @@ else:
|
||||
" || { echo "FAIL: HITL gate blocked" >&2; return 1; }
|
||||
}
|
||||
|
||||
echo "=== Step 5: run Checkov on $TF_DIR/main.tf ==="
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -f "$TF_DIR/main.tf" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov.json"
|
||||
echo "=== Step 5: runtime policy scan on the terraform plan (Wiz-or-Checkov, never both) ==="
|
||||
# REQ-250 (v1.21): after terraform plan, run Wiz against the plan when
|
||||
# configured; otherwise run Checkov against the plan as a drop-in
|
||||
# replacement. Wiz and Checkov are NEVER both run on the plan. The
|
||||
# static-code Checkov already ran in run_codegen.sh Step 3c (fail-fast).
|
||||
RUNTIME_SCAN_ENGINE=""
|
||||
if [ -n "${WIZ_API_TOKEN:-}" ] || [ -n "${WIZ_API_URL:-}" ]; then
|
||||
RUNTIME_SCAN_ENGINE="wiz"
|
||||
echo "--- Wiz configured (WIZ_API_TOKEN + WIZ_API_URL) → Wiz on the plan ---"
|
||||
python3 adapters/wiz/wiz_adapter.py --plan "$TF_DIR/tfplan" --contract-id "$CONTRACT_ID" --run-id "${CONTRACT_ID}" > "$WORK/pcr.json" 2> "$WORK/wiz.err" || {
|
||||
echo "WARNING: Wiz scan failed; falling back to Checkov on the plan" >&2
|
||||
RUNTIME_SCAN_ENGINE="checkov-plan"
|
||||
}
|
||||
else
|
||||
checkov -f "$TF_DIR/main.tf" --framework terraform -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov.json" 2> "$WORK/checkov.err"
|
||||
RUNTIME_SCAN_ENGINE="checkov-plan"
|
||||
fi
|
||||
[ -s "$WORK/checkov.json" ] || { echo "FAIL: checkov produced no output" >&2; exit 1; }
|
||||
echo ""
|
||||
echo "checkov summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
|
||||
echo ""
|
||||
echo "=== Step 6: Checkov adapter → PolicyCheckResult (compliance details) ==="
|
||||
python3 adapters/terraform/policy/checkov_adapter.py "$WORK/checkov.json" "$CONTRACT_ID" > "$WORK/pcr.json" || { echo "FAIL: checkov adapter failed" >&2; exit 1; }
|
||||
if [ "$RUNTIME_SCAN_ENGINE" = "checkov-plan" ]; then
|
||||
echo "--- Wiz not configured → Checkov on the plan (drop-in replacement) ---"
|
||||
if [ "$QUIET" = "0" ]; then
|
||||
checkov -f "$TF_DIR/tfplan" --framework terraform_plan -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ 2>&1 | tee "$WORK/checkov-plan.json"
|
||||
else
|
||||
checkov -f "$TF_DIR/tfplan" --framework terraform_plan -o json --soft-fail --external-checks-dir adapters/terraform/policy/custom_rules/ > "$WORK/checkov-plan.json" 2> "$WORK/checkov-plan.err"
|
||||
fi
|
||||
[ -s "$WORK/checkov-plan.json" ] || { echo "FAIL: checkov (plan) produced no output" >&2; exit 1; }
|
||||
echo ""
|
||||
echo "checkov (plan) summary: $(python3 -c "import json; d=json.load(open('$WORK/checkov-plan.json')); print(len(d.get('results',{}).get('failed_checks',[])), 'failed,', len(d.get('results',{}).get('passed_checks',[])), 'passed')")"
|
||||
echo ""
|
||||
echo "=== Step 6: Checkov (plan) adapter → PolicyCheckResult (compliance details) ==="
|
||||
python3 adapters/terraform/policy/checkov_adapter.py "$WORK/checkov-plan.json" "$CONTRACT_ID" > "$WORK/pcr.json" || { echo "FAIL: checkov (plan) adapter failed" >&2; exit 1; }
|
||||
fi
|
||||
echo "runtime scan engine: $RUNTIME_SCAN_ENGINE"
|
||||
python3 -c "
|
||||
import json
|
||||
pcrs = json.load(open('$WORK/pcr.json'))
|
||||
@@ -199,4 +218,4 @@ source "$ROOT/scripts/run_uptime.sh"
|
||||
|
||||
echo ""
|
||||
echo "=== POST-APPLY OK ==="
|
||||
echo "Checkov → confidence ($BAND) → outbox → outputs → uptime"
|
||||
echo "Checkov(static, pre-plan) → Wiz-or-Checkov(plan) → confidence ($BAND) → outbox → outputs → uptime"
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Offline-proven Terraform for the cross-account consumer deploy-role +
|
||||
`nova:owner` ABAC tag grant. This is the "role grant" half of the
|
||||
no-humans onboarding flow (D-113); the "request" half is P18 (Lambda
|
||||
autonomous onboarding flow (D-113); the "request" half is P18 (Lambda
|
||||
action) + P19 (env-file autogen).
|
||||
|
||||
## Scope (D-114)
|
||||
|
||||
@@ -173,16 +173,19 @@ class TestDeployPipelineContract:
|
||||
contract = yaml.safe_load(fh)
|
||||
jsonschema.validate(contract, schema)
|
||||
|
||||
def test_deploy_pipeline_has_six_stages(self):
|
||||
def test_deploy_pipeline_has_required_stages(self):
|
||||
with open(ROOT / "pipelines/contract.yml") as fh:
|
||||
contract = yaml.safe_load(fh)
|
||||
stage_names = [s["name"] for s in contract["stages"]]
|
||||
assert "validate-contract" in stage_names
|
||||
assert "resolve-stack" in stage_names
|
||||
assert "checkov-static" in stage_names, "REQ-250: checkov-static stage missing"
|
||||
assert "terraform-plan" in stage_names
|
||||
assert "checkov" in stage_names
|
||||
assert "runtime-policy-scan" in stage_names, "REQ-250: runtime-policy-scan stage missing"
|
||||
assert "confidence" in stage_names
|
||||
assert "apply" in stage_names
|
||||
# The old single 'checkov' stage is gone (split into checkov-static + runtime-policy-scan)
|
||||
assert "checkov" not in stage_names, "old 'checkov' stage should be replaced by checkov-static + runtime-policy-scan"
|
||||
|
||||
|
||||
class TestL2OutputsResolution:
|
||||
|
||||
@@ -206,14 +206,15 @@ class TestDeployPipelineContract:
|
||||
contract = _load_yaml("pipelines/contract.yml")
|
||||
jsonschema.validate(contract, schema)
|
||||
|
||||
def test_deploy_contract_has_nine_stages(self):
|
||||
def test_deploy_contract_has_ten_stages(self):
|
||||
contract = _load_yaml("pipelines/contract.yml")
|
||||
stage_names = [s["name"] for s in contract["stages"]]
|
||||
assert stage_names == [
|
||||
"validate-contract",
|
||||
"resolve-stack",
|
||||
"checkov-static",
|
||||
"terraform-plan",
|
||||
"checkov",
|
||||
"runtime-policy-scan",
|
||||
"confidence",
|
||||
"apply",
|
||||
"publish-outputs",
|
||||
|
||||
@@ -26,7 +26,7 @@ def test_cap_024_deck_structure():
|
||||
|
||||
def test_cap_024_deck_exists():
|
||||
"""The unified deck source of truth exists."""
|
||||
deck_path = ROOT / "docs" / "presentations" / "nova-no-humans-platform.md"
|
||||
deck_path = ROOT / "docs" / "presentations" / "nova-autonomous-cloud-delivery.md"
|
||||
assert deck_path.exists(), "unified deck not found"
|
||||
|
||||
|
||||
|
||||
@@ -1,12 +1,21 @@
|
||||
"""REQ-239..243 (v1.20): S&P theme + slide render pipeline tests.
|
||||
"""REQ-239..243 (v1.20) + REQ-245,251,252 (v1.21): S&P theme + slide render
|
||||
pipeline + deck-refinement tests.
|
||||
|
||||
Validates:
|
||||
v1.20 validates:
|
||||
- The Marp deck frontmatter references nova-sp-theme.css
|
||||
- The CSS file contains the S&P colors (#D6002A, #1B1B1B)
|
||||
- The mermaid theme JSON contains the S&P colors
|
||||
- Every .mmd has a corresponding .png
|
||||
- The render_slides.sh script exists and is executable
|
||||
- The CI workflow file exists
|
||||
|
||||
v1.21 adds (REQ-245,251,252):
|
||||
- Deck renamed to nova-autonomous-cloud-delivery*
|
||||
- No maturity badges in the Marp deck
|
||||
- No version in the Marp footer/title slide
|
||||
- 18 main + 1 appendix slides
|
||||
- No D-###/REQ-###/internal .py paths in audience-facing slides
|
||||
- Title is "Nova — The Autonomous Cloud Delivery Platform"
|
||||
"""
|
||||
import re
|
||||
from pathlib import Path
|
||||
@@ -18,7 +27,8 @@ PRESENTATIONS = ROOT / "docs" / "presentations"
|
||||
ASSETS = PRESENTATIONS / "assets"
|
||||
THEME_CSS = ASSETS / "nova-sp-theme.css"
|
||||
THEME_JSON = ASSETS / "mmd" / "sp-theme.json"
|
||||
MARP_DECK = PRESENTATIONS / "nova-no-humans-platform-marp.md"
|
||||
MARP_DECK = PRESENTATIONS / "nova-autonomous-cloud-delivery-marp.md"
|
||||
SOURCE_MD = PRESENTATIONS / "nova-autonomous-cloud-delivery.md"
|
||||
RENDER_SCRIPT = ROOT / "scripts" / "render_slides.sh"
|
||||
SLIDES_WORKFLOW = ROOT / ".github" / "workflows" / "slides.yml"
|
||||
|
||||
@@ -87,6 +97,13 @@ def test_render_slides_script_renders_marp():
|
||||
assert ".pptx" in text, "render_slides.sh does not produce PPTX"
|
||||
|
||||
|
||||
def test_render_slides_default_deck_renamed():
|
||||
"""REQ-245: render_slides.sh default deck is nova-autonomous-cloud-delivery."""
|
||||
text = RENDER_SCRIPT.read_text()
|
||||
assert "nova-autonomous-cloud-delivery" in text, \
|
||||
"render_slides.sh does not default to nova-autonomous-cloud-delivery"
|
||||
|
||||
|
||||
def test_slides_ci_workflow_exists():
|
||||
"""REQ-241: CI workflow for slides exists."""
|
||||
assert SLIDES_WORKFLOW.is_file(), "slides.yml workflow not found"
|
||||
@@ -124,3 +141,128 @@ def test_readme_no_retired_decks():
|
||||
"README still references retired 'how-the-platform-works' deck"
|
||||
assert "the-developer-experience" not in readme, \
|
||||
"README still references retired 'the-developer-experience' deck"
|
||||
|
||||
|
||||
def test_readme_no_old_deck_name():
|
||||
"""REQ-245: README references the new deck name, not the old one."""
|
||||
readme = (PRESENTATIONS / "README.md").read_text()
|
||||
assert "nova-autonomous-cloud-delivery" in readme, \
|
||||
"README does not reference nova-autonomous-cloud-delivery"
|
||||
|
||||
|
||||
def test_old_deck_files_removed():
|
||||
"""REQ-245: the old nova-no-humans-platform* files are gone."""
|
||||
old_files = sorted(PRESENTATIONS.glob("nova-no-humans-platform*"))
|
||||
assert not old_files, f"old deck files still present: {old_files}"
|
||||
|
||||
|
||||
def test_marp_deck_no_badges():
|
||||
"""REQ-252: no maturity badges in the Marp deck."""
|
||||
text = MARP_DECK.read_text()
|
||||
assert "badge" not in text, "Marp deck still contains badge spans"
|
||||
|
||||
|
||||
def test_marp_deck_no_version_in_footer():
|
||||
"""REQ-251: no version (v1.x) in the Marp frontmatter footer/header."""
|
||||
text = MARP_DECK.read_text()
|
||||
fm_match = re.match(r'^---\n(.*?)\n---', text, re.DOTALL)
|
||||
assert fm_match, "Marp frontmatter not found"
|
||||
frontmatter = fm_match.group(1)
|
||||
# No v1.x version string in the footer or header lines
|
||||
assert not re.search(r"v1\.\d+", frontmatter), \
|
||||
f"Marp frontmatter still contains a version: {frontmatter}"
|
||||
# No "Act" pagination artifact
|
||||
assert "Act %" not in frontmatter, \
|
||||
"Marp frontmatter still contains 'Act %{page}' artifact"
|
||||
|
||||
|
||||
def test_marp_deck_title_slide_no_version_subtitle():
|
||||
"""REQ-251: the title slide does not carry a version subtitle."""
|
||||
text = MARP_DECK.read_text()
|
||||
# The title slide is the first slide after the frontmatter
|
||||
# Find the title block (between the frontmatter and the first --- separator)
|
||||
after_fm = text.split("---\n", 2)[2] if text.startswith("---") else text
|
||||
first_slide = after_fm.split("\n---\n")[0]
|
||||
# The old subtitle was "v1.18 — Citizen Developer & Production-Grade Guidance"
|
||||
assert "v1.18" not in first_slide, \
|
||||
"Title slide still contains 'v1.18' subtitle"
|
||||
assert "Citizen Developer & Production-Grade Guidance" not in first_slide, \
|
||||
"Title slide still contains the old version subtitle"
|
||||
|
||||
|
||||
def test_marp_deck_title_is_autonomous_cloud_delivery():
|
||||
"""REQ-245: the deck title is 'Nova — The Autonomous Cloud Delivery Platform'."""
|
||||
text = MARP_DECK.read_text()
|
||||
assert "Autonomous Cloud Delivery Platform" in text, \
|
||||
"Deck title is not 'Autonomous Cloud Delivery Platform'"
|
||||
# The old title should not appear in the audience-facing deck
|
||||
# (speaker notes are not in the marp deck, so this is safe)
|
||||
assert "No-Humans Infrastructure Platform" not in text, \
|
||||
"Deck still carries the old 'No-Humans Infrastructure Platform' title"
|
||||
|
||||
|
||||
def test_marp_deck_slide_count():
|
||||
"""REQ-245: 18 main slides + 1 appendix = 19 slides total."""
|
||||
text = MARP_DECK.read_text()
|
||||
# Count slide separators: each slide ends with --- (except the last)
|
||||
# The frontmatter is one --- ... --- block, then each slide is separated by ---
|
||||
# Count "## Slide" and "## Appendix" headings
|
||||
slide_headings = re.findall(r"^## (?:Slide|Appendix) ", text, re.MULTILINE)
|
||||
main_slides = re.findall(r"^## Slide ", text, re.MULTILINE)
|
||||
appendix_slides = re.findall(r"^## Appendix ", text, re.MULTILINE)
|
||||
assert len(main_slides) == 18, \
|
||||
f"expected 18 main slides, found {len(main_slides)}: {slide_headings}"
|
||||
assert len(appendix_slides) == 1, \
|
||||
f"expected 1 appendix slide, found {len(appendix_slides)}"
|
||||
|
||||
|
||||
def test_marp_deck_no_internal_citations():
|
||||
"""REQ-252: no D-### decision IDs, REQ-### requirement IDs, or internal
|
||||
.py file paths in the audience-facing Marp deck."""
|
||||
text = MARP_DECK.read_text()
|
||||
# Decision IDs like D-121, D-083
|
||||
assert not re.search(r"\bD-\d{3}\b", text), \
|
||||
"Marp deck contains D-### decision IDs"
|
||||
# Requirement IDs like REQ-245
|
||||
assert not re.search(r"\bREQ-\d{3}\b", text), \
|
||||
"Marp deck contains REQ-### requirement IDs"
|
||||
# Internal python file paths like outbox_writer.py, confidence_signal.py
|
||||
# (allow .py only inside code blocks for the ROI formula? No — the deck
|
||||
# should not cite internal file paths at all)
|
||||
assert not re.search(r"\b(outbox_writer|confidence_signal|hitl_gates|"
|
||||
r"attestation_matrix|checkov_adapter|infracost_adapter|"
|
||||
r"contract_resolver|run_platform)\.py\b", text), \
|
||||
"Marp deck contains internal .py file paths"
|
||||
|
||||
|
||||
def test_source_md_no_internal_citations_in_slides():
|
||||
"""REQ-252: the source-of-truth markdown keeps internal citations only
|
||||
in speaker notes, not in the audience-facing slide body. Speaker notes
|
||||
are blockquoted (> ) — we check non-blockquote lines for D-###/REQ-###."""
|
||||
text = SOURCE_MD.read_text()
|
||||
# Split into lines; exclude blockquote lines (speaker notes) and the
|
||||
# header frontmatter (> ... at the top)
|
||||
in_note = False
|
||||
body_lines = []
|
||||
for line in text.splitlines():
|
||||
if line.lstrip().startswith(">"):
|
||||
in_note = True
|
||||
continue
|
||||
if in_note and line.strip() == "":
|
||||
in_note = False
|
||||
continue
|
||||
if not in_note:
|
||||
body_lines.append(line)
|
||||
body = "\n".join(body_lines)
|
||||
# Decision IDs and REQ IDs should not appear in the slide body
|
||||
assert not re.search(r"\bD-\d{3}\b", body), \
|
||||
"Source markdown slide body contains D-### decision IDs"
|
||||
assert not re.search(r"\bREQ-\d{3}\b", body), \
|
||||
"Source markdown slide body contains REQ-### requirement IDs"
|
||||
|
||||
|
||||
def test_source_md_no_badges():
|
||||
"""REQ-252: no maturity badges in the source-of-truth markdown."""
|
||||
text = SOURCE_MD.read_text()
|
||||
assert "badge" not in text.lower(), \
|
||||
"Source markdown still contains badge spans"
|
||||
Reference in New Issue
Block a user