General portal demo — 10-min script

Customer-facing demo script for the SARC compliance pipeline. Structured as 15 slide equivalents with minute-precise timings. Operators can paste each slide’s bullets into PowerPoint or use this file directly as speaker notes.

Target audience: one enterprise customer — technical sponsor plus two or three compliance or platform stakeholders. Total runtime: 15 minutes plus 10 minutes of Q&A.

This script is about what the customer hears. For the operator-side setup, contact the engagement team.

Slide 1 — The 30-second pitch

Minute 0–1.

• SARC is a working compliance pipeline that replaces manual CAB boards with an enforcing, audit-trailed GitOps flow.
• One repo, one pipeline, three CI platforms (GitLab, GitHub Actions, Azure DevOps), four clouds (AWS, Azure, GCP, local k3d).
• Three things enforced automatically, zero manual glue:
  1. Every artifact has Kosli attestations before it can deploy.
  2. Every deploy creates a ServiceNow change request.
  3. Every prod deploy waits for CAB approval in native ServiceNow.
• The demo app is incidental. The pipeline is the product.

Visual cue: one slide with four cloud logos plus the words “one repo, three CIs, four clouds”.

Slide 2 — The problem we are solving

Minute 1–2.

• Typical enterprise today: CI builds are fast but deploys lag in CAB paperwork; compliance is a weekly spreadsheet; nobody can answer “what exactly is in prod right now, and who approved it?” without a ticket audit.
• Point of failure: compliance lives outside the pipeline. Policies are advisory, not enforcing. Rollbacks are manual and often skip the CR entirely.
• What we want: policies that block deploys when violated; CRs created automatically with every approval requirement pre-filled; rollbacks that go through the same gates as forward deploys.

Visual cue: before/after diagram — manual CAB spreadsheet on the left, ArgoCD sync tree with PreSync gates on the right.

Slide 3 — The two-stage model

Minute 2–3.

• Stage 1 (BUILD): CI platform of your choice. Builds the image, runs Trivy, Grype, Semgrep, Checkov, tfsec. Attaches an SBOM. Writes Kosli attestations against the image fingerprint. Pushes a tag-bump commit to the gitops branch. Does not deploy.
• Stage 2 (DEPLOY): ArgoCD on the target cluster. Reads the gitops branch. Runs two PreSync jobs: ServiceNow CR creation and Kosli policy assertion. Only then runs helm upgrade. PostSync reports the deployment back to Kosli.
• Stage 1 is portable. Stage 2 is identical regardless of CI platform — ArgoCD only reads git.

Slide 4 — Scene 1: CI produces an attested artifact

Minute 3–5. (Total elapsed 5 min; start the live demo clock now.)

Action on screen:

• Open the editor, make a trivial change to the portal (e.g. change a heading string), commit, push to main.
• Switch to the GitLab UI; show the pipeline running.
• Narrate the parallel jobs: build-portal, scan matrix (Trivy + Grype + Semgrep + Checkov + tfsec), SBOM (syft), five Kosli attestation jobs, gitops tag-bump.
• Open the Kosli UI trail for the new SHA. 8–12 attestations are linked to one artifact fingerprint.

Talking points:

• At this moment, the pipeline has spent 2–3 minutes producing evidence. No pod has moved on any cluster. That separation is intentional — you want the auditable trail to exist before the deploy.

Key beat (say out loud): “The build succeeded. NO deploy has happened yet. That is the point.”

Slide 5 — Scene 2: dev auto-deploy

Minute 5–8.

Action on screen:

• Switch to the ArgoCD UI. The dev tile is OutOfSync. Within 30 seconds it moves to Syncing.
• Open the sync operation tree. Three waves play out:
  1. -10: ServiceNow CR job runs. Show the CR appearing in the ServiceNow UI alongside, auto-advancing because risk=low for dev.
  2. 0: Kosli assert job runs. Exits 0 — policy passes.
  3. Sync: Deployment rolls out.
  4. PostSync: Kosli deployment report appears in the Kosli environment record with the CR number linked.

Talking points:

• For dev and qa, the CR is auto-advanced. That matches real-world operation — you do not gate every dev deploy on a human approval.
• Even so, the CR still exists and is searchable in ServiceNow, with the Kosli trail URL linked. Every change is still audited.

Slide 6 — Scene 3: promote to qa

Minute 8–10.

Action on screen:

• Terminal: run the qa promotion recipe. The recipe wraps the gitops tag-bump for the qa env and pushes a commit to the gitops branch.
• ArgoCD qa tile goes OutOfSync.
• Same PreSync ceremony runs; qa policy is stricter than dev.
• PostSync DAST job runs ZAP against the qa URL. Show the ZAP output live. Results are attested to the same Kosli trail.

Talking points:

• Same SHA deploys to qa. The artifact is unchanged. Only the environment changes.
• This is the “one binary, many promotions” model. If you rebuild between environments, you cannot prove the thing in prod is the thing qa approved.

Slide 7 — Scene 4: promote to prod (the compliance moment)

Minute 10–11.

Action on screen:

• Terminal: run the prod promotion recipe.
• Switch to ArgoCD UI. Prod tile is OutOfSync but does not auto-sync. Point out the Sync button.
• Click Sync. PreSync wave –10: ServiceNow CR is created with risk=high, state=assess.
• Switch to ServiceNow. Show the CR record with 24 populated custom fields — short description, risk, Kosli trail URL, image fingerprint, CI pipeline URL, env name, target cloud, approver list.
• Back to ArgoCD: the Kosli assert job is waiting because the ServiceNow job is still polling.

Talking points:

• Prod is not a different pipeline. Same SHA, same artifact, same attestations. The only difference is the human approval gate.
• The CR carries the Kosli trail URL. The approver clicks through and sees every scan, every SBOM, every test result that led to this artifact. They are approving with evidence, not with paperwork.

Slide 8 — Scene 5: approve in ServiceNow

Minute 11–12.

Action on screen:

• In ServiceNow UI: click Approve on the CR. Show the approval modal, the approver name, the CAB policy that allowed it.
• Within 30 seconds, the ServiceNow PreSync job in ArgoCD exits 0.
• Kosli assert job runs, passes the prod strict policy (all required attestations present including DAST from qa).
• Helm upgrade runs.
• PostSync Kosli deployment report: prod environment record updates to the new image with the CR number and the approver captured as a Kosli attestation.

Talking points:

• From click-Approve to pod-ready: under two minutes. That is the speed of enforcement-by-automation.
• The approver never left ServiceNow. No bespoke UI, no training, no separate tool. Your existing CAB process stays intact.

Slide 9 — Scene 6: rollback

Minute 12–14.

Action on screen:

• Terminal: check out the gitops branch, revert the bad SHA, push.
• ArgoCD detects the revert within 30–180 seconds.
• Same PreSync ceremony: a new ServiceNow CR, this time change_type=emergency, auto-approved under the “standard rollback” policy.
• Kosli assert passes because the prior tag is still attested.
• Helm rolls back.
• kubectl rollout status confirms ready.
• Kosli environment record updates to the prior fingerprint, with the rollback CR linked.

Talking points:

• Rollback is not a separate playbook. It is the same flow with the SHA reversed. Same gates, same audit trail.
• Many CAB processes skip the CR for rollbacks. That is how you get audit surprises. Here the rollback CR is mandatory — but auto-approved for standard rollbacks, so the operator is not slowed down.
• Total time from bad-deploy to recovered: under 5 minutes.

Slide 10 — Close the loop: what the evidence looks like

Minute 14–15.

Action on screen:

• Kosli UI: open the prod environment record. Show the image timeline: artifact fingerprint → deploy timestamp → CR number → approver → rollback CR → prior fingerprint.
• Hyperlink chain: GitLab commit SHA → Kosli trail → gitops tag-bump commit → ArgoCD sync ID → ServiceNow CR number → Kosli env record.

Talking points:

• Five URLs. That is the full audit path for any deploy.
• No custom tooling. Every link is a native URL in a product you already run.
• The Kosli env record IS the compliance report. Export it to PDF for the external auditor.

Slides 11–15 — Bookends

If time permits, cover multi-cloud / multi-CI portability, security properties (Kosli attestation immutability, narrow PAT scope, secrets via external-secrets), operational properties (one-command bring-up + tear-down), and what’s deliberately not in the demo yet (progressive delivery, multi-region active-active, policy-as-code for ServiceNow CAB rules).

Close with the ask: which environments to pilot on, which CI to use, which ServiceNow instance to connect to.

Operator tips for running the deck

• Run the rehearsal first — within 24 hours of the call.
• Pre-open the four browser tabs (GitLab, Kosli, ServiceNow, ArgoCD) so tab-switching does not eat time.
• Narrate the failure path if it happens. A real failure is better evidence than a scripted success.
• Respect the 15-minute budget. Slides 11–15 are bookends, not core. Skip them if the customer wants more Q&A earlier.