The Data Lifecycle
Nine stages from Connect to Emit. Everything in the platform flows through this one pipeline.
Everything in Varcio FinOps Copilot flows through one pipeline. Each module sits at a specific point on it, and knowing where a module sits explains most of its behaviour.
Stage 1 — Connect
An administrator registers a cloud connection. For AWS this means creating a read-only IAM role that trusts the platform identity with a per-customer External ID — no access keys change hands. Azure uses a Service Principal, GCP a Service Account key, and OCI an API signing key, all encrypted before persistence.
A preflight check then verifies the credential works and reports precisely which permissions are missing, rather than failing opaquely later.
A connection may optionally carry a second, higher-privilege execution role. Read access powers analysis; the execution role is what makes remediation possible. They are verified and stored separately, so you can run the entire product in read-only mode indefinitely.
Module: Cloud Accounts
Stage 2 — Ingest
Billing data arrives through provider-specific paths — AWS Cost Explorer for fast summaries and CUR-via-Athena for authoritative detail, Azure Cost Management, GCP BigQuery billing export, the OCI Usage API. A generic CSV path covers edge cases.
Every run is recorded with record counts, timing, and errors, so ingestion health is itself observable.
In parallel:
| Stream | What it provides |
|---|---|
| Telemetry ingestion | Utilisation metrics from CloudWatch, Azure Monitor, GCP Monitoring, OCI Monitoring |
| Inventory scanning | Enumeration of live resources |
| Deployment events | So cost changes can later be correlated with the change that caused them |
| Cloud activity events | Control-plane activity in your providers |
Modules: Overview, Intelligence
Stage 3 — Normalize
Raw provider data is mapped onto the common ledger. Normalization rules standardise the team, environment, feature, and tenant dimensions across sources that name them differently, and a FOCUS normaliser aligns the ledger with the FinOps Foundation's open cost specification.
Without this stage, cross-cloud comparison and team-level allocation would both be impossible. This is why normalization rules are the first thing to configure in Policies.
Stage 4 — Detect
The waste engine runs the detector registry against live inventory, ingested telemetry, and the normalised ledger. Detection is layered:
Spend-pattern rules
Operate on the normalised ledger alone — weekend baseline leaks, duplicated environments, cross-account waste.
Live inspection rules
Enumerate real resources — unattached volumes, unused elastic IPs, orphaned load balancers, stale snapshots.
Utilisation rules
Require measured telemetry — underutilised compute, database and cache, multi-signal rightsizing on p95 CPU.
Log-derived rules
Read provider logs — Lambda memory rightsizing from Logs Insights, log-group ingestion cost priced per gigabyte.
Identity & security rules
Inspect IAM and directory state — unused keys, missing MFA, root activity, over-privileged policies.
AI-assisted rules
Semantic review that pattern matching cannot do — notably review of hand-written custom IAM policy documents.
Evidence, not assertions
Detectors backed by measured telemetry attach the daily utilisation series they measured to the finding, rendered as a sparkline with p95, average, minimum, and maximum.
A resource owner can check the recommendation against their own dashboards instead of taking it on faith — and Optimization reports what share of identified savings is backed by measured evidence rather than heuristics alone.
Module: Opportunity Queue
Stage 5 — Prioritise
Findings are scored into a ranked queue using a composite of savings, confidence, and effort, so the highest-value, highest-certainty, lowest-effort work rises to the top.
Simultaneously they are classified by remediation class — advisory, guided, or automatable — which determines whether the platform can act or must hand the work to a human.
Stage 6 — Decide
Policy evaluation, SLA tracking, and the approval workflow operate here. Advisory policies raise findings; blocking policies stop the change.
Approvals carry the savings at stake, the blast radius, the rollback plan, and the policy reason for the gate — and can be decided in the dashboard, from Slack or Teams, or through Apex.
Stage 7 — Act
Approved actions execute against your cloud using the execution role, inside configured execution windows, subject to rate limiting and rollout safety controls.
Protected tags
Resources tagged finops:protected=true are always skipped, unconditionally.
Execution windows
Nothing fires during a change freeze or a peak trading period.
Rollout safety
Execution is staged rather than firing everything at once.
Dry run
Simulates the entire action without calling the provider.
Modules: Optimization, Autopilot, Resource Parking
Stage 8 — Verify
After execution, savings verification compares subsequent actual spend against the prediction and records realised savings.
This is the stage that closes the loop
It turns "identified savings" — a number every cost tool can produce — into "realised savings", which is the number a CFO will actually accept.
Stage 9 — Emit
Every significant lifecycle event is published to webhooks, AWS EventBridge, or GCP Pub/Sub, with:
- HMAC-SHA256 signing
- exponential-backoff retry
- a dead-letter queue
- manual redrive
Nothing in the platform is a dead end; every state change can drive an external system.
Module: FinSecOps
Where each module sits
| Stage | Primary modules |
|---|---|
| Connect | Cloud Accounts, Integrations |
| Ingest | Overview, Intelligence, Kubernetes |
| Normalize | Policies (normalization rules) |
| Detect | Opportunity Queue, FinSecOps, Database Health, API Monitoring, AI Infrastructure |
| Prioritise | Opportunity Queue, Optimization |
| Decide | Policies, Approvals, PR Cost Review |
| Act | Optimization, Autopilot, Resource Parking |
| Verify | Optimization, Cost Center → Savings, CEO View |
| Emit | FinSecOps, Integrations |