How decisions get made

Needs, not vendors

An Endoskeletal specification says what the organization needs and why. It never says how. The compiler works out the full set of properties a capability must have from the rules and goals around it. It then judges every way of providing it on measured evidence, and it is indifferent to which of several equivalent answers ends up bound.

This page follows one need through the whole process: an audit trail that Northwind's enterprise customers can search and trust.

What a compiler is, and what this one does

Compilers exist so that people can say what they mean and leave the how to a program. Grace Hopper's A-0 in 1952 and FORTRAN in 1957 made the case: write formulas, not machine instructions, and let the compiler produce code nearly as good as a specialist would write by hand. Every compiler since has done some version of the same jobs:

1. Parse. Turn text into structure.
2. Check. Reject programs that can't mean anything, such as a type mismatch or an undefined name, before they ever run.
3. Infer. Work out what was left unsaid. Type inference derives the type of a value from how it is used, so the programmer doesn't have to write it.
4. Optimize under the as-if rule. Replace code with cheaper code only when the observable behavior is provably the same.
5. Select and link for a target. Choose among equivalent instruction sequences using a cost model of the specific machine, and resolve references to libraries.

Two later developments matter here. Just-in-time compilers, like the ones inside the JVM and JavaScript engines, watch a program run, compile the hot paths into fast specialized code guarded by assumptions, and fall back to the slower general path the moment an assumption breaks. And compiler writers learned not to trust data sheets: tools like llvm-exegesis measure instruction timings on the real chip, and projects like uops.info publish measurements because vendor manuals are incomplete.

Each job has a direct counterpart when the target is an organization:

Four things are different, and they're the reason this is a new language rather than a configuration format:

• It never stops compiling. A CPU's instruction set doesn't change after you ship. Prices, terms, outages and new offers change every week, so the compiler reruns whenever the evidence it depends on changes.
• It proposes; it doesn't bind. A CPU doesn't need to consent to being targeted. An organization does, so binding is an act that requires a power, performed by a party that holds it.
• Unknown is not assumed true. A C compiler trusts its target description. This one treats anything unproven as not permitted, and gives every unknown an owner.
• It explains itself. Every derived property, every rejected candidate and every ranking comes with its sources, in plain English.

The need, as written

This is the entire declaration. It names the operations, one guarantee, and the goals and rules the capability serves. It has no properties, no vendor and no architecture.

requires capability AuditTrail {
  operation append(e : au.Event) -> receipt : Entity
  operation query(t : cu.Tenant, q : Entity) -> rows : Entity
  guarantee eventually holds au.retained(e)
  for AuditExport, RecordsRetained, AuditIntegrity, TenantResidency, Frugal, ExitReadiness
}

The for line does the work. Each intent and norm named there is already in the specification for its own reasons: a contract clause, a SOC 2 control, a residency rule, a budget. The compiler reads what each of them implies for anything that stores audit events.

What the compiler derives

$ esk needs AuditTrail
AuditTrail · 0 properties written · 9 derived from 7 sources

  append-p99           <= 150 ms          ← intent AuditExport (contract § 6.1)
  query-p95            <= 2 s, ≤ 90 d     ← intent AuditExport (contract § 6.1)
                       <= 60 s, older
  throughput           >= 2,100 /s        ← claim ops.event-rate (peak × 1.5)
  retention            >= 7 y             ← norm RecordsRetained (soc2 CC7.2)
  single-party-delete  = impossible       ← norm RecordsRetained
                         not defeasible: must be prevented, not only forbidden
  tamper-evidence      = verifiable-by(t) ← norm AuditIntegrity (contract § 6.3)
  jurisdiction         = t.region         ← norm TenantResidency
                         every copy: replicas, backups, subprocessors
  cost                 <= 1,200 USD/mo    ← fin.Budget PlatformShare
  exit                 <= 5 d             ← norm ExitReadiness

$ esk realize AuditTrail --explain
searched 31 offers · 212 compositions · 8 survived decomposition
  equivalent   C  A  B  D     every condition T on evidence
  fails        E  jurisdiction F · cost F
               F  single-party-delete F · tamper-evidence F · query-older F
               G  single-party-delete F · tamper-evidence F
  unknown      H  terms N · retention N · single-party-delete N  → not admissible
proposal: C where cu.byob(t) holds, A otherwise; B, D as fallbacks
awaiting: bind by CTO (power PlatformBinds, collective)

Three of the nine are the ones design reviews miss:

• Single-party delete must be impossible, including for your own admins. RecordsRetained is a prohibition on any party and is not defeasible. A rule that can't be overridden can't rely on everyone behaving, so the compiler requires the realization to make the act impossible rather than merely forbidden. A lock that the account's root user can lift fails.
• Jurisdiction applies to every copy. TenantResidency is about custody, and custody includes replicas, backups and anyone with read access. A provider's support staff in another country count as a copy.
• Tamper evidence must be checkable by the customer. AuditIntegrity is owed to the tenant, so evidence only the operator can inspect doesn't discharge it.

The other six come from where you'd expect: latency and query speed from the contract, throughput from an observed claim (the 30-day peak with 50 % headroom, re-derived when the claim changes), retention from SOC 2, cost from the budget share, exit time from a constitutional norm.

The rules it derived them from

norm RecordsRetained {
  prohibition on any Party
  aim occurred execute(data.Delete, e) and e is au.Event and age(e) < 7 y
  source external soc2 # "CC7.2"
  level constitutional  not tradeable  not defeasible
}

norm AuditIntegrity {
  obligation of persona to cu.Tenant
  when e is au.Event and e.tenant = t
  aim holds au.verifiable-by(e, t)
  source external contract.Enterprise # "§ 6.3"
}

norm TenantResidency {
  prohibition on any Party
  aim exists x : Entity . x.tenant = t and custody-jurisdiction(x) != t.region
  level constitutional  not tradeable
}

-- what the compiler may believe about a provider's own description of itself
use ev.TrustPolicy(
  source-kind  = pv.Provider,
  base         = N,
  promote-when = ev.ConfirmedByOwnProbe(within = 14 d)
                 or ev.CorroboratedBy(3, independent = true),
  vocab        = { pv.latency, pv.throughput, pv.immutability, pv.residency }
) as ProviderSelfReports

position SecOfficer : org.Officer {
  cardinality 1
  incompatible with PlatformLead
}

What providers say is not evidence

A provider is authoritative about its own price list, terms and deprecations. It is not authoritative about its own latency, durability, immutability or residency. Under the ProviderSelfReports policy above, those claims start at N (unknown). They become T only when the organization's own probe confirms them, or when three independent organizations report the same measurement through the pool.

Three things in this table only show up because claims were checked:

• E advertises EU data residency. Its subprocessor list gives a US support team read access, so jurisdiction is F.
• F advertises searchable archives. A probe measured 4 to 9 hours to rehydrate an archived month, so query speed for older records is F.
• H advertises WORM compliance for a preview feature. No one has measured it and the preview terms exclude production data, so it is N. N is not permission: H isn't rejected, it waits, owned, until evidence arrives.

Claims are also not always wrong in the provider's disfavor. B's archive says “search in milliseconds” and measured 4.2 seconds, which is well inside the 60 seconds required for records older than 90 days. The engine uses the measured number either way.

Four equivalent designs

Each of these satisfies every derived property on evidence, so each is a correct implementation of the same specification. Only one of them resembles something you'd find in an architecture review.

Choosing among equivalents

Equivalence is decided by the properties. The choice among equivalents is decided by the organization's own objective, which is itself in the specification: money, logged human attention, and exit risk, each priced.

The engine proposes; it doesn't bind. The Architect's proposal is to bind C for every tenant where cu.byob(t) holds and A for everyone else, keeping B and D warm as fallbacks. The CTO holds the power to bind AuditTrail, and exercises it. The bind is one event in the log, with the whole argument attached: the derivation, the evidence behind every cell of the table, and the ranking.

What stays fixed when the implementation changes

Suppose the object store in A raises its price by 60 %. A price change is a trusted lifecycle claim, so Reconsider fires. B now ranks first for tenants outside the opt-in group; the Architect proposes the swap, the CTO binds it, and the migration runs as ordinary commitments with deadlines. Across that change:

• not one line of the specification changes;
• every norm keeps holding, because B was admissible under all of them before it was chosen;
• the audit history is continuous, because the log records which realization held each event;
• every tenant's query interface stays the same, because it is the capability's operation, not a vendor API.

That is what separating needs from implementation buys you. Infrastructure code describes one implementation and has to be rewritten to change it. A specification describes the need, and any implementation that satisfies it on evidence is interchangeable with any other.

How the search stays lawful

A composition search that finds an email archive can find many things. Three constraints keep it honest:

• Terms are a property like any other. Design B is admissible because a specific clause (§ 3.4) permits application-generated records. That clause is a recorded claim with a source. If the provider changes it, the claim changes and B drops out on the next evaluation.
• Probes run inside the terms. Every measurement comes from an experiment with its own budget and duration, and WithinTerms prohibits probing anything the contract doesn't permit. See Capability discovery.
• Unknown never counts as yes. Any condition at N makes a candidate inadmissible, however attractive its price. Unknown conditions get an owner and a deadline, so candidates like H come back when evidence does.

More compositions of this kind, including a backup archive used as object storage and a relay plus a store used as a queue, are on Non-obvious solutions. How measurements are shared across organizations is on Learn once, apply everywhere.