docs(P5): deck rebuild — unified narrative deck (18 slides, x3 arc, per-slide benefits) + retire old decks (D-130)
P5 (Wave 3, docs) — REQ-196, 197, 202, 203, 213 New deck (unified narrative): - docs/presentations/nova-no-humans-platform.md — source of truth (18 slides) - docs/presentations/nova-no-humans-platform-marp.md — Marp deck - docs/presentations/nova-no-humans-platform-talking-points.md — presenter cues 5-act arc: Problem -> Vision -> How -> Proof -> Roadmap x3 structure at deck level (slide 1 = arc preview, slides 2-15 = tell them, slide 16 = recap + ask) x3 per slide (opens with what it covers, delivers, closes with benefit callout) Fluid transitions (every slide references the previous slide's close) Act indicator in Marp footer Grill binding decisions applied: - G-Q4: D-122 honesty sentence on slide 7 - G-Q8: stake line (18V+0 consumers) on slide 1 - G-Q9: 4 filler benefit closes rewritten - G-Q10: slide 12 split into Zero-Touch Efficiency + Cost & ROI - G-Q11: preempt on slide 14 (deferrals are measurement infra, not autonomy) - G-Q13: Act 3->4 transition rewritten - G-Q14: slide 9 benefit reframed to trust substrate - G-Q15: ROI formula inline + N=0 caveat on slide 13 - G-Q16: slide 16 ask reframed as business decision Retired (D-130): - how-the-platform-works.md + marp + html + talking-points (DELETED) - the-developer-experience.md + marp + html + talking-points (DELETED) ---ci--- project: acdl phase: 5 milestone: v1.17 status: execute ---/ci---
This commit is contained in:
Jon Chery
@@ -1,334 +0,0 @@
|
||||
---
|
||||
marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "How The Platform Works"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
|
||||
font-size: 26px;
|
||||
color: #1B1B1B;
|
||||
}
|
||||
h1 { color: #D6002A; font-size: 40px; margin-bottom: 0.3em; }
|
||||
h2 { color: #D6002A; font-size: 32px; margin-bottom: 0.2em; }
|
||||
section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
|
||||
section.title h1 { color: #fff; }
|
||||
table { font-size: 22px; width: 100%; }
|
||||
th { background: #F0F0F0; }
|
||||
blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 24px; }
|
||||
img { display: block; margin: 0 auto; max-height: 300px; }
|
||||
.badge {
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 16px; font-weight: 600;
|
||||
}
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# How The Platform Works
|
||||
|
||||
### Nova — The New Dawn of DevSecOps
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
|
||||
section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
|
||||
</style>
|
||||
|
||||
---
|
||||
|
||||
# Four frictions slow every team
|
||||
|
||||
|
||||
|
||||
- **Cognitive load** — services inconsistent in security and observability
|
||||
- **Operational work** — manual promotion scaling with the system
|
||||
- **Red tape** — tickets and handoffs scaling with the organization
|
||||
- **Scalability** — throughput without scaling platform engineers
|
||||
|
||||
---
|
||||
|
||||
# The platform at a glance
|
||||
|
||||
|
||||
|
||||
- **Consumer surfaces** — technical dev or citizen dev; both produce a contract
|
||||
- **Central pipeline** — fixed stages, identical for every deployment: validate → resolve → security → plan → policy → confidence → evidence → apply
|
||||
- **Module catalog + engine adapter** — security-reviewed blocks; the adapter is the only engine-specific code (Terraform today)
|
||||
- **HITL gates + evidence stream** — human attestation for qa/prod/dr; every deployment writes a hash-chained event (RPO = 0)
|
||||
|
||||
---
|
||||
|
||||
# Declare intent; the platform delivers safe production
|
||||
|
||||
|
||||
|
||||
- A merged change progresses **without a ticket or thread**
|
||||
- A **non-technical consumer** ships by declaring intent
|
||||
- Every production change is **traceable to a human attestation**
|
||||
|
||||
---
|
||||
|
||||
# Nova owns infrastructure, not your app
|
||||
|
||||
|
||||
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding
|
||||
- **Nova is infrastructure only** — provisions and governs AWS resources
|
||||
- **Not a general-purpose AI** — autonomy is narrow, policy-bounded
|
||||
- **Not a permissive highway** — no escape hatches
|
||||
|
||||
---
|
||||
|
||||
# One YAML file. The platform owns everything else.
|
||||
|
||||
|
||||
|
||||
- **Module** — pre-built, security-reviewed building blocks
|
||||
- **Environment** — `dev`, `qa`, `prod`, `dr`; bar rises with sensitivity
|
||||
- **Inputs** — cpu, memory, port, desired_count
|
||||
- Consumer provides **no AWS account, no VPC, no state backend**
|
||||
|
||||
---
|
||||
|
||||
# Same stages, same checks, every deployment
|
||||
|
||||
|
||||
|
||||
- **Security and policy checks run *before* any infra is created**
|
||||
- **Every stage produces a record** — no "unchecked" path
|
||||
|
||||
---
|
||||
|
||||
# No long-lived credentials. Blast radius contained.
|
||||
|
||||
|
||||
|
||||
- **OIDC federation** — short-lived token per job, no stored credential <span class="badge planned">Planned: all runners</span>
|
||||
- **ABAC, not role-based** — repo identity + resource tags scope every action
|
||||
- **A consumer can only touch its own tagged resources.** One consumer can never affect another.
|
||||
|
||||
---
|
||||
|
||||
# Safety is a measurable signal, not a black box
|
||||
|
||||
|
||||
|
||||
- **Six weighted inputs** — manually tuned, auditable per-input breakdown
|
||||
|
||||
| Environment | Threshold | Attester |
|
||||
|---|---|---|
|
||||
| dev | ≥ 0.50 | No one — autonomous |
|
||||
| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
|
||||
| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |
|
||||
|
||||
- **A single critical finding hard-blocks** — not averaged away
|
||||
|
||||
---
|
||||
|
||||
# Every change traceable to a human attestation
|
||||
|
||||
|
||||
|
||||
- **Dev is fully autonomous** — confidence signal is the only gate
|
||||
- **qa, prod, dr require human attestation** — contract + plan + evidence <span class="badge planned">Planned</span>
|
||||
- **Separation of duties** — QA approver ≠ prod approver; platform **blocks on a match** <span class="badge planned">Planned</span>
|
||||
- **Hash-chained evidence event** — tampering breaks the chain. **RPO = 0**
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# The vision realized
|
||||
|
||||
- **Velocity without sacrificing safety** — speed in ergonomics, safety in unbypassable gates
|
||||
- **Security, observability, compliance as platform defaults** — not per-team effort
|
||||
- **Auditability as a byproduct, not a project** — every change traceable to a human attestation
|
||||
- **Blast radius contained by design** — OIDC + ABAC, only your own tagged resources
|
||||
- **Infrastructure as a utility, not a craft** — consume, don't maintain
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Appendix
|
||||
|
||||
**Contents:**
|
||||
|
||||
1. Platform-Managed Environments (detail)
|
||||
2. Observability Built In (detail)
|
||||
3. Security by Construction (the full defaults inventory)
|
||||
4. The Road to the North Star (phased roadmap)
|
||||
5. Testing vs. Planned (full inventory)
|
||||
6. Glossary
|
||||
7. Operating Model & Cost (real AWS spend + pre-mortem)
|
||||
8. Verified by Construction (the v1.11 architecture)
|
||||
|
||||
---
|
||||
|
||||
# A1 — Platform-Managed Environments
|
||||
|
||||
A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.
|
||||
|
||||
A named environment is a platform-owned bundle of:
|
||||
|
||||
- An AWS account (or a scoped partition of one)
|
||||
- A network (VPC + subnets)
|
||||
- A state backend (S3 + DynamoDB for state + locking)
|
||||
- An IAM role surfaced via ABAC, scoped to the consumer's identity and resource tags
|
||||
|
||||
The consumer selects an environment **by name** in their contract. The platform resolves it at run time. **The consumer never sees raw credentials.**
|
||||
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure). <span class="badge planned">Self-service: planned</span>
|
||||
|
||||
---
|
||||
|
||||
# A2 — Observability Built In
|
||||
|
||||
Monitoring is **a platform default, not a per-team project.**
|
||||
|
||||
- **Uptime monitoring deployed automatically with every stack** — separate state, feature flag to disable
|
||||
- **Monitored endpoints passed from the deployment's own outputs** — no manual endpoint registration
|
||||
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues
|
||||
- **The uptime URL is published to the developer** via a PR comment
|
||||
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
|
||||
# A3 — Security by Construction
|
||||
|
||||
Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema.
|
||||
|
||||
- **Policy checks** (Checkov, Wiz, Kyverno) — secrets, public ingress, IAM wildcards, **required tagging** — all run *before* infra is created
|
||||
- **Encryption on every resource** — at-rest on by default; per-stack CMKs with 90-day rotation, **no shared keys across stacks**
|
||||
- **Deletion protection on by default** — `prevent_destroy` on unless explicitly disabled via a documented flag
|
||||
- **Safe decommission** — a 2-step pipeline with **two SRE attestation gates** and a **change-request validated against the CMDB**
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A4 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A5 — Testing vs. Planned (Full Inventory)
|
||||
|
||||
<style>
|
||||
section { font-size: 18px; }
|
||||
td { font-size: 16px; vertical-align: top; }
|
||||
ul { margin: 0; padding-left: 1.2em; }
|
||||
li { margin-bottom: 2px; }
|
||||
</style>
|
||||
|
||||
**22/22 Verified** — the v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS for every L1 + L2 module, then tore down to zero-cost (D-096). The v1.10 "6 deploy-unverified (IAM drift)" status is closed (CAP-013 fixed in P67).
|
||||
|
||||
<table style="width: 100%; border: none;">
|
||||
<tr>
|
||||
<td style="width: 52%; border: none; padding-right: 12px;">
|
||||
|
||||
**Testing** (22/22 Verified — works internally, dev pilot-ready)
|
||||
|
||||
- Contract-driven deploys with a versioned reusable workflow
|
||||
- Module catalog (primitives + modules) with validated examples
|
||||
- Zero-trust OIDC + ABAC on GitHub Actions runners
|
||||
- Security + policy checks before infra creation (Checkov; Wiz + Kyverno ready)
|
||||
- Confidence signal (6 inputs, per-env thresholds) gating promotion
|
||||
- Hash-chained, tamper-evident evidence outbox (RPO = 0)
|
||||
- Encryption by default + per-stack customer-managed keys
|
||||
- Deletion protection by default + safe decommission with SRE gates
|
||||
- Uptime monitoring deployed automatically with every stack
|
||||
- Platform-managed environments + friendly onboarding
|
||||
- Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion
|
||||
|
||||
</td>
|
||||
<td style="width: 48%; border: none; padding-left: 12px;">
|
||||
|
||||
**Planned** (on the roadmap)
|
||||
|
||||
- Real OIDC federation on all platform runners
|
||||
- HITL wiring for qa / prod / dr environments
|
||||
- Full regulatory ledger: S3 Object Lock + JWS signatures + daily checkpoints
|
||||
- Compliance milestone: GDPR, SOX, SOC2, DORA extension points
|
||||
- Environment self-service provisioning
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow)
|
||||
- Pattern recognition compounds value over time
|
||||
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs)
|
||||
- Deeper observability bootstrap (dashboards, runbooks, on-call)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
---
|
||||
|
||||
# A6 — Glossary
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
|
||||
|
||||
---
|
||||
|
||||
# A7 — Operating Model & Cost
|
||||
|
||||
<style>
|
||||
section { font-size: 20px; }
|
||||
table { font-size: 18px; }
|
||||
</style>
|
||||
|
||||
Nova runs at **zero cloud cost** for day-to-day development. AWS spend was measured via Cost Explorer (`COST.md`, 2026-07-28):
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Total spend (8 days) | **$0.001883** |
|
||||
| Daily average | $0.000235 |
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867) |
|
||||
|
||||
- **S3 dominates** (98.8%, terraform state bucket) — no compute ran because v1.0→v1.10 was plan-only for IAM-gated capabilities
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The pipeline now **defaults to plan-only** on every PR; `NOVA_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). Any spike > $1/day is an anomaly.
|
||||
|
||||
**Pre-mortem (`PRE_MORTEM.md`):** the v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A8 — Verified by Construction
|
||||
|
||||
<style>
|
||||
section { font-size: 20px; }
|
||||
</style>
|
||||
|
||||
Two architectural pillars make "Verified" a structural property, not a claim:
|
||||
|
||||
- **The stateless adapter (918 → ~80 lines).** The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line **stateless assembler**: it owns no module content — no resource shape, no nested HCL blocks, no defaults. Each L1 module ships a real `terraform/` module dir owning its shape, nested blocks, and defaults. The adapter reads the registry and emits `module "x" { source = ... }` blocks. A new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)*
|
||||
- **Pipeline-driven lifecycle testing.** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's `examples/{simple,complex}.yml` contracts through apply→modify→destroy against live AWS. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `NOVA_LIFECYCLE_MODE=full` overrides to the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — **22/22 Verified** as of v1.12.
|
||||
|
||||
The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix.
|
||||
@@ -1,248 +0,0 @@
|
||||
# How The Platform Works — Talking Points
|
||||
|
||||
> **Companion to:** `how-the-platform-works-marp.md` (11 main + Appendix TOC + 8 appendix = 20 slides)
|
||||
> **Content source:** `how-the-platform-works.md` (full source of truth with speaker notes)
|
||||
> **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember.
|
||||
> **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Title
|
||||
|
||||
**Talking points:**
|
||||
- Brief introduction — this deck explains *how* the platform works internally, not the developer experience (that's the companion deck)
|
||||
- Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands
|
||||
- Every "Testing" claim is Verified — 22/22 capabilities via the v1.11 lifecycle pipeline (see A8)
|
||||
|
||||
**Key takeaway:** The platform is the organizational lever for safe, fast shipping.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Four frictions slow every team
|
||||
|
||||
**Talking points:**
|
||||
- Open with the cost of the status quo — every team running its own pipeline, Terraform, and review checklist pays a tax that doesn't differentiate the business
|
||||
- The four frictions are categorically parallel: cognitive load, operational work, red tape, scalability
|
||||
- The platform absorbs all four — that is the value proposition in one sentence
|
||||
- Don't dwell here; this is the setup for the before/after contrast on the next slide
|
||||
|
||||
**Key takeaway:** Four frictions slow every team. The platform absorbs all four.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
**Talking points:**
|
||||
- One-slide map of the whole platform — use it to orient the audience before diving into any single component
|
||||
- The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer; (3) the engine adapter is the only engine-specific code, which makes the catalog and confidence model portable
|
||||
- Don't walk every node — point to the boundaries and say "the rest of this deck zooms into each of these"
|
||||
- The contract schema is the boundary between upstream and Nova; everything left of it is the consumer's, everything right of it is the platform's
|
||||
|
||||
**Key takeaway:** Two surfaces, one pipeline, one evidence stream. The rest of the deck zooms in.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Declare intent; the platform delivers safe production
|
||||
|
||||
**Talking points:**
|
||||
- Land the before/after contrast: today's queue vs. Nova's autonomous flow
|
||||
- The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision
|
||||
- The North Star is one sentence: "declare intent → safe production deployment"
|
||||
- A non-technical consumer ships by declaring intent — no workflow, no config file, no module
|
||||
|
||||
**Key takeaway:** Declare intent; the platform delivers safe production — autonomously, with a complete audit trail.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — Nova owns infrastructure, not your app
|
||||
|
||||
**Talking points:**
|
||||
- The platform is deliberately scoped — it is not trying to be everything
|
||||
- The sovereign boundary: the platform team owns delivery and infrastructure, not the upstream development process
|
||||
- The anti-goals are as important as the goals — they tell leadership what not to expect
|
||||
- Upstream is anything: IDE, agentic SDLC, or vibe coding — Nova doesn't care how the contract was produced
|
||||
|
||||
**Key takeaway:** Nova is infrastructure only. App build/test/deploy is upstream.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — One YAML file. The platform owns everything else.
|
||||
|
||||
**Talking points:**
|
||||
- Hold this slide — emphasize the asymmetry. The consumer's surface is intentionally tiny; the platform's surface is large and opinionated
|
||||
- The contract names three things: module, environment, inputs — that's the entire consumer-facing interface to production
|
||||
- The contract shows infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure
|
||||
- The consumer provides no AWS account, no VPC, no state backend — the platform owns the blast radius
|
||||
|
||||
**Key takeaway:** One YAML file. The platform owns everything else.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Same stages, same checks, every deployment
|
||||
|
||||
**Talking points:**
|
||||
- Walk left to right once — don't dwell on internals; the point is the flow is fixed, opinionated, and identical for every consumer
|
||||
- The two leadership-relevant beats: (1) checks before creation, (2) every stage is evidenced
|
||||
- No team-specific pipelines, no tribal runbooks — the flow is the contract
|
||||
- The confidence signal (Slide 9) is where the "safety is computed" story lands
|
||||
|
||||
**Key takeaway:** Same stages, same checks, every deployment. No "unchecked" path.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — No long-lived credentials. Blast radius contained.
|
||||
|
||||
**Talking points:**
|
||||
- This is the slide for the Head of Cloud/Security — the key phrase is "blast radius contained to the consumer's own stack"
|
||||
- Contrast with the common failure mode of shared CI roles that can touch any account resource
|
||||
- OIDC federation: short-lived token per job, no credential stored in the consumer repo or runner secret
|
||||
- ABAC, not role-based: repo identity + resource tags scope every action — a consumer can only touch its own tagged resources
|
||||
- The static-key override exists for edge cases but is rotated daily on platform runners; it is never the default
|
||||
|
||||
**Key takeaway:** No long-lived credentials. A consumer can only touch its own tagged resources.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Safety is a measurable signal, not a black box
|
||||
|
||||
**Talking points:**
|
||||
- This is the bet that separates this platform from "yet another CI/CD tool" — reliance on operator instinct or tenure is not a substitute
|
||||
- The signal is auditable; the thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream
|
||||
- Six weighted inputs: policy, validation, freshness, provenance, history, NFRs — manually tuned, auditable per-input breakdown
|
||||
- If a consumer asks "why 0.62?", the platform answers with a per-input breakdown — not a black box
|
||||
- A single critical finding hard-blocks — critical findings are not averaged away
|
||||
|
||||
**Key takeaway:** Safety is a measurable, explainable signal — not a black box.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Every change traceable to a human attestation
|
||||
|
||||
**Talking points:**
|
||||
- The "lower environments autonomous, higher environments attested" tenet resolves the classic "move fast vs. be safe" false dichotomy
|
||||
- Be honest: the separation-of-duties *mechanism* is designed and the dev path is wired; qa/prod/dr wiring is on the roadmap
|
||||
- The audit trail is a byproduct of deployment, not a project — every production change is traceable to a human attestation
|
||||
- The full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable
|
||||
- RPO = 0 — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded
|
||||
|
||||
**Key takeaway:** Every change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — The vision realized
|
||||
|
||||
**Talking points:**
|
||||
- Close on the strategic frame — the platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands
|
||||
- Velocity without sacrificing safety: speed is in the ergonomics, safety is in the unbypassable gates
|
||||
- Security, observability, compliance as platform defaults — not per-team effort, not post-hoc remediation
|
||||
- A path to the citizen developer: the same safety envelope serves a senior engineer and a non-technical consumer
|
||||
- Invite questions; the companion deck ("The Developer Experience") covers who uses the platform and how fast/safe they ship
|
||||
|
||||
**Key takeaway:** Ship safely at the pace the business demands, with the security and audit posture the regulators require.
|
||||
|
||||
---
|
||||
|
||||
## Appendix TOC — Appendix
|
||||
|
||||
**Talking points:**
|
||||
- These are deep-dive slides for follow-up questions — don't walk them in the main 15-minute talk
|
||||
- Pull them up when an audience member wants detail on a specific topic
|
||||
- The appendix is indexed to match the Marp deck's A1-A8 structure
|
||||
|
||||
**Key takeaway:** Deep dives available — pull the relevant appendix slide when asked.
|
||||
|
||||
---
|
||||
|
||||
## A1 — Platform-Managed Environments
|
||||
|
||||
**Talking points:**
|
||||
- For the Head of Cloud: this is the governance story — the platform team owns the accounts, the network design, the state hygiene
|
||||
- Consumers can't drift into misconfigured state backends or over-permissioned roles because they never touch them
|
||||
- The onboarding prompt matters — first impressions of a platform are made when it fails for the first time
|
||||
- Self-service environment provisioning is planned
|
||||
|
||||
**Key takeaway:** The consumer never sees raw credentials. The platform owns the blast radius.
|
||||
|
||||
---
|
||||
|
||||
## A2 — Observability Built In
|
||||
|
||||
**Talking points:**
|
||||
- The Head of DevOps cares about this — "you don't deploy a service and *then* remember to set up monitoring; the platform does it as part of the deploy"
|
||||
- Uptime monitoring deployed automatically with every stack — separate state, feature flag to disable
|
||||
- The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly
|
||||
- Deeper observability bootstrap (dashboards, runbooks, on-call bindings) is on the roadmap
|
||||
|
||||
**Key takeaway:** Monitoring is a platform default, not a per-team project.
|
||||
|
||||
---
|
||||
|
||||
## A3 — Security by Construction
|
||||
|
||||
**Talking points:**
|
||||
- The phrase to land is "secure by default, not secure by effort"
|
||||
- The selling point is *normalization* — we can add a new security tool without changing the confidence model or the evidence stream
|
||||
- For the Head of Security: tagging standards are enforced, not advisory — a missing `nova:owner` tag fails the check, not a warning
|
||||
- The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path
|
||||
|
||||
**Key takeaway:** Secure by default, not secure by effort. Checks run before infra is created.
|
||||
|
||||
---
|
||||
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
**Talking points:**
|
||||
- Be clear with leadership: this is a proposed phasing, not a formally committed plan
|
||||
- The phases are sequenced by dependency, not by calendar — each phase's items are gated on the prior phase's maturity
|
||||
- Phase 1 is now fully Verified (22/22) and torn down to zero-cost — it is no longer aspirational
|
||||
- Invite questions on any phase boundary
|
||||
|
||||
**Key takeaway:** Proposed phasing, not formally planned. Phase 1 is Verified; Phase 4 is the North Star.
|
||||
|
||||
---
|
||||
|
||||
## A5 — Testing vs. Planned (Full Inventory)
|
||||
|
||||
**Talking points:**
|
||||
- Close on honesty — the platform delivers real, verifiable value today: 22/22 auto-verifiable capabilities Verified via the v1.11 lifecycle pipeline
|
||||
- The roadmap is concrete, not aspirational hand-waving — 9 planned items, each with a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap)
|
||||
- Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released
|
||||
- The lifecycle pipeline defaults to plan-only on every PR; `NOVA_LIFECYCLE_MODE=full` overrides for milestone verification
|
||||
|
||||
**Key takeaway:** 22/22 Verified today. 9 planned, each with a clear milestone and reason.
|
||||
|
||||
---
|
||||
|
||||
## A6 — Glossary
|
||||
|
||||
**Talking points:**
|
||||
- Use this slide as a reference when the audience asks for term definitions
|
||||
- Don't read it aloud — point to it as a takeaway reference
|
||||
- All acronyms used in the deck are defined here
|
||||
|
||||
**Key takeaway:** Reference slide — don't read aloud.
|
||||
|
||||
---
|
||||
|
||||
## A7 — Operating Model & Cost
|
||||
|
||||
**Talking points:**
|
||||
- The headline for the Head of Cloud / Finance: less than one cent over 8 days of active development; zero BAU cloud spend
|
||||
- The lifecycle pipeline defaults to plan-only so the PR-time cost is zero
|
||||
- The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural
|
||||
- The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation
|
||||
|
||||
**Key takeaway:** Zero BAU cloud cost. Pre-mortemed failure modes with structural mitigations.
|
||||
|
||||
---
|
||||
|
||||
## A8 — Verified by Construction
|
||||
|
||||
**Talking points:**
|
||||
- This is the deep-dive slide for the Head of Engineering / Architecture — the two pillars answer "how do you keep the decks honest?"
|
||||
- The adapter is simple enough to reason about (a stateless assembler); the lifecycle pipeline is the automated verification that backs every "Testing" claim
|
||||
- The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped
|
||||
- The ~80-line stateless adapter + the milestone regression gate are the structural fix
|
||||
- The plan-only default (v1.12) means verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override
|
||||
|
||||
**Key takeaway:** "Verified" is a structural property, not a claim — the stateless adapter + lifecycle pipeline make it so.
|
||||
File diff suppressed because one or more lines are too long
@@ -1,488 +0,0 @@
|
||||
# How The Platform Works
|
||||
|
||||
> **Subtitle:** Nova — The New Dawn of DevSecOps
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~16 minutes · 11 main + Appendix TOC + 8 appendix = 20 slides
|
||||
> **Purpose:** Sell the platform's value to tech leadership — zero-trust, security, observability, auditability, and the shift from "operators guess" to "the platform computes safety."
|
||||
> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap, not yet implemented. "Agentic" = involves AI agents or autonomous decision-making.
|
||||
> **Re-verification (2026-07-29):** Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. **22/22 auto-verifiable capabilities Verified** (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed; CAP-017/018 probe bugs fixed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See `.ciagent/CAPABILITY_INVENTORY.md` and `.ciagent/PRE_MORTEM.md`.
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Title
|
||||
|
||||
# How The Platform Works
|
||||
|
||||
### Nova — The New Dawn of DevSecOps
|
||||
|
||||
**Security as a seamless enabler of fast deployments — not a bottleneck, not a "no" department.**
|
||||
|
||||
> **Speaker notes:** Brief introduction — this deck explains *how* the platform works internally, not what the developer experience is (that's the companion deck). Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Four frictions slow every team
|
||||
|
||||
Most teams can write code; far fewer get the infrastructure right. Delivery scales with the **coordination surface around it**, not the engineering inside it.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph ROW1 [" "]
|
||||
direction LR
|
||||
A["Cognitive load\nauthoring infra correctly"]
|
||||
B["Operational work\nmerged → running"]
|
||||
end
|
||||
subgraph ROW2 [" "]
|
||||
direction LR
|
||||
C["Red tape\ntickets, approvals, handoffs"]
|
||||
D["Scalability\nthroughput without headcount"]
|
||||
end
|
||||
A ~~~ B
|
||||
C ~~~ D
|
||||
A ~~~ C
|
||||
B ~~~ D
|
||||
```
|
||||
|
||||
- **Cognitive load** — the long tail of services, inconsistent in security and observability.
|
||||
- **Operational work** — manual promotion that scales with the system, not the change.
|
||||
- **Red tape** — tickets and handoffs that scale with the organization.
|
||||
- **Scalability** — throughput without linearly scaling platform engineers.
|
||||
|
||||
> **Speaker notes:** Open with the cost of the status quo. Every team that stands up its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business. The platform absorbs all four frictions — that is the value proposition in one sentence.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
One picture of the whole platform — the components, how they connect, and where the boundaries are. The rest of this deck zooms into each piece.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph UP ["Consumer surfaces — upstream"]
|
||||
direction LR
|
||||
U1["Technical dev\napp code + contract"]
|
||||
U2["Citizen dev\nintent → AI agent → contract"]
|
||||
end
|
||||
|
||||
subgraph ACDL ["Nova — infrastructure only"]
|
||||
direction TB
|
||||
CS["Contract schema\n(validate + fail-fast)"]
|
||||
subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
|
||||
direction LR
|
||||
P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
|
||||
end
|
||||
CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
|
||||
ADAPT["Engine adapter\n(stateless → Terraform)"]
|
||||
ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
|
||||
HITL["HITL gates\nqa · prod · dr"]
|
||||
EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
|
||||
CS --> PIPE
|
||||
CAT --> P2
|
||||
ADAPT --> P4
|
||||
ADAPT --> P8
|
||||
ENV --> P8
|
||||
P6 --> HITL
|
||||
HITL --> P8
|
||||
P7 --> EVID
|
||||
end
|
||||
|
||||
subgraph DOWN ["Downstream"]
|
||||
direction LR
|
||||
D1["AWS resources\nrunning\n(tagged, encrypted)"]
|
||||
D2["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
|
||||
U1 --> CS
|
||||
U2 --> CS
|
||||
P8 --> D1
|
||||
D1 --> D2
|
||||
```
|
||||
|
||||
- **Consumer surfaces** — technical dev or citizen dev; both produce a contract. Upstream is anything.
|
||||
- **Contract schema** — the boundary between upstream and Nova; validated fail-fast.
|
||||
- **Central pipeline** — fixed stages, identical for every deployment: validate → resolve → security → plan → policy → confidence → evidence → apply.
|
||||
- **Module catalog** — security-reviewed primitives + modules the resolver expands against.
|
||||
- **Engine adapter** — stateless; the only engine-specific code (Terraform today).
|
||||
- **Platform-managed environments** — account, VPC, state, IAM role; the platform owns the blast radius.
|
||||
- **HITL gates** — human attestation for qa/prod/dr; dev is autonomous.
|
||||
- **Evidence stream** — hash-chained outbox, RPO = 0, written by every deployment.
|
||||
|
||||
> **Speaker notes:** This is the one-slide map of the platform. Use it to orient the audience before diving into any single component. The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer — no team-specific pipelines; (3) the engine adapter is the only engine-specific code, which is what makes the catalog and confidence model portable. Don't walk every node; point to the boundaries and say "the rest of this deck zooms into each of these."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Declare intent; the platform delivers safe production
|
||||
|
||||
Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, with a complete audit trail.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph TODAY ["Today"]
|
||||
direction TB
|
||||
A["Merged change"]
|
||||
B["Waits in queue"]
|
||||
C["Ticket + approvals"]
|
||||
D["Manual promotion"]
|
||||
A --> B --> C --> D
|
||||
end
|
||||
subgraph ACDL ["With Nova"]
|
||||
direction TB
|
||||
E["Declare intent\n(one YAML contract)"]
|
||||
F["Platform delivers\nsafely, autonomously"]
|
||||
G["Traceable to\nhuman attestation"]
|
||||
E --> F --> G
|
||||
end
|
||||
TODAY -.before.-> ACDL
|
||||
```
|
||||
|
||||
- A merged change progresses **without a platform engineer joining a thread.**
|
||||
- A **non-technical consumer** ships by declaring intent — no workflow, no config file, no module.
|
||||
- Every production change is **traceable to a human attestation** and an immutable evidence stream.
|
||||
|
||||
> **Speaker notes:** Land the before/after contrast: today's queue vs. Nova's autonomous flow. The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision. The North Star is "declare intent → safe production deployment."
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — Nova owns infrastructure, not your app
|
||||
|
||||
The platform is deliberately scoped — it is not trying to be everything.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph UP ["Upstream — anything"]
|
||||
direction TB
|
||||
A["IDE / IDE + AI\n(dev writes contract)"]
|
||||
B["Agentic SDLC\n(agent writes contract)"]
|
||||
C["Citizen dev\n(vibe codes → AI agent\n→ contract)"]
|
||||
end
|
||||
subgraph ACDL ["Nova — infrastructure only"]
|
||||
D["Contract\nvalidated"]
|
||||
E["Resolve → Plan\nSecurity + Policy checks\nConfidence signal"]
|
||||
F["Provision\nAWS resources"]
|
||||
G["Evidence\nhash-chained"]
|
||||
end
|
||||
subgraph DOWN ["Downstream"]
|
||||
H["AWS resources\nrunning"]
|
||||
I["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
A --> D
|
||||
B --> D
|
||||
C --> D
|
||||
D --> E
|
||||
E --> F
|
||||
E --> G
|
||||
F --> H
|
||||
H --> I
|
||||
```
|
||||
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. Nova doesn't care how the contract was produced.
|
||||
- **Nova is infrastructure only** — it provisions and governs AWS resources. App build/test/deploy is upstream.
|
||||
- **Not a general-purpose AI** — autonomy is narrow, scoped to delivery, bounded by strict policy.
|
||||
- **Not a permissive highway** — no escape hatches to bypass the confidence framework.
|
||||
|
||||
> **Speaker notes:** The sovereign boundary means the platform team owns delivery and infrastructure, not the upstream development process. The anti-goals are as important as the goals: they tell leadership what not to expect.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — One YAML file. The platform owns everything else.
|
||||
|
||||
The contract is the boundary between upstream and Nova. It's all a consumer writes.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Consumer<br/>writes a contract"] --> B["Platform resolves,<br/>compiles, checks,<br/>deploys, records"]
|
||||
B --> C["Resources running in AWS<br/>+ tamper-evident evidence"]
|
||||
```
|
||||
|
||||
- **Which module** — a catalog of pre-built, security-reviewed building blocks.
|
||||
- **Which environment** — `dev`, `qa`, `prod`, or `dr`. The bar rises automatically with sensitivity.
|
||||
- **Which inputs** — infrastructure values that vary per deployment (cpu, memory, port, desired_count).
|
||||
- The consumer provides **no AWS account, no VPC, no state backend** — the platform owns the blast radius.
|
||||
|
||||
> **Speaker notes:** Emphasize the asymmetry. The consumer's surface is intentionally tiny — a contract that fits on one screen. The platform's surface is large and opinionated. The contract examples show infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Same stages, same checks, every deployment
|
||||
|
||||
Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["Consumer contract<br/>(module + environment + inputs)"] --> B["Validate contract<br/>against the schema"]
|
||||
B --> C["Resolve to a target stack<br/>(expand the module's pattern)"]
|
||||
C --> D["Security checks<br/>(before any infra is created)"]
|
||||
D --> E["Infrastructure plan<br/>(platform compiles the stack)"]
|
||||
E --> F["Policy checks<br/>(normalized results)"]
|
||||
F --> G["Confidence signal<br/>(6 inputs → score + band)"]
|
||||
G --> H["Evidence event<br/>(hash-chained, tamper-evident)"]
|
||||
H --> I["Infrastructure apply<br/>(dev only — higher envs hold for attestation)"]
|
||||
```
|
||||
|
||||
- **Security and policy checks run *before* any infrastructure is created** — not as a post-deployment audit.
|
||||
- **Every stage produces a record** that feeds the confidence signal and the evidence stream. No "unchecked" path.
|
||||
|
||||
> **Speaker notes:** Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats: (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 9) is where the "safety is computed" story lands.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — No long-lived credentials. Blast radius contained.
|
||||
|
||||
Consumer repositories hold **no long-lived cloud credentials.** Ever.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Consumer repo\n(no credentials)"]
|
||||
B["OIDC federation\nshort-lived token"]
|
||||
C["ABAC session policy\nrepo identity + tags"]
|
||||
D["Tagged resources\nonly"]
|
||||
A --> B --> C --> D
|
||||
```
|
||||
|
||||
- **Authentication — OIDC federation.** Each job mints a short-lived token; no credential stored in the consumer repo or runner secret. <span class="badge planned">Planned: all runners</span>
|
||||
- **Authorization — attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
|
||||
- **Repository identity** — trust policy binds to the exact consumer repo + branch.
|
||||
- **Resource tags** — every resource tagged `nova:owner` + `nova:contract`; session policy grants access **only to matching tags.**
|
||||
- **The effect:** a consumer can only touch the resources it created. One consumer can never affect another.
|
||||
|
||||
> **Speaker notes:** This is the slide for the Head of Cloud/Security. The key phrase is "blast radius contained to the consumer's own stack." Contrast with the common failure mode of shared CI roles that can touch any account resource. The static-key override exists for edge cases but is rotated daily on platform runners; it is never the default.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Safety is a measurable signal, not a black box
|
||||
|
||||
Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["Policy"] --> S["Score"]
|
||||
V["Validation"] --> S
|
||||
F["Freshness"] --> S
|
||||
Pr["Provenance"] --> S
|
||||
H["History"] --> S
|
||||
N["NFRs"] --> S
|
||||
S --> B["Band + threshold"]
|
||||
```
|
||||
|
||||
- **Six weighted inputs** — policy, validation, freshness, provenance, history, NFRs. Manually tuned, auditable. If a consumer asks "why 0.62?", the platform answers with a per-input breakdown.
|
||||
- **Per-environment thresholds** that rise with sensitivity:
|
||||
|
||||
| Environment | Threshold | Attester |
|
||||
|---|---|---|
|
||||
| dev | ≥ 0.50 | No one — autonomous |
|
||||
| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
|
||||
| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |
|
||||
|
||||
- **A single critical finding hard-blocks** — critical findings are not averaged away.
|
||||
|
||||
> **Speaker notes:** This is the bet that separates this platform from "yet another CI/CD tool." Reliance on operator instinct or tenure is not a substitute. The signal is auditable; the thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream. Leadership cares because it makes promotion decisions *reviewable*.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Every change traceable to a human attestation
|
||||
|
||||
Computed safety handles the gate. Humans still matter — here's how accountability works.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph DEV ["dev — autonomous"]
|
||||
D1["Confidence ≥ 0.50\n→ apply"]
|
||||
end
|
||||
subgraph GATED ["qa / prod / dr — gated"]
|
||||
G1["Confidence ≥ threshold"]
|
||||
G2["Human attestation\nreviews contract\n+ plan + evidence"]
|
||||
G3["Separation of duties\nQA ≠ prod approver"]
|
||||
G1 --> G2 --> G3
|
||||
end
|
||||
DEV --> OUT["Hash-chained\nevidence event\n(RPO = 0)"]
|
||||
GATED --> OUT
|
||||
```
|
||||
|
||||
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate.
|
||||
- **qa, prod, dr require human attestation** — the approver reviews contract, planned Terraform, and accumulated evidence. <span class="badge planned">Planned</span>
|
||||
- **Separation of duties is enforced** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** <span class="badge planned">Planned</span>
|
||||
- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0.**
|
||||
|
||||
> **Speaker notes:** The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the separation-of-duties *mechanism* is designed and the dev path is wired; qa/prod/dr wiring is on the roadmap. The audit trail is a byproduct of deployment, not a project. The full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — The vision realized
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics; safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
|
||||
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
|
||||
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer.
|
||||
|
||||
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it's the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. The investment is in the abstraction, not the tool.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Table of Contents
|
||||
|
||||
For deep dives — these slides cover details omitted from the main 10.
|
||||
|
||||
**Contents:**
|
||||
|
||||
1. Platform-Managed Environments (detail)
|
||||
2. Observability Built In (detail)
|
||||
3. Security by Construction (the full defaults inventory)
|
||||
4. The Road to the North Star (phased roadmap)
|
||||
5. Testing vs. Planned (full inventory)
|
||||
6. Glossary
|
||||
7. Operating Model & Cost (real AWS spend + pre-mortem)
|
||||
8. Verified by Construction (the v1.11 architecture)
|
||||
|
||||
> **Speaker notes:** These are deep-dive slides for follow-up questions. Don't walk them in the main 15-minute talk — pull them up when an audience member wants detail on a specific topic.
|
||||
|
||||
---
|
||||
|
||||
## A1 — Platform-Managed Environments
|
||||
|
||||
A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.
|
||||
|
||||
A named environment is a platform-owned bundle of:
|
||||
|
||||
- An AWS account (or a scoped partition of one).
|
||||
- A network (VPC + subnets).
|
||||
- A state backend (S3 + DynamoDB for infrastructure state + locking).
|
||||
- An IAM role surfaced to the consumer via ABAC, scoped to the consumer's repository identity and resource tags.
|
||||
|
||||
The consumer selects an environment **by name** in their contract (`environment: dev`). The platform resolves the name to the underlying account/network/state/role at run time. **The consumer never sees the raw credentials.**
|
||||
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure) telling the consumer what the platform will provision and how to request it. *(Testing.)* **Self-service environment provisioning is planned.**
|
||||
|
||||
> **Speaker notes:** For the Head of Cloud: this is the governance story. The platform team owns the accounts, the network design, the state hygiene. Consumers can't drift into misconfigured state backends or over-permissioned roles because they never touch them. The onboarding prompt matters — first impressions of a platform are made when it fails for the first time.
|
||||
|
||||
---
|
||||
|
||||
## A2 — Observability Built In
|
||||
|
||||
Monitoring is **a platform default, not a per-team project.** *(Testing.)*
|
||||
|
||||
- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance (Uptime-kuma on ECS Fargate) is provisioned after any module deploy, in a separate state, with a feature flag to disable.
|
||||
- **Monitored endpoints passed from the deployment's own outputs** — the platform constructs a synthetic monitoring contract from what was just deployed. No manual endpoint registration.
|
||||
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues. *(Testing.)*
|
||||
- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it.
|
||||
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr. *(Planned.)*
|
||||
|
||||
> **Speaker notes:** The Head of DevOps cares about this. The framing: "you don't deploy a service and *then* remember to set up monitoring — the platform does it as part of the deploy." The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly.
|
||||
|
||||
---
|
||||
|
||||
## A3 — Security by Construction
|
||||
|
||||
Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them. *(Testing.)*
|
||||
|
||||
- **Infrastructure-as-code policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS key references, **required tagging standards** (`nova:owner`, `nova:contract`, `nova:environment`, `nova:cost-center`). All run *before* infra is created.
|
||||
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record. *(Adapter testing; activates when a Wiz tenant is configured.)*
|
||||
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler roadmap item. *(Adapter testing; inactive for Terraform-only stacks.)*
|
||||
- **Encryption on every resource** — at-rest encryption is on by default for every primitive (S3, RDS, ECR, ECS, and more). *(Testing.)*
|
||||
- **Per-stack customer-managed keys (CMKs)** — one key per deployment, 90-day rotation at creation, **no shared keys across stacks.** *(Testing.)*
|
||||
- **Managed-key fallback with a loud warning** — standalone primitives fall back to cloud-managed keys only when no CMK is provided, and the platform warns explicitly. *(Testing.)*
|
||||
- **Deletion protection on by default** — every resource has `prevent_destroy` on unless a consumer explicitly disables it via a documented feature flag. *(Testing.)*
|
||||
- **Safe decommission** — a 2-step pipeline (disable protection → zero counts → destroy) with **two SRE human-attestation gates** and a **change-request validated against the platform CMDB** before any destructive action. *(Testing.)* Encryption keys enter a grace window (default 30 days) so encrypted data remains recoverable during decommission.
|
||||
|
||||
> **Speaker notes:** The phrase to land is "secure by default, not secure by effort." The selling point is *normalization* — we can add a new security tool without changing the confidence model or the evidence stream. For the Head of Security: tagging standards are enforced, not advisory — a missing `nova:owner` tag fails the check, not a warning. The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path, not a lock with no key.
|
||||
|
||||
---
|
||||
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
A phased roadmap from the current Testing baseline to the full North Star:
|
||||
|
||||
- **Phase 1 — Testing baseline (current, v1.12):** contract-driven deploys, zero-trust OIDC + ABAC on GitHub Actions, confidence signal gating, hash-chained evidence, encryption by default, deletion protection + safe decommission, uptime monitoring, platform-managed environments. **22/22 capabilities Verified** via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS, then torn down to zero-cost). The stateless adapter + lifecycle pipeline are the structural verification (see A8).
|
||||
- **Phase 2 — Production readiness:** HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger (S3 Object Lock + JWS signatures + daily checkpoints), environment self-service.
|
||||
- **Phase 3 — Compliance & expansion:** compliance milestone (GDPR, SOX, SOC2, DORA extension points), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap.
|
||||
- **Phase 4 — Agentic frontier:** dynamic module creation from a contract (the agentic citizen-developer composition mechanism), pattern recognition that compounds value over time.
|
||||
|
||||
> **Speaker notes:** Be clear with leadership: this is a proposed phasing, not a formally committed plan. The phases are sequenced by dependency, not by calendar — each phase's items are gated on the prior phase's maturity. Phase 1 is now fully Verified (22/22) and torn down to zero-cost — it is no longer aspirational. Invite questions on any phase boundary.
|
||||
|
||||
---
|
||||
|
||||
## A5 — Testing vs. Planned (Full Inventory)
|
||||
|
||||
> **Verification status (v1.12, 2026-07-29):** 22/22 auto-verifiable capabilities **Verified** — the v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS for every L1 + L2 module, then tore down to zero-cost (D-096). The v1.10 "6 deploy-unverified (IAM drift)" status is closed (CAP-013 fixed in P67). See `CAPABILITY_INVENTORY.md`.
|
||||
|
||||
**Testing** (works internally, dev pilot-ready — 22/22 Verified via lifecycle pipeline + regression gate):
|
||||
|
||||
- Contract-driven deploys with a versioned reusable workflow.
|
||||
- Module catalog (primitives + modules) with validated examples.
|
||||
- Zero-trust OIDC + ABAC on GitHub Actions runners.
|
||||
- Security + policy checks before infra creation (Checkov; Wiz + Kyverno adapters ready).
|
||||
- Confidence signal (6 inputs, per-env thresholds) gating promotion. *(Agentic.)*
|
||||
- Hash-chained, tamper-evident evidence outbox (RPO = 0).
|
||||
- Encryption by default + per-stack customer-managed keys.
|
||||
- Deletion protection by default + safe decommission with SRE gates + CMDB validation.
|
||||
- Uptime monitoring deployed automatically with every stack.
|
||||
- Platform-managed environments + friendly onboarding.
|
||||
- Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion (GitHub + Gitea).
|
||||
|
||||
**Planned** (on the roadmap, not yet implemented) — 9 capabilities:
|
||||
|
||||
- Real OIDC federation on all platform runners (Gitea Actions OIDC pending an upstream merge).
|
||||
- HITL wiring for qa / prod / dr environments (design shipped; wiring is next).
|
||||
- Full regulatory ledger: S3 Object Lock (7-yr compliance mode) + JWS detached signatures + daily checkpoints.
|
||||
- Compliance milestone: per-module extension points for GDPR, SOX, SOC2, DORA.
|
||||
- Environment self-service (a consumer-facing flow to request and provision a new environment).
|
||||
- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism). *(Agentic.)*
|
||||
- Pattern recognition compounds value over time. *(Agentic.)*
|
||||
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs).
|
||||
- Deeper observability bootstrap (dashboards, runbooks, on-call bindings).
|
||||
|
||||
> **Speaker notes:** Close on honesty. The platform delivers real, verifiable value today — 22/22 auto-verifiable capabilities are Verified via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS) + the D-091 regression gate. The roadmap is concrete, not aspirational hand-waving — 9 planned items, each with a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap). Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released. The lifecycle pipeline defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); a CI variable (`NOVA_LIFECYCLE_MODE=full`) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
|
||||
---
|
||||
|
||||
## A6 — Glossary
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
|
||||
|
||||
> **Speaker notes:** Use this slide as a reference when the audience asks for term definitions. Don't read it aloud — point to it as a takeaway reference.
|
||||
|
||||
---
|
||||
|
||||
## A7 — Operating Model & Cost (real AWS spend + pre-mortem)
|
||||
|
||||
Nova runs at **zero cloud cost** for day-to-day development. The v1.0→v1.10 AWS spend was measured directly via Cost Explorer (`COST.md`, 2026-07-28):
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Total spend (8 days) | **$0.001883** |
|
||||
| Daily average | $0.000235 |
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867 — v1.10 regression + verify run) |
|
||||
|
||||
- **S3 dominates** (98.8%, terraform state bucket) — no compute (ECS/Lambda) ran because v1.0→v1.10 was plan-only for IAM-gated capabilities.
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB. *(Testing.)*
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost steady state (D-096 — teardown mandatory before milestone COMPLETE; no merge to main until `terraform show` confirms no resources). The lifecycle pipeline now **defaults to plan-only** on every PR (fast, no AWS mutation, no cost); a CI variable (`NOVA_LIFECYCLE_MODE=full`) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). Any cost spike > $1/day is an anomaly.
|
||||
|
||||
**Pre-mortem (`PRE_MORTEM.md`):** the project's failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects across 8 NFR-patch phases — decks advertised capability that wasn't reproducible) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations: (FM-1) IAM-drift recurrence → IAM policy baseline is regression-tested; (FM-2) cost spike from un-torn-down stacks → D-096 mandatory teardown; (FM-3) deck overstates capability → verified-only claims + decks unfrozen only after re-verification; (FM-4) pilot contract gap → honest scope (microservice + static-assets today; the L2 pattern is extensible). All mitigations are structural, not procedural.
|
||||
|
||||
> **Speaker notes:** This is the slide for the Head of Cloud / Finance. The headline: less than one cent over 8 days of active development; zero BAU cloud spend; the lifecycle pipeline defaults to plan-only so the PR-time cost is zero. The pre-mortem is the credibility slide — we have already asked "how does this fail?" and the mitigations are structural (regression-tested baselines, mandatory teardown, verified-only deck claims). The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation.
|
||||
|
||||
---
|
||||
|
||||
## A8 — Verified by Construction (the v1.11 architecture)
|
||||
|
||||
v1.11 rebuilt the platform on two architectural pillars that make "Verified" a structural property, not a claim:
|
||||
|
||||
- **The stateless adapter (REQ-123, 918 → ~80 lines).** The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line **stateless assembler**: it owns no module content — no resource shape, no nested HCL blocks, no defaults, no type-specific logic. Each L1 module ships a real `terraform/` module dir owning its resource shape, nested blocks, and defaults (centralized in `locals.tf`). The adapter reads the registry and emits `module "x" { source = ... }` blocks. No type-specific logic in the adapter means a new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect where multi-resource L1s — ecs-service, alb — produced invalid Terraform; CAP-013 now Verified.)*
|
||||
- **Pipeline-driven lifecycle testing (REQ-127/128).** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's `examples/{simple,complex}.yml` contracts through apply→modify→destroy against live AWS. No per-module Python. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `NOVA_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12.
|
||||
|
||||
> **Speaker notes:** This is the deep-dive slide for the Head of Engineering / Architecture. The two pillars are the answer to "how do you keep the decks honest?" The adapter is simple enough to reason about (a stateless assembler), and the lifecycle pipeline is the automated verification that backs every "Testing" claim. The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped. The ~80-line stateless adapter + the milestone regression gate are the structural fix. The plan-only default (v1.12) means this verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override.
|
||||
@@ -0,0 +1,324 @@
|
||||
---
|
||||
marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: 'Nova — The No-Humans Infrastructure Platform'
|
||||
footer: 'Act %{page}/5 — v1.17'
|
||||
style: |
|
||||
section { font-size: 0.85em; }
|
||||
h1 { color: #1a1a2e; }
|
||||
h2 { color: #16213e; }
|
||||
table { font-size: 0.75em; }
|
||||
.badge { padding: 2px 8px; border-radius: 3px; font-size: 0.8em; }
|
||||
.badge.planned { background: #fff3cd; color: #856404; }
|
||||
section.title { background: #1a1a2e; color: white; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Nova — The No-Humans Infrastructure Platform
|
||||
|
||||
**Shifting from Operational Overhead to Strategic Value**
|
||||
|
||||
v1.17 — Strategic Direction, Leadership Metrics & Unified Story
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
<!-- _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.
|
||||
@@ -0,0 +1,113 @@
|
||||
# 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
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,417 @@
|
||||
# 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).
|
||||
@@ -1,321 +0,0 @@
|
||||
---
|
||||
marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "The Developer Experience"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
|
||||
font-size: 26px;
|
||||
color: #1B1B1B;
|
||||
}
|
||||
h1 { color: #D6002A; font-size: 40px; margin-bottom: 0.3em; }
|
||||
h2 { color: #D6002A; font-size: 32px; margin-bottom: 0.2em; }
|
||||
section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
|
||||
section.title h1 { color: #fff; }
|
||||
table { font-size: 22px; width: 100%; }
|
||||
th { background: #F0F0F0; }
|
||||
blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 24px; }
|
||||
pre { font-size: 16px; line-height: 1.3; }
|
||||
code { font-size: 16px; }
|
||||
img { display: block; margin: 0 auto; max-height: 280px; }
|
||||
.badge {
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 16px; font-weight: 600;
|
||||
}
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# The Developer Experience
|
||||
|
||||
### Nova — The New Dawn of DevSecOps
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
|
||||
section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
|
||||
</style>
|
||||
|
||||
---
|
||||
|
||||
# Two consumer paths, one safety envelope
|
||||
|
||||
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition
|
||||
- **Citizen developer** — declares intent; an AI agent produces a contract that passes the **same** safety envelope
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. Nova doesn't care how the contract was produced
|
||||
- **Nova is infrastructure only** — provisions and governs AWS resources. Application deployment is upstream
|
||||
|
||||
---
|
||||
|
||||
# The platform at a glance
|
||||
|
||||
|
||||
|
||||
- **You own the left edge** — app code and a contract. That is the entire consumer surface
|
||||
- **The platform owns the middle** — pipeline, catalog, adapter, environments, gates, evidence
|
||||
- **Two surfaces, one pipeline, one evidence stream** — senior engineer and citizen dev converge on the same safety envelope
|
||||
- **The bar rises automatically** — confidence signal + HITL gates scale with the target environment, not a ticket
|
||||
|
||||
---
|
||||
|
||||
# Three things. The entire consumer surface.
|
||||
|
||||
<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 38%; margin-left: 20px; margin-bottom: 10px;" />
|
||||
|
||||
- **1. App code** — the consumer's service, at the top level of the repo
|
||||
- **2. A contract** — a single YAML file: id, name, environment, infrastructure
|
||||
|
||||
```yaml
|
||||
id: msvc
|
||||
name: microservice
|
||||
environment: dev
|
||||
infrastructure:
|
||||
microservice:
|
||||
version: "1.0.0"
|
||||
inputs:
|
||||
cpu: 256
|
||||
memory: 512
|
||||
desired_count: 2
|
||||
port: 8080
|
||||
```
|
||||
|
||||
- **3. A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow
|
||||
- The developer does **not**: write modules, clone the platform repo, hold cloud credentials, or maintain a state backend
|
||||
|
||||
---
|
||||
|
||||
# See what the platform does, in real time
|
||||
|
||||
- **Streamed output by default** — the plan, policy results, and each check record flow to stdout
|
||||
- **PR comments after every successful pipeline stage** — always know where you stand
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient signal, or a missing attestation. **Never opaque.**
|
||||
- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store, never to logs
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo
|
||||
|
||||
---
|
||||
|
||||
# Pick from pre-built, security-reviewed blocks
|
||||
|
||||
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS)
|
||||
- **Modules** — composed patterns (static site with CDN + WAF; microservice with VPC + ECS + ALB + ECR)
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml`, validated against the contract schema in CI
|
||||
- **Auto-promotion of patterns** — after 3 observed usages <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
|
||||
# The bar rises automatically with sensitivity
|
||||
|
||||
|
||||
|
||||
| Environment | What the platform adds | Maturity |
|
||||
|---|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | — |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 | <span class="badge planned">Planned</span> |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 | <span class="badge planned">Planned</span> |
|
||||
| dr | SRE human attestation + confidence ≥ 0.95 + DR drill | <span class="badge planned">Planned</span> |
|
||||
|
||||
- **No staging environment** — dev is the only autonomous environment
|
||||
- **Separation of duties** — the QA approver cannot be the prod approver
|
||||
|
||||
---
|
||||
|
||||
# Tearing down is as gated as deploying
|
||||
|
||||
|
||||
|
||||
<style>
|
||||
section { font-size: 22px; }
|
||||
pre { font-size: 13px; line-height: 1.2; }
|
||||
code { font-size: 13px; }
|
||||
</style>
|
||||
|
||||
```yaml
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.12
|
||||
with:
|
||||
contract: .nova/contract.yml
|
||||
mode: decommission
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
- **Validate the change request** — platform queries the CMDB; CR must be `approved` and match the consumer repo
|
||||
- **Two SRE human-attestation gates** — disable protection → SRE approves → zero counts + destroy → second SRE approves
|
||||
- **Per-stack encryption key enters a grace window** (default 30 days) so encrypted data remains recoverable
|
||||
|
||||
---
|
||||
|
||||
# You control when you absorb improvements
|
||||
|
||||
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.12`) — automatically receive patch updates within the line
|
||||
- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH
|
||||
- **Pin to an exact version** for stability, or float on MAJOR only (`@v1`) to absorb new features on your own cadence
|
||||
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates floating tags
|
||||
|
||||
---
|
||||
|
||||
# Fails gracefully, not opaquely
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely:
|
||||
|
||||
1. That no environment is bound to their repo yet
|
||||
2. What the platform will provision on their behalf (account, network, state, role)
|
||||
3. The expected turnaround for the platform team to grant the environment
|
||||
4. How to request an environment
|
||||
|
||||
The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
|
||||
|
||||
<span class="badge planned">Citizen developer onboarding path: planned</span>
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# The desired outcomes
|
||||
|
||||
- **Velocity without sacrificing safety** — speed in ergonomics, safety in unbypassable gates
|
||||
- **Security, observability, compliance as platform defaults** — not per-team effort, not post-hoc remediation
|
||||
- **Auditability as a byproduct, not a project** — every change traceable to a human attestation and a tamper-evident evidence event
|
||||
- **Blast radius contained by design** — OIDC + ABAC, only your own tagged resources
|
||||
- **The bottleneck moves off the platform team's ticket queue** — a merged change progresses without a platform engineer joining a thread
|
||||
- **Infrastructure as a utility, not a craft** — consume, don't maintain
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Appendix
|
||||
|
||||
**Contents:**
|
||||
|
||||
1. The Citizen Developer Experience (full)
|
||||
2. No Platform Code, No Cloning (detail)
|
||||
3. Local Reproducibility (detail)
|
||||
4. The Road to the North Star (phased roadmap)
|
||||
5. Glossary
|
||||
6. Operating Model & Cost
|
||||
7. Verified by Construction
|
||||
|
||||
---
|
||||
|
||||
# A1 — The Citizen Developer Experience
|
||||
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service")
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog**
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
|
||||
- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review)
|
||||
- Agents are **stateless** — all state lives in the platform; the platform trusts and **always verifies**
|
||||
- The agent's trace and submission confidence are captured in the contract for review
|
||||
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span>
|
||||
|
||||
---
|
||||
|
||||
# A2 — No Platform Code, No Cloning
|
||||
|
||||
Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**
|
||||
|
||||
|
||||
|
||||
- The consumer's CI definition is a thin wrapper — one `uses:` line
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace
|
||||
- The platform installs its own runtime dependencies — the consumer installs nothing
|
||||
- When the platform ships a fix, every consumer on a floating tag gets it on their next run
|
||||
|
||||
---
|
||||
|
||||
# A3 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI.
|
||||
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
|
||||
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
|
||||
- `--plan-only` runs through the infrastructure plan without applying
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A4 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# A5 — Glossary
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
|
||||
---
|
||||
|
||||
# A6 — Operating Model & Cost
|
||||
|
||||
<style>
|
||||
section { font-size: 20px; }
|
||||
table { font-size: 18px; }
|
||||
</style>
|
||||
|
||||
Nova runs at **zero cloud cost** for day-to-day development. AWS spend was measured via Cost Explorer (`COST.md`, 2026-07-28):
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Total spend (8 days) | **$0.001883** |
|
||||
| Daily average | $0.000235 |
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867) |
|
||||
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The pipeline now **defaults to plan-only** on every PR; `NOVA_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones.
|
||||
|
||||
**Pre-mortem (`PRE_MORTEM.md`):** the v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A7 — Verified by Construction
|
||||
|
||||
<style>
|
||||
section { font-size: 20px; }
|
||||
</style>
|
||||
|
||||
Two architectural pillars make "Verified" a structural property, not a claim:
|
||||
|
||||
- **The stateless adapter (918 → ~80 lines).** The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line **stateless assembler**: it owns no module content — no resource shape, no nested HCL blocks, no defaults. Each L1 module ships a real `terraform/` module dir owning its shape, nested blocks, and defaults. The adapter reads the registry and emits `module "x" { source = ... }` blocks. A new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)*
|
||||
- **Pipeline-driven lifecycle testing.** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's contracts through apply→modify→destroy against live AWS. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `NOVA_LIFECYCLE_MODE=full` overrides to the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — **22/22 Verified** as of v1.12.
|
||||
|
||||
The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix.
|
||||
@@ -1,253 +0,0 @@
|
||||
# The Developer Experience — Talking Points
|
||||
|
||||
> **Companion to:** `the-developer-experience-marp.md` (11 main + Appendix TOC + 7 appendix = 19 slides)
|
||||
> **Content source:** `the-developer-experience.md` (full source of truth with speaker notes)
|
||||
> **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember.
|
||||
> **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Title
|
||||
|
||||
**Talking points:**
|
||||
- Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck)
|
||||
- Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort
|
||||
- v1.12 re-verification: every "Testing" claim in this deck is now Verified — 22/22 capabilities via the v1.11 lifecycle pipeline (see A7)
|
||||
|
||||
**Key takeaway:** The consumer surface is intentionally tiny. The platform's surface is large and opinionated.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Two consumer paths, one safety envelope
|
||||
|
||||
**Talking points:**
|
||||
- This is the scope-boundary slide — here's who uses the platform, and here's where Nova's responsibility starts and stops
|
||||
- Two consumer paths converge on the same contract: **technical** developer writes the contract directly; **citizen** developer declares intent and an AI agent produces a contract that passes the same safety envelope
|
||||
- Upstream is anything — your IDE, an agentic SDLC, or vibe coding on a laptop. Nova doesn't care how the contract was produced
|
||||
- Nova is infrastructure only — it provisions and governs AWS resources. Application deployment is upstream of the contract
|
||||
- The two surfaces are *parallel*, not a progression. A citizen developer doesn't "graduate" to the developer surface. There is no "citizen developer mode" with weaker checks
|
||||
|
||||
**Key takeaway:** Two consumer paths, one safety envelope. Nova is infra only — anything upstream is fair game.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
**Talking points:**
|
||||
- One-slide map — frame it from the left edge: "this is what you touch, this is what the platform owns for you"
|
||||
- The leadership beat: the convergence — two surfaces, one pipeline, one evidence stream — is the design point that lets us expand who can ship safely without lowering the bar
|
||||
- Don't walk every node — point to the contract boundary and say "the rest of this deck zooms into the developer-facing pieces"
|
||||
- The bar rises automatically — the confidence signal and HITL gates scale with the target environment, not with a ticket
|
||||
|
||||
**Key takeaway:** You own the left edge (app + contract). The platform owns everything else, end to end.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Three things. The entire consumer surface.
|
||||
|
||||
**Talking points:**
|
||||
- Hold this slide — the audience should sit with how small the consumer surface is. Three things: app code, a contract, a one-line CI definition
|
||||
- The contract is a single YAML file: module, environment, inputs. That's the entire consumer-facing interface to production
|
||||
- The contract example shows **infrastructure inputs** (cpu, memory, desired_count, port) — not an `image:` field. The consumer declares capacity and shape; the platform resolves the rest
|
||||
- Walk the "does not" list quickly — no infrastructure modules, no platform repo cloning, no cloud credentials, no state backends. Every item is a category of toil the platform removes
|
||||
- For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue
|
||||
|
||||
**Key takeaway:** Three things. That's the entire consumer-side surface. Everything else is the platform's job.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — See what the platform does, in real time
|
||||
|
||||
**Talking points:**
|
||||
- This directly answers "but developers hate platforms that hide what they're doing" — the platform is opinionated about *what* runs, not *opaque* about *that* it runs
|
||||
- Streamed output by default — the plan, policy results, and each check record flow to stdout
|
||||
- PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard
|
||||
- Connection strings posted as PR comments — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs
|
||||
- The "errors become GitHub issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line
|
||||
- Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise
|
||||
|
||||
**Key takeaway:** The platform closes the feedback loop — streamed output, PR comments, clear halt reasons, no secrets in logs.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Pick from pre-built, security-reviewed blocks
|
||||
|
||||
**Talking points:**
|
||||
- The catalog is what makes "declare intent" practical — you can only declare a module that exists
|
||||
- For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset
|
||||
- Primitives are single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS) — each with documented inputs/outputs and versioning
|
||||
- Modules are composed patterns — a static site with CDN + WAF; a microservice with VPC + ECS + ALB + ECR
|
||||
- Validated examples per module (`simple.yaml` + `complex.yaml`) are validated against the contract schema in CI — examples cannot drift from the schema silently
|
||||
- Auto-promotion of patterns (after 3 observed usages) and compliance extension points (GDPR, SOX, SOC2, DORA) are on the roadmap
|
||||
|
||||
**Key takeaway:** You don't author infrastructure — you pick from pre-built, security-reviewed building blocks. The catalog is the compounding asset.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The bar rises automatically with sensitivity
|
||||
|
||||
**Talking points:**
|
||||
- Promotion is a workflow choice, not a contract edit — a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract
|
||||
- The DX win: the contract stays stable across environments; the safety win: the platform raises the threshold and attestation bar automatically based on the target environment
|
||||
- The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar
|
||||
- No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment
|
||||
- Separation of duties is enforced — the QA approver cannot be the prod approver
|
||||
- Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned
|
||||
|
||||
**Key takeaway:** The bar rises automatically with sensitivity. The consumer picks the environment; the platform applies the right gate.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Tearing down is as gated as deploying
|
||||
|
||||
**Talking points:**
|
||||
- The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`
|
||||
- The CMDB validation means decommission is auditable, not just possible — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo
|
||||
- Two SRE human-attestation gates: disable protection → SRE approves → zero all counts + destroy → a second SRE approves
|
||||
- The per-stack encryption key enters a grace window (default 30 days) so encrypted data remains recoverable during decommission
|
||||
- For the Head of Infrastructure: this is what makes deletion protection safe to ship by default — cleanup is a deliberate, gated path, not an impossible one
|
||||
|
||||
**Key takeaway:** Tearing down is as deliberate as deploying — two SRE attestation gates + CMDB-validated change request.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — You control when you absorb improvements
|
||||
|
||||
**Talking points:**
|
||||
- This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow
|
||||
- Floating MAJOR + MINOR tags (e.g. `@v1.12`) — a consumer automatically receives patch updates within the line
|
||||
- Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
|
||||
- A consumer can pin to an exact version for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence
|
||||
- Unversioned references (`@main`, bare) are discouraged — the versioned tag is the only immutability lever a consumer has
|
||||
- The automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags
|
||||
|
||||
**Key takeaway:** You control when you absorb platform improvements — no surprise upgrades, no forced forks.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Fails gracefully, not opaquely
|
||||
|
||||
**Talking points:**
|
||||
- This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known"
|
||||
- For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around
|
||||
- When no environment is bound, the platform emits a user-friendly onboarding prompt — not an opaque failure
|
||||
- The prompt tells the consumer: no environment bound, what the platform will provision, expected turnaround, how to request an environment
|
||||
- The pipeline then exits without attempting a deployment — no partial state, no confusing errors
|
||||
- The citizen developer onboarding path is planned
|
||||
|
||||
**Key takeaway:** The platform fails gracefully, not opaquely — first impressions are made when it fails for the first time.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — The desired outcomes
|
||||
|
||||
**Talking points:**
|
||||
- Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require
|
||||
- Velocity without sacrificing safety: speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass
|
||||
- Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation
|
||||
- Auditability as a byproduct, not a project — every production change is traceable to a human attestation and a tamper-evident evidence event
|
||||
- The bottleneck moves off the platform team's ticket queue — a merged change progresses through lower environments without a platform engineer joining a thread
|
||||
- A path to the citizen developer: the same safety envelope serves a senior engineer and a non-technical consumer
|
||||
- Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth
|
||||
|
||||
**Key takeaway:** Ship safely at the pace the business demands, with the security and audit posture the regulators require.
|
||||
|
||||
---
|
||||
|
||||
## Appendix TOC — Appendix
|
||||
|
||||
**Talking points:**
|
||||
- These are backup slides for Q&A. Use them when the audience asks for the detail behind a main-slide claim
|
||||
- Don't walk through them in the main talk unless time permits
|
||||
- The appendix is indexed to match the Marp deck's A1-A7 structure
|
||||
|
||||
**Key takeaway:** Backup slides for Q&A — pull the relevant appendix slide when asked.
|
||||
|
||||
---
|
||||
|
||||
## A1 — The Citizen Developer Experience
|
||||
|
||||
**Talking points:**
|
||||
- Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned
|
||||
- The "vibe coding on a laptop" framing is intentional — it meets the citizen developer where they already are, but every submission still passes the same safety envelope
|
||||
- The design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer
|
||||
- Guardrails: skills are versioned, signed, reviewed for sensitive data; agents are stateless; the platform trusts and always verifies
|
||||
- The agent's trace and submission confidence are captured in the contract (`profile: agentic`) for review
|
||||
|
||||
**Key takeaway:** A non-technical consumer ships by declaring intent — same pipeline, same safety envelope, no weaker checks.
|
||||
|
||||
---
|
||||
|
||||
## A2 — No Platform Code, No Cloning
|
||||
|
||||
**Talking points:**
|
||||
- The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem
|
||||
- The version-pinned `uses:` line is the *only* coupling, and it's a coupling that updates itself within the line
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace — the consumer never clones the platform repo
|
||||
- The platform installs its own runtime dependencies — the consumer installs nothing
|
||||
- When the platform ships a fix, every consumer on a floating tag gets it on their next run — no per-repo upgrade project
|
||||
|
||||
**Key takeaway:** The consumer never touches platform internals. The versioned `uses:` line is the only coupling.
|
||||
|
||||
---
|
||||
|
||||
## A3 — Local Reproducibility
|
||||
|
||||
**Talking points:**
|
||||
- This is the "no surprises before you push" story. A consumer can validate their contract offline, run the plan offline, and only push when they're confident
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
|
||||
- `scripts/run_platform.sh --check-only` runs the platform offline — no AWS, no policy engine, no outbox required
|
||||
- The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap
|
||||
|
||||
**Key takeaway:** The entire CI pipeline runs from the shell — no surprises before you push.
|
||||
|
||||
---
|
||||
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
**Talking points:**
|
||||
- This is a proposed phasing, not a formally committed plan — call that out explicitly
|
||||
- Phase 1 is what's tested and Verified today (22/22 capabilities, torn down to zero-cost)
|
||||
- Phase 2 is the next milestone (qa/prod/dr wiring)
|
||||
- Phase 3 introduces the agentic surface (skill catalog + agents)
|
||||
- Phase 4 is the north star: citizen developer GA on the same safety envelope
|
||||
- Use this only when an audience member asks "how do you get from here to there"
|
||||
|
||||
**Key takeaway:** Proposed phasing — Phase 1 Verified, Phase 4 is the North Star (citizen developer GA).
|
||||
|
||||
---
|
||||
|
||||
## A5 — Glossary
|
||||
|
||||
**Talking points:**
|
||||
- Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?"
|
||||
- Don't read it aloud
|
||||
- All acronyms used in the deck are defined here
|
||||
|
||||
**Key takeaway:** Reference slide — don't read aloud.
|
||||
|
||||
---
|
||||
|
||||
## A6 — Operating Model & Cost
|
||||
|
||||
**Talking points:**
|
||||
- The headline for the Head of Cloud / Finance: less than one cent over 8 days of active development; zero BAU cloud spend
|
||||
- The lifecycle pipeline defaults to plan-only so the PR-time cost is zero; `NOVA_LIFECYCLE_MODE=full` overrides for milestone verification
|
||||
- The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural
|
||||
- The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation
|
||||
- Cost drivers are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones
|
||||
|
||||
**Key takeaway:** Zero BAU cloud cost. Pre-mortemed failure modes with structural mitigations.
|
||||
|
||||
---
|
||||
|
||||
## A7 — Verified by Construction
|
||||
|
||||
**Talking points:**
|
||||
- This is the deep-dive slide for the Head of Engineering / Architecture — the two pillars answer "how do you keep the decks honest?"
|
||||
- The adapter is simple enough to reason about (a stateless assembler); the lifecycle pipeline is the automated verification that backs every "Testing" claim
|
||||
- The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped
|
||||
- The ~80-line stateless adapter + the milestone regression gate are the structural fix
|
||||
- The plan-only default (v1.12) means verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override
|
||||
|
||||
**Key takeaway:** "Verified" is a structural property, not a claim — the stateless adapter + lifecycle pipeline make it so.
|
||||
File diff suppressed because one or more lines are too long
@@ -1,457 +0,0 @@
|
||||
# The Developer Experience
|
||||
|
||||
> **Subtitle:** Nova — The New Dawn of DevSecOps
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~16 minutes · 11 main + Appendix TOC + 7 appendix = 19 slides
|
||||
> **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
|
||||
> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap. "Agentic" = involves AI agents or autonomous decision-making.
|
||||
> **Re-verification (2026-07-29):** Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. **22/22 auto-verifiable capabilities Verified** (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See `.ciagent/CAPABILITY_INVENTORY.md` and `.ciagent/PRE_MORTEM.md`.
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Title
|
||||
|
||||
**Nova — The New Dawn of DevSecOps.** Security as a seamless enabler of fast deployments — not a bottleneck, not a "no" department.
|
||||
|
||||
The consumer surface is intentionally tiny. The platform's surface is large and opinionated.
|
||||
|
||||
> **Speaker notes:** Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck). Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Two consumer paths, one safety envelope
|
||||
|
||||
The platform serves **two kinds of consumer** through two coordinated paths — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph UP ["Upstream — anything"]
|
||||
direction TB
|
||||
A["Technical dev\n(app code + contract)"]
|
||||
B["Citizen dev\n(intent → AI agent\n→ contract)"]
|
||||
end
|
||||
subgraph ACDL ["Nova — infrastructure only"]
|
||||
C["Same contract\nSame pipeline\nSame safety"]
|
||||
D["Provision\nAWS resources"]
|
||||
E["Evidence\nhash-chained"]
|
||||
end
|
||||
subgraph DOWN ["Downstream"]
|
||||
F["AWS resources\nrunning"]
|
||||
G["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
A --> C
|
||||
B --> C
|
||||
C --> D
|
||||
C --> E
|
||||
D --> F
|
||||
F --> G
|
||||
```
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition.
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope.
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. Nova doesn't care how the contract was produced.
|
||||
- **Nova is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream.
|
||||
|
||||
> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The scope boundary matters: anything upstream of the contract is out of Nova's concern. The leadership takeaway: we expand who can ship safely without lowering the bar.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
One picture of the whole platform — what you touch, what the platform owns, and where the safety lives. The rest of this deck zooms into the developer-facing pieces.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph UP ["Consumer surfaces — upstream"]
|
||||
direction LR
|
||||
U1["Technical dev\napp code + contract"]
|
||||
U2["Citizen dev\nintent → AI agent → contract"]
|
||||
end
|
||||
|
||||
subgraph ACDL ["Nova — infrastructure only"]
|
||||
direction TB
|
||||
CS["Contract schema\n(validate + fail-fast)"]
|
||||
subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
|
||||
direction LR
|
||||
P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
|
||||
end
|
||||
CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
|
||||
ADAPT["Engine adapter\n(stateless → Terraform)"]
|
||||
ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
|
||||
HITL["HITL gates\nqa · prod · dr"]
|
||||
EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
|
||||
CS --> PIPE
|
||||
CAT --> P2
|
||||
ADAPT --> P4
|
||||
ADAPT --> P8
|
||||
ENV --> P8
|
||||
P6 --> HITL
|
||||
HITL --> P8
|
||||
P7 --> EVID
|
||||
end
|
||||
|
||||
subgraph DOWN ["Downstream"]
|
||||
direction LR
|
||||
D1["AWS resources\nrunning\n(tagged, encrypted)"]
|
||||
D2["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
|
||||
U1 --> CS
|
||||
U2 --> CS
|
||||
P8 --> D1
|
||||
D1 --> D2
|
||||
```
|
||||
|
||||
- **You own the left edge** — app code and a contract. That is the entire consumer surface.
|
||||
- **The platform owns everything in the middle** — the pipeline, the catalog, the adapter, the environments, the gates, the evidence.
|
||||
- **Two surfaces, one pipeline, one evidence stream** — a senior engineer and a citizen developer converge on the same safety envelope.
|
||||
- **The bar rises automatically** — the confidence signal and HITL gates scale with the target environment, not with a ticket.
|
||||
|
||||
> **Speaker notes:** This is the one-slide map. For a developer-experience audience, frame it from the left edge: "this is what you touch, this is what the platform owns for you." The leadership beat: the convergence — two surfaces, one pipeline, one evidence stream — is the design point that lets us expand who can ship safely without lowering the bar. Don't walk every node; point to the contract boundary and say "the rest of this deck zooms into the developer-facing pieces."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Three things. The entire consumer surface.
|
||||
|
||||
Three things. That is the entire consumer-side surface.
|
||||
|
||||
```yaml
|
||||
id: msvc
|
||||
name: microservice
|
||||
environment: dev
|
||||
infrastructure:
|
||||
microservice:
|
||||
version: "1.0.0"
|
||||
inputs:
|
||||
cpu: 256
|
||||
memory: 512
|
||||
desired_count: 2
|
||||
port: 8080
|
||||
```
|
||||
|
||||
1. **App code** — the consumer's service, at the top level of the repo
|
||||
2. **A contract** — a single YAML file: id, name, environment, infrastructure
|
||||
3. **A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow
|
||||
|
||||
The developer does **not**: write infrastructure modules, clone the platform repo, hold cloud credentials, or maintain a state backend.
|
||||
|
||||
> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. The contract is the API — deliberately tiny so that it can be reviewed, validated, and audited. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — See what the platform does, in real time
|
||||
|
||||
Developers see **what the platform is doing**, in real time.
|
||||
|
||||
- **Streamed output by default** — the plan, policy-check results, and each check record flow to stdout.
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand.
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque debugging exercise.**
|
||||
- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs.
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo.
|
||||
|
||||
> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust. The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Pick from pre-built, security-reviewed blocks
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph PRIM ["Primitives"]
|
||||
direction TB
|
||||
P1["S3"]
|
||||
P2["VPC"]
|
||||
P3["ECS"]
|
||||
P4["IAM"]
|
||||
P5["ALB"]
|
||||
P6["ECR"]
|
||||
P7["CloudFront"]
|
||||
P8["WAF"]
|
||||
P9["RDS"]
|
||||
end
|
||||
subgraph MOD ["Modules — composed patterns"]
|
||||
direction TB
|
||||
M1["Static site\nCDN + WAF + S3"]
|
||||
M2["Microservice\nVPC + ECS + ALB + ECR"]
|
||||
end
|
||||
PRIM --> MOD
|
||||
```
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS), each with documented inputs/outputs and versioning.
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + ECR).
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml`, validated against the contract schema in CI. Examples cannot drift from the schema silently.
|
||||
- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages. <span class="badge planned">Planned</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. <span class="badge planned">Planned</span>
|
||||
|
||||
> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — The bar rises automatically with sensitivity
|
||||
|
||||
The contract is environment-agnostic. The platform raises the bar automatically.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DEV["dev<br/>autonomous"] -->|raise the bar| QA["qa<br/>QA attests"]
|
||||
QA -->|raise the bar| PROD["prod<br/>SRE attests"]
|
||||
PROD -->|raise the bar| DR["dr<br/>SRE attests + DR drill"]
|
||||
```
|
||||
|
||||
| Environment | What the platform adds | Maturity |
|
||||
|---|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | — |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 | <span class="badge planned">Planned</span> |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 | <span class="badge planned">Planned</span> |
|
||||
| dr | SRE human attestation + confidence ≥ 0.95 + DR drill reference | <span class="badge planned">Planned</span> |
|
||||
|
||||
- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern.
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver.
|
||||
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
|
||||
|
||||
> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. The DX win: the contract stays stable across environments; the safety win: the platform raises the threshold and attestation bar automatically based on the target environment. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar. Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Tearing down is as gated as deploying
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Validate CR\n(CMDB)"]
|
||||
B["Disable\nprevent_destroy"]
|
||||
C["SRE\napprove"]
|
||||
D["Zero counts\n+ destroy"]
|
||||
E["SRE\napprove"]
|
||||
F["Key enters\ngrace window"]
|
||||
A --> B --> C --> D --> E --> F
|
||||
```
|
||||
|
||||
```yaml
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.12
|
||||
with:
|
||||
contract: .nova/contract.yml
|
||||
mode: decommission
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
A 2-step pipeline with **two SRE human-attestation gates**:
|
||||
|
||||
1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
|
||||
2. **Disable deletion protection** → **SRE approves** → **Zero all counts + destroy** → **a second SRE approves.**
|
||||
|
||||
The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable.
|
||||
|
||||
> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — You control when you absorb improvements
|
||||
|
||||
Consumers control **when** they absorb platform improvements.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph FLOAT ["@v1.12 — floating MAJOR+MINOR"]
|
||||
direction LR
|
||||
F1["v1.12.0"]
|
||||
F2["v1.12.1"]
|
||||
F3["v1.12.2"]
|
||||
F1 --> F2 --> F3
|
||||
end
|
||||
subgraph PIN ["@v1.12.2 — pinned exact"]
|
||||
direction LR
|
||||
P1["v1.12.2"]
|
||||
P2["v1.12.2"]
|
||||
P3["v1.12.2"]
|
||||
P1 --> P2 --> P3
|
||||
end
|
||||
subgraph MAJ ["@v1 — float MAJOR only"]
|
||||
direction LR
|
||||
M1["v1.12.0"]
|
||||
M2["v1.13.0"]
|
||||
M3["v1.14.0"]
|
||||
M1 --> M2 --> M3
|
||||
end
|
||||
```
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.12`) — automatically receive patch updates within the line.
|
||||
- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH.
|
||||
- **Pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on your own cadence.
|
||||
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever.
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags.
|
||||
|
||||
> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Fails gracefully, not opaquely
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely. The prompt tells the consumer:
|
||||
|
||||
1. That no environment is bound to their repo yet.
|
||||
2. What the platform will provision on their behalf (account, network, state, role).
|
||||
3. The expected turnaround for the platform team to grant the environment.
|
||||
4. How to request an environment.
|
||||
|
||||
The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
|
||||
|
||||
<span class="badge planned">Citizen developer onboarding path: planned</span>
|
||||
|
||||
> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — The desired outcomes
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics; safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
|
||||
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread.
|
||||
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
|
||||
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer.
|
||||
|
||||
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Contents
|
||||
|
||||
For deep dives — these slides cover details omitted from the main 10.
|
||||
|
||||
1. **A1 — The Citizen Developer Experience** (full)
|
||||
2. **A2 — No Platform Code, No Cloning** (detail)
|
||||
3. **A3 — Local Reproducibility** (detail)
|
||||
4. **A4 — The Road to the North Star** (phased roadmap)
|
||||
5. **A5 — Glossary**
|
||||
6. **A6 — Operating Model & Cost** (real AWS spend + pre-mortem)
|
||||
7. **A7 — Verified by Construction** (the v1.11 architecture)
|
||||
|
||||
> **Speaker notes:** These are backup slides for Q&A. Use them when the audience asks for the detail behind a main-slide claim. Don't walk through them in the main talk unless time permits.
|
||||
|
||||
---
|
||||
|
||||
## A1 — The Citizen Developer Experience
|
||||
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module. Think of this as **vibe coding on a laptop** — the consumer describes what they want; an AI agent turns that into a contract that the platform treats identically to a senior engineer's.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
|
||||
- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review — it is the mandatory release gate).
|
||||
- Agents are **stateless** — all state lives in the platform. The platform does not run the skill blindly; it trusts and **always verifies** on the platform side.
|
||||
- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see *how* the contract was produced.
|
||||
- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap.
|
||||
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span>
|
||||
|
||||
> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. The "vibe coding on a laptop" framing is intentional — it meets the citizen developer where they already are, but every submission still passes the same safety envelope. The design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.
|
||||
|
||||
---
|
||||
|
||||
## A2 — No Platform Code, No Cloning
|
||||
|
||||
Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Consumer repo<br/>app + contract + 'uses:'"] -->|triggers on push to main| B["Platform runner"]
|
||||
B -->|checks out the consumer repo| A
|
||||
B -->|checks out the Nova platform repo<br/>into the workspace| C["Platform code<br/>(modules, adapters, schemas)"]
|
||||
C --> B
|
||||
B -->|runs the pipeline against<br/>the consumer's contract| D["Consumer's resources in AWS"]
|
||||
```
|
||||
|
||||
- The consumer's CI definition is a thin wrapper — one `uses:` line pointing at a versioned tag.
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace.
|
||||
- The platform installs its own runtime dependencies. The consumer installs nothing.
|
||||
- The consumer **never clones the platform repo, never invokes platform scripts locally** (optional `--check-only` validation is available but not required for the happy path).
|
||||
- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.
|
||||
|
||||
> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the *only* coupling, and it's a coupling that updates itself within the line.
|
||||
|
||||
---
|
||||
|
||||
## A3 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI.
|
||||
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence.
|
||||
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing.
|
||||
- `--plan-only` runs through the infrastructure plan without applying.
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement.
|
||||
|
||||
> **Speaker notes:** This is the "no surprises before you push" story. A consumer can validate their contract offline, run the plan offline, and only push when they're confident. The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap.
|
||||
|
||||
---
|
||||
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P1["Phase 1<br/>Core platform<br/>(22/22 Verified)"] --> P2["Phase 2<br/>Safe promotion<br/>qa/prod/dr wiring"]
|
||||
P2 --> P3["Phase 3<br/>Agentic surface<br/>(skill catalog + agents)"]
|
||||
P3 --> P4["Phase 4<br/>North star<br/>citizen developer GA"]
|
||||
```
|
||||
|
||||
> **Speaker notes:** This is a proposed phasing, not a formally committed plan — call that out explicitly. Phase 1 is what's tested and Verified today (22/22 capabilities, torn down to zero-cost). Phase 2 is the next milestone (qa/prod/dr wiring). Phase 3 introduces the agentic surface. Phase 4 is the north star: citizen developer GA on the same safety envelope. Use this only when an audience member asks "how do you get from here to there."
|
||||
|
||||
---
|
||||
|
||||
## A5 — Glossary
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
|
||||
> **Speaker notes:** Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" Don't read it aloud.
|
||||
|
||||
---
|
||||
|
||||
## A6 — Operating Model & Cost
|
||||
|
||||
Nova runs at **zero cloud cost** for day-to-day development. The v1.0→v1.10 AWS spend was measured directly via Cost Explorer (`COST.md`, 2026-07-28):
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Total spend (8 days) | **$0.001883** |
|
||||
| Daily average | $0.000235 |
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867 — v1.10 regression + verify run) |
|
||||
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB.
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost steady state (D-096 — teardown mandatory before milestone COMPLETE). The lifecycle pipeline now **defaults to plan-only** on every PR (fast, no AWS mutation, no cost); a CI variable (`NOVA_LIFECYCLE_MODE=full`) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones.
|
||||
|
||||
**Pre-mortem (`PRE_MORTEM.md`):** the project's failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects — decks advertised capability that wasn't reproducible) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope).
|
||||
|
||||
> **Speaker notes:** The headline for the Head of Cloud / Finance: less than one cent over 8 days of active development; zero BAU cloud spend; the lifecycle pipeline defaults to plan-only so the PR-time cost is zero. The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural.
|
||||
|
||||
---
|
||||
|
||||
## A7 — Verified by Construction (the v1.11 architecture)
|
||||
|
||||
v1.11 rebuilt the platform on two architectural pillars that make "Verified" a structural property, not a claim:
|
||||
|
||||
- **The stateless adapter (918 → ~80 lines).** The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line **stateless assembler**: it owns no module content. Each L1 module ships a real `terraform/` module dir owning its resource shape, nested blocks, and defaults. A new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)*
|
||||
- **Pipeline-driven lifecycle testing.** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's contracts through apply→modify→destroy against live AWS. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `NOVA_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12.
|
||||
|
||||
> **Speaker notes:** This is the deep-dive slide for the Head of Engineering / Architecture. The two pillars answer "how do you keep the decks honest?" The adapter is simple enough to reason about (a stateless assembler); the lifecycle pipeline is the automated verification that backs every "Testing" claim. The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix. The plan-only default (v1.12) means verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override.
|
||||
Reference in New Issue
Block a user