Board Pack

1. 1
   Improve Infrastructurecritical

   Infrastructure is at 30/100 and is dragging down Lifecycle Risk.

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

   $ not yet quantified

2. 2
   Improve Runtimecritical

   Runtime is at 31/100 and is dragging down Lifecycle Risk.

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

   $ not yet quantified

3. 3
   Remediate end-of-support: Windows Server 2012 R2critical

   Windows Server 2012 R2 (Infrastructure) is past end-of-support and is an active security and compliance risk. Plan replacement or extended support.

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

   $ not yet quantified

4. 4
   Resolve architecture debthigh

   Coupling and architectural drift are increasing change risk. Define target architecture and decomposition seams.

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

   $ not yet quantified

5. 5
   Reduce legacy code burdenhigh

   A large share of the codebase is legacy/unowned. Prioritize strangler-fig refactors on the highest-churn modules.

   Owner: CIO·Unlocks: +3 pts to Technical Debt

   $ not yet quantified

6. 6
   Address documentation debthigh

   Critical systems lack current documentation, slowing onboarding and incident response.

   Owner: CIO·Unlocks: +3 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 below. Higher is better; it moves only when the underlying domains move.

  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 most weight (1.5×), then Technical Debt, Lifecycle Risk, and Delivery Health (1.25×); the rest count 1×. 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 below (each from its own connected source)

• AI Readiness

  How prepared the organization is to adopt and scale AI across engineering, infrastructure, data, security, governance, and workforce. 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) and checks each against published end-of-life dates. 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)

• 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: Aggregates security findings from every connected source, counted by their actual severity (critical / high / medium), normalized against how many assets you have and how much of your estate is actually being scanned. 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
• Lifecycle Risk (50/100)the subscores and drivers behind the grade/lifecycle
• Security Readiness (50/100)the subscores and drivers behind the grade/security
• Technical Debt (62/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