A
Cost Visibility & Allocation
Maturity signal
27%
4/5 criteria assessed
Anti-pattern finding rate
50%
0 findings, 5 partial, 0 not assessed
Assessment score remains valid. Unsupported strategy wording or actions were removed or retained only in the appendix.
Phase 1 findings were verified against the raw material before Phase 2 metrics were calculated.
Evidence density 58% is below 60%, so readiness is capped until more current-state evidence is supplied.
Share of maturity criteria that scored as fully embedded (3 of 3 sub-criteria met).
Average maturity score across all criteria on a 0–3 scale, normalized to 0–100%. Captures partial progress that maturity_ratio misses.
Share of anti-patterns scored as deeply entrenched (3 of 3 sub-criteria met). Higher = worse.
Average severity across all anti-patterns. Higher = more friction blocking current FinOps practice. Low values mean "low confirmed burden" only when source evidence is strong enough.
Share of anti-patterns that were meaningfully tested and not found. This is positive only when the source had relevant coverage.
Share of anti-pattern criteria that were meaningfully assessed, either as findings or verified absences. Low coverage means absence is unknown, not good.
Did the audit pipeline complete? Share of maturity and anti-pattern criteria the LLM returned valid data for. Below 100% means batches failed.
Did the source actually cover the criterion? Share of maturity and anti-pattern criteria with verified source coverage, including positive evidence, quote-backed gaps, anti-pattern findings, and verified anti-pattern absences.
Per-domain maturity (emerald) vs anti-pattern burden (rose). Each axis is one assessment domain; values are the sum of sub-criterion counts (0–15) for that domain.
Validated maturity depth (x-axis) plotted against confirmed anti-pattern burden (y-axis). When evidence or anti-pattern coverage is insufficient, quadrant labels are suppressed.
Maturity target is high; anti-pattern finding rate target is low. Grey means the source did not provide enough assessable coverage.
4/5 criteria assessed
0 findings, 5 partial, 0 not assessed
3/5 criteria assessed
0 findings, 5 partial, 0 not assessed
3/5 criteria assessed
0 findings, 5 partial, 0 not assessed
3/5 criteria assessed
0 findings, 3 partial, 1 not assessed
2/5 criteria assessed
0 findings, 4 partial, 0 not assessed
0/5 criteria assessed
0 findings, 0 partial, 4 not assessed
Anti-pattern absence is not fully assessable from source coverage.
Fact-only current state · Crawl
1. Current-State Snapshot: The assessed organization is classified as Crawl with an evidence-gated readiness score of 3/100 and a maturity depth index of 17%. Anti-pattern burden is 29% (confirmed), with anti-pattern clearance of 10% and coverage of 83%. Delivery integrity is 100% across criteria returned, while evidence density sits at 58%. Domain scores are A=4/15, B=3/15, C=3/15, D=3/15, E=2/15, F=0/15. The audit recorded 22 anti-pattern findings, 3 verified absences, 15 maturity gaps, and 15 silent areas.
2. Evidence-Backed Findings: Strengths visible in the source include tagging used for allocation (cost center and m-code), reservation usage in targeted scopes, Hybrid Benefit utilization, some Spot use (e.g., Databricks), Azure Advisor reviewed at least annually for reservations, and PowerBI cost reports available on request. Confirmed gaps include: no active cost-governing policies on the platform (interviewee states Tällä hetkellä ei ole aktiivisena yhtään), unclear roles for cost responsibilities outside manager level, inconsistent cost visibility (not everyone sees their costs), manual cost allocation flow with invoices arriving a month late, limited anomaly detection (only individual subscriptions have anomaly alerts), no KPI on commitment coverage in some areas (with one mention that 95% utilization is informally aimed for), forecasting cycles showing up to 40% swings per quarter, service-demand growth not incorporated into budgets (e.g., Tämän vuoden budjetti on edellinen +2 %), almost no shutdowns of inactive resources, very limited autoscaling, and rightsizing not systematically followed up. The governance model is described as still in draft. GenAI/AI cost management (F) scored 0/15 with no source evidence.
3. Source Confidence & Boundaries: The source is interview-style notes covering visibility, allocation, reporting, forecasting, budgeting, development practices, commitments, anomaly detection, and rate optimization. It supports operational findings but does not contain quantified spend figures, tool inventories, or measured KPI baselines. AI/GenAI cost practices are silent. Evidence density at 58% means several criteria lack direct evidence and remain not assessable.
1. Current-State Snapshot: The assessed organization is at Crawl maturity with a 3/100 readiness score and 17% maturity depth. Anti-pattern burden is 29% (confirmed), clearance 10%, coverage 83%. Delivery integrity 100%; evidence density 58%. The audit recorded 22 anti-pattern findings and 15 maturity gaps across the domains.
2. Evidence-Backed Findings: Cloud spend is centralized under one unit's budget (excluding Oracle) and allocated to m-codes, with PowerBI reporting available. Budget framing is described as a fixed envelope into which activity must fit. The source describes a pure cost budget that does not reflect inbound revenue from service buyers (Puhdas kulubudjetti | epäreilua koska rahaa tulee myös sisään palveluiden ostajilta). Forecast accuracy is reported as variable with up to 40% swings in three-month cycles. Cost data reaches Controllers roughly half a month late, with invoices arriving a month after the period and manual journal entry creating human-error risk. There are no active cost-governing platform policies; anomaly detection exists only on individual subscriptions. Unexpected cost incidents have occurred (Log Analytics, Defender, Sentinel). A 10% cost-reduction target was mentioned alongside growing consumption. Domain F (GenAI/AI cost management) is silent (0/15).
3. Source Confidence & Boundaries: The audit can describe governance, allocation, forecasting, and reporting practices as reflected in interviews. It cannot quantify annual savings opportunity, ROI, or current unit economics because spend figures, benchmarks, and KPI baselines are not present in the source. Risk language here is qualitative.
1. Current-State Snapshot: Crawl classification, readiness 3/100, maturity depth 17%. Anti-pattern burden 29% (confirmed), clearance 10%, coverage 83%. Domain D (Architecture & Engineering) scored 3/15; E (Culture & Organization) 2/15; B (Rate & Usage) 3/15; F (GenAI) 0/15. Evidence density is 58%.
2. Evidence-Backed Findings: Architecture and engineering signals from the source: IaC adoption is uneven (Tietoaltaassa kaikki IaCina. HUS-Sote ei niin pitkällä); workloads are largely static with very limited autoscaling; shutdowns in inactive times are reported as not done by the assessed organization; rightsizing surfaces via Advisor but is not systematically followed up; storage tiering is used in places (e.g., genomics) but Archive tier underused; orphan/waste workbooks exist but periodic-only. Shared resources include networks, firewalls, ER, WAF, partial centralized logging, shared Kubernetes clusters, Databricks, and a centralized log-analytics retention policy (30 days, then to storage). Procurement-driven architecture frequently arrives pre-packaged with on-prem or SaaS preferences, limiting cloud-native design choices. Cost considerations in design are described as case-by-case rather than templated; modernization assessment in migrations is largely silent. Multi-cloud is acknowledged (Azure dominant, GCP for contingency, Oracle SaaS). Domain F is silent.
3. Source Confidence & Boundaries: The interview content evidences engineering practices qualitatively but does not provide architecture diagrams, workload-level performance data, or measured cost-per-feature. Statements about technology choices reflect interviewee perspective; the audit cannot independently verify the breadth of adoption across the estate.
Interpretation of evidence — not the implementation plan
Governance and operational cost-management mechanisms are largely informal or in draft, while cost handling downstream (allocation, reporting, invoicing) is manual and time-lagged, limiting the organization's ability to act on cost data.
Confidence (medium): Findings are grounded in interview content with consistent themes across multiple respondents, but evidence density is 58% and several criteria (notably F and parts of migration/development) are silent, limiting confidence on the full picture.
Locked findings show Crawl maturity with confirmed gaps in tagging coverage, cost-governing policies, manual lagging allocation, limited anomaly detection, weak commitment KPIs, minimal autoscaling/shutdowns, and a draft governance model. These support a foundation-stage roadmap. However, evidence density is 58% with several silent areas (notably Domain F, migration assessment, KPI definitions), confidence is medium, and no quantified spend or savings baseline exists. Action should proceed on the confirmed gaps while validating silent areas before scaling controls.
Locked findings show tagging used for allocation but visibility uneven, manual lagging cost flow with invoices a month late, no active cost-governing platform policies, anomaly detection limited to individual subscriptions, and unexpected-cost incidents discovered late. The governance model is described as draft and roles for cost responsibilities are not clear below manager level. Foundation work must close visibility and ownership basics before optimization can be measured. Per cautious mode, this phase prioritizes attribution, dashboards reachable by engineering, broader anomaly coverage, and finalizing the policy framework rather than scaling controls. Silent areas (Domain F, KPI baselines) need parallel validation.
Strengthen the tag and allocation foundation so attribution is reliable, give engineering teams visibility into the costs they influence, broaden anomaly detection beyond individual subscriptions, and convert the draft governance model into a published policy framework with named cost responsibilities. Validate evidence gaps in parallel (KPI baselines, AI workloads, migration assessment detail) so later phases can act on facts rather than assumptions. The intended outcome is consistent cost attribution, faster surfacing of anomalies, and a documented financial policy baseline. This phase does not claim to close optimization gaps; it establishes the conditions under which optimization actions become measurable.
Locked findings show reservations, Hybrid Benefit, and some Spot in place, but no consistent commitment coverage KPI, an unwritten commitment process, reservation visibility issues (e.g., Databricks reservation not visible in Azure), rightsizing recommendations surfacing in Advisor without systematic follow-up, shutdowns of inactive resources not practiced, and very limited autoscaling. Forecast swings up to 40% in three-month cycles and budgeting at prior +2% indicate weak budget controls. With the foundation established, this phase targets the optimization mechanics already partially present and adds the budget and lifecycle discipline needed to act on visible waste.
Operationalize the commitment process with documented coverage targets and utilization tracking, establish a recurring rightsizing review using existing Advisor signals, introduce resource lifecycle controls for inactive resources, and tighten budget enforcement so variance has named owners and escalation paths. The intent is to convert known but informal practices into governed, repeatable activities producing reviewable outcomes. The phase does not promise specific savings figures because no quantified baseline exists in the locked findings; outcomes are measured through coverage, utilization, waste recurrence, and budget variance signals rather than financial projections.
Locked findings show cost responsibilities not described in writing for most projects, CCoE recently formed (about a year), engineering engagement outside IT described as limited, IaC adoption uneven, design-stage cost considerations case-by-case rather than templated, and storage tiering used in places (e.g., genomics) but Archive tier underused with retention policy unclear. Procurement frequently dictates packaged architectures ahead of cloud-fit assessment. Embedding work links the foundation and optimization layers to engineering and finance routines so cost becomes part of how decisions are made, not a separate exercise.
Embed cost ownership in engineering routines, create a cross-functional cadence that brings finance, engineering, and the CCoE into shared decisions, introduce cost estimation at architecture review time so design-stage choices include cost evidence, and govern storage lifecycle for the data-lake estate where access patterns and retention can be defined. The intent is to make cost a routine input into engineering and architecture practice rather than a downstream report. Outcomes are measured through review participation, decision records that include cost rationale, and lifecycle policy coverage rather than dollar savings claims.
Locked findings show evidence density at 58% with Domain F (GenAI/AI cost management) entirely silent, no quantified spend or unit-economics figures, KPI definitions and targets largely undefined, and no documented chargeback/showback methodology beyond m-code allocation. Forecast accuracy remains weak. Once foundation, optimization, and embedding work has produced reliable data and routines, continuous-stage work can shift toward outcome-based measurement and address the AI cost surface if and when usage is confirmed. This phase remains conditional on evidence improvement during earlier phases.
Move FinOps measurement from activity to documented outcomes such as commitment coverage, waste recurrence, and budget variance, contingent on baselines established earlier. If AI/GenAI usage is confirmed during foundation-phase evidence gathering, introduce AI cost attribution as the entry point for Domain F. The intent is to sustain the practice through outcome tracking rather than expand scope ahead of evidence. This phase does not promise unit-economics maturity because the locked findings do not provide a baseline; it sets the conditions for outcome accountability once data is reliable.
The organization must implement a consistent, enforced tagging and labeling strategy across all cloud resources. Tags must map spend to business units, applications, environments, and cost centers. Untagged resources must be actively tracked and remediated.
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 minimal/partial maturity score: tagging is used for allocation and can be applied by automation, but there are documented gaps including many untagged resources, Terraform tagging issues, and reservations not appearing in tagged reports. No documented/enforced policy or SLA remediation is evidenced.
The organization must have mechanisms to attribute cloud costs back to consuming teams or business units. This can be showback (visibility without billing) or full chargeback (actual cost transfer). The model must be transparent and accepted by stakeholders.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports partial showback/chargeback capability: costs are split to codes, Azure consumption is billed onward to Sote areas, and there is an allocation process. However, the same evidence shows it is manual, delayed, and shared-cost logic is fragmented, with no evidence of stakeholder acceptance or regular refinement.
The organization must have automated systems to detect unexpected cost spikes, billing anomalies, and budget threshold breaches. Alerts must reach the right stakeholders in near-real-time with actionable context.
Crit 1: Partially met at best. Anomaly alerts exist in individual subscriptions, but coverage is fragmented and mostly aspirational/planned at broader scope. No evidence of systematic detection within 24 hours across all scopes. Score aspirational/partial = 1 max. Crit 2: Not met. Alerts do not consistently include actionable context or route to responsible teams. Response is described as 'manual human work' without defined ownership routing. Crit 3: Not met. No defined response process or escalation path documented. Total: 1.
The organization must provide accessible, role-appropriate cost dashboards to all stakeholders. Engineering sees resource-level detail; finance sees business-unit rollups; executives see trends and forecasts. Dashboards must be current, not stale.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports partial dashboard/reporting maturity: PowerBI reporting and subscription-level dashboards exist, and some groups review cost data monthly/weekly. The evidence also supports the scanner's limitations: not everyone can see their own costs, timeliness can be half a month, and reporting is split across PowerBI, Azure dashboards, and finance Excel/reporting.
The organization must measure cloud cost efficiency in business terms — cost per customer, per transaction, per API call, or per revenue dollar. Raw spend is insufficient; unit economics connect cloud investment to business value.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The zero score is supported. The source contains only aspirational or very limited references to business value and unit economics; it does not show active cost-per-customer, cost-per-transaction, unit-cost trend monitoring, or engineering unit-cost targets.
The organization must actively manage commitment-based discount instruments (Reserved Instances, Savings Plans, Committed Use Discounts) to reduce on-demand pricing. Coverage targets must be set, tracked, and optimized.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 2 to 1. Verifier status: weak. The cited commitment evidence is real and traceable in src-001-c001/src-001-c008. It supports use of reservations, Hybrid Benefit, expiry alerts, and some utilization alerting. However, the source also says usage is not comprehensive, there is no written process, no coverage KPI, poor visibility for some reservations, and Advisor review is at least annual rather than quarterly. Only commitment utilization/management is clearly partially supported; defined coverage targets and quarterly portfolio review are not.
The organization must continuously analyze resource utilization and right-size instances, databases, and services to match actual demand. Over-provisioned resources represent waste; under-provisioned resources create performance risk.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The quotes are present in src-002-p002-c002 page 2. They support a limited right-sizing practice for Innofactor-managed resources, monthly review in that scope, and Azure Advisor recommendations that are not systematically followed by HUS. No evidence supports organization-wide right-sizing or financial impact tracking, so the low score of 1 is appropriate.
The organization must actively identify and terminate orphaned resources (unattached volumes, unused IPs, idle load balancers), zombie instances, and dev/test environments left running outside business hours.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 1 to 0 after a targeted rescan. Verifier status: weak. The cited page supports occasional workbook/Advisor-based orphan-resource reviews and project/system-owner approval for deletion, while also describing the practice as poor. It also supports that inactive-time shutdowns are not done at HUS. This justifies only a minimal maturity score; automation and waste KPI/targets are not evidenced.
The organization must leverage spot/preemptible instances for fault-tolerant and batch workloads to achieve significant rate reductions. Workload architecture must support interruption handling.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The spot-instance quotes are traceable in src-001-c001 and show some limited/individual/test usage plus a Databricks-related statement. However, the evidence is internally mixed because another cited quote says Databricks is no longer spot. There is no evidence of a spot strategy, interruption-handling pattern, or savings tracking. A minimal score is defensible only as weak evidence of limited usage, not strategy maturity.
The organization must implement storage lifecycle policies that automatically tier data from hot to warm to cold storage based on access patterns. Retention policies must be enforced to prevent unbounded storage growth.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 1 to 0 after a targeted rescan. Verifier status: weak. The cited evidence supports some storage tiering/data optimization in specific areas, project-specific backup rules, and a 30-day Log Analytics policy before pushing data to storage. The same source indicates lack of a single broad policy and limited archive/cold-tier use. No automated lifecycle policy or per-GB optimization monitoring is evidenced, so the low score of 1 is supported.
The organization must have a documented cloud financial management policy framework covering spend limits, approval workflows, resource provisioning standards, and accountability structures. Policies must be enforced, not aspirational.
Crit 1: A hallintamalli (governance model) exists but has been in draft since 2018, lacks documented responsibilities, and is described as still in progress or 'at the speech level' - aspirational at best. Score partial. Crit 2: No automated guardrails (SCPs, Azure Policy, OPA) are mentioned as actively enforced. Respondent confirms 'currently none are active'. No evidence of automated policy enforcement. Not met. Crit 3: No regular policy review cadence is described. Not met. Total: 1 (aspirational/partial framework only).
The organization must maintain cloud budgets at the team, project, and organizational level with accurate forecasting. Budget-to-actual variance must be tracked monthly, with variance analysis driving corrective action.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The score is supported. src-001-c015 confirms budgeting exists at m-code/cost-center level, and src-001-c001 confirms forecasting every three months with possible 40% variance. The same source indicates business/service growth is not incorporated, so only limited budget/forecast maturity is evidenced.
The organization must have a defined FinOps operating model with clear roles, responsibilities, and RACI matrices. Whether centralized, federated, or hybrid, the model must have executive sponsorship and operational cadence.
Crit 1: No defined RACI matrix. Respondents explicitly state 'no responsibilities around costs', 'Marjo is the only person in CCC', and that the overall model (FinOps, RACI, unified operating model) is aspirational work still to be done. Score: not met. Crit 2: CCoE was started only ~1 year ago. There is mention of 'johdon tuki' (management support) being better now, but no formal executive sponsorship or steering committee engagement is described. Score: not met. Crit 3: CCoE reviews costs monthly, Jaakko's team weekly - some operational cadence exists. Score: partially met. Total: 1 (only a weak operational cadence exists; formal operating model, RACI and executive sponsorship are absent or aspirational).
The organization must have a structured approach to cloud procurement including Enterprise Discount Programs (EDPs), negotiated pricing, and multi-year agreements. Vendor relationships must be actively managed, not passively consumed.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 1 to 0. Verifier status: weak. The quotes are traceable and show weak commitment/procurement governance, including unclear 3-year reservation guidance and supplier-contract confusion. However, the maturity criteria require evidence of negotiated pricing/EDPs/private rates, structured vendor management, benchmarking, and documented multi-year commitment justification or exit analysis. Those are not supported by the cited material. The scanner's mention of EDP-type constructs is not evidenced.
The organization must ensure cloud financial operations comply with regulatory requirements including data residency cost implications, audit trail requirements, and financial reporting standards.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 1 to 0. Verifier status: weak. The cited quotes are real or faithful excerpts and show awareness of Sentinel, Defender, logging, and Sweden-region cost concerns. However, they do not demonstrate the maturity capability: systematic data residency cost-impact analysis, audit trails for cloud financial decisions, or separate tracking/justification of compliance-driven cost increases. The score is therefore too generous for the stated criteria.
Engineering teams must consider cost as a first-class architecture constraint alongside performance, reliability, and security. Architecture reviews must include cost modeling. The cheapest architecture that meets requirements wins.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited quote is present in src-001-c001 and supports only informal/project-dependent architecture cost discussion when Innofactor participates. The raw material does not support formal first-class cost constraints, required cost modeling, or broad engineering cost visibility, so the low score of 1 is adequately supported and should not be higher.
Infrastructure provisioning must be codified (Terraform, Pulumi, CloudFormation) with embedded cost guardrails. Policy-as-code must prevent provisioning of oversized or non-compliant resources before deployment.
Crit 1 (All infrastructure provisioned through IaC): Partially met - IaC is used in some areas (Tietoallas fully, Terveyskyla well) but not universally; HUS-Sote is not as advanced. Partial evidence only, score capped at 1. Crit 2 (Cost guardrails embedded in IaC pipeline): Not found. No mention of Infracost, OPA, or any policy-as-code preventing over-provisioning. Crit 3 (Cost estimation step in CI/CD pipeline): Not found. No evidence of any cost estimation in deployment pipelines. Total: 1.
The organization must implement automated scaling (horizontal and vertical) based on demand signals to avoid both over-provisioning (waste) and under-provisioning (performance degradation). Scaling policies must be tested and monitored.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The cited PDF page 2 quote is present and clearly states autoscaling is used very little and applications are mostly static, with only some small scalable container solutions. This supports a very weak/limited autoscaling signal, but it does not clearly evidence production scaling policies, policy testing, or cost monitoring of scaling events.
If operating across multiple cloud providers or hybrid environments, the organization must have unified cost visibility, consistent tagging, and cross-provider optimization strategies. Single-pane-of-glass for total cloud economics.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source mentions Azure dominance with GCP possible and Oracle/SaaS references, but does not provide evidence of unified cross-provider cost visibility, normalized tagging/allocation, or cost-based cross-provider workload placement. A score of 0 is supported.
The organization must optimize container orchestration (Kubernetes) for cost efficiency including pod right-sizing, cluster autoscaling, and bin-packing. Serverless workloads must be monitored for execution cost and duration optimization.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source mentions Kubernetes clusters, shared resources, Databricks centralization, and some function/serverless usage, but does not evidence Kubernetes cost optimization practices, serverless execution cost optimization, or a formal container/serverless/VM decision framework. A score of 0 is supported.
The organization must have a dedicated FinOps function — whether a central team, federated practitioners, or a virtual CoE. This team drives standards, tooling, training, and optimization campaigns across the organization.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited CSV text supports that a CCC/CCoE-like function exists, including a virtual architecture team and shared-governance activities, but is immature, lightly funded, and effectively dependent on one named CCC resource. The raw material does not support measurable cross-organizational savings campaigns or mature value-enabler positioning, so a low score of 1 is appropriate.
Engineering teams must own the cost of the resources they provision. Cost accountability must be embedded in team objectives, sprint reviews, and performance evaluations — not siloed in finance.
Final maturity assessment: Partial. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The quoted text is present and supports some cost/budget responsibility at manager or project-owner level, while also showing that cost responsibilities are not broadly clear. However, the evidence is weak for true engineering cost accountability: it does not show cost efficiency in engineering OKRs, sprint reviews, performance evaluation, or incentives, and the quoted 'päällikkötaso' responsibility is not necessarily engineering-team accountability.
FinOps must have executive sponsorship (CTO, CFO, or VP-level) with active engagement, not just nominal support. Executives must participate in FinOps reviews and allocate budget for tooling and headcount.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source mentions a need for management support and limited CCoE budget, but does not show active executive FinOps sponsorship, regular executive FinOps reviews, dedicated executive funding for FinOps tooling/training/headcount, or cloud cost efficiency as a standing executive agenda item.
FinOps requires active collaboration between finance, engineering, and business stakeholders. These groups must share a common language, common tools, and common goals around cloud investment.
Final maturity assessment: NOK. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: supported. The source shows some recurring cost review activity and finance/controller involvement, but the scanner's zero score is supported because the material does not evidence mature cross-functional collaboration with shared tooling/language, a structured joint FinOps cadence across finance-engineering-business, or shared accountability. Manual handoffs from Jaakko/service management to Esa/controller and ERP/Excel processing indicate weak integration rather than mature collaboration.
The organization must treat FinOps as a continuous improvement discipline, not a one-time project. Internal benchmarking (month-over-month, team-vs-team) and external benchmarking (industry peers) must drive ongoing maturity.
Crit 1: Not found — no mention of FinOps retrospectives or maturity assessments. Crit 2: Not found — no internal benchmarking described. Crit 3: Not found — no external benchmarking referenced. The document covers operational interviews about cloud cost practices but does not address continuous improvement or benchmarking as disciplines. Total: 0.
The organization must be able to see AI token, API, model, and inference spend by application, team, use case, customer, and environment. AI consumption must be visible as an operational cost surface, not only as a provider invoice line.
Crit 1: No evidence of token, API, model, or inference spend tracking by application, use case, team, or environment. Crit 2: No mention of provider model endpoints, retry costs, cache, or batch cost drivers for AI. Crit 3: No dashboard or alert views for AI cost trends mentioned. Document is silent on GenAI entirely. Total: 0.
The organization must map GenAI costs to products, workflows, customers, transactions, or business outcomes. AI costs should be connected to unit economics so teams can judge whether usage is economically justified.
Crit 1: No evidence of LLM or AI platform costs allocated to products, workflows, customers, or business units. Crit 2: No documented shared AI platform cost allocation model. Crit 3: No unit metrics for AI tasks, workflows, or outcomes. Document is silent on AI cost allocation. Total: 0.
The organization must optimize GenAI cost through model routing, prompt design, context management, caching, batching, retry controls, and cost-quality tradeoff measurement. Premium models should be used intentionally where quality, risk, or reasoning need justifies them.
Crit 1: No model-routing policy mentioned. Crit 2: No monitoring of prompt length, context size, retrieval scope, caching, batching, retry behavior, or agent loops for AI. Crit 3: No cost-quality-latency tradeoff measurement for AI models. Document is silent on AI optimization. Total: 0.
The organization must govern AI consumption with budgets, quotas, alerts, approvals, anomaly detection, and forecasting. AI workloads need guardrails against runaway spend from high-volume usage, retries, context growth, or experimental systems becoming production traffic.
Crit 1: No AI-specific budgets, quotas, alerts, or approval thresholds for AI applications or model tiers. Crit 2: No AI spend forecasting or anomaly monitoring for token volume, retries, or context growth. Crit 3: No production AI workload guardrails such as rate limits or model-access controls. Document is silent on AI budgeting/guardrails. Total: 0.
The organization must compare AI consumption cost against business value, productivity gain, quality improvement, risk reduction, or revenue impact. AI governance should include cost ownership and decisions about whether AI usage is worth continuing.
Crit 1: No evidence of AI costs compared against productivity gain, quality improvement, risk reduction, or revenue impact. Crit 2: No AI cost ownership or governance structure across product/engineering/finance/risk. Crit 3: No review or retirement process for low-value AI use cases. Document is silent on AI value realization. Total: 0.
Cloud resources lack consistent tagging or have inconsistent, redundant tag taxonomies. Cost allocation is impossible or unreliable. Untagged spend is treated as acceptable overhead rather than a governance failure.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports a partial tag-sprawl/missing-tags anti-pattern signal: many resources without tags are explicitly noted, Terraform tagging issues are mentioned, and reservations do not appear in tagged reporting. The scanner correctly limits the score because there is no quantified >20% untagged-spend figure or explicit statement that untagged spend is accepted as overhead. Coverage interpretation: Relevant tagging and allocation questions are covered, and they show real but partial harmful signals. The evidence is insufficient to confirm the full anti-pattern at high severity.
Cloud costs are visible only to a small group (typically finance or a single cloud admin). Engineering teams cannot see the cost of the resources they provision. Cost is discovered only during monthly invoice shock.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 1. Verifier status: weak. The quotes are real and support uneven/restricted cost visibility: not everyone can see their own Azure costs, PowerBI access may require a request, and some issues were found late. However, the score of 2 is somewhat too strong because the source also shows some PowerBI/Azure reporting access and does not prove that spend is visible only to finance or a single admin, nor that overruns are discovered only via monthly invoice shock. Coverage interpretation: There is a real partial black-box spend signal, but coverage also shows some available reporting and access paths, so the harmful pattern is not fully established.
Cost data is stale — reports arrive days or weeks after the spend occurs. By the time anomalies are discovered, the damage is done. No near-real-time cost signal exists.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 2. Verifier status: supported. The source strongly supports delayed reporting: cost data may be delayed by about half a month, invoices arrive a month late, allocation uses manual Excel work, and entries are manually keyed into the ERP. It also supports fragmented/reactive anomaly detection, though some subscription-level anomaly alerts exist, so a score of 2 rather than 3 is appropriate. Coverage interpretation: Relevant reporting timeliness, manual allocation, and anomaly-response questions are covered and show the harmful pattern substantially present, but not absolute because some anomaly alerting exists.
Each cloud provider, account, or team has its own cost view with no unified perspective. Total cloud economics is unknown. Finance sees invoices; engineering sees resource metrics; nobody sees both together.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The source supports a low/partial siloed-cost-view signal: getting a unified view is described as difficult, reporting appears split across subscription dashboards, CCoE/Jaakko review processes, controller processes, PowerBI, and finance Excel. The scanner appropriately does not claim stronger evidence such as conflicting finance vs engineering numbers or inability to calculate total cost per customer. Coverage interpretation: The source has relevant reporting and visibility coverage showing partial fragmentation, but not enough to confirm the full anti-pattern at higher severity.
The organization tracks meaningless or misleading cost metrics — total spend without context, percentage discounts without baseline, or savings numbers that cannot be verified. Metrics look good on slides but drive no real optimization.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 1 to 0. Verifier status: unsupported. Adjudication: The cited source shows cost KPIs and business-value metrics are mostly absent or aspirational, e.g. KPIs are only 'in thoughts' and cloud value is considered mainly at total cost level. This supports weak metric maturity, but not the specific harmful anti-pattern of vanity cost metrics such as misleading executive metrics, unverifiable savings claims, or dashboards optimized for presentation rather than action. Coverage interpretation: The source has limited coverage of KPI and business-value practices, but does not substantively cover executive reporting content, savings-claim validation, or whether metrics drive behavior change. The vanity-metrics anti-pattern is therefore not assessable from the available source coverage.
The organization runs predominantly on on-demand pricing despite stable, predictable workloads. Fear of commitment (vendor lock-in anxiety, forecasting uncertainty) results in paying 40-70% premiums unnecessarily.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The cited source supports commitment hesitancy and fragmented/narrow reservation use: not comprehensive, no large-scope reservations, weak readiness to commit, and difficulty establishing guidance for 3-year reservations. It does not quantify that more than 50% of stable workloads are on-demand or prove that on-demand premium has never been calculated. A score of 1 for partial commitment-avoidance signal is supported. Coverage interpretation: Relevant commitment-management coverage exists, and it shows partial harmful signals, but not enough quantitative evidence to confirm the full anti-pattern.
Resources are systematically oversized 'just in case.' Instances run at 5-15% CPU utilization. Databases are provisioned for peak capacity that never arrives. Nobody right-sizes because nobody owns the waste.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The cited evidence supports weak over-provisioning/right-sizing risk signals: Advisor recommendations remain open, vendor-required specifications can block resizing, autoscaling is very limited, and HUS follow-up is not systematic. However, there are no utilization figures, no evidence of systematic average CPU below 20%, and no direct proof of chronic organization-wide oversizing. The score is only weakly supported. Coverage interpretation: Relevant right-sizing coverage exists and shows partial harmful signals, but it lacks utilization metrics and scale/extent evidence needed to confirm chronic over-provisioning.
Teams accumulate cloud resources they no longer use — stopped instances with attached storage, orphaned snapshots, unused IP addresses, dev environments left running permanently. Cleanup is nobody's job.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The evidence supports a resource-hoarding/zombie-resource risk: orphan/waste management is described as poorly done, scheduled shutdowns are not used at HUS, and an example is given of resources running at night. The evidence is not quantified and does not prove significant numbers of orphaned resources, so the conservative score of 1 is appropriate. Coverage interpretation: Relevant waste/shutdown coverage exists and shows partial harmful-pattern evidence, but the extent and financial impact are not quantified.
Cost optimization is a manual, periodic exercise — someone reviews a spreadsheet quarterly and makes recommendations. There is no automation, no continuous optimization, no integration with engineering workflows.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited evidence supports manual/periodic optimization practices: monthly review only for Innofactor-managed resources, Advisor not followed regularly elsewhere, and recommendations informally passed to vendors. There is no evidence of continuous automated optimization or CI/CD integration. A low anti-pattern score of 1 is supported. Coverage interpretation: The packet contains relevant optimization-process coverage and shows partial manual-only optimization behavior, though not enough to prove the full anti-pattern across all optimization domains.
The organization does not understand how discounts interact across providers. Savings Plans applied to already-discounted workloads, conflicting commitment types, or unused negotiated rates indicate a lack of rate optimization sophistication.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The cited evidence supports fragmented reservation visibility and narrow reservation scoping, including poor visibility into Databricks reservations. It does not directly evidence misunderstanding of discount interactions, overlap/double-coverage problems, or conflicting commitment types. The score is therefore weakly supported only as a governance/visibility signal, not as clear discount-stacking ignorance. Coverage interpretation: Commitment/discount coverage is relevant but does not directly test discount-stacking interaction knowledge. Partial harmful signals exist around visibility and portfolio governance, so absence cannot be confirmed.
Teams or individuals create cloud accounts outside the governed organizational structure. Spend occurs on personal credit cards, department accounts, or unlinked accounts. Total cloud exposure is unknown.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The quoted evidence supports governance fragmentation and visibility/budgeting gaps, including 80 project codes and more than 20 places not budgeting Azure costs. It does not support the stronger shadow IT criteria of personal-credit-card spend, unlinked accounts, or cloud accounts outside the governed organizational structure. Coverage interpretation: Relevant governance and visibility coverage exists in src-001-c001, but it only evidences fragmentation inside known structures, not confirmed shadow accounts or unlinked spend.
Cloud budgets are set but not enforced. Overruns are discovered after the fact with no consequences. Forecasts are fiction. The budget process is a compliance exercise disconnected from operational reality.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The score is supported. src-001-c001 confirms forecast variance up to 40%, budgets that do not account for service-demand growth, and overruns handled by cutting other budgets. This supports a materially disconnected budgeting/forecasting pattern, although not every sub-criterion is fully proven. Coverage interpretation: The source has direct coverage of budgeting and forecasting practices and contains concrete harmful-pattern signals, but the evidence does not fully prove all three anti-pattern criteria.
The organization has FinOps titles, meetings, and dashboards but no actual optimization outcomes. FinOps is a checkbox for management reporting, not an operational discipline. Meetings happen but nothing changes.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The evidence supports a weak signal: CCoE/FinOps structures are nascent, RACI and operating model work remain unresolved, and Azure Advisor review is not regular. However, the source does not show classic 'FinOps theater' with mature-looking roles/dashboards that produce no outcomes, nor does it show false Walk/Run maturity claims. The scanner correctly notes this is more nascent than theatrical. Coverage interpretation: The source has relevant FinOps operating-model coverage and shows weak process-without-outcome signals, but not enough to confirm the full anti-pattern.
The organization makes major cloud commitments (multi-year EDPs, proprietary service adoption) without evaluating exit costs, portability, or competitive alternatives. Lock-in is accepted by default rather than managed deliberately.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: weak. The cited quotes are traceable and support weak vendor/commitment governance: unclear 3-year reservation guidance, Databricks pre-purchase friction, and poor understanding of multiple supplier contracts. They do not directly prove major commitments made without exit-cost or portability analysis, default acceptance of lock-in, or lack of competitive benchmarking. Coverage interpretation: The source covers procurement and commitment issues enough to show partial harmful signals, but not enough to confirm full vendor lock-in blindness.
Regulatory and compliance requirements create cost surprises because they are not integrated into architecture planning. Data residency, encryption mandates, and audit requirements add unplanned spend.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 1. Verifier status: weak. The quotes support one clear harmful signal: security/compliance-adjacent costs such as logging, Sentinel, and Defender have caused or may cause cost surprises. The Sweden-region cost ownership issue is also relevant but not enough to prove systematic data-residency cost failure. The evidence does not directly establish that regulatory cost impact is absent from architecture design reviews or that compliance-driven infrastructure choices are generally made without cost analysis. A score of 2 is therefore too strong. Coverage interpretation: Relevant evidence exists for logging/security cost surprises, but coverage is insufficient to verify the broader compliance-cost-afterthought pattern at the scanner's strength.
Workloads are migrated to the cloud with their on-premises sizing intact. Virtual machines mirror physical server specs. No cloud-native optimization occurs post-migration. The cloud becomes an expensive colocation facility.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1 after a targeted rescan. Verifier status: supported. The cited src-002 page 2 quotes are present and support a partial harmful signal: workloads are largely static and rightsizing recommendations may be blocked by supplier-required specs. The source does not directly prove retained on-prem sizing or physical-server mirroring, so the low partial score of 1 is appropriate. Coverage interpretation: Relevant optimization/rightsizing/autoscaling coverage exists and shows partial lift-and-shift-like inefficiency, but not enough to confirm the full anti-pattern.
Architecture decisions are made purely on technical merit without cost modeling. Teams choose services, instance types, and configurations based on features or familiarity, not cost-performance tradeoffs.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 1 after a targeted rescan. Verifier status: weak. The cited excerpts are traceable in src-001-c001 and support a meaningful cost-blind architecture pattern: architecture is often driven by procurements, cloud-strategy alignment is missing in procurement evaluation, costs have surprised teams, and cost controls are project-specific rather than systematic. The service-selection-by-familiarity criterion is weaker, but the overall score of 2 is supported. Coverage interpretation: Architecture/design-process coverage is relevant and shows recurring lack of systematic cost modeling/controls, but not every cost-blind criterion is directly evidenced.
Autoscaling is configured without cost ceilings. A traffic spike or runaway process can scale resources to unlimited cost. There are no circuit breakers between demand signals and infrastructure provisioning.
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 indicates autoscaling is used very little and applications are mostly static. Unexpected cost examples are tied to logging, Sentinel, and Defender rather than runaway autoscaling. The scanner's 0 score is supported. Coverage interpretation: The packet includes directly relevant autoscaling and unexpected-cost coverage; that coverage points away from scaling-without-limits and toward limited autoscaling instead.
The organization is locked into a single cloud provider without evaluating whether specific workloads would be more cost-effective elsewhere. Provider loyalty overrides economic rationality. Competitive pricing pressure is absent.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 1 to 1. Verifier status: weak. The cited multi-cloud quote is traceable in src-001-c021 and supports Azure-centric practice with GCP possible but not common. The second quote is also a faithful excerpt from src-001-c001. The evidence supports only a partial tunnel-vision signal, not full provider lock-in or absent benchmarking, so the low score of 1 is appropriate. Coverage interpretation: Relevant multi-cloud-policy coverage exists and shows practical Azure concentration, but the material also mentions GCP/Oracle use or possibility, so full single-cloud tunnel vision is not proven.
Large monolithic applications prevent granular cost allocation and optimization. The entire monolith must be scaled together even if only one component is under load. Decomposition is deferred indefinitely.
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 evidence monolithic applications preventing granular cost allocation, forcing whole-application scaling, or causing deferred decomposition. The scanner's 0 score is supported, but absence is not strongly tested because application decomposition coverage is limited. Coverage interpretation: The available architecture material discusses fragmentation, shared resources, Kubernetes/Databricks, and static workloads, but it does not provide enough application-structure/decomposition evidence to meaningfully test for monolith tax.
Cloud cost management is viewed as solely an IT or infrastructure responsibility. Business stakeholders who drive demand feel no accountability for cost. Engineers who provision resources never see the bill.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The cited source text supports a harmful pattern where cloud-cost understanding and action are centered in IT/tietohallinto, with unclear cost responsibilities, limited customer/business visibility, and an explicit statement that outside IT there is little interest in improving cloud use. The evidence does not prove the pattern is universal or absolute, but it supports two criteria at least partially. Coverage interpretation: The harmful pattern is evidenced but partial: cost ownership appears IT-centered and business/customer visibility is limited, while some areas can request access or have localized accountability.
Cost overruns trigger blame and punishment rather than systemic analysis. Teams hide cost problems instead of surfacing them. Cost discussions are adversarial between finance and engineering rather than collaborative.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 0 to 0 after a targeted rescan. Verifier status: weak. The scanner is correct that the provided material does not show blame, punishment, hiding of cost problems, or adversarial finance-engineering behavior. However, because the packet has weak coverage and the interviews do not directly test psychological safety or blame dynamics, the claimed absence should not be treated as strongly verified. Coverage interpretation: There is some coverage of overruns and escalation, but no direct questioning or evidence about blame/punishment behavior. With weak coverage, absence of this anti-pattern is not fully assessable.
Leadership talks about FinOps but does not invest in it. No dedicated team, no tooling budget, no training. FinOps is an additional duty for someone who already has a full-time job. Optimization is expected to happen organically.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 2 after a targeted rescan. Verifier status: supported. The cited quotes are present and support underinvestment/immaturity relative to stated cloud-first or FinOps ambitions: CCoE has little budget, Marjo is the sole CCC resource, larger operational FinOps work remains undone, and cloud-first is described as partly at the level of talk. The evidence is stronger for underinvestment and thin staffing than for explicit executive FinOps rhetoric, but the original score of 2 is supportable. Coverage interpretation: The harmful pattern is partially present: there is evidence of limited budget, thin staffing, and unfinished operationalization, though the source does not fully prove leadership formally endorses FinOps while withholding all investment.
Finance and engineering operate as separate fiefdoms with different tools, languages, and objectives around cloud spend. Finance sees cost centers; engineering sees resource metrics. Translation between them is manual and lossy.
Final anti-pattern assessment: Partial finding. Evidence-check resolved the scanner score from 2 to 1 after a targeted rescan. Verifier status: weak. The quoted source text supports manual and delayed translation between service-management/cloud cost data and finance/controller processes: Jaakko provides cost data to Esa, work is manual, billing is month-late, Excel adjustments are used, and invoices are manually entered into ERP. The controller question about connecting to where billing originates also supports a finance-technical disconnect. This adequately supports a partial finance-engineering wall score. Coverage interpretation: The harmful pattern is evidenced as partial separation and translation overhead between finance and technical cost sources. The source does not prove a complete wall or adversarial separation, but it supports two criteria at least partially.
The organization treats FinOps maturity as a destination rather than a continuous journey. After initial optimization efforts, the discipline atrophies. No regular maturity assessment, no improvement targets, no benchmarking.
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 does not support a static maturity assumption. Instead, it repeatedly indicates that cloud/FinOps work is immature or still in progress, with comments such as larger operational work remaining, CCoE still being early-stage, and much still to do. No evidence shows the organization believes FinOps maturity is complete or that optimization momentum has atrophied after a completed program. Coverage interpretation: Relevant maturity/culture coverage exists and points away from complacency: the organization acknowledges immaturity and unfinished work. Lack of external benchmarking is not enough by itself to evidence the static-maturity anti-pattern.
AI/API usage exists, but token and model costs are not visible by owner, use case, application, or system. GenAI cost appears only as a provider invoice or platform total, preventing accountability.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The scanner did not claim the anti-pattern is present. The supplied source material contains no evidence that GenAI/AI API spend exists, and no token/model spend visibility gaps are described. Therefore the harmful pattern is not evidenced. Coverage interpretation: Absence cannot be tested because the interview material is largely about general Azure/cloud FinOps and appears silent on GenAI/LLM usage. With weak domain coverage, lack of AI mention should not be treated as proof that invisible token spend is absent.
Experiments, pilots, or playground usage become production AI consumption without cost governance. Sandbox keys, prototypes, or ad hoc integrations accumulate persistent spend without lifecycle review.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. No source evidence describes AI experiments, playgrounds, sandbox AI keys, prototypes, or AI pilots moving into production without governance. The scanner's zero count is supported. Coverage interpretation: The source does not appear to cover AI lifecycle governance at all, so absence of playground-to-production AI drift is not meaningfully tested.
Expensive models are used where cheaper models, caching, batching, smaller context, or simpler workflows would meet the need. Model choice is driven by convenience or prestige rather than measured cost-quality fit.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source does not mention premium AI model usage, model selection, cheaper model alternatives, AI caching/batching, or premium-model retry/agent-loop costs. The anti-pattern is not evidenced. Coverage interpretation: Because the provided material is silent on AI model usage and model-selection practices, the anti-pattern cannot be considered tested absent.
RAG, prompt, memory, or conversation context grows without cost-quality control. The organization pays for excessive tokens because retrieval scope, history length, documents, or prompt structures are not governed.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. No source evidence mentions RAG, prompts, context windows, conversation history, AI retrieval scope, token budgets, or context-cost instrumentation. The scanner's zero count is supported. Coverage interpretation: The source material does not cover AI architecture or context-management practices, so absence of unbounded context growth is unknown rather than tested.
AI usage is celebrated while cost per outcome is unknown. The organization tracks usage, pilots, or activity volume but cannot show whether AI spend improves productivity, quality, revenue, risk, or customer outcomes.
Final anti-pattern assessment: Not assessed. Evidence-check resolved the scanner score from 0 to 0. Verifier status: supported. The source includes general cloud/data value comments but no evidence of AI adoption being celebrated, AI activity dashboards, AI pilots, or AI use cases continuing without ROI. The anti-pattern is not evidenced. Coverage interpretation: The available evidence is not focused on AI value realization or GenAI adoption governance, so the absence of AI Value Theater cannot be confirmed.
Quality Gate detail is retained here for traceability. WARN-level strategy hygiene notes do not invalidate the assessment score.
The gate did not block the assessment, but it found that several scores and Phase 3 statements were not fully grounded in verified evidence. Strategy hygiene notes were retained for traceability; they do not invalidate the score. Read the maturity results with attention to downgraded or zero-scored criteria where the source actually contains discussion.
This snapshot shows how parsed source material was chunked, sampled for DLP review, and routed into A-F context packets before model audit. Packetization controls attention, not truth: findings still require verified source evidence.
| Metric | Value |
|---|---|
| Source documents | 3 |
| Parsed chunks | 41 |
| DLP review chunks | 8 |
| High-risk DLP hits | 0 |
| Caution DLP hits | 0 |
| Packet | Included chunks | Candidate chunks | Coverage | Characters |
|---|---|---|---|---|
| ACost Visibility & Allocation | 5 | 6 | OK | 35,438 |
| BRate & Usage Optimization | 3 | 5 | OK | 36,118 |
| CGovernance & Policy | 5 | 6 | OK | 35,091 |
| DArchitecture & Engineering | 4 | 5 | OK | 34,983 |
| ECulture & Organization | 4 | 8 | Weak coverage | 35,208 |
| FGenAI & AI Cost Management | 3 | 4 | Weak coverage | 34,710 |
RunTrace is a client-side provenance artifact. It records source/chunk references, hashes, model-stage metadata, evidence paths, score paths, tactic paths, and Quality Gate decisions without embedding full raw source documents or full prompts.