SaaS organizations

Voting a scale-up

An agent can see that the API needs more capacity long before the spend is obviously worth it. Endoskeletal lets a council hold that spend back, and makes sure it can't hold it back forever: every rise in the cost of not scaling reopens the vote, and past a hard ceiling a rejection simply doesn't count.

Days 11–14. With 20 units bound, the cost of not scaling falls back to about 2,600 USD/mo. Had the council kept rejecting past 36,800 (twice the cost), a reject would have misfired.

The council may block a recommendation it thinks isn't worth the money. It can't ignore the evidence: every rise in the cost of not scaling re-opens the vote, and past twice the cost, a reject misfires.

Day 1. The Ops agent recommends scaling Api from 12 to 20 units (+18,400 USD/mo). Not scaling costs about 3,000 USD/mo in expected SLA credits and churn. Vote: 1 of 3. Blocked.
Day 4. Utilization hits 78 % and the cost of not scaling rises past 25 % of its last value, so the reconsider trigger re-opens the vote. Still 1 of 3. Blocked.
Day 7. p95 latency drifts and the error budget starts to burn. Cost of not scaling: 12,400 USD/mo, still below the 18,400 it would cost to scale. Blocked.
Day 10. Cost of not scaling reaches 20,100 USD/mo and now outweighs the cost. Product votes to approve: 2 of 3. The power's condition is true, the OpsLead authorizes, and Scale(20) executes.
Days 11–14. With 20 units bound, the cost of not scaling falls back to about 2,600 USD/mo. Had the council kept rejecting past 36,800 (twice the cost), a reject would have misfired.

The parts

A recommendation, not an action. The Ops agent's envelope covers scaling up to 12 units. Going to 20 is outside it, so the agent can only propose a ScaleRecommendation with its projected cost.
A cost of doing nothing. A finance program derives ops.cost-of-inaction(Api) every hour: expected SLA credits × breach probability, plus churn exposure on the affected accounts. It's a claim like any other, with a source and an expiry.
A council with a power. Finance, Ops and Product leads vote. The OpsLead's power to authorize the scale-up holds only when two of the three have voted to approve within the last four hours.
A trigger that reopens the vote. When the cost of inaction rises by a quarter since the last vote, the council owes a new vote within two hours.
A ceiling. Once the cost of inaction is more than twice the cost of scaling, a reject by any council member misfires. The council keeps its judgment in the grey zone and loses it where the answer is obvious.

The specification

northwind.esk · scope Operationsesk

vocabulary ops @ 1.2.0 {
  utilization(r : Capability)       : claim "observed utilization of r"                        decays after 1 h
  cost-of-inaction(r : Capability)  : claim "expected monthly cost of not scaling r:
                                             SLA credits × breach probability + churn exposure" decays after 6 h
  need-rose(s : Entity)             : claim "cost of inaction rose 25 % since the last vote on s"
  ScaleRecommendation(n : Number, delta : Quantity<currency>) : entity "a proposal to run n units"
  Scale(n : Number)                 : event external "change the unit count of a realization"
}

position InfraCouncil : org.Member {
  cardinality 3
  eligible when self is pp.Person
}

-- What the Ops agent may do alone.
use rz.RealizationEnvelope(
  holder      = Ops,
  requirement = Api,
  operation   = ops.Scale,
  admissible  = a.n <= 12
                and holds ops.price(bound(Api)) * a.n <= 11_000 USD per month
) as OpsEnvelope

-- The council votes; two of three approvals within four hours give the OpsLead the power.
norm Vote {
  power of InfraCouncil to decide vote-approve | vote-reject about ops.ScaleRecommendation
}

norm ScaleUp {
  power of OpsLead to authorize execute about ops.Scale
  when s is ops.ScaleRecommendation and a.n = s.n
       and count decide(vote-approve, s) by InfraCouncil over 4 h >= 2
  level operational
}

-- New evidence reopens the question.
norm Revote {
  obligation of InfraCouncil to Ops
  when occurred derive(ops.need-rose(s)) and s is ops.ScaleRecommendation
  aim within 2 h: count decide(_, s) by InfraCouncil over 2 h >= 3
}

-- Past twice the cost, the council may not say no.
norm NoRejectPastCeiling {
  prohibition on InfraCouncil
  aim occurred decide(vote-reject, s)
      and holds ops.cost-of-inaction(Api) > 2 * s.delta
  level collective   not tradeable
}

use rz.Reconsider(
  holder   = Ops,
  on       = { holds ops.utilization(Api) > 0.85 },
  deadline = 1 h
) as Recommend

Tuning it

Every number in this circuit is the organization's to choose, and each choice is a different company. A startup watching its runway might raise the ceiling to four times the cost. A company with strict SLAs might lower the revote threshold to 10 %, or let the OpsLead approve alone when ApiUp is already burning its error budget. Simulate each variant against the same traffic scenario and compare spend, SLO breaches and time-to-capacity before you adopt one.

Why not just autoscale?

Autoscaling inside the envelope is still automatic. The council only exists for the step beyond it, where the spend is large enough that someone accountable for the budget should agree. The circuit makes that agreement fast when the evidence is clear and impossible to stall when it's overwhelming.