Jon Chery
eb7634da28
v1.15-Nova rebrand doc verification (phase/05-final-review-ship) found stale ACDL references where the code/terraform already uses Nova names. Critical drift fixed (doc said old name; code uses new): - README.md: `.acdl/contract.yml` -> `.nova/contract.yml`; `acdl-spike-runner` -> `nova-spike-runner`; ABAC tag keys `acdl:owner|contract` -> `nova:owner|contract`. - docs/environments/index.md: `acdl-contract-ingestor` -> `nova-contract-ingestor`; `aws:PrincipalTag/acdl:owner` -> `nova:owner`; `acdl-contracts` -> `nova-contracts`. - docs/consumer-guide.md: `acdl-change-requests` -> `nova-change-requests`; state bucket example `acdl-qa-state` -> `nova-qa-state`. - docs/presentations/* (4 decks + 2 HTML + talking-points): `acdl:owner|contract| environment|cost-center` -> `nova:*`; `ACDL_LIFECYCLE_MODE` -> `NOVA_LIFECYCLE_MODE`. - pipelines/modules-lifecycle.yml comments: `ACDL_LIFECYCLE_MODE` -> `NOVA_LIFECYCLE_MODE` (workflows already use NOVA_; the contract comments were stale). - docs/NOVA_MIGRATION.md: status banner -> COMPLETE (P5 cutoff passed). - .ciagent/ARCHITECTURE.md: header `ACDL` -> `Nova`; NOVA_LIFECYCLE_MODE rename noted in the live lifecycle-mode section (v1.15 addendum already correct). - .ciagent/ROADMAP.md: v1.15 phase statuses P1-P4 pending -> complete (v1.15.1..v1.15.4); P5 -> in progress (phase/05-final-review-ship). Verification: - grep for `acdl:*` tag keys / `.acdl/contract` / `acdl-contract-ingestor` / `acdl-contracts` / `ACDL_LIFECYCLE_MODE` in README/docs/pipelines -> 0 hits (excluding explicitly-unchanged repo path `acdl/.github/...`, `continuous-intelligence/acdl`, and historical narrative). - core/output_publisher.py uses `/nova`; schemas/tagging-standard.json uses `nova:*`; terraform uses `nova-*` (0 `acdl-` in *.tf) — docs now match. - git tag v1.15.0..v1.15.4 exist. - pytest tests/test_lifecycle_mode_flag.py tests/test_pipeline_contract.py -> 111 passed. ---ci--- project: acdl
248 lines
13 KiB
Markdown
248 lines
13 KiB
Markdown
# 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. |