# Capability discovery and synthesis

> An organization knows what it needs. It doesn't know which of the thousands of things providers offer, alone or combined, would meet that need, whether it's allowed to use them that way, or whether the answer still holds next month. Discovery is the work of finding out, with evidence. Synthesis is composing what it finds into candidates. Both are ordinary organizational work, done by parties with bounded powers, and both stop at the edge of the providers' terms.

Canonical: https://endoskeletal.com/discovery/
Last updated: 2026-09-28

## The need side

The compiler derives the requirement statement (IR-R) from the definitions: every hard and soft intent, and every norm that needs a mechanism, becomes a required capability traced to its source.

- A **maintain** intent yields an *observe* requirement with a freshness derived from how fast deviation must be detected, and an *act* requirement if the spec names one.
- A **prohibition** yields an observe requirement over its aim: you can't enforce what you can't see.
- A **budget** yields metering; an obligation to inform yields delivery; a power yields authorization; every external verb yields the external capability.
- Requirements inherit tradeability. A plan that leaves a non-tradeable requirement unmet is inadmissible, not merely penalized.

The Architect works from IR-R, not the source: required contracts, their current statuses and evidence expiry, non-tradeable constraints, the objective and budgets. It doesn't need to know who occupies which position.

## The supply side is claims

A provider's catalog enters as offered capabilities, one per operation or bundle, and a claim per property, asserted by the provider at status N. A provider's category name ("backup archive", "edge cache") is kept as metadata and ignored by matching. What matters is the **affordance vector**: the evidenced properties of the primitive, whether or not the provider markets them.

## Matching by contract

A candidate realizes a requirement when a refinement argument can be built for it, conjunct by conjunct:

| Conjunct | Question |
| --- | --- |
| Signature | Do inputs and outputs unify, under recorded vocabulary mappings? |
| Assumptions | Does the requirement's assumption imply the offer's? |
| Guarantee | Does the offer's guarantee, under those assumptions, imply the requirement's? |
| Properties | For each required property, is there evidence at T that meets the threshold? |
| Terms | Do the provider's terms permit this use, and do they conflict with any non-tradeable norm? |

Each conjunct has a status. The argument's status is their meet, so one N anywhere makes the candidate N.

## Composition: finding things nobody sells

When no single offer refines a requirement, the search decomposes the contract (durable persistence → append + index + retention + jurisdiction pin, and so on) and binds each part to an offer, an offer plus an adapter, another provider's offer, or an existing organizational resource such as a bound realization's export operation or a human procedure. Adapters are offered capabilities with their own small contracts and costs. The composite's properties are derived by declared composition rules; a missing rule is U and leaves the composite at N.

**Diagram: Composition graph: BlobVault plus EdgeKV refining DurableObjectStorage.**

- Required capability kind **DurableObjectStorage**: durable, key-addressable, persistent, low-latency-get.
- Composite offer **BlobVault + EdgeKV(front)** via a read-through cache adapter, synthesized three days after EdgeKV appeared. It refines the requirement (`arch.Refines`, status T, from 4 sandbox probes).
- Part **BlobVault** (provider kind "backup archive", metadata only): durable T, key-addressable T, persistent T, low-latency-get T; the last two were unmarketed and found by probe.
- Part **EdgeKV** (provider kind "edge cache", new offer on day 90): conditional-write T, persistent T, both unmarketed.
- Claim **pr.ContractPermitted** (Counsel's finding on the terms): on day 155 a `pr.TermsForbid` finding attacked it and the composite became inadmissible.

*From the provider-research run. The composite was verified, published as a knowledge bundle, and then revised when the provider's terms changed on day 150 to forbid the archive serving live traffic. The observations stand; the use is no longer permitted.*

## Aggressive inside the terms, never outside

Admissibility is a conjunction with a hard unknown:

```text
admissible(r) = permitted(r) ∧ lawful(r) ∧ no non-tradeable norm in force is violated by r
```

If contract permissibility is N, admissibility is N, and N is not permission. Provider intent is evidence, not a boundary: "the provider markets this for X" weakly supports permission for X but neither admits nor excludes Y. What excludes a use is a term the use would breach. What admits it is evidence that no term does: counsel's finding, an attestation, or the provider's own statement under a trust policy that gives providers standing on their own terms.

The provider-research organization makes this a constitutional line, and conditions the sandbox power itself on it, so an impermissible probe isn't forbidden and punished afterwards. It simply can't validly happen:

*provider-research.esk*

```esk
norm WithinTerms {
  prohibition on any Party
  aim occurred execute(pr.Probe(o, prop)) and not holds pr.ContractPermitted(o)
  level constitutional   not tradeable   not defeasible
}

pattern Experiment(owner : Party, hypothesis : Entity, budget : Quantity, duration : Duration) {
  scope Exp : org.Project in Research {
    position ExpOwner { cardinality 1 }
    requires capability Sandbox { operation probe(o : Entity) -> outcome : Claim  for Tested }
    norm SandboxProbe { power of ExpOwner to authorize execute about pr.Probe
                        when holds pr.ContractPermitted(hypothesis)
                        level operational }
    use fin.Budget(scope = here, resource = econ.Money, limit = budget, reserve = 0 USD,
          window = lifetime, orElse = gov.Freeze(except = { })) as ExpBudget
  }
}
```

## Provider research as an organization

Discovery at fleet scale is itself an Endoskeletal organization, with ten scopes running a twelve-step lifecycle as obligations:

DISCOVER → DOCUMENT → DECOMPOSE → HYPOTHESIZE → CHECK TERMS → EXPERIMENT → CLASSIFY → MAP → TEST COMPOSITIONS → VERIFY → PUBLISH → REVERIFY

Model-based positions (Reader, Decomposer, Hypothesizer, SecurityAnalyst) produce claims at N. Counsel, a person, rules on the terms for every hypothesis before any probe. Programs experiment, verify and publish. An Economist program ranks research by fleet demand × importance × uncertainty × savings × reuse ÷ probe cost. Over 270 days against a fictional provider:

|  |  |
| --- | --- |
| Unmarketed affordances found by experiment | 8 of 9. The ninth (a scheduled-jobs service used as general execution) is the one the terms forbid testing; the organization doesn't know it, on purpose |
| First-order hypotheses | 24 proposed, 16 refuted in the sandbox |
| Compositions verified and published | BlobVault + EdgeKV(front) as DurableObjectStorage; EventRelay + StateStore(dedupe) as DurableQueue |
| Deliberate misfires | 2, both an experimenter pressing ahead while Counsel's finding was N. Nothing was executed |
| Reverifications as claims aged | 114, all confirmed |
| Cost | 344.07 USD of sandbox probes, 36.38 USD surrogate inference, 7,560 min of Counsel attention |

## Knowledge bundles

Research is published as a bundle: content-addressed claims with their sources, validity and a verification policy. Importing a bundle doesn't make its claims true. They're asserted under the *importer's* trust policy, usually N until corroborated by the importer's own probe or a second publisher. Bundles never attack each other; corroboration and contradiction are derived claims.

*durableobjectstorage@2027.04.09.bundle.json (excerpt)*

```json
{
  "@type": "KnowledgeBundle",
  "name": "endoskeletal/knowledge/aurelian/durableobjectstorage",
  "version": "2027.04.09",
  "valid_from": "2027-04-09", "valid_to": "2027-06-08",
  "verification_policy": {
    "reverify_after": "P60D",
    "method": "sandbox re-probe",
    "corroborate_with": ["an importer's own sandbox probe", "a second research organization's bundle"]
  },
  "claims": [{
    "proposition": ["prop", "arch.Refines", "esk:entity/f97e033a98f5c8f0f58e682e", "DurableObjectStorage"],
    "provenance": "derived",
    "evidence": ["obs-9a9defab7a44", "obs-3bc26564368d", "obs-8237d1df775b", "obs-572941aae3fa"],
    "confidence": { "p": 0.9 },
    "derivedFrom": { "method": "refinement argument" }
  }],
  "content_hash": "sha256-88bf13f0315459318637345d178a924d5ad0a10d7f41063363ceee5b7f87557e"
}
```

A bundle is never edited. When the terms changed, the publisher issued `durableobjectstorage@2027.06.06-revised` containing a `pr.TermsForbid` claim that attacks the earlier refinement and supersedes the earlier content hash.

## The capability frontier

For each requirement, at any index, the frontier says where the organization stands. REALIZABLE splits by authority: the check runs the felicity function on a hypothetical bind and discards the verdict.

| State | Meaning |
| --- | --- |
| **REALIZED** | A bound, active realization with satisfaction T |
| **REALIZABLE within authority** | An evidenced, admissible candidate exists and some occupied position could validly bind it now |
| **REALIZABLE after amendment** | A candidate is admissible under every non-tradeable norm, but every bind power excludes it (allow-list, cost cap, level) — the answer names which envelope term, and the amendment level needed |
| **UNSATISFIABLE** | Every candidate over the current catalog fails a conjunct at F. Derived from catalog claims, so it lapses when the catalog changes |
| **UNKNOWN** | Otherwise, partitioned by why: no evidence, expired evidence, contract permissibility unknown, composition rule missing |

Real transitions from the Meridian run:

| When | Requirement | State |
| --- | --- | --- |
| week 1 | InferenceEU | UNSATISFIABLE (no catalog offer in EU jurisdiction) |
| week 32 | TicketTriage | UNKNOWN (expired evidence) |
| 2028-03-05, new offer | Observability | REALIZABLE within authority |
| week 61 | InferenceEU | UNKNOWN (contract permissibility) |
| week 62 | InferenceEU | REALIZED |
| 2028-07-01, offer removed | Queue | UNKNOWN (contract permissibility) |
| week 100 | Queue · Analytics · Observability | UNKNOWN (contract permissibility) |

`tools/frontier.py` answers the eight standing questions from this projection: what can we do now; what can we make true with existing authority; what after governance approval; what is blocked by provider availability; what is impossible and what would have to change; what remains unknown and why; and the cheapest and fastest paths to a given capability.