From Capability to Quoted Deliverable
The hardest part of selling a service is knowing what you are actually selling. A capability library — the 71-skill canvas documented in the S4 series — is a list of things the fleet can do. A service catalog is a list of things customers can buy. The distance between the two is where most service businesses fail: they either quote capabilities as if they were deliverables (“we can do AI agents!”) or they hide the capability behind vague promises (“we provide digital transformation”). The S6 series has been building the business side of the sovereign stack; this article is the mechanism that turns internal capability into external offer.
What a capability actually is
In the Council’s architecture, a capability is a skill plus the infrastructure that runs it. The skill library (S4.1) holds the procedure; the narrow gate (S7.1) scopes who can run it; the profile registry (S5.6) says which agent holds it; the audit layer (S7.7) records what happened when it ran. A capability is therefore not a promise — it is a demonstrated, audited, repeatable operation. The catalog’s job is to package that operation as something a customer can buy.
The packaging has four parts:
- Inputs. What does the customer provide? A topic, a dataset, a target market, a set of credentials? The input is the contract’s beginning.
- Outputs. What does the customer receive? A published article, a verified report, a generated image set, a deployed stack? The output is the contract’s end.
- Constraints. What are the limits? Budget caps, time windows, scope boundaries, compliance requirements? The constraints are the contract’s walls.
- Evidence. How does the customer know it happened? The audit trail, the artifact link, the verification record? The evidence is the contract’s proof.
These four fields are the same four fields the kanban board uses for tasks — inputs, outputs, constraints, evidence. The catalog is the board’s grammar applied to commerce.
Why quoting a capability is a mistake
Quoting a capability sounds confident and means almost nothing. “We can build AI agents” is a statement about the fleet’s toolbox, not about the customer’s outcome. The customer cannot evaluate it, price it, or hold the fleet to it. It is a noun list in search of a verb.
The fix is to quote deliverables, not capabilities. The catalog entry is a deliverable: “publish a 1,200-word SEO-grounded article on topic X, with hero image, schema markup, and verification record, within 48 hours.” That sentence has inputs (topic X), an output (the article), constraints (48 hours, 1,200 words), and evidence (the verification record). It can be priced, scoped, and audited. The capability made it possible; the deliverable makes it buyable.
Catalog tiers: the Platonic pricing connection
The S6.8 and S7.2 articles described Platonic pricing — the tiered access architecture where each tier is a Platonic solid with a fixed geometry of access. The service catalog is where that geometry meets actual deliverables. A T1 entry buys one deliverable from a small set. A T5 entry buys the full catalog with higher limits, faster turnaround, and deeper evidence. The catalog is not a flat price list; it is the access architecture’s visible surface.
The connection matters because it solves the pricing problem from both sides. From the customer side, the tier tells them what they can reach. From the fleet side, the tier tells the gate which scope to grant. The catalog entry and the solid-key scope are the same contract expressed twice: once for the customer’s understanding, once for the gate’s enforcement.
Building the catalog from real runs
The honest way to build a service catalog is not to invent offers. It is to inspect the audit ledger and ask: what have we actually delivered, how often, at what cost, with what quality? The ledger (S7.7) records every tool call, every publish, every artifact. A few queries turn it into a catalog:
- Which skills ran successfully in the last 90 days? Those are candidate capabilities.
- Which outputs were published or delivered? Those are candidate deliverables.
- What was the median budget per run? That is the cost basis for pricing.
- Which runs produced verifiable artifacts? Those are the offers with evidence built in.
A catalog built this way is grounded in reality. It prices what the fleet has already proven it can do, at the cost the fleet has already paid. The alternative — a wish-list of offers nobody has tested — is a marketing document, not a catalog.
The catalog as a living contract
The catalog is not static. When a new skill ships (S4.7), the catalog gains a row. When a deliverable proves unreliable, the catalog loses one or the constraint tightens. The catalog and the audit ledger stay in sync: every catalog entry can point to real runs that produced that deliverable, and every real run can be traced back to the catalog entry that defined it. This is the S3.7 publish-loop discipline applied to services: knowledge becomes article becomes post becomes node — and capability becomes catalog entry becomes deliverable becomes evidence.
For a sovereign-infrastructure business, this is the difference between selling hope and selling receipts. The catalog is the receipt’s front cover; the ledger is its back matter.
Grounded in wiki concepts capability-library, service-plans, subscription-model, platonic-solid-access-architecture, skill-lifecycle-management, and the S4 + S6 + S7 series. Design notes on a running system.
