FinOps Maturity Assessment

Crit 1: Found. A documented and enforced tagging policy mapping resources to business_unit, product, environment, owner_team, cost_center is explicitly described with enforcement via policy-as-code in Terraform. Crit 2: Found. Untagged/mis-tagged resources are reported daily in the FinOps dashboard and Platform Engineering must remediate within five business days (defined SLA). Crit 3: Found. The tagging strategy explicitly supports the showback model (weekly cost allocation to product teams by tags) and the optimization backlog review cadence. All 3 met. Total: 3.

• “All production cloud resources must carry business_unit, product, environment, owner_team, cost_center, and data_classification tags. Untagged or mis-tagged resources are reported daily in the FinOps dashboard. Platform Engineering must remediate critical tag defects within five business days. Exceptions require FinOps Council approval and expire after 30 days.” — Tagging policy · Policy
• “Cloud costs are allocated weekly to product teams using tags, account hierarchy, and shared platform allocation rules. Team leads receive showback views for product, environment, and owner_team.” — Showback model · Accountability
• “New Terraform modules include mandatory tags and policy-as-code checks. Infracost estimates are visible in pull requests for the platform account, but not yet enforced for all product repositories.” — Infrastructure as Code · Automation

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports a functioning weekly showback model using tags, account hierarchy, and shared platform allocation rules. The scanner correctly withheld credit for formal stakeholder acceptance and regular refinement of the allocation model, which are not evidenced.

• “Cloud costs are allocated weekly to product teams using tags, account hierarchy, and shared platform allocation rules. Team leads receive showback views for product, environment, and owner_team.” — Showback model · Accountability
• “Chargeback is not yet active; Finance plans to pilot chargeback for shared analytics workloads in 2026-Q3.” — Showback model · Policy

Crit 1: Found. Automated anomaly detection runs daily, well within the 24-hour threshold. Crit 2: Found. Alerts include affected service, account, owner_team, amount, percentage variance, and route to the owning team Slack channel — actionable context is present. Crit 3: Partial/Not fully met. Escalation is defined only for high-severity anomalies (one business day acknowledgement); the runbook explicitly lacks escalation timing for low-severity anomalies, and development accounts lack team-level routing. This prevents a score of 3. Total: 2.

• “Automated anomaly detection runs daily against account, product, service, and environment dimensions. Alerts include affected service, account, owner_team, amount, percentage variance, and a link to the dashboard. Alerts route to the owning team Slack channel and to the FinOps on-call analyst. High-severity anomalies require acknowledgement within one business day.” — Anomaly detection · Automation
• “On 2026-03-18, checkout-api compute spend increased 31% after a misconfigured autoscaling threshold. The alert was routed to Platform Checkout and FinOps. The team corrected the scaling policy, created a follow-up architecture review, and recorded estimated monthly avoided cost.” — Recent anomaly example · Process
• “The anomaly runbook does not yet define escalation timing for low-severity anomalies. Several development accounts are monitored daily but do not yet have team-level Slack routing.” — Known limitation · Process

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The dashboard evidence supports role-appropriate executive, finance, and engineering views, 12-hour refresh, trend/forecast information, and AWS/Azure/GCP billing export integration. The scanner correctly withheld full credit because SaaS platform integration is not evidenced.

• “The FinOps dashboard refreshes every 12 hours and integrates AWS, Azure, and GCP billing exports. It contains executive trend views, finance budget views, and engineering resource-level views.” — Dashboards · Operational
• “The dashboard tracks month-to-date spend, forecasted month-end spend, previous-period comparison, and committed-discount utilization.” — Dashboards · Operational

Crit 1: Partial. Unit economics exist for only two metrics (checkout transactions and loyalty API calls); coverage is incomplete and explicitly acknowledged as a gap. Score capped at 1 for partial/aspirational state. Crit 2: Not found. No evidence of unit cost trends being monitored over time to separate growth-driven spend from efficiency degradation. Crit 3: Not found. Engineering teams are explicitly NOT given unit cost targets as formal metrics. Total: 1.

• “Unit economics are defined only for checkout transactions and loyalty API calls. Cost per customer and cost per order are not yet used as formal engineering targets.” — Policy gaps · Policy

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The cited chunks support active RI/Savings Plan/CUD management across AWS/Azure/GCP, a defined 72% coverage target, current 68% coverage tracking, monthly utilization review, escalation of unused commitments, dashboard utilization tracking, and quarterly commitment strategy review. The source does not show exchange/resale/remediation of unused commitments, so a score of 2 is appropriate.

• “Northstar Retail manages Reserved Instances, Savings Plans, and committed-use discounts across AWS, Azure, and GCP. Target commitment coverage is 72% for stable compute and database workloads. Current coverage is 68%.” — Commitment management · Operational
• “Utilization is reviewed monthly; unused commitments above EUR 5,000 monthly amortized value are escalated to Finance and Platform Engineering.” — Commitment management · Process
• “Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process
• “The dashboard tracks month-to-date spend, forecasted month-end spend, previous-period comparison, and committed-discount utilization.” — Dashboards · Operational

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The source supports right-sizing recommendations generated weekly from CPU, memory, and storage utilization, product-team review in an optimization backlog, weekly backlog review, and tracked financial impact of EUR 46,000 monthly run-rate reduction. Automatic generation is not explicit, so criterion 2 is only partially supported; count 2 is reasonable.

• “Recommendations are generated weekly from CPU, memory, and storage utilization. Product teams must approve or reject recommendations in the cost optimization backlog.” — Optimization actions · Process
• “During 2026-Q1, engineering accepted 22 right-sizing recommendations and deferred 7 due to release freeze risk. Accepted actions reduced monthly run-rate by EUR 46,000.” — Optimization actions · Financial-Integration
• “Weekly: optimization backlog review with product cost owners.” — Cadence · Process

Crit 1: Found. Idle load balancers, unattached disks, and orphaned snapshots detected weekly and acted upon — systematic identification and termination is described. Crit 2: Found. Non-production environments shut down outside business hours with an automated tag-based exception mechanism (always_on=true with owner approval). Crit 3: Partially found. Waste is measured as a percentage of monthly cloud spend (4.8%) with a stated 2026 target (below 3%), satisfying reporting and target aspects. However, this is a single aggregate metric and does not provide explicit evidence of a broader multi-dimensional waste reporting system — but the criteria are substantially met. Awarding Crit 3 as met given the waste percentage and reduction target are explicitly stated. Total: 3.

• “Non-production environments shut down outside business hours unless tagged always_on=true with owner approval. Idle load balancers, unattached disks, and orphaned snapshots are detected weekly.” — Waste controls · Automation
• “The waste report shows idle resource waste at 4.8% of monthly cloud spend, against a 2026 target of below 3%.” — Waste controls · Accountability

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports spot/preemptible approval for batch analytics, CI test runners, and image-processing jobs. It also explicitly limits maturity: interruption handling exists only for analytics batch jobs, CI fallback remains manual, and expansion targets are not approved. Count 1 is supported.

• “Spot instances are approved for batch analytics, CI test runners, and image-processing jobs.” — Spot and preemptible usage · Operational
• “Interruption handling exists for analytics batch jobs, but CI runner fallback is still manual. Spot savings are tracked, but expansion targets are not yet approved.” — Spot and preemptible usage · Operational

Crit 1: Partially found. Archive tiering exists for audit logs older than 180 days — partial hot/warm/cold tiering — but product telemetry lifecycle tiering is 'planned but not yet enforced' and tiering is not enforced across all buckets. At best this is one partial implementation. Crit 2: Partially found. Retention is defined for security, audit, and application logs, but enforcement is incomplete (not across all buckets). Crit 3: Not found. No evidence of monitoring storage cost per GB or optimizing for appropriate storage class. Given plans and partial implementation but no enforcement breadth and no storage-cost-per-GB monitoring, total: 1 (aspirational/partial).

• “Log retention is defined for security, audit, and application logs. Archive tiering exists for audit logs older than 180 days. Object storage lifecycle tiering for product telemetry is planned but not yet enforced.” — Storage · Policy
• “Storage retention rules exist for logs, but lifecycle tiering is not yet enforced across all buckets.” — Policy gaps · Policy

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The source supports a documented governance framework, tagging requirements, exception approval, named governance ownership, and some policy-as-code enforcement in Terraform modules. It also supports the scanner's caveats: spend limits/full provisioning approval workflows and policy lifecycle review cadence are not explicit.

• “The FinOps Council owns cloud financial governance with named representatives from Finance, Platform Engineering, Security, and Product Operations.” — Governance · Policy
• “All production cloud resources must carry business_unit, product, environment, owner_team, cost_center, and data_classification tags... Exceptions require FinOps Council approval and expire after 30 days.” — Tagging policy · Policy
• “New Terraform modules include mandatory tags and policy-as-code checks.” — Infrastructure as Code · Automation

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. src-001-c001 directly supports monthly product-team budgets, monthly budget-to-actual variance checks above 10%, a forecasting model using historical spend/planned launches/commitment expiries/traffic growth, and corrective actions in a monthly FinOps action log. The scanner appropriately did not award full credit because project/org-level budget hierarchy is not explicit.

• “Each product team has a monthly cloud budget. Finance compares budget to actuals every month and flags variance above 10%.” — Budget and forecast · Process
• “The forecasting model uses historical spend, planned product launches, reserved commitment expiries, and expected traffic growth.” — Budget and forecast · Process
• “Corrective actions are captured in the monthly FinOps action log.” — Budget and forecast · Accountability

Crit 1: Found. A defined federated FinOps operating model with explicit named roles (FinOps lead, cloud economist, platform analyst, engineering cost owners) and a RACI matrix is documented. Crit 2: Found. Executive sponsorship is evidenced by the quarterly CTO/CFO steering group engagement and the FinOps Council reporting unresolved cost risks to CTO and CFO. Crit 3: Found. A documented operational cadence covering daily, weekly, monthly, and quarterly FinOps activities is explicitly stated. Total: 3.

• “The FinOps operating model is federated. The central FinOps team has one FinOps lead, one cloud economist, and one platform analyst. Each product domain appoints an engineering cost owner. The RACI states that Finance owns budgets, FinOps owns allocation and optimization process, Platform Engineering owns guardrails, and product teams own cost decisions for their services.” — Operating model · Accountability
• “Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process
• “Daily: anomaly triage for high-severity alerts. Weekly: optimization backlog review with product cost owners. Monthly: budget variance review with Finance and engineering leads.” — Cadence · Process

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited quote in src-004-c001 directly supports annual vendor pricing benchmarking. The scanner correctly treats RI/SP/CUD management as insufficient evidence for EDP/private pricing/negotiated rates and notes that exit-cost analysis is only partial.

• “Vendor pricing is benchmarked during annual renewal, but exit-cost analysis for proprietary managed services is only performed for tier-1 systems.” — Compliance and vendor management · Process

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. src-004-c001 supports data residency review during architecture design and separate tracking of compliance-driven cost increases. The scanner correctly withholds additional credit because audit trails for financial decisions and separate justification of compliance costs are not evidenced.

• “Data residency requirements are reviewed during architecture design. Compliance-driven cost increases such as dedicated logging, encryption, and regional replication are tracked separately in the Finance view.” — Compliance and vendor management · Process

Crit 1: Found. Architecture review templates include a cost-performance tradeoff section, placing cost as a first-class constraint alongside other factors. Crit 2: Found. Templates require estimated monthly cost and scaling cost curves — explicit cost modeling in architecture proposals. Crit 3: Found. Engineering teams can view service cost before and after releases, confirming cost data access during development. Total: 3.

• “Architecture review templates require estimated monthly cost, scaling cost curve, data-retention cost impact, and a cost-performance tradeoff section.” — Architecture standards · Process
• “Engineering teams can view service cost before and after releases.” — Architecture standards · Operational
• “Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process

Crit 1: Found. Terraform is the declared standard for production infrastructure provisioning. However, legacy manually provisioned resources exist in two accounts, so IaC is not universal — partial but clearly operational. Crit 2: Partially found. Policy-as-code checks exist in new Terraform modules, but enforcement is not complete across all repositories. Score is operational (2) not embedded (3). Crit 3: Found. Infracost estimates are visible in pull requests for the platform account, providing a cost estimation step in the CI/CD pipeline, though not yet enforced everywhere. Total: 2 (all three criteria partially met, but none fully enforced across the entire estate).

• “Terraform is the standard for production cloud infrastructure. New Terraform modules include mandatory tags and policy-as-code checks.” — Infrastructure as Code · Policy
• “Infracost estimates are visible in pull requests for the platform account, but not yet enforced for all product repositories.” — Infrastructure as Code · Automation
• “Legacy manually provisioned resources still exist in two older analytics accounts.” — Infrastructure as Code · Operational

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited evidence supports only limited autoscaling governance: autoscaling policies must define maximum capacity, target utilization, and cost ceiling guardrails, and one autoscaling misconfiguration was detected as a cost anomaly. There is no source evidence of systematic horizontal/vertical autoscaling implementation across production, scale-to-zero testing, or comprehensive scaling-event cost monitoring.

• “Autoscaling policies must define maximum capacity, target utilization, and cost ceiling guardrails.” — Architecture standards · Policy
• “On 2026-03-18, checkout-api compute spend increased 31% after a misconfigured autoscaling threshold.” — Recent anomaly example · Operational

Crit 1: Found. The FinOps dashboard integrates AWS, Azure, and GCP billing exports into a single unified view — this is a single-pane-of-glass for multi-cloud cost visibility. Crit 2: Partial. Tagging policy applies to production resources (src-001) and commitment management spans all three clouds (src-003), suggesting some consistency, but explicit cross-provider apples-to-apples tagging comparison is not described. Crit 3: Not found. No evidence that workload placement decisions are informed by cross-provider cost analysis. Vendor pricing is benchmarked at annual renewal (src-004) but this is not described as informing workload placement. Total: 2.

• “The FinOps dashboard refreshes every 12 hours and integrates AWS, Azure, and GCP billing exports. It contains executive trend views, finance budget views, and engineering resource-level views.” — Dashboards · Operational
• “Northstar Retail manages Reserved Instances, Savings Plans, and committed-use discounts across AWS, Azure, and GCP.” — Commitment management · Operational

Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. No cited source mentions Kubernetes, pod right-sizing, node autoscaling, bin-packing, serverless function cost monitoring, execution-duration optimization, memory/concurrency optimization, or a decision framework for containers vs. serverless vs. VMs. The scanner’s zero score is supported by the available packet evidence.

Crit 1: Found. A dedicated federated FinOps team with named headcount, a charter (RACI), and a FinOps Council with cross-functional named representatives is explicitly described. Crit 2: Found. The team drives weekly optimization backlog reviews with product cost owners and runs quarterly commitment/architecture reviews; the Q1 review documents 22 accepted right-sizing actions and measurable run-rate reduction. Crit 3: Found. The operating model positions FinOps as owning 'allocation and optimization process' with engineering accountability embedded at the product-domain level, and engineering teams have pre/post-release cost visibility — indicating value-enabler positioning with engineering credibility. Total: 3.

• “The FinOps operating model is federated. The central FinOps team has one FinOps lead, one cloud economist, and one platform analyst. Each product domain appoints an engineering cost owner. The RACI states that Finance owns budgets, FinOps owns allocation and optimization process, Platform Engineering owns guardrails, and product teams own cost decisions for their services.” — Operating model · Accountability
• “Weekly: optimization backlog review with product cost owners. Monthly: budget variance review with Finance and engineering leads. Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process
• “The FinOps Council owns cloud financial governance with named representatives from Finance, Platform Engineering, Security, and Product Operations. The council meets monthly, reviews cloud budget variance, and reports unresolved cost risks to the CTO and CFO steering group.” — Cloud Financial Governance Policy · Operational

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 1 after a targeted rescan. Verifier status: weak. The source clearly supports engineering visibility and accountability through service-cost visibility, engineering cost owners, and product-team approval/rejection of optimization recommendations. However, the second criterion is not supported because there is no evidence of cost efficiency in OKRs, sprint reviews, performance evaluations, or similar team objectives. The third criterion is only partially supported: engineers appear empowered to optimize, but the source does not show explicit incentives. The scanner's count of 2 is therefore too strong.

• “Engineering teams can view service cost before and after releases.” — Architecture standards · Operational
• “Each product domain appoints an engineering cost owner.” — Operating model · Accountability
• “Product teams must approve or reject recommendations in the cost optimization backlog.” — Optimization actions · Accountability

Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 1 after a targeted rescan. Verifier status: weak. The evidence supports active CTO/CFO engagement through quarterly commitment and architecture cost reviews and escalation of unresolved risks to the CTO/CFO steering group. It does not support executive allocation of dedicated budget for FinOps tooling, training, or headcount, and it does not establish cloud cost efficiency as a standing agenda item in broader executive leadership meetings. The scanner's count of 2 is not supported by its own reasoning or the raw material.

• “Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process
• “The council meets monthly, reviews cloud budget variance, and reports unresolved cost risks to the CTO and CFO steering group.” — FinOps Council · Process

Crit 1: Found. Finance, Platform Engineering, Security, and Product Operations all collaborate on the FinOps Council with shared governance; a common allocation model and shared dashboard tooling is described. Crit 2: Found. A structured monthly budget variance review brings Finance and engineering leads together; a quarterly steering with CTO/CFO also exists; weekly optimization backlog reviews further embed cadence. Crit 3: Found. The RACI explicitly distributes ownership across Finance (budgets), FinOps (allocation/optimization), Platform Engineering (guardrails), and product teams (cost decisions) — this is a shared accountability model, not an 'engineering buys, finance pays' model. Total: 3.

• “The FinOps Council owns cloud financial governance with named representatives from Finance, Platform Engineering, Security, and Product Operations.” — Cloud Financial Governance Policy · Process
• “Monthly: budget variance review with Finance and engineering leads.” — Cadence · Process
• “The RACI states that Finance owns budgets, FinOps owns allocation and optimization process, Platform Engineering owns guardrails, and product teams own cost decisions for their services.” — Operating model · Accountability
• “Cloud costs are allocated weekly to product teams using tags, account hierarchy, and shared platform allocation rules. Team leads receive showback views for product, environment, and owner_team.” — Showback model · Financial-Integration

Final maturity assessment: NOK. Evidence-check resolved the scanner score from 1 to 0 after a targeted rescan. Verifier status: weak. The quoted source supports ongoing optimization activity, weekly recommendation generation, and waste tracking against a target. However, E5 specifically requires continuous improvement with retrospectives and maturity assessments, internal benchmarking, and external/peer benchmarking. None of those are explicitly evidenced. The scanner correctly noted the gaps, but counting one criterion as met is too strong based on the available material.

Crit 1: No evidence that the organization tracks token, API, model, or inference spend by application, use case, team, customer, or environment. Documents cover general cloud billing visibility only. Crit 2: No mention of provider AI costs, model endpoints, retry costs, cache costs, batch inference, or real-time inference cost drivers. Crit 3: No AI-specific dashboards or alerts for token cost trends or anomalies described. Total: 0.

Crit 1: No evidence of LLM or AI platform costs allocated to products, workflows, customers, teams, or business units. Crit 2: No shared AI platform cost allocation model described. Crit 3: No AI-specific unit metrics such as cost per AI task, per AI interaction, or per model call. General unit economics (checkout, loyalty API) exist but are not AI-related. Total: 0.

Crit 1: No model-routing policy or model selection governance described. Crit 2: No mention of prompt length, context size, retrieval scope, caching, batching, retry behavior, or agent loops. Crit 3: No cost-quality-latency tradeoff measurement for AI models described. Total: 0.

Crit 1: No AI budgets, quotas, alerts, or approval thresholds for AI applications, model tiers, or AI environments described. Crit 2: No AI-specific spend forecasting or anomaly detection for token volume, retries, or context growth described. Crit 3: No production AI guardrails such as rate limits, spend limits, or model-access controls described. General infrastructure guardrails (autoscaling cost ceilings) exist but do not apply to AI workloads. Total: 0.

Crit 1: No comparison of AI costs against business value such as productivity gain, quality improvement, risk reduction, or revenue impact. Crit 2: No AI cost governance structure involving product, engineering, finance, risk, or business stakeholders. Crit 3: No process for reviewing, redesigning, downgrading, or retiring low-value AI use cases. Total: 0.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The raw material shows the opposite of tag sprawl: mandatory tag keys, daily defect reporting, remediation SLA, exception expiry, and policy-as-code checks for new Terraform modules. No evidence supports significant untagged spend, ad-hoc taxonomy, or acceptance of untagged spend as overhead. Coverage interpretation: Relevant tagging governance and remediation coverage is present in src-001-c001 and src-004-c001, so this anti-pattern would likely have been revealed if present.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source contradicts black-box cloud spend: engineering has resource-level dashboard views and drill-downs, dashboards refresh every 12 hours, and alerts route to owning teams. No evidence suggests cost visibility is restricted to finance or a single admin. Coverage interpretation: Dashboard and alert-routing evidence in src-002-c001 directly covers engineering visibility, making absence meaningful.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source supports 12-hour dashboard refreshes and daily automated anomaly detection with Slack/on-call routing. There is no evidence of reporting delays over 48 hours, manual spreadsheet-based reporting, or lack of automated anomaly alerting. Coverage interpretation: Cost reporting cadence and anomaly automation are explicitly covered in src-002-c001, so the absence of delayed reporting is reasonably tested.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source describes a unified FinOps dashboard integrating AWS, Azure, and GCP billing exports with role-appropriate views. There is no evidence of isolated provider/team views or finance and engineering using conflicting tools or numbers. The unit-economics gap does not by itself evidence siloed cost views. Coverage interpretation: Cross-cloud dashboard integration and shared stakeholder views are explicitly covered in src-002-c001, so absence of provider/account silos is meaningfully tested.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 1 to 0. Verifier status: unsupported. Adjudication: The cited sources show limited unit economics maturity and some savings reported as absolute EUR run-rate reduction, but they do not show misleading, unverifiable, presentation-only, or non-actionable vanity metrics. The optimization evidence indicates operational use through right-sizing recommendations, product-team approval/rejection, and backlog decisions. Coverage interpretation: Source coverage discusses unit economics gaps and optimization reporting, but does not provide enough targeted evidence about metric definitions, dashboard intent, or savings-verification practices to support a harmful vanity-metrics finding.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The raw material contradicts commitment avoidance: it documents active commitment management, defined target coverage, current coverage, monthly utilization review, escalation of unused commitments, committed-discount utilization tracking, and quarterly strategy review. No source evidence supports fear-driven avoidance or predominantly on-demand use for stable workloads. Coverage interpretation: Commitment management is directly covered in src-003-c001 and src-002-c001. The evidence is specific enough that a commitment-avoidance pattern would likely be visible if present.

• “Target commitment coverage is 72% for stable compute and database workloads. Current coverage is 68%. Utilization is reviewed monthly; unused commitments above EUR 5,000 monthly amortized value are escalated to Finance and Platform Engineering.” — Commitment management · Operational

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 1 to 0. Verifier status: unsupported. Adjudication: The only harmful signal is that 7 right-sizing recommendations were deferred due to release freeze risk, while 22 were accepted and reduced monthly run-rate by EUR 46,000. The source does not show chronic over-provisioning, utilization below 20%, unvalidated peak-capacity justification, or ignored recommendations due to lack of ownership. Coverage interpretation: Relevant right-sizing coverage exists in src-003-c001 and src-004-c001, but it tends to contradict the anti-pattern by showing weekly utilization-based recommendations and product cost owner review. The scanner signal is too weak to support a partial finding.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source shows non-production shutdown outside business hours, owner-approved exceptions, weekly detection of idle/orphaned resources, and waste reporting with a reduction target. This contradicts the core anti-pattern conditions of dev/test running permanently and no lifecycle management or cleanup ownership. Coverage interpretation: Waste controls are directly covered in src-003-c001. Although residual waste exists, the source includes controls that would reasonably reveal hoarding/no-cleanup behavior if present.

• “Non-production environments shut down outside business hours unless tagged always_on=true with owner approval. Idle load balancers, unattached disks, and orphaned snapshots are detected weekly.” — Waste controls · Automation

Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The cited evidence shows some manual or incomplete automation gaps: CI runner fallback is manual, Infracost is not enforced across all product repositories, and legacy manually provisioned resources remain. However, these do not support the Manual-Only Optimization anti-pattern criteria. The source also documents weekly generated optimization recommendations, weekly backlog review, automated anomaly detection, dashboarding, and non-production shutdowns. The positive score is too strong for the harmful pattern. Coverage interpretation: There are real partial manual-process signals, but not enough to verify the manual-only anti-pattern. The environment is not shown to lack optimization automation or engineering workflow integration entirely.

• “Interruption handling exists for analytics batch jobs, but CI runner fallback is still manual.” — Spot and preemptible usage · Operational
• “Infracost estimates are visible in pull requests for the platform account, but not yet enforced for all product repositories. Legacy manually provisioned resources still exist in two older analytics accounts.” — Infrastructure as Code · Automation

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: weak. The source supports commitment utilization tracking and multi-cloud commitment management, which argues against a total absence of rate optimization governance. However, it does not specifically evidence discount-interaction understanding, overlap analysis, or avoidance of double-coverage. The scanner's zero positive score is acceptable, but its claim that the source directly contradicts all discount-stacking ignorance criteria is overstated. Coverage interpretation: The available commitment evidence is relevant but not detailed enough to prove absence of discount-overlap or stacking-governance issues. Targeted evidence on overlap analysis and discount interaction governance would be needed.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. No source chunk evidences personal-card spend, unlinked accounts, unknown cloud exposure, or cloud accounts outside the governed structure. The noted legacy manually provisioned resources and development accounts without Slack routing are governance gaps, not direct shadow IT evidence. Coverage interpretation: The packet includes relevant governance, tagging, billing-dashboard, account-dimension monitoring, and known account limitation material. These sources would reasonably surface unmanaged account exposure if documented in the available evidence.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source material shows active budget governance: monthly budget-to-actual comparison, variance flagging above 10%, forecasting inputs, monthly reviews, and corrective actions. This contradicts budget blowout tolerance. Coverage interpretation: Budgeting and forecasting are directly covered in src-001-c001 and src-004-c001, with enough process detail to assess whether overruns are ignored or disconnected from operations.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source material contains measurable FinOps outcomes, including accepted right-sizing recommendations, EUR 46,000 monthly run-rate reduction, and an anomaly remediation with EUR 18,400 estimated monthly avoided cost. This contradicts the FinOps Theater anti-pattern. Coverage interpretation: The packet includes operating model, cadence, optimization review, and anomaly remediation evidence, which is relevant and sufficient to test whether FinOps activities produce measurable outcomes.

Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The cited quote is real and supports a partial portability-governance gap: exit-cost analysis for proprietary managed services is only performed for tier-1 systems. However, the scanner's inference that this means major commitments below tier-1 are made without exit analysis is stronger than the raw text. Competitive benchmarking is explicitly present. Coverage interpretation: There is a real but limited harmful-pattern signal around incomplete exit-cost analysis. The same source also shows vendor pricing benchmarking, so full vendor lock-in blindness is not established.

• “Vendor pricing is benchmarked during annual renewal, but exit-cost analysis for proprietary managed services is only performed for tier-1 systems.” — Compliance and vendor management · Process

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source material shows data residency requirements reviewed during architecture design and compliance-driven costs such as logging, encryption, and regional replication tracked separately. No source evidence shows compliance cost surprises or compliance treated reactively. Coverage interpretation: Compliance cost handling is directly covered in src-004-c001, and architecture standards also include data-retention cost impact. This is enough to test the stated anti-pattern in the available evidence.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: weak. No source evidence shows workloads migrated with on-premises sizing intact, VMs matching physical server specs, or cloud being treated as colocation. However, the packet is mostly current FinOps/engineering governance and optimization material, not migration-history evidence, so the scanner’s strong claim that absence is fully verified is too strong. Coverage interpretation: The sources contain relevant current optimization signals, including right-sizing and architecture cost reviews, but they are largely silent on original migration approach and inherited on-prem sizing. Absence of this anti-pattern is therefore not fully testable from this packet.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source directly contradicts cost-blind architecture: architecture review templates require estimated monthly cost, scaling cost curves, data-retention cost impact, and cost-performance tradeoff sections. Infracost is also visible in some pull requests, although not enforced everywhere. No harmful cost-blind decision pattern is evidenced. Coverage interpretation: Architecture governance and deployment-cost evidence are directly covered in src-004-c001, and the documented requirements are the opposite of the anti-pattern criteria.

• “Architecture review templates require estimated monthly cost, scaling cost curve, data-retention cost impact, and a cost-performance tradeoff section.” — Architecture standards · Policy

Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The checkout-api incident in src-002-c001 supports one harmful-pattern criterion: compute spend increased 31% after a misconfigured autoscaling threshold. The broader anti-pattern is not fully supported because src-004-c001 states autoscaling policies must define maximum capacity, target utilization, and cost ceiling guardrails, indicating governance exists or is being remediated. Coverage interpretation: There is a real but limited harmful signal: one documented autoscaling-related cost spike. The available source also shows corrective action and policy guardrails, so the anti-pattern is only partially evidenced rather than broadly embedded.

• “On 2026-03-18, checkout-api compute spend increased 31% after a misconfigured autoscaling threshold. The alert was routed to Platform Checkout and FinOps. The team corrected the scaling policy, created a follow-up architecture review.” — Recent anomaly example · Operational
• “Autoscaling policies must define maximum capacity, target utilization, and cost ceiling guardrails.” — Architecture standards · Policy

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The evidence contradicts single-cloud tunnel vision: the dashboard integrates AWS, Azure, and GCP billing exports, commitments are managed across all three providers, and vendor pricing is benchmarked during annual renewal. The limited exit-cost analysis for proprietary services is a vendor-risk gap, not evidence of single-cloud provider loyalty. Coverage interpretation: The packet has direct multi-cloud cost-management and vendor-benchmarking evidence, which would reasonably reveal this anti-pattern if the organization were single-cloud or avoided provider comparison.

• “The FinOps dashboard refreshes every 12 hours and integrates AWS, Azure, and GCP billing exports.” — Dashboards · Operational
• “Vendor pricing is benchmarked during annual renewal, but exit-cost analysis for proprietary managed services is only performed for tier-1 systems.” — Compliance and vendor management · Process

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: weak. No source evidence shows monolithic applications preventing granular allocation, whole-application scaling, or deferred decomposition. However, the source packet does not materially discuss application architecture or decomposition, so the scanner’s claim that absence is adequately verified is too strong. Coverage interpretation: The sources include service/product cost visibility, but they are not detailed application-architecture documents. They do not provide enough coverage to test whether monolith-related scaling or allocation constraints exist.

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The raw source describes the opposite of 'Cost is IT's Problem': product domains appoint engineering cost owners, product teams own cost decisions for their services, team leads receive showback, and anomaly alerts route to owning teams. No harmful-pattern criterion is evidenced. Coverage interpretation: Coverage is directly relevant to ownership and accountability. The operating model, showback policy, and anomaly routing would reasonably reveal if cost were isolated to IT; instead they show distributed accountability across Finance, FinOps, Platform Engineering, and product teams.

• “Each product domain appoints an engineering cost owner... product teams own cost decisions for their services.” — Operating model · Accountability

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source does not show blame, punishment, hidden cost problems, or adversarial finance-engineering interactions. The anomaly example shows routed alerting, correction by the owning team, follow-up architecture review, and recorded avoided cost. Corrective actions are also captured in a FinOps action log. Coverage interpretation: Coverage includes an anomaly runbook, a recent anomaly response, budget variance process, and cross-functional review cadence. These are relevant enough to test for blame-based behavior, and the described behavior is collaborative rather than punitive.

• “The alert was routed to Platform Checkout and FinOps. The team corrected the scaling policy, created a follow-up architecture review, and recorded estimated monthly avoided cost.” — Recent anomaly example · Process
• “Corrective actions are captured in the monthly FinOps action log.” — Budget and forecast · Process

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source supports a staffed FinOps function, a federated cost-owner model, recurring reviews, dashboards/anomaly tooling, optimization backlog processes, and executive steering engagement. That contradicts the main FinOps Lip Service indicators of no dedicated team, no structured program, and optimization expected to happen organically. Explicit training budget is not shown, but no harmful criterion is positively evidenced. Coverage interpretation: Coverage includes operating model, headcount, tooling, governance cadence, and optimization processes. These materials would reasonably expose whether FinOps were merely nominal; instead they show operational implementation.

• “The central FinOps team has one FinOps lead, one cloud economist, and one platform analyst.” — Operating model · Operational
• “Quarterly: commitment strategy and architecture cost review with CTO/CFO steering group.” — Cadence · Process

Final anti-pattern assessment: Tested absent. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source shows shared cross-functional forums and tooling rather than a finance-engineering wall: the FinOps Council includes Finance, Platform Engineering, Security, and Product Operations; monthly reviews bring Finance and engineering leads together; and the dashboard includes executive, finance, and engineering views. No harmful-pattern criterion is evidenced. Coverage interpretation: Coverage is directly relevant to finance-engineering collaboration, tooling, and governance forums. Although individual financial/technical literacy is not assessed, the available source shows structures that bridge rather than separate finance and engineering.

• “The FinOps Council owns cloud financial governance with named representatives from Finance, Platform Engineering, Security, and Product Operations. The council meets monthly, reviews cloud budget variance.” — Cloud Financial Governance Policy · Process
• “The FinOps dashboard refreshes every 12 hours and integrates AWS, Azure, and GCP billing exports. It contains executive trend views, finance budget views, and engineering resource-level views.” — Dashboards · Operational

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source does not positively evidence a static maturity assumption. It shows ongoing optimization activity, weekly recommendations, monthly/quarterly review cadences, waste targets, and measured run-rate reduction. However, the source is also silent on formal FinOps maturity assessments and external maturity benchmarking, so absence of the anti-pattern is not fully testable. Coverage interpretation: The available material meaningfully contradicts stalled optimization momentum, but it does not fully cover maturity-assessment or external benchmarking practices. Therefore the harmful pattern is not evidenced, but full absence cannot be confirmed.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The scanner correctly does not score Invisible Token Spend as present. The source does not establish that AI/API/token/model spend exists at all, so invisible AI spend cannot be confirmed from these documents. Coverage interpretation: The documents cover general cloud FinOps governance, but are silent on AI consumption. Because there is no evidence of existing AI spend, absence of the anti-pattern is not tested; it is unknown/not assessable.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. No AI experiments, playgrounds, sandbox AI keys, prototypes, or AI production transitions are described. The scanner correctly leaves the anti-pattern unscored rather than asserting absence. Coverage interpretation: The supplied material is silent on AI lifecycle or GenAI workload promotion. This does not prove the anti-pattern is absent; it only makes it not assessable from the provided evidence.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. There are no references to AI models, premium model usage, cheaper model alternatives, AI caching/batching, prompt reduction, retries, or agent loops. Premium Model Overuse is not evidenced. Coverage interpretation: The source is silent on AI model usage and model-selection practices, so the anti-pattern cannot be tested absent.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The documents contain no RAG, prompt, memory, context-window, conversation-history, retrieval-scope, cache-efficiency, or token-budget evidence. Unbounded Context Growth is not evidenced. Coverage interpretation: The source does not cover AI context or retrieval architecture. Absence is therefore unknown rather than tested absent.

Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. No AI adoption metrics, AI pilot reporting, AI activity dashboards, AI ROI claims, or continued AI use cases with unclear value are present in the source. AI Value Theater is not evidenced. Coverage interpretation: The documents are silent on AI adoption/value reporting, so the anti-pattern cannot be meaningfully tested absent.