Board Pack

1. 1
   Bring down the most serious known security flawscritical

   The count of serious known security flaws is high for the size of your technology estate. Fix the most serious ones on customer-facing and business-critical systems first.

   Owner: CISO·Unlocks: +25 pts to Security Readiness

   $ not yet quantified

2. 2
   Replace unsupported system: Windows Server 2012 R2critical

   Windows Server 2012 R2 (Infrastructure) no longer receives any support or security fixes from its maker, leaving it exposed to known attacks and likely to fail an audit. Upgrade to Windows Server 2022, or replace it or buy extended support.

   Owner: CIO·Unlocks: +8 pts to Lifecycle Risk

   $ not yet quantified

3. 3
   Replace aging core systemscritical

   Some of the servers and core systems the business runs on are at or past the point where their vendors stop providing fixes and security updates. Plan replacements or paid extended support before one fails an audit or causes an outage. At risk now: Windows Server 2012 R2 (all vendor support ended Oct 2025) — upgrade to Windows Server 2022, Ubuntu 18.04 LTS (standard support ended May 2025) — upgrade to Ubuntu 24.04 LTS. Support dates come from a curated industry catalog; the dated inventory lists each one.

   Owner: CIO·Unlocks: +4 pts to Lifecycle Risk

   $ not yet quantified

4. 4
   Move software onto supported versionscritical

   Some of the underlying technology the company's software is built on has reached, or is nearing, the point where its maker stops issuing security fixes — anything found after that stays open. Move to versions the maker still supports. At risk now: Node.js 18 (standard support ended Apr 2026) — upgrade to Node.js 22, Python 3.8 (standard support ended Oct 2025) — upgrade to Python 3.12, .NET 6 (standard support ends Nov 2026). Support dates come from a curated industry catalog; the dated inventory lists each one.

   Owner: CIO·Unlocks: +3 pts to Lifecycle Risk

   $ not yet quantified

5. 5
   Modernize the oldest parts of the systemhigh

   A large share of the software is aging code that no one actively owns, which makes every change slower and riskier. Focus modernization on the parts that change most often.

   Owner: CTO·Unlocks: +4 pts to Technical Debt

   $ not yet quantified

6. 6
   Untangle how the system is put togetherhigh

   Parts of the system have grown so intertwined that changing one thing risks breaking another, which makes delivery slower and more expensive. Agree on a target design and separate the pieces step by step.

   Owner: CTO·Unlocks: +4 pts to Technical Debt

   $ not yet quantified

How to read these numbers

Every score is a 0–100 measure, graded A–F. What each one means, how it's calculated, and the real data behind it:

• ShipReady Score

  The single headline grade for technology readiness — a weighted blend of all nine domain scores. Higher is better; it moves when the underlying domains move — or when what's measured changes, such as a new domain coming online or a domain gaining a second corroborating source.

  How it's calculated: A weighted average of every domain score that has a connected, synced data source. Security Readiness and AI Readiness carry the highest base weight (1.5×), then Technical Debt, Lifecycle Risk, and Delivery Health (1.25×); the rest count 1×. Each domain's weight is then scaled by how well-backed it is — a domain measured by two or more sources counts in full, a single well-measured source at 80%, a thin single-signal domain at 55% — so a lightly-measured domain can't steer the headline. Domains with no connected source are left out entirely rather than guessed at, so the composite only reflects measured signal.

  Data source: All nine domain scores (each from its own connected source)

• AI Readiness

  How prepared the organization is to adopt and scale AI across engineering, infrastructure, data, security, governance, workforce, and agent operations. Higher means fewer gaps before AI can scale safely.

  How it's calculated: A weighted average of up to seven readiness dimensions, each scored 0–100. The Engineering dimension is measured automatically from your GitHub repositories (do repos carry tests, context docs, type/lint guardrails, CI?); the remaining dimensions come from the AI Readiness Pulse, a short first-party survey. Dimensions nobody has measured yet are omitted, never filled with a placeholder.

  Data source: GitHub repository scan (Engineering dimension); AI Readiness Pulse survey

• AI ROI

  The return your AI tooling spend is producing — value delivered and productivity gained, measured against what you pay. Higher means more value per dollar of AI spend.

  How it's calculated: AI ROI grades from value signals — hours saved per week, engineering headcount, and loaded hourly cost (which together give spend efficiency and realized value) — combined with your monthly AI spend. If you haven't entered hours saved, it's ESTIMATED from your measured AI-authored code share and team size (bounded by team capacity, clearly labeled an estimate) so the score reflects real signal; enter your own number to override. Adoption (AI-assisted code share) is shown as context and drives that estimate, but never grades ROI on its own.

  Data source: AI ROI inputs (Admin → AI ROI Inputs); AI-spend connector (OpenAI / Anthropic)

• Agent Health

  How reliable and autonomous your AI coding agents are in practice — do they finish work on their own, and do their tool calls succeed? Higher means more dependable, hands-off agents.

  How it's calculated: Computed from agent execution telemetry: the share of runs that complete successfully, the share that finish autonomously (without a human stepping in), and the success rate of the tool calls the agents make. It only lights up once agent runs are being ingested.

  Data source: Agent execution telemetry (ingested from your Claude Code / agent runs)

• Technical Debt

  The accumulated drag on your codebase — legacy code, vulnerable dependencies, missing tests, and weak guardrails. This is an inverse score: higher is better (less debt).

  How it's calculated: Built from GitHub signals across your repositories: stale/legacy repos, open Dependabot dependency alerts (severity-weighted), security findings, and the share of repos without a detectable test suite. Architecture debt (coupling/drift) isn't measurable from GitHub, so it's omitted rather than proxied; branch-protection governance is scored under Security Readiness, not double-counted here. Each sub-dimension is measured only where GitHub returns data; the rest are omitted so a blind spot never reads as 'clean'.

  Data source: GitHub repository scan (dependencies, tests, security findings)

• IT Modernization

  How modern your delivery stack is — cloud adoption, automation, modern deployment, platform tooling, and infrastructure-as-code. Higher means a more modern, automatable estate.

  How it's calculated: Measured from a file-tree scan of your repositories. Deploying to a managed/serverless platform (Vercel, Supabase, Netlify, Cloudflare, AWS/Azure/GCP…) counts as Cloud Migration, and makes Container Adoption N/A for serverless-first estates — choosing a managed runtime over containers is an architectural choice, not a gap, so it's omitted rather than scored low. IaC Maturity counts only genuine infrastructure-as-code (Terraform, CloudFormation, Pulumi, CDK, SAM/Serverless Framework, Supabase migrations, SST) — a deploy descriptor like vercel.json is credited as Cloud, not as IaC. Automation Maturity reflects CI (GitHub Actions); Platform Modernization reflects internal paved-road tooling. So one deploy file never inflates three dimensions at once.

  Data source: GitHub repository file-tree scan

• Lifecycle Risk

  Your exposure to end-of-life and end-of-support technology — runtimes, databases, and services past or nearing their support cutoff. This is an inverse score: higher is better (less EOL exposure).

  How it's calculated: The scan detects runtimes and services declared in your repositories (e.g. Node, Python, Postgres versions) — plus anything you declare in the End-of-Life inventory — and dates each against a curated end-of-life catalog built from the community endoflife.date dataset and vendor lifecycle policies. Only versions that are actually pinned are evaluated — a floor like 'Node ≥20' is treated as a range, not a pinned EOL version — so the score reflects real exposure rather than false alarms.

  Data source: GitHub repository scan (declared runtimes & services) + the End-of-Life inventory; Curated end-of-life date catalog (endoflife.date community dataset + vendor policies)

• Security Readiness

  Your overall security posture — open vulnerabilities by severity, scanning coverage, and configuration hygiene across every connected system. Higher means fewer and less severe exposures.

  How it's calculated: Combines up to six measured factors: findings attackers are already actively exploiting (weighted heaviest); open vulnerabilities counted by severity (critical / high / medium) — each distinct vulnerability counted once even when the same advisory appears across many repositories — normalized against how many assets you have; how much of the estate has deep code and secret scanning enabled (where such scanning is partially enabled, the covered share is graded; where it is absent everywhere, the score is not penalized for the missing scanner — the blind spot is flagged as a priority action and the score's confidence is reduced instead); the pass rate of configuration checks; the share of compliance controls passing; and how quickly findings get fixed. Findings left open past their fix-by deadline can shave up to 12 points (a capped nudge, never the dominant signal). Finally, an absolute safety floor keeps the headline honest: the score is capped at 50 while any critical vulnerability is open, and at 30 while any actively-exploited finding is open — no matter how large the asset base — and the summary discloses the cap whenever it is what's holding the number down. Findings from different connectors cover different assets, so they add together into one organization-wide posture.

  Data source: GitHub (Dependabot, code scanning, secret scanning); Cloud & database connectors (AWS / Azure / GCP / Supabase, when connected)

• Delivery Health

  Engineering delivery performance, framed by DORA metrics — how often you ship, how fast changes flow, and how often they fail. Higher means faster, more reliable delivery.

  How it's calculated: Derived from your connected delivery sources over a 30-day window: deployment frequency (real production deployments — CI runs are not counted as deploys), pull-request/MR lead time (cycle time), and change-failure rate (failed CI/pipeline runs or failed production deploys). When more than one source measures the same metric, the source that measured it most completely is used, so a thin or idle connector can't skew it. Metrics none of them observe (MTTR, release predictability) are left unmeasured rather than estimated.

  Data source: GitHub (deployments, pull requests, Actions); GitLab / Vercel / Azure DevOps & observability tools, when connected

• Cloud Health

  Cost efficiency, security, reliability, and architecture maturity across your cloud providers. Higher means a healthier, better-run cloud estate.

  How it's calculated: Each dimension (cost, security, reliability, architecture) is read from your connected cloud and observability providers. It only lights up once at least one cloud source is connected and synced; unmeasured dimensions are omitted.

  Data source: Cloud & observability connectors (AWS / Azure / GCP / Supabase / Datadog, when connected)

Appendix — traceability

Every claim above is backed by a live page in your tenant — drill from the headline into the source once you connect your own data.

• ShipReady score & what movedthe live composite, trend, and decisions/dashboard
• Security Readiness (50/100)the subscores and drivers behind the grade/security
• Lifecycle Risk (60/100)the subscores and drivers behind the grade/lifecycle
• Technical Debt (63/100)the subscores and drivers behind the grade/scores/technical-debt
• IT Modernization (65/100)the subscores and drivers behind the grade/scores/it-modernization