-
-
Notifications
You must be signed in to change notification settings - Fork 0
Two units of analysis
OikosBot works at two scales. They answer different questions and carry very different evidential weight — conflating them is the easiest way to misread the tool.
| Per file | Per estate | |
|---|---|---|
| Commands |
analyze check report compare
|
estate collect analyse report
|
| Question | Did this change dominate its base, or trade off? | Which repositories turn spend into verified capability? |
| Inputs | tree-sitter AST metrics | GitHub CI telemetry |
| Confidence |
Estimated only |
Measured money & time, Calibrated energy, Estimated carbon |
| Can it block? | No — cannot justify it | Not yet; read-only by design |
| Maturity | Original surface; known weaknesses | Newest surface; strongest evidence |
The unit is a function, and the comparison is base-versus-head. Its strength is the dominance engine: ε-tolerant comparison, min-max normalisation before any distance is taken (raw joules and bytes are not commensurable), objective weights participating in the metric, and total functions throughout.
Its weakness is upstream of all that. Energy, duration, carbon and memory are each derived from one integer — a raw AST node count — so four of the five objectives are scalar multiples of one another. The mathematics is sound; the inputs make it close to a one-dimensional sort. This is documented rather than papered over: see What is owed.
The unit is a repository, and the comparison is against every peer in the organisation at once.
This exists because allocative efficiency is not a property of a single change. It means scarce resources flow to their highest-valued competing use — and one diff has nothing to compete with. The same is true of opportunity cost and marginal analysis. Once the unit is a portfolio, all three become well-defined and measurable.
It also solved the collinearity problem, though that was not why it was built: money, wall-clock, energy and carbon sourced from telemetry are mutually independent, and independent of code volume (measured correlation with repository size: −0.049).
See The estate pipeline.
- Reviewing a pull request → per file. Accept that it is advisory.
- Deciding where the next engineering week goes → per estate. That is the question it was built for.
- Wanting a blocking gate today → neither, honestly. The per-file path cannot justify blocking, and the estate path is deliberately read-only until its numbers have been through more than one snapshot.
Because the interesting information is in the shape of the trade-off, and a weighted sum destroys it. Two changes with identical composite scores can be completely different decisions — one bought speed with memory, the other reduced carbon and raised complexity. Pareto dominance keeps that distinction; a single score throws it away and then presents the result with more confidence than it earned.
The composite EconScore does exist, for ranking. But the verdict — improvement, regression, trade-off, neutral — is a dominance judgement, and trade-offs are reported as trade-offs.