# Reading the console Everything on the dashboard exists to keep two different kinds of facts honest at once: modeled estimates (with uncertainty) and exact retirements (without any). This page explains each element. A public, read-only [demo console](/demo) shows all of it with synthetic data. ## Monthly usage-phase footprint Three charts: Water (gallons), Carbon (kg CO2e), Energy (kWh), one bar per month. - **The bar rises to P90**, the retirement accrual basis for every account. - **The shade change** inside the bar marks P50, the central estimate. The lighter segment above it is deliberate conservatism headroom, not a higher belief about the footprint. - **The whisker** spans P05 to P95, the 90 percent plausible range. It ships with every figure; hovering a bar shows the numeric range with both ends in the same unit scale. - The estimates credit cache reads at the methodology's cached-input coefficient and apply conservative treatment where providers hide reasoning tokens; banner notices appear when the model-registry disclosure threshold (over 15 percent unclassified tokens) or the hidden-reasoning multiplier fired. ## Filters The API multi-select and date range filter every figure on the page at once. The cap readout shows billable tokens against your tier cap (see [Billing](/docs/billing) for how billable tokens are counted). ## Your longer window A 6 or 12 month view of the same estimate, and the sizing basis for a backfill purchase: retroactive retirements against the window's history. The card can freeze the window into a quote, which fixes both the retirement quantities (at the accrual basis) and the price (certificates at supplier cost plus a fixed margin) so neither moves after you have seen them; methodology revisions and supplier price changes never touch an issued quote. Purchasing opens with paid launch and requires a paid tier; a purchased backfill accrues into the same obligation ledger as everything else and is retired by the next monthly close, dated honestly as retired at purchase and sized against the window, never as if coverage had existed during it. After purchase, a confirmation email restates the price, the window, and the quantities funded, and the console shows the purchase under **Backfill purchases** with its ledger stage: funded and awaiting the next monthly close, ordered and awaiting registry confirmation, or retired and confirmed. Nothing appears on your record or certificates as retired before the registry confirms it. Lookback stops at twelve months because of coefficient validity, below. It states its basis, because the two are very different kinds of evidence: - **Metered**: real recorded usage in the window. On the free tier this is sized on what was actually estimated, so if a month hit the 10M estimation cap the window says how much usage it could not include rather than quietly reporting a smaller figure. Moving to a paid tier estimates the parked history and fills the window in. - **Metered rate, extrapolated**: the common case for a twelve-month window. Provider usage APIs keep only recent history, so most accounts hold real data for weeks or months and nothing before it. Rather than reporting a window that is mostly blank, we ask one question (was your earlier usage higher, lower, about the same, or were you not using AI yet) and project your metered rate across the rest. The rate is real; the answer is recall. The range widens with how much of the window is projection and how far past the anchor it reaches, and the card says what share was projected. Nothing is projected until you answer, and seven days is the shortest anchor we will project from. - **Self-estimated**: projected from your usage profile when there is no metered history at all. This is conditional, not historical: it says what a window would look like if your usage had been at that level throughout, and it is labelled that way on screen. Where any part of the window is projected, the headline figure is labelled accrual basis rather than P90, because it is deliberately no longer the 90th percentile of the range beside it. The range widens with how much is projection; the accrual basis does not. See the glossary entry in [Overview](/docs/overview). Lookback stops at twelve months because the model registry begins in May 2024 and grid intensities are dated; reaching further back would apply today's coefficients to a grid and a hardware generation they do not describe. No certificates are retired against this view. ## Retirement history Whole registry units retired per month, one panel per category. Solid bars are confirmed retirements, the only kind certificates report; dashed outlines are funded orders awaiting supplier confirmation. This strip is deliberately separate from the estimate charts: retirements are exact instruments, estimates are modeled, and the two are never overlaid. ## Credit position Per category: units retired to date, pending fulfillment, buffer coverage, and the carryover obligation (fractions below a whole unit roll forward to the next close). Categories never mix; there is no combined score. ## Invoices One local invoice per closed period, mirroring your Stripe subscription charge. Self-serve accounts are charged by the subscription itself, never twice. The Manage billing button opens the Stripe customer portal for card changes, invoice history, and cancellation. ## Certificates Each closed period's four-section certificate, downloadable as PDF and JSON. See [Certificates](/docs/certificates) for the anatomy. ## Managed connections and Report usage Add a scoped provider connection (Google today), trigger a manual sync for any window, remove or rotate credentials, or self-report monthly totals. The full setup guide renders below these cards inside the console. ## Close a billing period Operator tooling for the monthly close: aggregate the period, accrue at P90, retire (buffer first, then supplier orders), enforce the retirement basket, issue the certificate, and invoice. Every step is journaled and idempotent; re-running a closed period changes nothing.