Forecast
Scenario -> analyze_delta -> risk_drivers -> escalated_curve -> classify -> render_pr_comment.
Code islands
Code examples from the Class1 cost engine
This page maps the public claims back to the internal system boundaries.
cost_enginePure math layer: Monte Carlo, classification, calibration, capability, structured pricing, cloud, capex, footprint, evidence.
takeoffPR product layer: Scanners, scenario translation, estimate_pr, policy discovery, JSON output, GitHub Action glue.
blue_bookLedger layer: Provider ingest, OTel, FOCUS, price medallions, actuals, specs, capability, allocation, footprint actuals.
autobuildSelf-maintenance layer: Health, planner, scout, governor, driver, metering, locks, drift, resilience, jobs.
snapshotsFrozen basis: Pricing, price index, capability, spec sheet, actuals, cloud index, footprint basis.
End-to-end trace
A public claim should point to a source boundary.
When the site says Class1 reads a pull request, that maps to takeoff: scanners, diff parsing, scenario translation, estimate_pr, and policy discovery. When the site says Class1 models P90 monthly delta, that maps to cost_engine: Scenario, analyze_delta, risk_drivers, escalation, classification, recommendation, and report rendering. These aren't just marketing terms; they are directory names and Python modules you can inspect.
When the site says the estimate is auditable, that maps to Blue Book and snapshots: pricing, structured rates, price histories, model specs, capability grades, actuals, cloud indexes, and footprint bases. When the site says the system can learn, that maps to calibration: stored estimates, FOCUS actuals, ActuarialTable, and recommended recalibration. The code structure directly reflects the business ontology.
This page exists to keep marketing honest. A buyer can ask for any claim and the answer should be a module, a data file, a test, or a named open item. That posture is stronger than pretending every future feature is already finished. If a feature isn't in the codebase, it doesn't exist on the website.
Enforcement
.class1 config -> evaluate_policy -> gate_payload -> CI exit code.
Calibration
Persist estimate at merge -> ingest actuals -> ActuarialTable -> class improves only with pairs.
Data moat
Bronze source artifacts -> silver normalizers -> gold snapshots -> reproducible estimates.
Claim-to-code map
The sales story is defensible because each promise has a local implementation path.
Before-merge approvaltakeoff/estimate_pr.py compares base and head, builds the report, evaluates policy, writes comments and JSON, and exits non-zero when the budget gate fails.
Risk-adjusted forecastcost_engine/monte_carlo.py runs paired scenarios on shared draws so deltas are sharp and self-deltas are exactly zero.
Model-fit economicscost_engine/capability.py and recommend.py connect benchmark fitness to retries, rework, and cost per completed task.
Data moatblue_book/prices, blue_book/spec, blue_book/capability, actuals, and snapshots implement the reproducible basis behind the numbers.
Honest gapsGOAL.md and NEEDS_HUMAN.md keep variance waterfall actuals, license gate, paste-a-diff web demo, and general intelligence grades visible.
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.