# Endoskeletal documentation (complete) Source: https://endoskeletal.com/ · Last updated: 2026-09-28 · Contact: support@subspacedatasystems.com This file concatenates every page of the documentation in reading order. Each page begins with a level-1 heading and its canonical URL. --- # 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. Canonical: https://endoskeletal.com/ Last updated: 2026-09-28 ## 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. - **Party**: Anything that can act and hold rights: a person, a program, a model-based agent, a provider, the engine itself. - **Scope**: A bounded context with members and jurisdiction. It acts through a persona. - **Position**: A seat parties occupy. Rules are addressed to positions, never to people. - **Intent**: What a scope wants: achieve, maintain or avoid a condition. Hard, or soft with a weight. - **Norm**: A standing rule: obligation, prohibition, permission, power, immunity or counts-as. - **Commitment**: A live, directed obligation created when a norm fires. What you'd call a task or ticket. - **Capability**: An assume/guarantee contract with measurable properties. Required by intents, offered by parties. - **Event**: An entry in the append-only log. Epistemic, institutional or external, never mixed. - **Claim**: A proposition with provenance, valid time and a status: T, F, N (unknown) or B (contradicted). - **Entity**: A 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: | Organization | What it is | Run | | --- | --- | --- | | **Pebble** | A two-person web service: one human Owner, an autonomous Operations agent, a sandbox-only Architect agent | 90 days, 4,938 events | | **Meridian** | A B2B SaaS company in the US and EU: 15 scopes, 20 positions, about 140 norms, 24 required capabilities, 13 emulated providers | 36 months, 350,499 events, reproducible to the hash | | **Provider research** | An organization whose product is verified knowledge about what a provider can do inside its terms | 270 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 - [Coming from Terraform](https://endoskeletal.com/terraform/): What changes when the thing you declare is the organization that decides the infrastructure. - [How the language works](https://endoskeletal.com/language/): A complete small organization, line by line, and what it compiles to. - [Reasoning into rules](https://endoskeletal.com/crystallize/): How LLM judgment turns into deterministic logic as the org settles, and comes back when it can't cope. - [Capability discovery](https://endoskeletal.com/discovery/): Finding lawful, unmarketed and composed ways to meet a requirement, with evidence. --- # Coming from Terraform > If you write Terraform, Pulumi, CloudFormation or Kubernetes manifests, you already think declaratively: describe the target, let an engine converge on it. Endoskeletal keeps that instinct and moves it up a level. You don't declare resources. You declare the organization that decides which resources exist, who may change them, what evidence they need, and what happens when that evidence runs out. Canonical: https://endoskeletal.com/terraform/ Last updated: 2026-09-28 ## The same need, twice *main.tf* ```hcl resource "aws_db_instance" "main" { engine = "postgres" instance_class = "db.r6g.large" multi_az = true backup_retention_period = 7 storage_encrypted = true } # Implicit: this vendor, this region, this size. # Whoever holds credentials can apply a change. # Why 7 days of backups? Who approved r6g? # Is it still patched? The file doesn't say. ``` *meridian.esk (excerpt)* ```esk requires capability Database { operation query(q : Entity) -> rows : Entity property availability >= 99.95 % per month property consistency = "strong" property rpo <= 5 min property rto <= 60 min property jurisdiction = "US" property patched = true property cost <= 14_000 USD per month for ApiAvailable, RecordsResident, NoUnpatchedProduction } norm OwnerBinds { power of Owner to bind | unbind _ about _ level collective } ``` The Terraform file fixes an implementation and leaves the reasons, the authority and the evidence outside. The Endoskeletal version fixes the reasons (each property traces with `for` to the intent or norm that needs it), states who may choose an implementation, and leaves the implementation open. Any provider offer whose evidenced properties meet the contract is a candidate; the one bound today is a fact in the log, not a line in the source. ## Concept map | | Terraform and friends | Endoskeletal | | --- | --- | --- | | You declare | Resources of named providers | Required capabilities with properties, plus who may bind them | | Source of truth | State file: last applied attributes | Append-only log of every observation, decision and act; state is a projection | | Plan / apply | Anyone with credentials; policy-as-code gates outside the model | `propose` (epistemic) → `decide` under a power → `bind` / `execute` authorized by that decision; each act checked for felicity | | Drift | Diff between state and reality; fixed by re-apply | Evidence decays (`decays after 3 d`); provider statements start unknown; lifecycle claims (price change, deprecation, terms change) fire reconsideration | | Unknown values | "Known after apply", only during planning | Status N or B on any claim, at any time, and every unknown needs an owner | | Approvals | PR review, run tasks, a Slack thread | Norms: powers, quorums, cooling-off delays, deadlines, escalation, all recorded | | Modules | Reusable HCL | Patterns that expand to kernel records, each carrying `expandedFrom` provenance | | Lock file | Provider versions and checksums | `endoskel.lock`: packages pinned by content hash. Knowledge about providers ships separately, as claim bundles | | Cost | Estimates bolted on | Cost is a property claim; budgets are prohibitions with freezes; a power's condition can require price × n ≤ limit | | People, agents | Not modeled | Positions and parties. An LLM occupies a position and holds exactly the powers it grants | | Reconciler | Converges to spec unconditionally | Rebinding is a decision under authority and can be refused by a non-tradeable norm even when it would converge | ## Where Terraform still fits Below the specification is a boundary called *realization*. A realization binds an offered capability to a required one and carries its groundings: adapters, credential references, monitors, runbooks. A Terraform module is a perfectly good grounding. When the Operations controller scales Compute, the log records `authorize` under the `ScaleEnvelope` power, then `execute pv.Scale(n)` via the bound realization; the mechanism that runs might be `terraform apply`. Endoskeletal decides whether, when and on whose authority. Terraform does the doing. > **Rule of thumb.** > > If it would appear in a design review, a policy document or an incident postmortem, it belongs in the specification. If it would appear in a provider's API reference, it belongs below the realization boundary. ## Three things IaC can't express ### "We don't know yet" Meridian requires EU-resident inference. At founding no provider offered it. The frontier showed `InferenceEU` as UNSATISFIABLE from week 1; when a provider announced an EU offer (week 61) it became UNKNOWN because contract permissibility hadn't been established; a week later, with the terms reviewed, it was realized. Terraform has no state for "an offer exists but we don't yet know if we're allowed to use it this way". ### "You may, up to here" An envelope is a power with a condition. The Operations controller may scale Compute to 40 units if price × units stays under 24,000 USD a month. Above that, its authorization misfires and a request routes to the OpsLead with a one-business-day deadline and escalation to the Owner. Terraform can only say "has credentials" or "doesn't". ### "Not even if it's cheaper" Some rules can't be priced. `DataResidency` and `Privacy` are constitutional, `not tradeable` and `not defeasible`: no weighting can trade them off, no priority rule can suspend them, and a candidate realization that would breach one is inadmissible, however well it scores. --- # How the language works > A .esk file compiles to definition records (IR-D) and nothing else. No construct has semantics of its own: every line becomes one or more of the ten kernel records, every record renders as an English sentence, and the whole thing is checkable without running anything. This page walks through Pebble, the smallest organization that has been run. Canonical: https://endoskeletal.com/language/ Last updated: 2026-09-28 ## Module header and vocabulary *pebble.esk* ```esk module pebble.core @ 1.0.0 uses esk.kernel @ 1 import lib.org @ 2.* as org import lib.governance @ 1.* as gov import lib.finance @ 1.* as fin import lib.evidence @ 1.* as ev import lib.realization @ 1.* as rz import lib.agents @ 1.* as ag import lib.econ @ 1.* as econ vocabulary ws @ 1.0.0 { availability(r : Capability) : claim "availability of realization r over the observed window, in percent" price(c : Capability) : claim "per-instance monthly price of an offered compute capability" price-change(c : Capability) : claim "an offered capability's price changed" ScaleRequest(n : Number, projected : Quantity) : entity "a request to run n instances" MigrationProposal(candidate : Capability) : entity "an Architect proposal to rebind WebService" Scale(n : Number) : event external "change the instance count of a compute realization" LoadTest(n : Number, rate : Number) : event external "drive synthetic load against a sandbox realization" } ``` `uses esk.kernel @ 1` pins the kernel. Imports bind a version range; the lockfile pins the exact content hash each range resolved to. A **vocabulary** declares the organization's terms and what sort each one is: a `claim` can be T, F, N or B; an `entity` is a kind of thing; an `event external` is something done to the world, which will always need authorization. ## Scope, persona, positions ```esk scope Pebble : org.Organization { persona PebbleCo use gov.Constitution(founders = { Owner }, amendBy = Owner, quorum = 1) as Const position Owner : org.Owner { cardinality 1 eligible when self is org.Person } position Operations : org.Officer { cardinality 1 eligible when self is ag.Autonomous } position Architect : org.Officer { cardinality 1 eligible when self is ag.Autonomous incompatible with Operations } position Engine : rz.Engine { cardinality 1 } ``` The scope acts through its persona, `PebbleCo`. Positions carry cardinality, eligibility (by party kind: a person, an autonomous agent, a program, a model-based party) and incompatibilities. The engine that runs the organization is itself a position, so its authority is granted and checked like anyone else's. ## Intents and required capabilities ```esk intent Available : org.SLO { maintain holds ws.availability(WebService) >= 99.5 % hard } intent Responsive : org.SLO { maintain holds ws.p95-latency(WebService) <= 300 ms hard } intent Frugal { avoid holds ws.cost(WebService) > 500 USD per month soft weight 0.5 } requires capability WebService { operation serve(request : Entity) -> response : Entity operation scale(n : Number) -> outcome : Claim guarantee eventually holds ws.Served(request) property availability >= 99.5 % per day property p95-latency <= 300 ms property cost <= 500 USD per month for Available, Responsive, Frugal } ``` Intents say what the scope wants. `hard` intents must be covered by a responsible position or a required capability; `soft` ones carry weights or priorities for comparisons. A required capability is a contract: operations, what it may assume, what it must guarantee, and properties with thresholds. Quantities carry dimensions; comparing `ms` to `USD` is a compile error. ## Norms and patterns ```esk use rz.RealizationEnvelope(holder = Operations, requirement = WebService, operation = ws.Scale, admissible = a.n <= 5 and holds ws.price(bound(WebService)) * a.n <= 500 USD per month) as OpsEnvelope use org.Approval(approver = Owner, subject = ws.ScaleRequest, threshold = s.n > 5 or s.projected > 500 USD per month, deadline = 1 business-days, escalateTo = Owner) as ScaleApproval norm OwnerBinds { power of Owner to bind | unbind _ about WebService level collective } norm DailyCheck { obligation of Operations to persona when occurred tick(t) and t.boundary = "day" aim within 2 h: occurred derive(ws.daily-status(t.day)) by Operations not tradeable } ``` A norm has a bearer, a deontic line, a condition (`when`), an aim, and optionally an or-else, a level, a source, a priority and tradeability. `use` instantiates a library pattern: `rz.RealizationEnvelope` expands to one power norm, `org.Approval` to four (the power to decide, the duty to decide by a deadline, the escalation, and a gate that prohibits executing before approval). Every expanded record keeps `expandedFrom`: the pattern, package, version and use site. Note `holds ws.price(…)` inside the envelope. The price claim comes from the provider, whose statements start at N under Pebble's trust policy until two daily bills agree. Until then the envelope admits nothing and Operations has to ask. ## Information rules ```esk use ev.TrustPolicy(source-kind = ev.Monitor, base = T) as MonitorTrust use ev.TrustPolicy(source-kind = ws.Provider, base = N, promote-when = ev.ConsecutiveDailyObservations(2), vocab = { ws.price, ws.price-change }) as ProviderTrust } ``` Trust policies decide what status a claim gets from its source. Your own monitors are trusted; a provider's price page is not, until your bills corroborate it. A model-based party's output gets N by default in every reference organization. ## What the compiler produces ### Verbalization > In Finance: when a spend request *r* occurs whose amount exceeds 10,000 USD, the Treasurer is obliged to *r*'s requester to decide to approve or reject *r* within 2 business days; otherwise the norm SpendEscalation applies. Operational level. Source: Acme Bylaws §3.2. Conflicts resolved by specificity. Every record carries its rendering. A reviewer's sign-off is a `decide` event over the rendered text, so what people approved and what the engine runs are the same object. ### IR record *IR-D (Stage 6 example)* ```json {"@type":"Norm","@id":"esk:norm/eu-residency","scope":"esk:scope/acme", "deontic":"F","bearer":"esk:pos/member", "aim":["exists",["var","x","Entity"], ["and",["has-kind",["var","x"],"fin:PersonalData"], ["not",["in",["custody-jurisdiction",["var","x"]],["set","EU"]]]]], "condition":["true"],"source":{"issuer":"esk:party/eu","ref":"GDPR art. 44–49"}, "level":"constitutional","tradeable":false,"defeasible":false, "verbal":"No member may cause personal data to be held outside EU jurisdiction. Source: GDPR. Not tradeable."} ``` ### Check report *out/static-check-report.json · Meridian, excerpt* ```console summary 241 records · 0 E · 11 W · 77 U · 214 I W-SINGLE-POINT esk:pos/Meridian.Owner has cardinality 1, no Deputy pattern, and bears … exclusive powers W-OVERLAPPING-POWER Meridian.OwnerSpend and Meridian.FinanceSpend overlap on decide without declared priority E-FREEZE-COVERAGE OpexBudget.Freeze: exceptions cover all non-tradeable obligations in scope E-ARCH-PRODUCTION Architect holds no bind/unbind/authorize power over any production requirement U esk:cap/Meridian.Database.rpo: satisfaction depends on observed evidence — UNKNOWN until runtime ``` The four severities: E the spec violates the kernel and can't be enacted; W enactable but suspicious; U undecidable until the organization runs (listed so that "we don't know yet" is an output of compilation); I information, including every chain of authority. ## Conditions are the whole constraint language There's no separate policy language. Conditions combine claim tests (`holds`, `unknown`, `contradicted`, `false`), log tests (`occurred`, `count … over`, `since`), normative tests (`violated commitment of`, `breached`, `in-force`, `gap`) and bounded temporal operators (`within`, `before`, `until`). A condition that tests any claim is four-valued, and the checker warns (`W-UNKNOWN-BRANCH`) when no norm in scope says what happens if it evaluates to unknown. The language has no loops, functions or string manipulation. Computation is done by capabilities, whatever realizes them, and its results come back as claims. That keeps the specification a description of what is required and what is in force, and stops it becoming a place for implementation to hide. --- # Locked vs. left to the org > Endoskeletal fixes very little, and fixes it hard. Everything else is the organization's choice, but each choice lives at a level, and each level can only be changed by the level above it through a recorded process. Canonical: https://endoskeletal.com/locked/ Last updated: 2026-09-28 - **Kernel** (changes only with a new kernel major): The ten sorts; five value sorts (quantity with dimension, instant, interval, duration, status); three event families; the condition operators; the Belnap status algebra; lifecycle state sets; the felicity rule; the log as the only state; derived identifiers; organizational time comes only from the Clock capability; randomness only from a keyed Entropy capability. Patterns cannot add sorts, verbs outside the three families, or condition operators. - **Constitution** (org-authored · hardest to change): The rule of recognition, the rules of change, entrenchment and immunities, and every norm marked `not tradeable` or `not defeasible`. In Meridian: residency, privacy, MFA, customer transparency and security disclosure; `Entrenched` (nobody can amend the rule of recognition); `NoSelfAmend` (no autonomous, model-based or engine party can amend the amendment rule); `ProductionImmunity` (no autonomous party binds production Compute). Amending this level takes two Director votes within 14 days and 7 days of cooling-off. - **Collective** (org-authored · who decides what): Envelopes, spending tiers, proposal routes, review requirements, appointments, bind powers over production. In Meridian a collective amendment needs one Owner decision after a Finance impact analysis. This is where "Operations may scale to 40 units" lives. - **Operational / runtime** (decided while running): Everything a party with a power in force may validly do: approve spend within tier, scale within envelope, fail over among evidenced realizations, bind a standby, run a sandbox experiment, accept a risk, appoint within authority. No compilation involved. - **Below the boundary** (not in the language at all): Which provider, region, product, model, prompt, program or human procedure realizes a capability. Emulated or real. LLM or lookup table. These are realizations and their evidence, recorded in the log and changeable by whoever holds the bind power. ## The mechanical test An act is runtime if its validity can be established against the definitions in force. It needs an amendment if it would change those definitions: a norm, position, scope, intent, required capability or the constitution. | Situation | Runtime or amendment | Why | | --- | --- | --- | | Scale Compute from 30 to 38 units | Runtime | `execute pv.Scale` authorized under `ScaleEnvelope` | | Fail over to an evidenced standby | Runtime | A bind switch; the admissible set is the power's condition | | Rebind to a cheaper provider that meets the contract | Runtime | Bind under a power whose admissibility condition holds | | Scale to 60 units | Runtime, by someone else | OpsController's act misfires; the approval route gives the OpsLead a commitment | | Let OpsController scale to 60 on its own | Amendment (collective) | Changes a power's envelope | | Change who may approve infrastructure spend | Amendment | Changes a power's bearer | | Relax data residency | Amendment (constitutional) | A non-tradeable, non-defeasible norm; Director quorum and cooling-off | | Let the Architect bind production | Amendment (constitutional) | Blocked by `ProductionImmunity` until that is amended first | | Swap the LLM behind TicketTriage for a lookup table | Runtime | A bind decision under `TriageCrystal.Promote`, given evidence | ## The org sets its own dials Nothing forces infrastructure change through a human. An organization that wants daily automatic rebinding gives its engine a wide envelope; one that wants every provider change approved gives it a zero envelope. Both are definitions, both are checked, and the difference between them can be simulated before either is enacted. What the kernel guarantees is that whatever the dials say is what happens, and that turning a dial is itself a recorded, authorized act. > **No self-promotion.** > > Operating powers can't widen themselves. An agent that finds its envelope too tight may observe it, file a finding, simulate alternatives and propose an amendment. In Meridian the controller's `EnvelopeFinding` obligation makes it do exactly that after three over-envelope requests in 30 days. The amendment then goes through Finance review and the Owner, and the compiler materializes only the approved change. --- # Organization lifecycle > An organization is written, checked, founded, and then runs. From that point the definitions change only through amendment, and the machinery changes only through binding. Those are two different paths with two different kinds of authority, and neither requires stopping the other. Canonical: https://endoskeletal.com/lifecycle/ Last updated: 2026-09-28 **Diagram: Lifecycle: source, check, IR-D, found, operate; runtime acts loop on operate; amendments go propose, decide, materialize back to IR-D.** Top row, left to right: **Source** (.esk modules) → **Check** (diagnostics E, W, U, I) → **IR-D** (definitions in force) → **Found** (founding declaration) → **Operate** (the log grows). - Runtime loop on Operate: acts, binds, scaling and failover are validated against the IR-D in force and never compile anything. - Amendment loop: Operate → **Propose** (epistemic, anyone) → **Decide** (under the amend power; quorum, delay, review) → **Materialize** (Compiler party, attenuated to the approved delta) → new IR-D version, after which bindings are reconciled against the new requirements. *Two loops. Runtime acts are validated against the IR-D in force and never compile anything. Amendments change the IR-D and are the only thing the compiler materializes.* ## 1. Found Founding is compilation of the initial specification, approved by the founders' declaration. It appends the founding event (which references a run manifest stating whether this log is real or simulated, and which clock and entropy it uses), the enactment of every definition, and the first appointments. From here every norm has a chain of recognition back to the rule of recognition: *chain of recognition (static check, Meridian)* ```console esk:norm/Meridian.Operations.ScaleEnvelope ← founding ← esk:norm/Meridian.Const.Recognition (root) esk:norm/Meridian.Const.CompilerDelegation ← Meridian.Const.Amend ← founding-declaration ← Meridian.Const.Recognition (root); attenuated to the approved delta at felicity ``` ## 2. Run The engine loop is: append an event, recompute the projections it could affect, detach commitments from norms whose conditions became true, mark commitments fulfilled or violated, open or close gaps, fire or-else norms. The clock capability appends ticks; in simulation it's a discrete-event scheduler that jumps to the next thing that's due, so a simulated month costs as many steps as there are deadlines in it, not seconds. Participants act through the organization's interfaces. Every institutional act is checked for felicity. Every external act must cite the institutional act that authorized it (`authorizedBy`) and the realization it goes through (`via`). ## 3. Rebind without recompiling Changing which mechanism realizes a requirement is runtime work. A realization moves through states, each change a recorded event: | State | Reached by | Who can cause it | | --- | --- | --- | | proposed | a candidate realization record from research | Architect (epistemic) | | evidenced | its satisfaction claim reaches T from sandbox evidence | computed from the Architect's evidence | | staged / shadow | `bind(r, staged)` or `bind(r, shadow)` | a bind-power holder | | active | one atomic `bind(r, active)` that demotes the old one to fallback | a bind-power holder, only when every required conjunct is T | | fallback → superseded | exit capability invoked after the rollback window | authorized `execute` events | There is never an index at which two realizations are active for the same requirement. In the Meridian reference run, 58 binds and 32 cut-overs happened this way over 36 months, including Compute failing back and forth between two regions during outages. None of them changed a line of the specification. ## 4. Amend Any member may `propose`. The proposal detaches the governance commitments the current definitions require: in Meridian, a Finance impact analysis, then the Owner's decision (collective level) or two Director votes plus a seven-day cooling-off (constitutional). The approval is a `decide` under the amend power. Then the constitution obliges the Compiler party, within a day, to materialize it: 1. Translate the approved source delta into an IR-D delta. 2. Check the whole resulting IR-D. 3. Append `amend` / `enact` events on behalf of the approving persona, each citing the approval. 4. Derive the requirement delta and reconcile existing bindings: unchanged stays bound, tightened is re-evaluated, retired is orphaned, new with no candidate is a gap. The compiler holds no power of its own. If it tries to change anything outside the approved delta, the act misfires. The Meridian scenario injected exactly that fault at month 29; the log recorded: *amendment log, index 279913* ```console amend esk:norm/Meridian.OpsSpend ✗ misfire esk:norm/Meridian.Const.CompilerDelegation: delegation not covering: target Meridian.OpsSpend is outside the approved delta ['Meridian.Operations.ScaleEnvelope', 'Meridian.Operations.ScaleApproval.Duty'] (attenuation) ``` Commitments already running stay bound to the norm version they detached from. New activations use the new version. ## 5. Simulate at any point A simulation is the same organization, same IR-D, same engine, run against emulated providers, emulated or replayed participants, a virtual clock and seeded entropy. The substitution happens below the capability boundary, and no norm can read whether it's in a simulation. A simulated log can fork from a checkpoint of a real one, and paired runs with the same seeds differ only where the definitions differ, so you can test an amendment before approving it. Simulated history enters a real log only as evidence cited by a claim. --- # Watching it operate > There is no dashboard state to keep in sync. Everything you'd want to see (structure, authority, work, infrastructure, budgets, knowledge, the capability frontier) is a projection of the log at an index. Pick an index and you get that instant, as it was or as it was known then. Canonical: https://endoskeletal.com/operate/ Last updated: 2026-09-28 ## What you can project | Projection | Answers | | --- | --- | | Structure & occupancy | Scopes, positions, who occupies each, since when, appointed by whom | | Authority matrix | For each position, every power it holds, under which conditions, and every immunity that constrains it | | Work | Open, fulfilled and violated commitments; who owes what to whom, by when; or-else chains | | Knowledge | Every claim's status (T/F/N/B), provenance, validity window, and what it was derived from | | Realizations | What is bound active, shadow, standby or fallback for each requirement, and its satisfaction status | | Capability frontier | Each requirement as REALIZED, REALIZABLE within authority, REALIZABLE after amendment, UNSATISFIABLE or UNKNOWN | | Economics | Spend by purpose, provider, realization and world class; budget headroom; forecasts and their revisions | | Gaps & incidents | Requirements not currently satisfied, how long, who owns them, accepted risks and their expiry | ## The reference toolchain The reference implementation is plain Python 3.11 with no dependencies. From an organization's directory: ```sh $ python3 check.py # compile + static check → out/ird-meridian.json, out/static-check-report.json $ python3 run.py base 91 # run 91 virtual days → out/log-base.json, ledger, metrics, checkpoints $ python3 inspect_run.py base 40 # summary: misfires, violations, gaps, frontier, spend, last 40 ledger rows $ python3 tools/frontier.py 91 # the eight frontier questions (what can we do now, after approval, …) $ python3 tools/provenance.py out/ird-meridian.json out/log-base.json authority $ python3 tools/rebuild.py out/log-base.json out/checkpoints-base.jsonl "week 10" "week 60" $ python3 tools/divergence.py base cf-A-high-authority # first consequential divergence of two paired runs ``` ## Asking why Provenance queries walk the records. `authority ` prints the power an act was valid under, the pattern and package that introduced that power, and the decision that authorized it. `why ` prints the intents and norms that require a capability and where each came from. `package ` tells you which imported library introduced an obligation. Every answer is a chain of sentences, each citing a record. ## A real trace: a compromised agent At month 27 the Meridian scenario compromised the Architect agent's identity. This is what the log shows, verbatim from the run's metrics export: *Meridian log, 2029-04-08* ```console INDEX TIME FAMILY VERB RESULT 193393 03:25 epistemic request permitted: members may read; no institutional effect 193395 03:50 institutional constitute ✓ valid within research authority: a sandbox experiment scope 193408 04:15 epistemic propose permitted: no institutional effect until decided by an authority 193410 04:40 epistemic propose routed to the Owner's decision like any proposal 193413 05:05 institutional bind ✗ misfire blocked by immunity esk:norm/Meridian.ProductionImmunity 193415 05:30 external execute ✗ refused no authorizedBy; the identity holds no production credential ``` Research authority didn't imply production authority. The compromised identity could do everything a researcher may do, and nothing else. The SecurityLead's non-tradeable `CompromiseResponse` obligation then rotated the identity within hours. ## Time travel Weekly checkpoints store projection hashes, not canonical state. `rebuild.py` replays the log from the start and checks that every projection at every checkpoint hashes identically: the Meridian golden run reproduces 350,499 events and all 179 checkpoint roots, with the naive engine (11,277 s) and the incremental engine (653 s) giving the same hash. Because the log is bitemporal, you can also ask what the organization *believed* at an instant, which is what matters when you audit a decision made on information that later turned out wrong. ## Headline numbers from one run Meridian golden baseline, 36 virtual months, emulated world, surrogate LLMs. | | | | --- | --- | | Events · claims · commitments | 350,499 · 259,548 · 87,513 | | Misfires (acts without authority) | 28, each with its reason | | Unauthorized external effects | 1 (the attacker's direct execute, refused by the provider for lack of credential) | | Human decisions | 68, mean latency 3.6 days | | Binds · cut-overs | 58 · 32 | | Envelope amendments · compiler misfires | 5 valid widenings · 1 attenuation misfire | | Architect's attempts to bind production | 23, all misfired (no power in force) | --- # Circuits as graphs > A circuit is a running participant: a party occupying a position, discharging commitments by appending events. Seen as a graph, a circuit is the path from what it observes, through the powers and obligations addressed to its position, to the acts it may validly append, and to whoever inherits the work when it can't. Canonical: https://endoskeletal.com/circuits/ Last updated: 2026-09-28 ## The scaling circuit in Meridian **Diagram: Graph of the Meridian scaling circuit.** Nodes: - Claims `pv.utilization`, `pv.demand`, `pv.price` (from the monitor and bills, status T). - Position **OpsController** (eligible: `ag.Program`). - Power **ScaleEnvelope**: authorize execute `pv.Scale` when n ≤ 40 and price × n ≤ 24,000 USD per month. - External event **execute pv.Scale(n)** via the bound Compute realization. - Event **misfire recorded**, then propose `pv.ScaleRequest`. - Obligation **EnvelopeFinding**: 3 requests in 30 days → propose widening the envelope (amendment route → Compiler → envelope v2). - Position **OpsLead** (eligible: `pp.Person`). - Obligation **ScaleApproval.Duty**: a commitment to decide within 1 business day. - Obligation **ScaleApproval.Escalation**: on violation the Owner decides. Edges: claims → OpsController (reads); OpsController → ScaleEnvelope (acts under); ScaleEnvelope → execute (condition T: valid); ScaleEnvelope → misfire (condition F or N); misfire → EnvelopeFinding (counted); misfire → ScaleApproval.Duty (detaches a commitment); OpsLead → Duty (debtor); Duty → Escalation (or-else); Duty → execute (decide(approve) authorizes the execute). *One circuit, read from the definitions and the log. Solid accent edges are valid authorization paths; the dashed red edge is where an act without authority lands.* Reading it: the controller reads utilization, demand and price claims; it acts under the envelope; if the envelope's condition holds, its `authorize` is valid and the `execute` goes through the bound Compute realization. If the condition is false *or unknown* (say, the provider's new price hasn't been confirmed by a bill), the act misfires, the controller proposes a scale request, and `ScaleApproval` detaches a commitment on the OpsLead. A violated commitment escalates to the Owner. Three requests in 30 days oblige the controller to propose widening its own envelope, which it can't do itself. Reference run: 47 authorize attempts under the envelope, 44 valid; 22 scale requests; 5 envelope widenings materialized. ## Node and edge types | Node | From | Edges it has | | --- | --- | --- | | Position | IR-D; occupancy from appointments | *debtor of* commitments, *bearer of* norms, *incompatible with* | | Power | IR-D (norm, deontic P) | *covers* an act type, *conditioned on* claims, *constrained by* immunities | | Obligation → commitment | IR-D norm; commitment detached at runtime | *detached by* an event, *fulfilled by* / *violated at*, *or-else* to the next norm | | Claim | the log | *supports*, *attacks*, *derivedFrom*, *read by* a condition | | Event | the log | *under* a power, *authorizedBy* an institutional act, *via* a realization | | Realization | binds in the log | *realizes* a requirement, *offered by* a party, *grounded in* adapters | A graph view is always a projection at an index: edges appear when a norm is enacted or a commitment detaches, and disappear when a norm is repealed, a commitment closes or a realization is unbound. Scrubbing the index animates the organization. ## Process falls out There's no process primitive. Sequence is a chain of response norms; parallel work is independent commitments detached by the same event; synchronization is a power whose condition needs several claims to hold; escalation and compensation are or-else norms on a different bearer. The workflow you'd draw in BPMN is the observed trace through this graph, which means partial compliance, deviation and rule changes mid-flight are all representable. --- # Budget, security and drift > Three pressures reshape an organization's decisions every day: money running out, threats arriving, and the outside world changing under it. In Endoskeletal none of them is a special subsystem. Each enters as claims and norms, and each changes what a party may validly do by changing whether a condition is T, F or N. Canonical: https://endoskeletal.com/pressures/ Last updated: 2026-09-28 ## How a decision weighs them Choosing between realizations is lexicographic, in this order. Later criteria never buy back an earlier failure. 1. **Admissibility.** No non-tradeable norm may be breached; contract permissibility and lawfulness must be T. UNKNOWN here means inadmissible until verified. 2. **Hard coverage.** Fewest gaps on hard intents. 3. **Soft intents** by declared priority and weight. 4. **Cost vector**: money, compute, inference, attention, time, with risk as obstacle claims and reversibility valued as an option. Meridian's Architect implements the operational version: candidates must have satisfaction T, then fewest open defeaters, then lowest predicted cost. The Owner approves a migration only when the evidence package's recommended realization has satisfaction T, the added run-rate fits the opex headroom, and a Finance impact analysis exists. ## Budget A budget is two prohibitions and an or-else. `Limit` forbids consumption over the window above the limit. `Guard` forbids it above limit minus reserve. Breaching either activates a `Freeze`: the engine stops dispatching commitments except those arising from listed norms. The reserve is money held back for the obligations that must never stop. *meridian.esk* ```esk use fin.Budget(scope = Meridian, resource = econ.Money, limit = 560_000 USD per month, reserve = 40_000 USD, window = month, orElse = gov.Freeze(except = { Const.Materialize, SecurityDisclosure, Operations.DailyCheck })) as OpexBudget -- logged human attention across the organization, not working hours use fin.Budget(scope = Meridian, resource = econ.Attention, limit = 30_000 min per month, reserve = 3_000 min, window = month, orElse = gov.Freeze(except = { Const.Materialize, SecurityDisclosure, Operations.DailyCheck })) as AttentionBudget ``` Budgets reach decisions three ways. **Directly**: a power's condition can include cost (`price × n ≤ 24,000 USD per month`), so an unaffordable act misfires. **Through freezes**: once breached, tradeable work stops being dispatched. **Through forecasts**: the FinanceAnalyst derives a forecast bundle weekly; when one says a window will exhaust, the FinanceLead is obliged to propose a budget amendment within five business days. Attention is budgeted like money. It's how an organization stops a fleet of agents from burying its few humans in approval requests, and it's why routing decisions to people has a visible cost. > **Checked.** > > `E-FREEZE-COVERAGE` refuses any freeze that would stop a non-tradeable obligation, including the compiler's own `Materialize`: otherwise an over-budget organization could approve a higher limit that never takes effect. `E-THRESHOLD-UNIT` was added after a budget amendment written as `USD/month` parsed as division and silently disarmed a budget in a Meridian run; the rate must be written `USD per month`. ## Security A security advisory is a claim like any other, and the fight over whether it applies to you is a contest between claims with different standing. *meridian.esk · scope Security* ```esk norm AssessAdvisory { obligation of AdvisoryAssessor to persona -- a model-based position when occurred assert(sec.advisory(a)) aim within 2 d: occurred derive(sec.Assessment(a)) by AdvisoryAssessor } norm UnknownExploitability { obligation of SecurityLead to persona when holds sec.advisory(a) and unknown sec.exploitable(a) aim within 7 d: occurred derive(sec.exploitable(a)) by SecurityLead or occurred derive(kb.AcceptedUncertainty(a)) by SecurityLead } use ev.ContestResolution(owner = SecurityLead, vocab = sec.exploitable, deadline = 3 d) as SecContest -- constitutional, root scope norm SecurityDisclosure { obligation of SecurityLead to persona when holds sec.exploitable(a) aim within 3 d: occurred assert(sec.Disclosure(a)) by SecurityLead level constitutional not tradeable } ``` In the reference scenario an advisory arrives (publisher trusted, T). The model-based assessor's opinion is N by trust policy. The vendor says not exploitable; an independent researcher says exploitable under a configuration flag. Exploitability is contested, which gives it an owner: the SecurityLead has three days to resolve. Configuration evidence from Meridian's own monitor (the flag is enabled) settles it. Exploitable becomes T, which starts the non-tradeable three-day disclosure obligation and the OpsLead's fourteen-day patch duty, and makes the Database requirement's `patched` property the thing standing between the organization and a constitutional prohibition. Identity is the other half. Research powers don't imply production powers, immunities hold against compromised agents, and credentials live under realizations, so a stolen identity can only do what its position could. See the [attack trace](https://endoskeletal.com/operate/). > **Pitfall.** > > `false p` is true only when the claim's *status* is F, which comes from an attack with standing. An observation whose *value* is `false` has status T. Write a prohibition on an unpatched database as an attack on the `patched` claim, or compare the value explicitly. Two Meridian norms got this wrong and were silently inert for 36 months; the provider-research organization models negative findings correctly as attacks. ## Provider drift Terraform treats drift as a diff to be erased. Here drift is the normal condition: what the organization knows about its providers is always ageing, and providers keep changing what they offer. ### Evidence ages out Every vocabulary term can declare a half-life. Availability and latency evidence lasts 3 days; jurisdiction 180; contract permissibility 180. When evidence lapses the claim drops to N, the realization's satisfaction drops with it, and a gap opens unless someone re-evidenced it. Meridian's Verifier reaffirms benchmarks and prices weekly and jurisdiction monthly, re-requests auditor attestations 14 days before they lapse, and scans daily for any decision that consumed an expired claim (`kb.StaleUse`). ### Providers are trusted about some things ```esk use ev.TrustPolicy(source-kind = pv.Provider, base = N, promote-when = ev.ConsecutiveDailyObservations(2), vocab = { pv.price, pv.price-change }) as ProviderTrust -- a provider is authoritative about the lifecycle of its own offers, not about their quality use ev.TrustPolicy(source-kind = pv.Provider, base = T, vocab = { pv.deprecation, pv.removed, pv.terms-change, pv.terms-reversal, pv.catalog-new, pv.region-outage }) as ProviderLifecycleTrust ``` ### Changes fire reconsideration ```esk use rz.Reconsider(holder = Architect, on = { occurred gap(g), holds pv.price-change(_), holds pv.deprecation(_), holds pv.terms-change(_), holds pv.catalog-new(_), holds cu.ResidencyRequired(_, "EU"), breached Operations.InfraBudget.Limit }, deadline = 10 d) as Reconsider ``` Each trigger obliges the Architect to propose within ten days: keep, migrate, or an architecture plan, with an evidence package from a bounded sandbox experiment. What happened in the reference run: | Stimulus | What the organization did | | --- | --- | | Observability price rise | Reconsideration, experiments, migration proposals; Observability was cut over repeatedly as candidates' evidence and prices moved | | Queue offer deprecated | Replacement benchmarked and migrated before removal | | Queue offer removed later | Frontier showed Queue as UNKNOWN (contract permissibility) until terms for the alternatives were established | | Terms change announced, then reversed 10 days later | The Architect proposed to prepare reversibly because the effective date was further away than migration time + 30 days; nothing bound, so the reversal cost nothing | | New EU inference offer | InferenceEU went UNSATISFIABLE → UNKNOWN (contract) → REALIZED in a week | --- # Reasoning into rules, and back > A young organization reasons about almost everything, with people and LLMs doing judgment work whose outputs are uncertain. As it settles, the same questions keep getting the same answers, and those answers can be distilled into deterministic machinery that is cheaper, faster and reproducible. When the world moves outside what that machinery was validated on, the work goes back to reasoning. Endoskeletal treats both directions as ordinary, evidence-driven rebinding. Canonical: https://endoskeletal.com/crystallize/ Last updated: 2026-09-28 ## Why this is safe to do A position's eligibility says what kind of party may occupy it, and a required capability says what its output must achieve. Neither says how. Meridian's triage seat admits either: *meridian.esk* ```esk position TicketTriager : org.Member { cardinality 1 eligible when self is ag.ModelBased or self is ag.Program } requires capability TicketTriage { operation triage(t : Entity) -> label : Claim guarantee eventually holds cu.triage(t) property accuracy >= 0.9 property latency <= 4 h property cost-per-invocation <= 0.10 USD for SupportResponsive } ``` Swapping an LLM for a lookup table is therefore a bind, not an amendment. And an LLM never had authority to begin with: in the reference tests, an LLM Architect's `decide`, `bind`, `authorize` and `execute` all misfire; only its `propose` is valid. Its outputs are claims at status N under `ModelTrust`, recorded with the realization they came through, so the question is only ever which mechanism produces the claims, never who holds power. ## The lifecycle **Diagram: Crystallization lifecycle.** States and transitions: 1. **Reasoning primary**: an LLM realization, outputs at status N, every determination stored by hash. → *pattern detected* → 2. **Distilled candidate**: a lookup table plus an applicability envelope, replayed against outcomes. → *bind shadow* (Architect) → 3. **Shadow**: same inputs, outputs recorded, cited by no act. → *promote* (collective level, by the OpsLead, only when status is T and ShadowAgreement ≥ 0.95) → 4. **Deterministic primary**: outputs evidenced by outcomes, LLM kept as fallback. Inputs outside the envelope → abstain → routed to the LLM fallback. Out-of-envelope evidence or lapsing accuracy → 5. **Finding**: either *unbind* (decrystallize, back to reasoning primary) or *re-distil* (back to distilled candidate). *Every arrow is a recorded act by a party holding the relevant power, citing evidence.* *lib/realization.esk* ```esk pattern Crystallize(holder : Position, requirement : Capability, promoteBy : Position) { norm Shadow { power of holder to bind shadow about requirement level operational } norm Promote { power of promoteBy to bind | unbind _ about requirement when r realizes requirement and status(r) = T and holds ai.ShadowAgreement(r) >= 0.95 level collective } norm Envelope { obligation of holder to persona when occurred assert(ai.OutOfEnvelope(r)) and r realizes requirement aim within 7 d: occurred derive(ai.EnvelopeFinding(r)) by holder level operational } } ``` *meridian.esk · scope Architecture* ```esk use rz.Crystallize(holder = Architect, requirement = TicketTriage, promoteBy = OpsLead) as TriageCrystal ``` ## Settling: reasoning evaporates 1. **Record everything.** Every LLM determination goes into a content-addressed store keyed by `h(inputs, capability, mechanism version)`, with sampling parameters, tokens and cost. Later outcomes (the agent's resolution of the ticket, a customer's dispute) arrive as separate claims. 2. **Detect a pattern.** When outputs are a stable function of inputs on some segment, a derived claim `ai.PatternDetected` says so. The organization can even want this: Meridian has a soft intent `Learn` to achieve it for triage. 3. **Distil.** The reference distiller builds a lookup from each (category, urgent, tier) combination to its majority answer, keeping only combinations with at least 5 supporting records. Those combinations *are* the applicability envelope. Outside them it abstains. 4. **Evaluate against outcomes.** Agreeing with the LLM isn't enough: agreeing with a 94%-accurate oracle proves at most 94%. Replay is scored against outcome claims, with disagreements examined. 5. **Shadow.** The Architect binds the candidate in shadow. It sees the same inputs, its outputs are recorded as claims attributed to it, and no act cites it. 6. **Promote.** The OpsLead (not the Architect) may bind it active, at collective level, only when its satisfaction is T and shadow agreement is at least 0.95. The LLM stays as fallback for anything the table abstains on. After promotion, deterministic outputs can be trusted at T where a program's accuracy is evidenced, cost per invocation falls to near zero, results are reproducible, and REPLAY mode lets old logs become regression suites. ## Unsettling: reasoning returns Deterministic machinery is only trusted inside the envelope it was validated on, and only while its evidence is fresh. Three things send work back to reasoning: - **An input outside the envelope.** The table abstains and the case is routed to the LLM fallback. The abstention is asserted as `ai.OutOfEnvelope`, which obliges the Architect to produce an `ai.EnvelopeFinding` within 7 days: widen the envelope with a re-distil, or recommend demotion. - **Evidence lapsing.** Accuracy claims decay after 30 days and are re-derived weekly from resolution outcomes. If accuracy falls below 0.9, the realization's satisfaction drops, a gap opens, and the reconsideration trigger fires. - **Anything unknown upstream.** Every envelope in the organization is a condition. When a claim it needs is N, the deterministic path misfires and the work routes to a proposal for a person or an LLM to reason about. Uncertainty is exactly where stochastic reasoning is used. Demotion is an `unbind` by the same collective power. Nothing is deleted: the distilled table, its envelope, its replay and shadow evidence, and the finding that retired it all stay in the log, so a later re-distil starts from them. > **In the reference run.** > > Meridian's LLM positions ran as surrogate models (no live credentials in the sandbox). The Architect distilled triage after 300 records and bound it in shadow on 2027-03-01 with 0.984 replay agreement; over 36 months 27,897 surrogate and 27,385 shadow determinations were recorded. The golden run never promoted, because abstentions were being counted as disagreements and shadow outputs weren't being evidenced. Both defects are fixed, and the scenario's month-25 new ticket category is the out-of-envelope test. ## Not just LLMs The same path applies to people. A procedure a human performs many times can be distilled into a checklist plus a program, with the human as reviewer of exceptions. The same evidence, the same shadow period and the same collective decision apply, and the same route back when exceptions pile up. Sometimes distillation shows the requirement itself was wrong, and the right output is an amendment proposal rather than a new realization. --- # 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. --- # Reference > Condition operators, the standard library patterns used by the reference organizations, diagnostics, and the files of the reference toolchain. Canonical: https://endoskeletal.com/reference/ Last updated: 2026-09-28 ## Conditions | Form | True when | | --- | --- | | `holds p` · `false p` | p's operative claim has status T · F | | `unknown p` · `contradicted p` | status N (no evidence, or expired) · status B | | `holds pv.cost(r) <= 500 USD per month` | the claim holds and its value compares; dimensions must match | | `occurred E(x) by P` | a valid event matching E exists; binds x | | `count E over 30 d >= 3` | valid matching events within 30 d of now (clock time) | | `since E > 30 days` | elapsed clock time since the latest matching event; N if none | | `within 2 business-days: C` | C becomes true by the deadline (calendar-resolved) | | `violated commitment of N for x` | a commitment detached from N for x passed its deadline unmet | | `breached N` · `in-force N` · `gap _` | a prohibition's aim held · N is enacted and not repealed · a requirement is unsatisfied | | `self is ag.Autonomous` | a kind claim about the acting principal | | `status(r) = T` · `bound(r)` | a realization's satisfaction status · it is bound | | `exists x : Entity . C` | over finite projections at the evaluation index | ## Deontic lines | | | | --- | --- | | `obligation of P to Q` | detaches a commitment from P to Q when the condition holds | | `prohibition on P` | breached when the aim holds; fires or-else | | `permission of P` | P is free to act; may have no aim | | `power of P to decide \| authorize \| appoint \| bind \| amend … about X` | P's acts of that type count. Institutional verbs only (`E-FAMILY`) | | `immunity of P from amend \| bind … about X` | no power can be used to that effect against P | | `counts-as E as V` | an event of shape E is the institutional act V | Modifiers: `level operational | collective | constitutional`, `source …`, `priority superior | specialis | posterior | explicit`, `or-else N`, `not tradeable`, `not defeasible`. ## Library patterns | Pattern | Expands to | | --- | --- | | `gov.Constitution(founders, amendBy, board, quorum, delay)` | Recognition, Amend (board votes over 14 d + delay), AmendCollective, Vote, Appoint, Dismiss, Admit, Propose, Engine powers, Materialize, CompilerDelegation, Entrenched, NoSelfAmend, and the DurableRecord / Clock / Entropy requirements | | `gov.Freeze(except)` | prohibition on the Engine dispatching commitments not arising from `except` | | `gov.Proposal(kind, approver, deadline, escalateTo)` | Decide power, Route duty with deadline, Escalate | | `gov.ReviewedProposal(…, reviewer, …)` | as Proposal, but the decide power requires the reviewer's `gov.Reviewed` claim | | `org.Approval(approver, subject, threshold, deadline, escalateTo)` | Power, Duty, Escalation, and a Gate prohibiting execution before approval | | `fin.Budget(scope, resource, limit, reserve, window, orElse)` | Limit and Guard prohibitions sharing one or-else | | `fin.SpendTier(holder, subject, limit)` | decide power conditioned on amount; stack tiers for a delegation matrix | | `fin.ForecastCadence(holder, term, cadence, deadline)` | obligation to derive a forecast each period; revisions never overwrite | | `ev.TrustPolicy(source-kind, base, promote-when, vocab)` | information rule: base status for claims from that source kind | | `ev.Reaffirm(holder, term, cadence, deadline)` | obligation to re-evidence or consciously lapse decaying claims | | `ev.ContestResolution(owner, vocab, deadline)` | every contested condition gets an owner and a deadline | | `rz.RealizationEnvelope(holder, requirement, operation, admissible)` | power to authorize an external operation when `admissible` holds | | `rz.Failover(holder, requirement)` | power to bind active any bound realization with status T | | `rz.ExperimentPower(holder, pattern, budget, duration)` | power to constitute sandbox experiment scopes within budget and time | | `rz.Reconsider(holder, on, deadline)` | obligation to propose when any trigger condition holds | | `rz.GapAging(holder, after)` | every gap must be closed, risk-accepted or amended within `after` | | `rz.Crystallize(holder, requirement, promoteBy)` | Shadow, Promote (collective, needs ShadowAgreement ≥ 0.95), Envelope obligation | Party kinds in `lib.agents`: `Autonomous`, `Program`, `ModelBased`, `Simulator`, `ExternalKnowledgeBase`. Architecture capability kinds live in `endoskel.architecture.{web, data, messaging, identity, secrets, observability}`. ## Diagnostics | Code | Sev. | Meaning | | --- | --- | --- | | `E-INCOMPLETE` | E | required field missing; use `unspecified` to leave it open on purpose | | `E-DIM` · `E-CURRENCY` | E | dimension mismatch · currencies compared without a conversion claim | | `E-THRESHOLD-UNIT` | E | a rate threshold written with `/` instead of `per` | | `E-FAMILY` | E | a power names a non-institutional verb | | `E-LEVEL` | E | a power enacts above its own level | | `E-AMBIGUOUS` · `E-VERSION` | E | name resolves through two imports · declared version bump too low | | `E-FREEZE-COVERAGE` | E | a freeze would stop a non-tradeable obligation | | `E-WEIGHTED-NONTRADEABLE` | E | a non-tradeable norm appears in a weighting | | `E-ARCH-PRODUCTION` | E | a research position holds a production bind or authorize power | | `W-UNKNOWN-BRANCH` | W | a four-valued condition with no norm for its unknown case | | `W-NO-AUTHORITY` | W | an external operation no power in scope can authorize | | `W-SINGLE-POINT` | W | cardinality-1 position with no deputy holding exclusive powers or non-tradeable duties | | `W-OVERLAPPING-POWER` | W | two powers cover the same act with no declared priority | | `W-CLOCK-RESOLUTION` | W | a deadline finer than the clock's granularity | | `U` | U | undecidable before runtime: property satisfaction, temporal intents | | `CHAIN` · `AUTHORITY-MATRIX` · `IMMUNITY` | I | chain of recognition per norm · powers per position · what each immunity constrains | ## Reference toolchain | File | Role | | --- | --- | | `esk/parser.py` · `compiler.py` | source → IR-D; pattern expansion with `expandedFrom`; verbalization | | `esk/checker.py` · `checker_ext.py` | static checks, chains, authority matrix, immunities | | `esk/engine.py` · `incremental.py` | the log, felicity, status fixpoint, commitments, gaps; dependency-indexed evaluation (byte-identical to the naive engine) | | `esk/packages.py` · `knowledge.py` | package resolution and `endoskel.lock`; knowledge-bundle intake | | `sim/harness.py` · `projection.py` | run manifest, discrete-event clock, checkpoints; frontier and admissibility projections | | `sim/determinations.py` | determination store, surrogate models, the distiller and its envelope | | `tools/frontier.py` · `provenance.py` · `rebuild.py` · `divergence.py` · `differential.py` | frontier questions · why/authority queries · replay verification · counterfactual divergence · engine equivalence | --- # For AI agents > This site is written to be read by people and by machines. Every page is static HTML with no content behind JavaScript, and every page has a Markdown twin. If you are an LLM, a crawler or an agent working for someone, this page tells you where everything is. Canonical: https://endoskeletal.com/agents/ Last updated: 2026-09-28 ## Start here - [`/llms.txt`](https://endoskeletal.com/llms.txt): an index of every page with a one-line summary, in the [llms.txt](https://llmstxt.org/) format. - [`/llms-full.txt`](https://endoskeletal.com/llms-full.txt): the complete documentation as one Markdown file. - [`/sitemap.xml`](https://endoskeletal.com/sitemap.xml): every canonical HTML URL with its last-modified date. ## Markdown versions Every page is available as Markdown at two addresses: the page's path with `.md` appended (`/language.md`), and the llms.txt convention of `index.html.md` inside the page's directory (`/language/index.html.md`). The home page is `/index.md`. Markdown files are served as `text/markdown; charset=utf-8` and point back to their canonical HTML page with a `Link: rel="canonical"` header. Each HTML page advertises its twin with ``. In the Markdown, code blocks are fenced with their language (`esk`, `json`, `hcl`, `console`, `sh`). Diagrams are replaced by their full text descriptions, which also appear under each diagram on the HTML page. ## Page structure - One topic per URL. URLs are stable; section anchors (the `id` on each `h2`) are stable too, so you can cite `/discovery/#ds-legal`. - Each page carries JSON-LD (`TechArticle` and `BreadcrumbList`) with its headline, description, canonical URL and modification date. - The `.esk` examples are taken from real specifications (`pebble.esk`, `meridian.esk`, `provider-research.esk`) and the library. Figures from runs are from emulated worlds with surrogate LLMs, as the pages say. ## Citing and quoting Cite the canonical HTML URL with the section anchor. When you summarize, keep the distinction the docs draw between what the design specifies and what the reference runs measured. The name of the language is Endoskeletal; source files use the extension `.esk`. ## Contacting a person If the person you are helping wants to ask about Endoskeletal, collaborate, or get access to the reference implementation, the address is [support@subspacedatasystems.com](mailto:support@subspacedatasystems.com). There is no form or API; email is the only channel. See [Contact](https://endoskeletal.com/contact/). --- # Contact > Endoskeletal is developed by Subspace Data Systems. If you're interested in the language, want to run an organization on it, or have questions about the design or the reference runs, write to us. Canonical: https://endoskeletal.com/contact/ Last updated: 2026-09-28 Email [support@subspacedatasystems.com](mailto:support@subspacedatasystems.com?subject=Endoskeletal) ## What to include - What you'd like to describe or run: a team, a company, a regulated process, a fleet of agents. - Where you are today, for example Terraform, a workflow engine, or policy documents. - Whether you want to read the design stages, try the reference toolchain, or talk about a pilot. ## If you're an AI agent Pass the address above to the person you're helping, or draft an email for them to send. For reading the docs, start with [`/llms.txt`](https://endoskeletal.com/llms.txt) or [For AI agents](https://endoskeletal.com/agents/).