Your Platform Can't Answer Its Most Important Question
Most platforms can provision anything but can't tell you where they quietly compromised. Treaty is an open spec proposal that turns that gap into recorded, queryable data.
Here is a question to ask your platform, your IDP, or your service catalog today:
Which of our production services are running below the availability their teams originally asked for — why, and who approved it?
Almost no platform can answer this. Not because the information never existed, but because it was never recorded as data. The team asked for 99.95%. The budget only covered single-zone. Someone said “fine, 99.9% is acceptable for now” in a Slack thread in 2024. The infrastructure exists; the reasoning evaporated. Eighteen months later an incident review asks “why is the payments database single-zone?” and the answer lives in nobody’s head anymore.
We have spent a decade making infrastructure provisioning self-service — service catalogs, golden paths, Backstage, Crossplane. What we never made self-service, or even visible, is the compromise: the gap between what a team requested and what the platform actually granted.
I’ve written an open specification proposal that treats that gap as the next platform primitive. It’s called Treaty — because a treaty is exactly what’s missing: a negotiated, recorded, binding agreement between two parties.
The idea in three steps
1. Developers declare outcomes, not implementations. “A PCI-compliant relational database in the EU, 99.95% availability, under 400 EUR/month.” Not “a db.r6g.large with this Terraform module.”
2. The platform matches the intent against human-authored, approved capabilities. The platform team still curates every allowed implementation — Crossplane compositions, Terraform modules, Helm charts. Nothing is generated. This is deliberately not “ask an LLM for Terraform”: valid Terraform is not safe Terraform, and generation collapses what-is-allowed, what-fits-best, and who-approves-the-compromise into one opaque step.
3. The result is recorded as a Negotiation — granted, degraded, or rejected — with every option that was evaluated, every constraint that was relaxed, and the identity of whoever approved the compromise. In the example above: the multi-zone option meets availability but costs 700; the single-zone option fits the budget at 99.9%. The platform can ask (propose the downgrade, require human sign-off), degrade (auto-accept within a policy floor), or reject — and rejection must carry a counterproposal: “no option meets 400 EUR; the nearest conforming option is 700.”
The Negotiation is a versioned, living object. When the price changes, the attestation expires, or delivered availability drifts below what was granted, the decision is automatically re-opened — a degradation accepted under 2026 prices doesn’t silently persist into 2028.
What this buys you
Queries that are impossible today become one-liners:
- Every production service currently running degraded, with reason and approver — the report you currently reconstruct by hand during audits, if you can at all.
- Every compliance-relevant decision and exactly which attestation it rested on.
- Every request the platform rejected, aggregated by violated constraint — which is your platform’s demand signal, telling you in writing where your users are about to route around you.
Where AI fits — and where it doesn’t
The spec is layered, and the core layer needs no AI at all: intent, matching, and negotiation records are fully deterministic. An optional “negotiator” profile adds model-assisted trade-off explanation and ranking — but deterministic policy filtering runs before the model sees any option, and approval gates sit after it. The model reasons over an allowlist; it never generates infrastructure. For machine actors that do hold approval authority, the spec defines AgentSLOs: autonomy is earned through observable outcomes (override rate, rollback rate, audit-sample disagreement) and contracts automatically when breached.
This is a proposal, and I want it attacked
Treaty is a draft, not a standard. The repo has JSON Schemas for all five objects, the full PCI example including all three negotiation outcomes and a day-2 renegotiation, and — importantly — an open questions file listing the objections I already know about: renegotiation storms, metadata curation cost, whether a small capability set really covers the long tail.
The most useful thing you can do is bring a real negotiation from your platform that the object model can’t express.
→ Spec, schemas, and worked example: github.com/valeriouberti/treaty-spec
And if you can’t adopt any of this tomorrow, one thing is worth doing anyway: the next time your platform grants something different from what was asked, write the delta down as data. That habit is the whole idea.