Estate pipeline

The estate pipeline

Treats a whole GitHub organisation as a portfolio competing for one budget of minutes, money, energy and carbon.

Why this exists

Three of the efficiencies OikosBot claims to measure are undefined for a single diff:

• Allocative efficiency means scarce resources flow to their highest-valued competing use. With one change in front of you, there is nothing to allocate between.
• Opportunity cost needs an alternative that was forgone.
• Dynamic efficiency is a rate of change, so it needs history.

All three need a portfolio and a time axis. So the portfolio is the unit, and the per-PR check becomes one projection of a persistent model rather than the whole product.

Running it

oikosbot estate collect  --owner <org> --out <staging> [--max-runs 200]
oikosbot estate analyse  --staging <staging> --snapshot <dir>
oikosbot estate report   --snapshot <dir> [--format md|json] [-o FILE]

collect reads CI run history through the authenticated gh CLI. Three properties matter:

• No instrumentation. Nothing is installed into the measured repositories. The data already exists server-side.
• Retroactive. History that already happened is available immediately — including periods when the repos' own CI was broken.
• Resumable. A staging file that already exists is skipped, so an interrupted sweep is re-run, not restarted. Per-repo failures are logged and the sweep continues; one 404 must not kill a 400-repo run.

analyse derives per-repo cost and capability, then runs the DEA, and writes Parquet plus analysis.json. It is deterministic: two runs over the same staging produce byte-identical output.

report renders the frontier, the worst performers with their peers, and the X-inefficiency list.

Inputs: what it costs

Measured from telemetry, so the axes are genuinely independent of each other and of code volume — see Reading the confidence ladder for how far each can be trusted.

Outputs: verified capability

The output measure is deliberately not activity (commits, lines, PRs). It is whether the repository demonstrably works:

• Does the workflow parse? A run that dies at startup produced nothing from real input.
• Can the gate fail? A check with many successes and zero failures in its entire history has never demonstrated it can fail.
• Do artefacts publish?

That second signal is worth dwelling on. It needs no source analysis at all — just run history — and it turns a familiar pathology into an economic fact: a repository burning CI minutes on a gate that has never failed is consuming real input for no verified output.

A candidate is not a conviction. "Never failed" is not proof of a fake gate — a genuinely correct, genuinely stable workflow looks identical from the outside. Telemetry can only say this has never demonstrated it can fail, and that is exactly what the metric claims.

Data Envelopment Analysis

DEA is the standard instrument for comparing units with multiple incommensurable inputs and outputs, with no prices. That is precisely the situation here: you cannot convert minutes, kilowatt-hours and released artefacts into a common currency without inventing exchange rates.

For each repository, OikosBot solves an input-oriented linear program (CCR, plus BCC for variable returns to scale) and returns three things:

1. θ — an efficiency score in (0, 1]. θ = 1 means on the frontier.
2. The peer reference set — which frontier repositories this one is measured against. This is the most actionable output DEA gives: it names a concrete exemplar rather than just a number.
3. The dual variables — virtual weights on each input and output. These are shadow prices derived from the estate's own data rather than hand-set constants, and they are the intended bridge to Eclexia's shadow_price().

Both the envelopment and multiplier forms are solved, and their objectives asserted equal to within 1e-5. That is a strong-duality check built into the implementation: if the two disagree, the LP is wrong.

What round one deliberately does not do

It does not gate. It reports.

The premise was tested before anything was built on it. If measured compute time had turned out to be a proxy for code volume, the DEA inputs would have been one variable wearing two hats and the whole design would have been wrong. Measured across 381 repositories and 69,445 runs: pearson(wall_minutes, size_kb) = −0.049. Independent. The falsifier was run first and reported either way.

Where the data lives

hyperpolymath/oikosbot-estate — data only, no code, no CI. One directory per collection run. History is git history, which is what makes dynamic efficiency possible later.

Keeping it out of the main repository is deliberate: OikosBot should not silently measure a corpus that contains OikosBot.

Known rough edges

See What is owed for the full list. The two worth knowing before reading a report:

• Repositories with zero CI runs do not appear in the analysis at all.
• Repositories with zero verified output score θ = 0.0 with an empty peer set — an artefact of flooring, not a meaningful ranking. They belong in the X-inefficiency list, not on the efficiency scale.