Four pillars behind every verified saving.
How Tallywyrm measures a saving, computes kgCO₂e from spend by cloud + region, refuses to write to your cloud directly, and builds the audit trail every reconciliation framework already asks for. Read top to bottom for the procurement-grade version, or jump to a pillar:
Autodesk Tally®is a building life-cycle LCA application for Revit — it reports the embodied-carbon and life-cycle environmental impacts of a designed building asset, used by architects and structural engineers during design.
Tallywyrmis a FinOps agent for cloud spend in AWS, GCP and Azure — it reports verified multi-cloud savings and the Scope 3 category 1 (purchased cloud services) emissions that the spend implies, used by finance and platform teams during operations.
Same first syllable, unrelated product. If you arrived here from a search result for Autodesk Tally® we’d suggest the Revit help docs; if you are here for multi-cloud FinOps, keep going.
Verified savings = one PR, one deploy timestamp, one measurement.
Every saving Tallywyrm claims is anchored to a single row: a recommendation became a PR, a human approver merged it, a deploy timestamp attached to it, and a post-deploy measurement reads from it. Forecast and realized are reported separately so a forecast inflation cannot pass for a saving.
- A recommendation becomes a saving only when a scoped pull request against your Terraform, Pulumi or Crossplane repo is merged and the deploy timestamp is recorded.
- The percentage-of-savings pricing reads from this same audit row — you pay a share of what survived the post-deploy measurement window, not a share of a forecast.
- Realized savings and forecast savings are surfaced as separate lines so drift between them is visible in the same weekly report.
- If a merged recommendation does not survive the measurement window the credit is reversed on the next invoice; the audit row never quietly ages out.
Drift reporting lives on /how-it-works and the bought-vs-realized split on /pricing.
Cloud workloads sit in GHG Protocol Scope 3 category 1; we measure kgCO₂e from spend by cloud + region.
Cloud spend is an indirect emissions input. Tallywyrm attributes each verified saving to a cloud + region pair and converts the spend delta into kgCO₂e using published grid intensity factors. The output rolls up to the same audit row the savings measurement reads from — the dollar, the carbon and the PR travel together.
- Factor source attribution: every kgCO₂e figure traces back to the grid intensity factor the public Cloud Sustainability Console / Electricity Maps publish for the cloud + region pair.
- Location-based vs market-based: we report location-based emissions by default to match how Scope 3 category 1 disclosures are normally reconciled; market-based figures are available on request.
- Tree-equivalent and secondary-equivalent derivations: tree-equivalents + secondary material equivalents are derived from the same kgCO₂e figure, not from a separate forecast.
- Audit-trail pointer: the kgCO₂e row links to the audit row that produced it, so a reviewer can trace any number on the report back to the PR + the deploy timestamp + the cloud-spend delta.
Per-framework mapping under /security/compliance#sec-climate-disclosure (Scope-3 cat. 1) and /security/compliance#eu-csrd (ESRS E1).
The agent emits IaC snippets; your CI/CD or platform team applies. No agent-side write surface, no break-glass role, no admin escalation.
Tallywyrm has no execution surface against your cloud account. The agent reads from a read-only credential brokered through your OIDC trust; the only write path is the pull request that lands in your Terraform, Pulumi or Crossplane repo. Anything that would require a write surface is denied by policy — not hidden behind a feature flag.
- PR-only delivery: the agent emits IaC snippets (src/lib/business/iac-snippets.ts); your CI/CD or platform team owns the merge and the apply. There is no terraform-apply execution surface reachable from the agent.
- OIDC trust boundary: cloud credentials are issued by you, brokered through your existing OIDC trust, and rotated by your IdP. The agent never holds a long-lived static key.
- Scope-of-credential contract: the credential scope is the smallest AWS / GCP / Azure role that produces a useful saving. Cost-attribution scopes are included; control-plane scopes are not.
- Denied actions by policy: no billing API writes, no IAM writes, no cross-account sts:AssumeRole into resources you have not federated, no break-glass role, no admin escalation. Same wording on /privacy.
Credential contract and denied actions on /security-and-compliance, the access-control grid and /privacy.
Each saving is one row: who, what, when, IP, PR diff, deploy timestamp, post-deploy measurement, sha256 of the bundle.
Every recommended change is stored as a single audit row. The row carries the user identity, the action, the timestamp, the source IP, the PR diff, the deploy timestamp, the post-deploy measurement and a sha256 of the row bundle. The weekly CSV export is the byte-for-byte projection of this row order so a finance team, an auditor and a procurement reviewer all reconcile against the same artifact.
- Weekly CSV export schema: the export is the same column order as the /api/audit-trail/export endpoint, with one row per savings entry plus a summary header — who, what, when, IP, PR diff, deploy timestamp, post-deploy measurement, credit applied.
- Integrity guarantee: each export ships a bundle_sha256 in the response body and an X-Bundle-SHA256 header so a downstream consumer can verify the row they downloaded is the row the agent wrote. Same wording on /security and /security-and-compliance.
- Retention window: 13 months minimum, configurable per workspace; the same window bounds the export on /privacy.
- Sub-processor list: the named AWS, Cloudflare R2, Stripe, email proxy and session-library parties — lifted verbatim from the sub-processor table on /security-and-compliance#sub-processors.
Retention window on /privacy; sub-processor list on /security-and-compliance#sub-processors; integrity guarantee on /security.
The same audit row already satisfies the evidence clause on each framework you reconcile against.
Every dollar saving, every kgCO₂e figure and every PR diff on this page is anchored to a single audit row. The row is the artifact SOC 2 Type II CC7.2, ISO 27001 Annex A.12.1.2, FedRAMP Moderate CM-3/CM-5, EU CSRD ESRS E1 §62–§66 and the SEC climate disclosure Scope 3 category 1 preview all already ask for. The chips below open the per-framework page directly on the matching section.
CC7.2 change-management evidence on the PR row — merge actor, deploy timestamp, source IP.
Annex A.12.1.2 change-management + A.14.3.1 segregation of duties on the same audit row.
CM-3 / CM-5 configuration change and access-restriction evidence on the PR + OIDC trust row.
ESRS E1 §62–§66 transition plan + resource-use evidence; schedule execution events map to transaction-level disclosure.
Scope 3 category 1 (purchased cloud services) kgCO₂e on the same row as the verified dollar saving.
The post-deploy measurement window is one calendar week — same workload, same account, same time-of-week.
The window opens seven days after the deploy timestamp and runs for one calendar week. Inside that window Tallywyrm re-reads the same workload in the same account, in the same cloud region, over the same time-of-week window as the baseline. The post-change bill minus the baseline bill is the verified delta for that period; forecast and realized stay on the weekly report as separate lines so drift between them is visible at the same time.
pricing-verification.verified-readings.- Window length: one calendar week (seven full days), starting seven days after the deploy timestamp. No partial-day windows, no rolling averages, no moving baselines.
- Workload, account, region, time-of-week: every dimension of the re-read window matches the baseline window. A change in the workload set, the account pairing, or the time-of-week voids the re-read for that period.
- Verified-cents formula: verified_cents = re_read_bill_baseline − re_read_bill_post_change. The post-change bill is the bill you would have paid without the change, less the bill you paid with the change.
- Below-baseline re-reads do not promote: if the re-read produces a delta at-or-below baseline (or a workload change voids the re-read), the entry does not enter the verified pool for that period. There is no claw-back on a previously sent invoice.
- Forecast vs realized: forecast and realized are surfaced as separate lines on the weekly report. A forecast inflation cannot pass for a saving — the credit applied to the next invoice reads from the realized side of the same row.
Verified savings = observed in the post-action bill. The boundary in one glance.
A saving is verified when the same workload, in the same account, in the same cloud region, over the same time-of-week window reads lower on the post-action cloud bill than on the baseline bill — with one full calendar week between deploy and re-read, and no workload change voiding the comparison.
The Growth tier on the pricing page (/pricing →) reads from the verified pool only — the criteria below are the gate.
- The post-action bill line for the same workload, same account, same region, same time-of-week is strictly below the baseline bill line for the equivalent period.
- The verified-cents formula reads the two real bill lines: verified_cents = re_read_bill_baseline − re_read_bill_post_change. No forecast, no survey, no proxy.
- The measurement window is one calendar week (seven full days), starting seven days after the deploy timestamp. Partial-day windows and rolling averages do not qualify.
- The change is traceable on a single audit row — PR, merge actor, deploy timestamp, re-read window, baseline and post-change bill lines, bundle_sha256 — so a reviewer can reproduce the verification from the export.
- A sub-baseline re-read (the post-change bill is equal to or below the baseline line) does not enter the verified pool for that period; the entry is surfaced as observed-but-not-credited on the same row.
- A recommendation that has not been merged into your Terraform, Pulumi or Crossplane repo. The agent emits an IaC snippet — until a human approver merges and the deploy timestamp is recorded, there is no saving to verify.
- A forecast surfaced by the signal layer before merge. Forecast and realized are surfaced as separate lines on the weekly report; a forecast inflation cannot promote into the verified pool.
- A merged change that does not survive the measurement window. If the re-read produces a delta at-or-below baseline the credit is reversed on the next invoice and the row never quietly ages out.
- A change where the workload, account, region, or time-of-week in the re-read window differs from the baseline window. A drift in any of those four dimensions voids the re-read for that period.
- A non-bill-model estimate — list prices, calculator outputs, third-party survey figures, or a unit-economics derivation that does not read from your post-action cloud bill. Useful as a directional signal only; never as a verified cents figure.
Walk 1 — 198 GB gp3 EBS, dev RDS stopped, us-east-2. From forecast to verified delta to invoice line.
A single weekly entry, walked through all seven steps. 198 GB gp3 EBS volume attached to a dev RDS that has been stopped since December. Baseline week Feb 3–9, post-deploy re-read Feb 10–16. Every line on the audit row below is a real field on the weekly export — the dollar, the carbon, the PR diff, and the deploy timestamp travel together.
The verified delta on this row ties back to the worked dollar walk on /pricing →. Framework evidence column on this row: Scope-3 cat. 1 indicator on /security/compliance#sec-climate-disclosure →.
- Forecast surfaced
198 GB gp3 EBS volume in us-east-2, attached to a dev RDS that has been stopped since 2025-12-14. Forecast: $612/wk.
forecast_centscloudregionworkload_idforecast_timestamp - IaC diff and PR
PR #1842 to the terraform repo drops the aws_ebs_volume block that owns the unattached disk. The PR description carries the diff, the rollback command, and the forecasted saving.
pr_urlpr_diff_hashrollback_command - PR merges, deploy ships
PR merged by @alice at 2026-02-02 14:32 UTC. Deploy timestamp recorded at 2026-02-02 14:48 UTC.
merge_actormerge_timestamp_utcdeploy_timestamp_utc - Re-read window opens
Baseline window: 2026-02-03 → 2026-02-09. Post-deploy re-read window: 2026-02-10 → 2026-02-16. Same workload, same account, same region, same time-of-week, seven full days.
re_read_window_startre_read_window_endre_read_basis_window - Re-read computes the verified delta
Re-read post-change bill line for that volume: $0. verified_cents = $612 − $0 = $612. The entry enters the verified pool for that period.
re_read_bill_baseline_centsre_read_bill_post_change_centsverified_cents - Audit row closes with bundle_sha256
The row is sealed with a sha256 of the row bundle. The weekly CSV export ships the same sha256 in the response body and an X-Bundle-SHA256 header so a downstream consumer can verify the row they downloaded is the row the agent wrote.
bundle_sha256x_bundle_sha256_header - Invoice reads the row; kgCO₂e travels on the same row
12% Growth share on this row: $612 × 12% = $73.44 on the next invoice line. kgCO₂e on the same audit row: $612 × location-based grid factor (AWS us-east-2 PJM, ~0.40 kgCO₂e/kWh) ÷ electricity unit price (~$0.13/kWh) ≈ 1,884 kgCO₂e. The dollar, the carbon, the PR, and the deploy timestamp travel together.
tier_pct_appliedinvoice_centskgco2e_kgkgco2e_factor_sourcekgco2e_scope
Walk 2 — r6g.4xlarge → r6g.2xlarge, EC2 us-east-1, baseline week CPU < 20%. From forecast to verified delta to invoice line.
A second weekly entry, walked through the same seven steps. An EC2 instance on the r6g family was provisioned for a workload that turned out to be I/O-bound rather than compute-bound; the baseline week shows CPU < 20% across all seven days and the on-demand rate for r6g.4xlarge in us-east-1 is materially higher than r6g.2xlarge. Baseline week Feb 17–23, post-deploy re-read Feb 24–Mar 2. Every line on the audit row below is a real field on the weekly export.
The verified delta on this row ties back to the worked dollar walk on /pricing →. Framework evidence column on this row: Change-management evidence on /security/compliance#iso-27001 (Annex A.12.1.2) →.
- Forecast surfaced
EC2 instance i-0a1b… in us-east-1, instance class r6g.4xlarge, baseline 7-day average CPU 17.4% with p95 22.1%. On-demand rate $0.8064/hr; rightsizing to r6g.2xlarge at $0.4032/hr projects a sustained $283.78/wk saving at the same workload.
forecast_centscloudregioninstance_class_preinstance_class_postbaseline_cpu_avg_pctforecast_timestamp - IaC diff and PR
PR #1917 to the terraform repo updates the aws_instance resource, keeping instance_type = "r6g.2xlarge", preserving the AMI, subnet, security group, EBS volume and IAM instance profile. The PR description carries the diff, the rollback command, and the forecasted saving.
pr_urlpr_diff_hashinstance_profile_unchangedrollback_command - PR merges, deploy ships
PR merged by @bob at 2026-02-16 13:05 UTC. Deploy timestamp recorded at 2026-02-16 13:21 UTC. The instance is replaced in-place via Terraform’s create_before_destroy lifecycle; no customer-facing downtime.
merge_actormerge_timestamp_utcdeploy_timestamp_utc - Re-read window opens
Baseline window: 2026-02-17 → 2026-02-23. Post-deploy re-read window: 2026-02-24 → 2026-03-02. Same workload, same account, same region, same time-of-week, seven full days. The re-read observes CPU at p95 44.6% on the smaller class — comfortably under the 80% throttle threshold.
re_read_window_startre_read_window_endre_read_basis_windowpost_change_cpu_p95_pct - Re-read computes the verified delta
Re-read post-change instance-hour line for the seven-day window: $67.73. Re-read baseline line: $361.51. verified_cents = $361.51 − $67.73 = $283.78 (rounded to the cent). The entry enters the verified pool for that period.
re_read_bill_baseline_centsre_read_bill_post_change_centsverified_cents - Audit row closes with bundle_sha256
The row is sealed with a sha256 of the row bundle. The instance_class_pre and instance_class_post columns travel on the same row so a downstream finance reviewer can confirm the in-place class change without leaving the export.
bundle_sha256x_bundle_sha256_headerinstance_class_preinstance_class_post - Invoice reads the row; kgCO₂e travels on the same row
12% Growth share on this row: $283.78 × 12% = $34.05 on the next invoice line. kgCO₂e on the same audit row: $283.78 × location-based grid factor (AWS us-east-1 SRMC/PJM, ~0.41 kgCO₂e/kWh) ÷ electricity unit price (~$0.13/kWh) ≈ 894 kgCO₂e. The post-change CPU p95 reading proves the smaller class carries the workload — a verification cannot pass on a regression to baseline performance.
tier_pct_appliedinvoice_centskgco2e_kgkgco2e_factor_sourcekgco2e_scopepost_change_cpu_p95_pct
Walk 3 — dev RDS stopped weekends 18:00 → 08:00 UTC, 104 hrs/wk. From forecast to verified delta to invoice line.
A third weekly entry, walked through the same seven steps. The dev RDS cluster is only used during weekday business hours in a single region; the agent surfaces a stop-start schedule that runs Friday 18:00 UTC → Monday 08:00 UTC (104 hrs/wk) on the dev RDS class. Baseline week Feb 17–23, post-deploy re-read Feb 24–Mar 2. The same seven-step audit-row format. A schedule execution event maps to ESRS E1 §62–§66 transaction-level evidence, so the row doubles as the resource-efficiency disclosure anchor.
The verified delta on this row ties back to the worked dollar walk on /pricing →. Framework evidence column on this row: ESRS E1 §62–§66 resource-use evidence on /security/compliance#eu-csrd →.
- Forecast surfaced
dev RDS cluster db.t3.medium in eu-west-1, on-demand 24/7. Forecast at $0.0526/hr × 168 hrs/wk = $8.84/wk baseline. Stop-start schedule Friday 18:00 UTC → Monday 08:00 UTC removes 104 hrs/wk, projecting $3.28/wk post-change → $5.56/wk saving.
forecast_centscloudregionworkload_idschedule_idforecast_timestamp - IaC diff and PR
PR #1933 to the terraform repo attaches a schedule block (aws_rds_cluster + aws_scheduler_schedule + aws_iam_role for rds:stopDBCluster + rds:startDBCluster scoped to the dev tag) and removes the always-on DB cluster maintenance tag. The PR description carries the diff, the cron schedule, the rollback command, and the forecasted saving.
pr_urlpr_diff_hashschedule_cronrollback_command - PR merges, deploy ships
PR merged by @charlie at 2026-02-16 17:48 UTC. Deploy timestamp recorded at 2026-02-16 18:02 UTC. The first scheduled stop fires 2026-02-20 18:00 UTC; the first scheduled start fires 2026-02-23 08:00 UTC.
merge_actormerge_timestamp_utcdeploy_timestamp_utcfirst_schedule_event_utc - Re-read window opens
Baseline window: 2026-02-17 → 2026-02-23. Post-deploy re-read window: 2026-02-24 → 2026-03-02. Same workload, same account, same region, same time-of-week. The schedule execution log shows four schedule events fired in the re-read window (Fri 18:00 stop, Mon 08:00 start — checked twice). No weekend on-demand usage on the dev RDS.
re_read_window_startre_read_window_endre_read_basis_windowschedule_events_in_window - Re-read computes the verified delta
Re-read post-change line: $3.32. Re-read baseline line: $8.84. verified_cents = $8.84 − $3.32 = $5.52 (a $0.04 discrepancy against the forecast attributable to a partial-resolution hour at the cluster startup; the verified cents figure reads from the bill line, not the forecast).
re_read_bill_baseline_centsre_read_bill_post_change_centsverified_cents - Audit row closes with bundle_sha256
The row is sealed with a sha256 of the row bundle. The schedule_id and schedule_events_in_window columns travel on the same row so a reviewer can confirm the schedule fired on the dates the verified delta depends on.
bundle_sha256x_bundle_sha256_headerschedule_idschedule_events_in_window - Invoice reads the row; kgCO₂e travels on the same row
12% Growth share on this row: $5.52 × 12% = $0.66 on the next invoice line. kgCO₂e on the same audit row: $5.32 saved on RDS compute × location-based grid factor (AWS eu-west-1, ~0.31 kgCO₂e/kWh) ÷ electricity unit price (~$0.16/kWh) ≈ 10 kgCO₂e. The schedule execution row doubles as ESRS E1 §62–§66 resource-use transaction evidence — the dollar, the carbon, the schedule events, and the deploy timestamp travel together.
tier_pct_appliedinvoice_centskgco2e_kgkgco2e_factor_sourcekgco2e_scopeesrs_e1_evidence
8% Starter · 12% Growth · 18% Enterprise. Paid out of verified savings, before the cloud bill.
The audit trail is the same artifact every reconciliation framework already asks for.
Nothing on this page is a new attestation — it is a public mapping from the credential contract and the weekly export that /security, /privacy, /terms and /faq already publish. Pricing is the percentage-of-realized line, not the forecast line.