endoskeletal kernel 1 · lib 2026.09

Start here

Endoskeletal

Endoskeletal is a declarative language for describing an organization precisely enough that software, autonomous agents and people can run it together. A specification says who holds which positions, what the organization wants, which rules are in force, who may change them, and what the organization needs from the outside world. It never says which vendor, service or model provides any of it. That choice is made at runtime, by someone with the authority to make it, on recorded evidence.

Ten kinds of thing

Every specification compiles to records of ten kinds. Departments, workflows, tickets, approvals, budgets, KPIs, databases, agents and LLMs are all configurations of these ten, or implementation details beneath them.

PartyAnything that can act and hold rights: a person, a program, a model-based agent, a provider, the engine itself.
ScopeA bounded context with members and jurisdiction. It acts through a persona.
PositionA seat parties occupy. Rules are addressed to positions, never to people.
IntentWhat a scope wants: achieve, maintain or avoid a condition. Hard, or soft with a weight.
NormA standing rule: obligation, prohibition, permission, power, immunity or counts-as.
CommitmentA live, directed obligation created when a norm fires. What you'd call a task or ticket.
CapabilityAn assume/guarantee contract with measurable properties. Required by intents, offered by parties.
EventAn entry in the append-only log. Epistemic, institutional or external, never mixed.
ClaimA proposition with provenance, valid time and a status: T, F, N (unknown) or B (contradicted).
EntityA versioned, content-addressed thing: a document, dataset, package, adapter, plan.

Four ideas that make it different

  • The log is the only state. Who occupies what, which commitments are open, which claims hold, which rules are in force and which provider is bound are all computed from one append-only, bitemporal log. Nothing is updated in place, and any past instant can be reconstructed.
  • Authority is computed. Every institutional act is checked against the powers in force for that party, in that position, at that instant. An act without authority is still recorded, as a misfire with its reason, and changes nothing.
  • Unknown is a first-class answer. Claims are four-valued, and N and B are stable. No rule turns unknown into true. Evidence expires, so facts the organization once had go back to unknown unless someone re-establishes them.
  • What you need is separate from what provides it. You declare required capabilities with properties. Providers offer capabilities whose properties are claims with evidence. Binding one to the other is a runtime decision under a power, and it can change without touching the specification.

What exists and has run

The design is written up in nineteen stages (kernel, formal model, IR, language, realization, persistence, adversarial review, simulation, packages, architecture synthesis). A reference toolchain in Python 3.11 (standard library only) parses, checks, compiles and runs specifications. Three organizations have been run end to end against emulated providers on a virtual clock:

OrganizationWhat it isRun
PebbleA two-person web service: one human Owner, an autonomous Operations agent, a sandbox-only Architect agent90 days, 4,938 events
MeridianA B2B SaaS company in the US and EU: 15 scopes, 20 positions, about 140 norms, 24 required capabilities, 13 emulated providers36 months, 350,499 events, reproducible to the hash
Provider researchAn organization whose product is verified knowledge about what a provider can do inside its terms270 days, 11,988 events

Examples in these docs come from those three specifications and their logs unless marked otherwise. Numbers from runs describe emulated worlds and, where the LLM positions are involved, surrogate models.

Where to go