How decisions get made
Non-obvious solutions
Because requirements are contracts and provider offers are bundles of evidenced properties, the search for a way to meet a need isn't limited to products sold for that need. It finds primitives that happen to afford what you require, composes them, and keeps only what the providers' terms allow. Some of the best answers are things nobody would have put on a vendor shortlist.
Text description of this diagram
The requirement DurableQueue (ordered, at-least-once, persistent, idempotent) is decomposed by a library method into sub-contracts. A managed queue fails on jurisdiction (F). Using a scheduled-jobs service as a queue fails because the provider's terms forbid that use (F). An event relay provides ordering and persistence; a state store with conditional writes provides deduplication. Together, through an adapter, they refine DurableQueue with terms at T and verified evidence, and the composite is offered back as a candidate with its refinement argument. The two rejections are recorded so a later change in evidence can revive them.
How the search thinks
- Categories are ignored. A provider calling something "backup archive" is metadata. What counts is the affordance vector: durable, key-addressable, conditional writes, ordered, jurisdiction, cost per operation.
- Contracts decompose. Library methods split a requirement into sub-contracts (durable persistence → append + index + retention + jurisdiction pin), and each part can be met by a different offer, an adapter, an existing realization or a person.
- Terms bound the search. A composition is admissible only when contract permissibility is T. Unknown is not permission.
- Rejections are kept. Every candidate that fails is recorded with the conjunct that failed, so when a price, a term or a property changes, it comes back by itself.
A gallery
Need · durable object storage, fast reads
A backup archive with an edge cache in front
The archive turned out to be persistent with low-latency gets, neither of which it advertises. An edge key-value store with conditional writes fronts it through a read-through adapter. Together they refine DurableObjectStorage at a fraction of the price of the product sold for it.
Why it's admissible: counsel's finding that the archive's terms permit serving live reads, cited to the clause.
Need · ordered, at-least-once, idempotent queue
An event relay plus a state store for dedupe
The relay gives ordering and persistence. The store's conditional writes give idempotency keys. The adapter writes the key before acknowledging. The composite behaves like exactly-once processing for consumers that never saw a queue product.
Why it's admissible: both offers' terms permit the use; the composite's properties are derived by declared composition rules, and sandbox probes confirm them.
Need · 10-year tamper-evident record, EU
An append-only sheet with hourly snapshots
A spreadsheet service in append-only mode, a scheduler that snapshots it hourly to EU object storage, and an adapter exposing record and retrieve. For low-volume records like board minutes or access reviews, this meets the contract with no database at all.
Why it's admissible: retention and jurisdiction evidenced by the storage provider's attestation, immutability by snapshot hashes the organization checks itself.
Need · triage 20,000 tickets a month at under 1 cent each
A lookup table distilled from the LLM's own history
Most tickets fall into a few hundred (category, urgency, tier) combinations the LLM always answers the same way. A table covers those; the LLM handles the rest. Cost per ticket drops two orders of magnitude, and nothing leaves the envelope it was validated on. See Reasoning into rules.
Why it's admissible: shadow agreement ≥ 0.95 against outcome claims, not just against the LLM.
Need · disaster recovery for the primary database
The migration machinery you already have
Every bound realization must have an exit capability, rehearsed. Scheduling that exit's export into a second provider's import, daily, gives a warm standby built from parts the realization contract already required.
Why it's admissible: the export is an operation of the realization you already bound; the standby's RPO is evidenced by the rehearsal.
Need · quarterly access review for SOC 2
A person with a checklist
Sometimes the answer isn't software. A human procedure is a realization too: the GRC analyst's position offers the capability, the runbook is its grounding, the attestation is its evidence. It costs four hours a quarter and satisfies the control without a new vendor.
Why it's admissible: the attestation event counts as the review under the organization's own counts-as rule.
Need · general-purpose background compute
A scheduled-jobs service as a worker pool (rejected)
It would work, and it would be cheap. The provider's terms forbid using it for general execution. The candidate is recorded as rejected on the terms conjunct and never probed, and if the terms ever change, it comes back.
Why it's out: pr.TermsForbid at T. No budget or priority can outweigh a non-tradeable rule.
Asking for one
You don't ask for solutions by name. You state the need precisely and let the Architect's research, bounded by its sandbox budget, find candidates. The more exact the contract, the more unusual the answers it can accept.
requires capability EventLog {
operation append(e : Entity) -> receipt : Entity
guarantee ordered(e) and eventually holds delivered(e)
property idempotent = true
property durability >= 99.999 %
property jurisdiction in { "EU" }
property p99-append <= 50 ms
property cost <= 900 USD per month
for OrdersProcessed, EUResidency
}
use rz.Reconsider(
holder = Architect,
on = { gap EventLog, holds pv.catalog-new(_) },
deadline = 10 d
) as FindEventLogNothing here says "queue". A managed queue, a relay with a store, or a composite nobody has thought of yet are all candidates, ranked by evidence and cost, and the one that gets bound is chosen by whoever holds the bind power.