Home DocsProduct map

Product truth map

What Rateplane actually covers

This page is written for enterprise buyers, operators, and end users who need a clear view of the product surface. It separates public catalog value from connected-account workflows, integration-required work, configured controls, admin-only operations, and partial or future-facing features.

Public catalog

Pricing research, comparisons, filters, calculators, and public docs can be inspected before cloud accounts are connected.

Connected workflows

Spend, forecasts, allocation, recommendations, and reports depend on successful billing or usage syncs.

Integration-required

APIs, webhooks, notifications, SaaS connectors, and partner tools require tokens, credentials, or customer-side setup.

Configured controls

SSO, roles, auditability, billing, security review, and rollout support depend on workspace or plan configuration.

Admin-only operations

Operator dashboards for jobs, catalog refreshes, platform health, and sync failures are not customer-facing workflow promises.

Partial and future-facing

Labs and partially wired features are labeled separately so buyers do not treat them as generally available enterprise controls.

Buyer-facing product groups

Public catalog

Pricing research, comparison, filters, calculators, reference catalogs, and public education that work before customer billing data is connected.

No customer billing data required

Connected-account workflows

Spend, budget, forecast, allocation, optimization, and reporting workflows that depend on imported billing, usage, resource, contract, or user-maintained data.

Requires imported spend or usage data

Integration-required workflows

External service connections, APIs, notification channels, webhooks, and sync operations that require tokens, credentials, or customer-side setup.

Requires setup, tokens, or external services

Configured controls

Controls for identity, roles, billing, security review, rollout, procurement, auditability, and governance that require workspace or plan configuration.

Requires workspace or plan configuration

Admin-only operations

Operator-only administration for catalog operations, jobs, sync health, billing health, audit review, and external dependency readiness.

Operator-only surfaces

Partial and future-facing features

Labs, previews, redirect stubs, or partially wired workflows that should be evaluated as emerging capabilities rather than generally available product promises.

Labs, partial, or future-facing capabilities

Status labels

Public catalog

Works without customer cloud credentials.

Workspace feature

Requires a signed-in workspace for saved or collaborative state.

Requires connected data

Needs imported billing, usage, resource, or account data.

Requires integration setup

Needs a configured external service, token, webhook, or provider setup.

Plan-configured control

Relevant to SSO, billing, roles, procurement review, and rollout configuration.

Admin / operations

Operator or admin-facing control surface.

Partial / future

Labs, preview, or partially wired workflow that should not be sold as generally available.

Capability coverage

Each section states what the code-backed product surface is meant to do, what the workflow requires, where users find it, and the claim boundary to keep buyer-facing copy accurate.

Open user guide

Public catalog

Pricing research, comparison, filters, calculators, reference catalogs, and public education that work before customer billing data is connected.

1Public catalog

Catalog and pricing reference

Verified cloud compute pricing across AWS, Azure, and GCP so teams can research provider, region, family, and purchase-model tradeoffs before connecting billing data. Adjacent infrastructure catalogs stay in Labs until their own provider-specific datasets are verified.

Audience

Engineering, platform, procurement, FinOps

What it covers

AWS, Azure, and GCP compute catalog with normalized vCPU, memory, region, operating system, hourly pricing, commitment, and spot fields where providers publish them.
GPU and AI reference views where catalog data exists; databases, storage, Kubernetes, serverless, network/edge, platform, SaaS, and PaaS lanes require separate provider-specific validation before live customer exposure.
Expression filters, provider filters, region filters, family filters, and CSV export from filtered catalog views.
Provider source context and freshness-oriented catalog health surfaces.

Claim boundary

Catalog pages should not imply customer-specific spend until a billing account is connected.
Some service categories are reference catalogs rather than live vendor integrations.
Provider imports determine availability of spot, reserved, and specialty rates.

2Workspace feature

Compare, shortlist, and saved decisions

Shortlist cloud options, compare them side by side, save decision context, and export or share the resulting view for architecture and buying reviews.

Audience

Engineering, architecture review, procurement

What it covers

Side-by-side comparison of selected catalog offers across providers and regions.
Saved filters for reusable catalog views such as vCPU, memory, price, family, provider, and region constraints.
Shareable comparison and filter workflows for team review.
Export of filtered catalog data for spreadsheet or procurement analysis.

Claim boundary

Comparisons are pricing and specification comparisons, not workload performance benchmarks unless a page explicitly shows benchmark data.
Exports reflect available catalog rows and filters; missing provider rates should remain visibly unavailable rather than invented.

3Workspace feature

AI, SaaS, platform, and specialty cost catalogs

Broaden cost review beyond core compute by giving teams reference pricing and connected spend surfaces for AI models, SaaS vendors, APIs, Kubernetes, serverless, databases, object storage, CDN, CI/CD, and observability.

Audience

AI platform, developer productivity, SaaS owners, infrastructure teams

What it covers

AI model pricing, LLM metering, AI cost, GPU fleet, GPU costs, and SageMaker views.
SaaS catalog, SaaS spend tracker, SaaS discovery, licenses, contracts, and vendor credits.
Database, storage, serverless, Kubernetes, API gateway, CDN, DNS, VPN, firewall, WAF, message queue, observability, and CI/CD pricing surfaces.
Platform service pages that should show available catalog data or truthful empty states, not invented prices.

Claim boundary

Reference pricing is not the same as connected invoice spend.
Many SaaS vendors do not expose complete billing APIs; documentation should say when a connector is setup-required or reference-only.
AI model pricing changes frequently, so freshness and source notes are important.

Connected-account workflows

Spend, budget, forecast, allocation, optimization, and reporting workflows that depend on imported billing, usage, resource, contract, or user-maintained data.

1Requires connected data

Cloud account connection and sync

Connect read-only billing sources so Rateplane can import customer-specific spend for dashboards, budgets, forecasts, allocation, and recommendations.

Audience

Cloud operations, FinOps admins, platform owners

What it covers

Cloud account setup, credential storage, sync status, health, and disconnect flows.
AWS, Azure, and GCP billing ingestion paths with provider-specific setup guides.
Manual and scheduled sync surfaces, sync logs, and account health reporting.
Encrypted credential handling for cloud account secrets.

Claim boundary

Rateplane should describe these as read-only billing connections, not infrastructure control-plane access.
GCP billing depends on an existing BigQuery billing export; Rateplane does not create that export for the user.
Features depending on spend remain empty or limited until the first successful sync completes.

2Requires connected data

Spend analytics and cost reporting

Analyze imported cloud spend by provider, account, service, tag, time period, region, and owner so teams can run monthly and weekly cost reviews from shared data.

Audience

FinOps, finance, engineering managers, service owners

What it covers

Spend overview, trends, cost reports, connected cost views, calendar, heatmap, velocity, and period-over-period analysis.
Service, account, provider, region, and tag breakdowns where source data includes those dimensions.
Annotations and explanations that help teams attach business context to spend movement.
Executive summaries and KPI views for leadership-level review.

Claim boundary

Spend analytics should clearly distinguish imported customer spend from public catalog pricing.
Real-time language should be avoided unless a view is actually backed by streaming or near-real-time data.
Charts are only as complete as connected account coverage and provider billing dimensions.

3Requires connected data

Budgets, alerts, and guardrails

Define budgets, thresholds, price alerts, anomaly rules, and notification routes so teams can review risk before spend surprises become month-end issues.

Audience

Budget owners, finance, platform teams

What it covers

Monthly budgets, budget variance review, threshold notifications, and budget guardrails.
Price alerts for catalog pricing changes and target thresholds.
Alert log and notification preference surfaces.
Custom anomaly rules and rule-builder surfaces for spend movement review.

Claim boundary

Catalog price alerts and spend budget alerts are different workflows and should be described separately.
Notification delivery depends on configured email or notification channel settings.
Spend-based thresholds need connected billing data.

4Requires connected data

Forecasting, planning, commitments, and contracts

Use synced spend, catalog rates, commitments, contracts, and renewal records to plan budgets, forecast month-end outcomes, and prepare procurement conversations.

Audience

Finance, procurement, FinOps, platform leadership

What it covers

Forecast, forecast studio, forecast accuracy, seasonality, and spend-planning workflows.
Commitment, RI, Savings Plan, renewal calendar, and marketplace planning views.
Vendor contracts, credits, licenses, negotiation tracking, and procurement-facing renewal views.
Scenario and budget-planning surfaces for future spend decisions.

Claim boundary

Forecasts are estimates, not accounting records.
Contract and license pages depend on user-maintained records unless an integration supplies them.
Procurement workflow claims should avoid promising negotiated savings without user action.

5Requires connected data

Optimization, waste, rightsizing, and automation

Prioritize savings candidates from connected data, catalog benchmarks, utilization signals, waste scans, approval workflows, and automation dry-runs.

Audience

Platform engineering, cloud operations, FinOps practitioners

What it covers

Rightsizing, recommendations, idle resources, waste scanner, waste tracker, and optimization scoring.
Savings tracker, savings plays, RI and Savings Plan planning, and savings portfolio views.
Automation recommendations, approval queues, dry-run records, history, power schedules, and policy scan surfaces where configured.
Runbooks and remediation workflow documentation for operational follow-through.

Claim boundary

Recommendation pages should be described as decision support unless live action execution is configured and tested.
Live remediation requires explicit provider permissions and should not be implied by read-only billing setup.
Dry-run and approval flows are separate from executing cloud-side changes.

6Requires connected data

Allocation, showback, chargeback, and unit economics

Map raw cloud spend into the business dimensions people actually manage: teams, products, cost centers, tags, virtual tags, folders, and unit-cost metrics.

Audience

Finance, FinOps, product owners, business unit owners

What it covers

Tag allocation, allocation rules, allocation folders, virtual tags, preferred tags, and segment views.
Showback, chargeback, chargeback invoicing, cost centers, MSP, and rate-card workflows.
Unit costs, unit economics, cost-per-unit, and business metric mapping.
Governance reports and accountability views for ownership review.

Claim boundary

Allocation accuracy depends on source tags, account structure, and configured rules.
Virtual tags help reporting but do not fix provider-side tagging by themselves.
Chargeback invoices should be treated as operational artifacts unless finance approves them as formal invoices.

7Requires connected data

Exports, reports, digests, and evidence packs

Turn catalog, spend, allocation, and governance views into exportable reports for finance, BI, ERP, operating reviews, and stakeholder communication.

Audience

Finance, executives, FinOps, auditors, BI/data teams

What it covers

CSV, JSON, reports, scheduled reports, and export manifests where the underlying workspace data exists.
Reports, report generator, shared reports, export hub, scheduled reports, and digest generator surfaces.
Executive briefing, cost pulse, governance reports, and monthly/weekly digest workflows.
Stakeholder-facing reporting options where configured.

Claim boundary

Exports should state whether they are catalog exports, spend exports, allocation exports, or report manifests.
LLM-written digests must be grounded in actual imported data and should not fabricate missing values.
Scheduled reporting depends on cron/job infrastructure and configured recipients.

Integration-required workflows

External service connections, APIs, notification channels, webhooks, and sync operations that require tokens, credentials, or customer-side setup.

1Requires integration setup

Integrations, API, notifications, and webhooks

Connect Rateplane workflows to the tools teams already use for tickets, alerts, repositories, open cost data, infrastructure estimates, and internal APIs.

Audience

Platform, DevOps, FinOps automation, incident response

What it covers

API keys, API explorer, pricing API, alert APIs, and export APIs.
Slack, PagerDuty, Jira, GitHub, webhooks, notification channels, and alert log surfaces.
OpenCost, Infracost, CloudQuery, Kubernetes, SaaS integrations, and SaaS discovery areas.
Webhook delivery and integration health views where configured.

Claim boundary

Integration cards should distinguish connected integrations from reference-only catalogs.
Webhook routes must fail closed when secrets are missing in production.
API key docs must match the authentication behavior implemented by the API routes.

Configured controls

Controls for identity, roles, billing, security review, rollout, procurement, auditability, and governance that require workspace or plan configuration.

1Plan-configured control

Security, identity, and enterprise rollout

Buyer-facing controls for workspace identity, roles, billing, security review, and enterprise rollout readiness.

Audience

IT, security, workspace admins, procurement

What it covers

Workspace settings, team management, invites, roles, SAML SSO, billing portal, and subscription controls.
Audit events, alert logs, event logs, and sync logs that support internal review and procurement diligence.
Security, privacy, trust, DPA, terms, cookies, status, and account-connection setup pages for buyer review.
Enterprise rollout documentation and controls that should be described as configurable, not automatically enabled.

Claim boundary

Enterprise claims should distinguish implemented controls from procurement process support.
SSO and notification controls require explicit workspace configuration before they affect sign-in or delivery.
Security review pages should avoid promising certifications, case studies, or customer references that are not present in the codebase.

2Workspace feature

Onboarding, demo data, labs, and product education

Help users understand the product through onboarding, getting-started checklists, demo seed/reset flows, docs, FAQ, labs, changelog, and guided setup.

Audience

New users, evaluators, internal champions, solution engineers

What it covers

Registration, login, email verification, password reset, onboarding wizard, and getting-started checklist.
Demo seed/reset flows for evaluation and sales walkthroughs where enabled.
Public docs, FAQ, guide, pricing methodology, changelog, status, and account-connection docs.

Claim boundary

Demo data should never be described as customer data.
Onboarding should explain what works before and after connecting billing data.

Admin-only operations

Operator-only administration for catalog operations, jobs, sync health, billing health, audit review, and external dependency readiness.

1Admin / operations

Operator administration and operational readiness

Operator-only dashboards for catalog operations, jobs, sync health, billing health, audit review, and external dependency readiness.

Audience

Internal operators, platform operations, support admins

What it covers

Admin dashboards for users, jobs, sync, catalog, billing, audit, health, and CloudQuery where available.
Job retry and cancel operations, catalog refresh status, sync logs, cron freshness, and webhook delivery health.
Read-only health checks for primary database, pricing database, queues, Stripe, Resend, Sentry, OpenCost, and CloudQuery where configured.
Operational pages that should be documented as internal controls rather than end-user or buyer workflows.

Claim boundary

Admin routes require appropriate roles and should not be marketed as end-user pages.
Operational readiness depends on configured env vars, cron jobs, queues, logging, and external provider credentials.
Health checks show platform state; they are not customer-facing uptime commitments.

Partial and future-facing features

Labs, previews, redirect stubs, or partially wired workflows that should be evaluated as emerging capabilities rather than generally available product promises.

1Partial / future

Labs, partial, and future-facing workflows

Expose emerging capabilities without presenting them as generally available enterprise workflows.

Audience

Evaluators, solution engineers, product teams, early-access users

What it covers

FOCUS export, API explorer, automation, arbitrage calculator, RI marketplace, OKRs, and other labs routes marked as LABS in the feature-status source.
Early-access pages that should show honest empty states or setup requirements rather than sample metrics.
Roadmap and education content that can guide evaluation without promising delivery dates or production readiness.

Claim boundary

Partial and labs capabilities should not appear in plan tables as guaranteed production features.
Roadmap and labs pages should avoid delivery dates unless the release plan is documented elsewhere.
Demo or sample data must be visibly labeled and kept separate from connected customer data.