C1 Class1 Apply for pilot

Executive manual

AI cost governance for engineering and finance

By Founder and cost engineering lead Updated

The manual explains the product without hiding the math: Q x R + C + E, estimate class, P90, Blue Book basis, policy gates, and actuals calibration.

Five-page version

The attached executive PDF is the sales brief. This page is the web manual.

The core question remains: can we afford this pull request at P90 after scale?

Every buyer page points back to the same method so the pitch stays crisp instead of becoming a feature dump.

Open the 5-page PDF

How to use the manual

The manual is a sales asset because it makes the product legible to non-specialists without weakening the technical truth.

The executive reader should start with the core question: can we afford this pull request at P90 after scale? That frames the product as an approval system, not a dashboard or a developer toy.

The finance reader should follow the formula Q x R + C + E. Quantity is the workload the pull request creates. Rate is the frozen price and capability basis. Contingency is the cost-risk allowance to move from the expected case to the budget case you approve against - here, the P90 minus the expected delta from the paired Monte Carlo, not a flat percentage add-on. Escalation is the future curve driven by price, volume, and structural growth.

The engineering reader should use the code-island framing: scanner, scenario, Monte Carlo, policy, actuals. That keeps implementation details connected to the buyer promise and prevents marketing from drifting away from the repo.

Manual table of contents

  1. Chapter 1 - What Class1 Is and Why It Exists
  2. Chapter 2 - The Pull Request Is Where the Bill Begins
  3. Chapter 3 - The P90 Question After Scale
  4. Chapter 4 - Q: Quantity Takeoff for AI Workloads
  5. Chapter 5 - R: Rate Basis and Structured Pricing
  6. Chapter 6 - Base Estimate and Contingency
  7. Chapter 7 - Escalation: Why Cheaper Tokens Can Still
  8. Chapter 8 - Estimate Class: How Mature the Estimate
  9. Chapter 9 - Monte Carlo Without the Mystery
  10. Chapter 10 - Model Fit: Cheap per Token Is Not Cheap
  11. Chapter 11 - Agents, MCP, and Tool Schema Overhead
  12. Chapter 12 - Carbon, Water, and the Second Currency
  13. Chapter 13 - Policy Gates: From Warning to
  14. Chapter 14 - Actuals Ingestion: Bringing Reality Back
  15. Chapter 15 - The Blue Book: The Historical Cost Ledger
  16. Chapter 16 - Variance and Calibration: Learning From
  17. Chapter 17 - One Report, Three Readers: CTO, CFO,
  18. Chapter 18 - AI FinOps Beyond Tokens
  19. Chapter 19 - The Business Pilot: What Is Sold and
  20. Chapter 20 - Limits, Product Honesty, and the

Reader paths

Different buyers need different entry points into the same system.

CTO pathStart with pull request timing, scanner coverage, risk drivers, and controls. The key question is whether the architecture creates an uncapped workload.
CFO pathStart with P90, estimate class, escalation, and actuals. The key question is which number should be approved and how confidence improves.
CEO pathStart with the one-report story. The key question is whether the feature is worth the cost and whether the company can govern it repeatedly.
Developer pathStart with the takeoff, policy config, JSON output, and CI workflow. The key question is how to install without slowing normal review.

For engineering

How the scanner, scenarios, Monte Carlo, policy gate, and CI workflow fit together.

For finance

How to read P50, P90, P95, contingency, escalation, and estimate class.

For executives

What to approve, what to defer, and which controls matter before merge.

For product

Why free comments build adoption while paid enforcement creates the monetization lever.

Deeper context

The Class1 engine

At the heart of our platform lies a strict adherence to the principles of cost engineering, adapted for the unpredictable nature of Large Language Models. Unlike traditional software where compute costs are deterministic and tied directly to traffic, AI feature costs are highly variable. They depend on model selection, input token length, output token variability, the frequency of retries due to hallucinations or malformed JSON, and dynamic fallback chains.

To capture this complexity, Class1 employs Monte Carlo simulations using Common Random Numbers (CRN). By modeling the system before and after a pull request across thousands of synthetic scenarios, we isolate the true cost delta of your architectural change from background noise. This approach allows us to assign an AACE (Association for the Advancement of Cost Engineering) estimate class to the forecast, communicating both the expected cost and the confidence interval.

Furthermore, this estimation does not happen in a vacuum. The Blue Book ledger records historical execution data, creating a closed-loop calibration system. As your team merges changes and actuals are observed in production, the engine updates its actuarial tables. This continuous feedback loop ensures that our pre-merge budget gates remain accurate and actionable, preventing catastrophic cost overruns before they reach production while maintaining developer velocity.

Continue exploring

AI cost gateTurn AI code changes into reviewable monthly cost forecasts and enforce P90 budget policy in GitHub Actions before a pull request is merged.MethodologyReview the Class1 methodology, tests, assumptions, estimate classes, reproducibility controls, known limitations and evidence behind each cost claim.PricingCompare the Class1 open estimate layer, Team Gate and Business Pilot for private repositories, blocking P90 policy and actuals calibration.GuidesPractical guides for LLM cost estimation, AI FinOps, model selection, retries, fallbacks, token controls, P90 forecasting and pre-merge governance.