# Endoskeletal > Endoskeletal is a language for describing a software company precisely enough that people, programs and AI agents can run it together. You write who holds which seats, what the company wants, which rules are in force and who may change them. The compiler checks it, explains it back in plain English, and draws it as the org tree and circuits you see below. Canonical: https://endoskeletal.com/ Last updated: 2026-10-07 **Live demo.** The home page shows this specification typing itself while its org tree (Northwind → CEO, VPEng, Platform [OnCall, Deployer (program)], Product [PM, Triage (LLM)]) and its circuit render beside it. A low-risk change flows through the AutoShip envelope straight to deploy; a high-risk change routes to the VPEng's Review commitment, whose approval authorizes the deploy; the deploy is measured by the ApiUp SLO. ```esk module northwind.core @ 1.0.0 import lib.org @ 2.* as org import lib.agents @ 1.* as ag import lib.realization @ 1.* as rz scope Northwind : org.Organization { persona NorthwindCo position CEO : org.Owner { cardinality 1 } position VPEng : org.Officer { cardinality 1 } scope Platform : org.Team in Northwind { position OnCall : org.Member { cardinality 2.. } position Deployer : org.Member { eligible when self is ag.Program } } scope Product : org.Team in Northwind { position PM : org.Officer { cardinality 1 } position Triage : org.Member { eligible when self is ag.ModelBased } } intent ApiUp : org.SLO { maintain holds ops.availability(Api) >= 99.95 % hard } use rz.RealizationEnvelope( holder = Deployer, requirement = Api, operation = eng.Deploy, admissible = c.risk = "low" and holds ci.passed(c) ) as AutoShip use org.Approval( approver = VPEng, subject = eng.Change, threshold = c.risk = "high", deadline = 4 h, escalateTo = CEO ) as Review } ``` ## What you write, what you get - **An org tree that is also a permission system**: Scopes and positions are the org chart. Powers attached to positions decide which acts count. There is no separate IAM model to drift out of sync. - **Circuits instead of workflows**: Approvals, escalations, on-call ladders and release trains fall out of obligations with deadlines and or-else rules. Every run leaves a trace you can replay. - **Vendors as a runtime choice**: You declare the capabilities you need and their properties. Which provider, model or program fills them is bound on evidence and can change without touching the spec. ## A real circuit: the observability bill A provider changes its log-ingest price and Northwind's observability bill heads 38 % over budget. Nobody files a ticket. Watch seven separate responsibilities resolve it: observation, finance, research, security, a council vote, platform and verification. Each act can only be performed by one seat, and one seat tries to act outside its role. **Circuit diagram: an observability bill over budget, resolved across seven separated responsibilities** (swimlanes: Observability, Finance, Research, Security, InfraCouncil, Platform, Verification). Steps: 1. The Monitor, a program, reports log ingest at 41 TB this month, and the vendor's invoice at its new rate. Both are claims, each with a source and an expiry. 2. FinanceBot projects Observability at 18,600 USD against a 13,500 USD budget. The projected breach is true, so ObsBudget opens a commitment: a proposal within 5 days, or debug-level ingest is throttled. 3. The Architect, an agent, owes the proposal. It searches 212 compositions and shortlists three: sampling at the collector, a self-hosted collector writing to object storage with a query engine, and a second vendor. 4. Research runs as an Experiment with its own 400 USD budget and a 7-day limit, probing only what each provider's terms permit. The self-hosted design measures p95 query at 1.8 s for 9,800 USD a month. 5. The logs contain customer personal data, so moving them needs a security clearance. The SecurityLead, who proposed nothing, clears it on one condition: the collector scrubs PII before storage. 6. InfraCouncil votes on the proposal and its evidence. Finance approves, Ops approves, Product rejects over the cost of migrating dashboards. Two of three within 24 hours: the vote carries. 7. The Architect tries to bind the new realization itself. Misfire: the Architect's seat is incompatible with the CTO's, so the seat that proposes can't bind. The attempt is recorded and changes nothing. 8. The CTO binds. That is valid now, because the vote carried and security cleared. The Deployer, a program, executes the cut-over. It may execute, but never bind or verify. 9. The Verifier, a different program, checks coverage: all 212 services reporting within 48 hours. The rollback obligation lapses. The new forecast is 9,800 USD, and the budget holds. Who may do what: - **Monitor** (program): may observe - **FinanceBot** (program): may forecast - **Architect** (agent): may propose, research; forbidden: clear (incompatible with SecurityLead); bind (incompatible with CTO); verify (incompatible with Verifier) - **SecurityLead** (person): may clear - **InfraCouncil** (3 people): may vote - **CTO** (person): may bind; forbidden: propose (a binder may not propose) - **Deployer** (program): may execute; forbidden: verify (incompatible with Verifier) - **Verifier** (program): may verify; forbidden: execute (a verifier may not execute) ```esk use fin.Budget( scope = Platform, resource = econ.Money, limit = 13_500 USD per month, reserve = 1_000 USD, window = month, orElse = ops.Throttle(level = "debug") ) as ObsBudget norm ProposeOnBreach { obligation of Architect to persona when holds fin.projected-breach(ObsBudget) aim within 5 d: occurred assert(arch.Proposal(_, Observability)) by Architect } use rz.ExperimentPower( holder = Architect, pattern = Experiment, budget = 400 USD, duration = 7 d ) as Research norm EgressReview { obligation of SecurityLead to persona when p is arch.Proposal and holds data.contains-pii(p.moves) aim within 3 d: occurred decide(clear | refuse, p) by SecurityLead } norm CouncilVote { power of InfraCouncil to decide vote-approve | vote-reject about arch.Proposal } norm BindObservability { power of CTO to bind | unbind _ about Observability when p is arch.Proposal and count decide(vote-approve, p) by InfraCouncil over 24 h >= 2 and occurred decide(clear, p) by SecurityLead level collective } norm VerifyCutover { obligation of Verifier to persona when occurred execute(rz.CutOver(Observability, r)) aim within 48 h: occurred derive(ops.coverage(r)) by Verifier or-else Rollback } position Architect : org.Member { eligible when self is ag.Autonomous incompatible with CTO, SecurityLead, Verifier } position Verifier : org.Member { eligible when self is ag.Program incompatible with Deployer } ``` ## A compiler, pointed at an organization A compiler turns something written for people into something a machine can run. Along the way it rejects programs that can't mean anything, infers what the programmer left unsaid, and chooses the cheapest of many equivalent instruction sequences for the exact chip in front of it. The programmer never picks registers. Endoskeletal's compiler does the same jobs for a company. The program is the specification. The machine is everything available to run it: people, programs, models and providers, each with measured costs and limits. Two differences matter: it never stops compiling, because that machine changes every week, and it proposes but never binds, because an organization has to consent to what runs it. **Diagram: A classic compiler and the Endoskeletal compiler, stage by stage.** Two rows of seven stages. A classic compiler: source, parse, type check, infer types, optimize under the as-if rule, select instructions with a cost model of the CPU, link into a binary. The Endoskeletal compiler: the .esk specification, parse into records, felicity check, derive needs from norms and intents, search for equivalent realizations, rank them by the organization's own objective, and bind by a party with authority. Dotted lines pair each stage with its counterpart. A loop from bind back to derive shows that the Endoskeletal compiler reruns whenever evidence changes. *Same five jobs, different machine. The highlighted stages are where the organization’s rules and measured evidence replace a CPU’s data sheet.* [What compilers have always done, and how each job maps to an organization.](https://endoskeletal.com/needs/#n-compiler) ## You write the need. The compiler works out the rest. A specification never names a vendor, a product or a model. Below is an enterprise audit trail declared with no properties at all. The compiler derives nine from the rules and intents around it, including three that design reviews routinely miss. It then tests 31 offers and 212 compositions against measured evidence, not against what providers say about themselves. **Diagram: Seven statements in the specification imply nine properties of the AuditTrail capability.** Seven statements in the specification imply the nine properties of AuditTrail. Properties marked “often missed” are ones a design review commonly overlooks. - **intent AuditExport** (enterprise contract § 6.1) → append p99 ≤ 150 ms, query p95 ≤ 2 s recent · ≤ 60 s older - **claim ops.event-rate** (observed · 30-day peak × 1.5) → throughput ≥ 2,100 events/s - **norm RecordsRetained** (SOC 2 CC7.2 · not defeasible) → retention ≥ 7 years, single-party delete impossible, even for our admins - **norm AuditIntegrity** (enterprise contract § 6.3) → tamper evidence verifiable by the customer - **norm TenantResidency** (DPA § 4 · constitutional) → jurisdiction tenant region, every copy and backup - **fin.Budget PlatformShare** (weighted by intent Frugal) → cost ≤ 1,200 USD per month - **norm ExitReadiness** (constitutional) → exit ≤ 5 days to another realization *Nobody wrote these nine properties. Each follows from a rule or goal already in the specification, and changes when that rule or goal changes.* **Candidates against the derived properties** (T true on evidence, F false, N unknown): - **A. Locked object storage + queue + embedded query**: equivalent. jurisdiction of all copies: T (EU and US buckets, replication off; provider says “multi-region by default”: switched off and verified). - **B. Search cluster we already run (90 d) + an email-journaling archive**: equivalent. query p95 ≤ 60 s (older): T (4.2 s; provider says “search in milliseconds”: measured 4.2 s, still inside 60 s). - **C. Customer-held buckets, for tenants who opt in**: equivalent. every condition T. - **D. Two providers, two roots, held by incompatible seats**: equivalent. every condition T. - **E. Managed audit-log service**: fails. jurisdiction of all copies: F (US support subprocessor has read access; provider says “EU data residency”); cost ≤ 1,200 USD/mo: F (3,400 USD). - **F. Our observability vendor's log archive (already under contract)**: fails. single-party delete impossible: F (an account admin can purge); customer-verifiable tamper evidence: F (nothing the customer can check); query p95 ≤ 60 s (older): F (rehydration takes 4–9 h; provider says “searchable archives”). - **G. Append-only table in the primary Postgres**: fails. single-party delete impossible: F (a superuser can drop the table); customer-verifiable tamper evidence: F (nothing the customer can check). - **H. A provider's new “immutable tables” (preview)**: unknown · not permitted. terms permit this use: N (preview terms exclude production data); throughput ≥ 2,100/s: N (no independent observation); retention ≥ 7 y: N (says 7 y; no evidence; provider says “WORM compliance”); single-party delete impossible: N (no evidence; provider says “cannot be deleted”); customer-verifiable tamper evidence: N (unknown); query p95 ≤ 60 s (older): N (unmeasured); exit ≤ 5 d: N (unknown). Four designs are equivalent, and none of them is the one an experienced architect would sketch first: a compliance-locked object store fed by a queue you already run; your search cluster plus an email-journaling archive; the customer's own bucket; and two ordinary stores whose root keys sit in seats the org chart declares incompatible. [See all four, and how the engine chooses among them.](https://endoskeletal.com/needs/) ## Watch it work through real situations Four situations from one month at a SaaS company. Step through the log: each entry says who acted, in what capacity, and why the engine accepted, held or refused it. The strip above each log shows who carried the work at each step, a program, a model, or a person. ### Crystallized logic meets a product launch Support tickets at Northwind are labelled by a program distilled from four months of LLM decisions. It handles 96 % of tickets at under a tenth of a cent each and abstains on the rest. On Tuesday, Billing v2 ships. 1. **Tue 10:00 · event · Deployer · program.** `eng.Release(billing-v2)` executed through AutoShip. *Why:* A routine low-risk release. Nothing about triage has changed yet. 2. **Tue 11:40 · scripted · TriageProgram.** Abstains on 214 of 690 tickets (31 %) as outside its envelope; they route to the model-based triager. *Why:* The envelope is the region of input the program was distilled from. Tickets about proration and invoice previews fall outside it, so the program declines instead of guessing. Abstaining is a valid act. Mislabelling is not. 3. **Tue 11:41 · reasoning · Triage · LLM.** Labels the 214 abstained tickets, at 0.041 USD each. *Why:* The stochastic path was never removed, only bypassed. It takes back exactly the inputs the program can't cover, so the capability's accuracy ≥ 0.9 keeps holding while cost per ticket rises. 4. **Tue 11:41 · claim · engine.** `ai.OutOfEnvelope(TriageProgram)` asserted. The Envelope norm opens a commitment on the Architect, due in 7 days. *Why:* A rising abstention rate is evidence that the program's world has moved. The pattern turns that into an owned obligation with a deadline, not a dashboard someone might notice. 5. **Tue 12:05 · reasoning · Architect · agent.** Clusters the abstained tickets into three new intents (proration dispute, invoice preview, seat downgrade) and drafts rules for them. *Why:* Naming categories nobody has written down yet is reasoning work. Its output is a proposal in the log, not a change to production. 6. **Tue 12:06 · valid act · Architect · agent.** `bind shadow TriageProgram v5`. Valid under TriageCrystal.Shadow. *Why:* A shadow sees every live ticket and its labels are compared with the LLM's, but never used. The Architect may do this alone because a shadow can't act. 7. **Thu–Mon · claim · engine.** `ai.ShadowAgreement(v5)` rises 0.88 → 0.93 → 0.97 over 2,900 tickets. *Why:* Agreement is a claim with a source and an expiry like any other. It must reach 0.95 before promotion is even possible. 8. **Mon 09:30 · misfire · Architect · agent.** `bind TriageProgram v5` → misfire: the power to promote belongs to the OpsLead. *Why:* The seat that wrote the rules can't promote them. The attempt is recorded and changes nothing. 9. **Mon 09:44 · person · OpsLead · person.** `bind TriageProgram v5`. Valid: status T and agreement 0.97 ≥ 0.95. *Why:* Promotion is a collective-level act by a different seat, conditioned on evidence that is current. 10. **Mon 09:45 · scripted · TriageProgram v5.** Abstention back to 4 %; 0.0009 USD per ticket. Envelope commitment discharged on day 6 of 7. *Why:* Scripted logic covers the new world, and reasoning returns to the edges. **Outcome.** Accuracy never dropped below 0.9. The reasoning share rose from 4 % to 31 % for six days and fell back. No person wrote a triage rule; one person approved one promotion. The rules behind it (northwind.esk · scope Support): ```esk requires capability TicketTriage { operation triage(t : Entity) -> label : Claim property accuracy >= 0.9 property cost-per-invocation <= 0.10 USD for SupportResponsive } use rz.Crystallize( holder = Architect, requirement = TicketTriage, promoteBy = OpsLead ) as TriageCrystal ``` ### A production credential leaks at night A deploy token for the production API is pushed to a public fork at 02:14. The on-call engineer is asleep; the Ops agent is not. Two different acts are needed, and they need different authority. 1. **02:14:07 · event · secret scanner · vendor.** `sec.exposed(tok-prod-deploy)` reported by the code host's secret scanning. *Why:* Exposure reports from the code host are trusted at T by the org's SecretTrust policy, so the clock starts without anyone confirming. 2. **02:14:07 · scripted · engine.** Norm RotateExposed fires: a commitment on Ops to rotate within 30 minutes, or else on OnCall. *Why:* A standing obligation, written once. The deadline sits on a seat, not a person. 3. **02:14:40 · reasoning · Ops · agent.** Assesses blast radius: token scoped to deploys of Api, last used 01:58 from CI, three services read it. *Why:* Reasoning over logs and the dependency graph. The assessment is an entity in the log that later acts can cite. 4. **02:15:08 · valid act · Ops · agent.** `execute sec.Rotate(tok-prod-deploy)`. Valid inside RotationEnvelope; the three services pick up the new token. *Why:* Rotating a credential the org can reissue is inside the agent's envelope, so nobody is woken. The exposed token has been dead for 61 seconds. 5. **02:19:30 · reasoning · Ops · agent.** Finds the fork also holds `.env.staging` with 41 tokens from the same CI runner, 12 of them used by customer webhooks. Proposes change #7741: revoke all 41. *Why:* A broader act with a broader blast radius: revoking now would break 12 customer integrations at 2 a.m. 6. **02:19:31 · misfire · Ops · agent.** `decide approve #7741` → misfire: NoSelfApproval, the author of a change can't approve it. *Why:* The prohibition is not defeasible. The agent isn't trusted less than a person; nobody may approve their own change. 7. **02:19:31 · scripted · engine.** RevokeReview opens on the VPEng: customer-affecting revocation, decide within 4 h or escalate to the CEO. Paged. *Why:* The threshold is part of the approval pattern: affecting customers routes to a person. 8. **02:20:02 · unknown · engine.** `sec.exploitable(staging tokens)` is unknown. UnknownExploitability commitment on the SecurityLead, 7 days. *Why:* Nobody knows yet whether staging tokens reach customer data. Unknown is not treated as safe, or as breached; it gets an owner. 9. **02:44:15 · person · VPEng · person.** Approves a narrower change: revoke the 29 internal tokens now; rotate the 12 webhook tokens with a 24-hour overlap. *Why:* Valid under RevokeReview. Judgment about customer impact at 2 a.m. is what the person was woken for. 10. **09:10:00 · claim · SecurityLead · person.** `sec.exploitable = F` for the staging tokens: no path to production data. *Why:* SecurityDisclosure is constitutional and not tradeable. Had this come back T, a disclosure within 3 days would be owed whatever the roadmap said. **Outcome.** The production token was dead 61 seconds after exposure. The broad revoke that would have broken 12 customers never ran. One person woke once, for the one decision that needed a person. The rules behind it (northwind.esk · scope Security): ```esk norm RotateExposed { obligation of Ops to persona when holds sec.exposed(k) and k is sec.Credential aim within 30 min: occurred execute(sec.Rotate(k)) by Ops or-else RotateByHand } use rz.RealizationEnvelope( holder = Ops, requirement = Secrets, operation = sec.Rotate, admissible = holds sec.reissuable(a.k) ) as RotationEnvelope use org.Approval( approver = VPEng, subject = sec.Revocation, threshold = r.affects-customers, deadline = 4 h, escalateTo = CEO ) as RevokeReview use org.SegregationOfDuties( act = decide(approve, c), subject = eng.Change, separate = { c.author } ) as NoSelfApproval ``` ### Two trusted sources disagree about the budget Day 22 of the month. Northwind's opex budget is 560,000 USD, and its or-else is a spending freeze. The cloud bill export and the FinOps tool, both trusted, give different forecasts. 1. **06:00 · claim · cloud bill export.** `fin.forecast(OpexBudget) = 583,400 USD`: over the limit. *Why:* A trusted source says the freeze should fire. 2. **06:02 · claim · FinOps tool · program.** `fin.forecast(OpexBudget) = 541,900 USD`: under the limit. *Why:* Another trusted source says it shouldn't. 3. **06:02 · contradicted · engine.** `fin.over-limit(OpexBudget)` is B: contradicted. *Why:* Neither source wins by default. The freeze needs the claim to be T, and B is not T, so nothing freezes. But anything that needs headroom to be T is also not admissible. 4. **06:02 · scripted · engine.** ForecastContest opens on the FinanceLead, due in 3 days. *Why:* Every contradiction gets an owner and a deadline. 5. **10:15 · misfire · Ops · agent.** `execute ops.Scale(Search, 8 → 10)` → not admissible: SearchEnvelope needs `fin.headroom ≥ 1,800 USD`, which is B. *Why:* The agent isn't stopped by a spending rule. It's stopped because it can't show it's allowed. The request is held, not dropped. 6. **10:16 · reasoning · Finance · agent.** Reconciles line items: the bill export counts a 41,500 USD committed-use credit both as applied and as pending. Proposes 552,100 USD. *Why:* Reasoning across two ledgers. The output is a proposal with evidence attached, not a fact. 7. **11:02 · person · FinanceLead · person.** `derive fin.forecast = 552,100 USD`, citing the reconciliation. The contest resolves and over-limit is F. *Why:* A person resolves it, on the record, with evidence other readers can check. 8. **11:02 · valid act · engine.** Headroom is 7,900 USD and T. The held Scale(10) is re-evaluated and executes. *Why:* Nothing was lost while the question was open. The held act simply became admissible. 9. **11:05 · claim · Architect · agent.** Publishes to the pool: “bill export double-counts pending commit credits”, with the reconciliation as evidence. *Why:* Learn once, apply everywhere: other organizations import it under their own trust policy and never hit the same contradiction. **Outcome.** No freeze on bad evidence, and no silent overspend. One person made one decision, five hours after the conflict appeared. The fix became evidence other companies can use. The rules behind it (northwind.esk · scope Finance): ```esk use fin.Budget( scope = Northwind, resource = econ.Money, limit = 560_000 USD per month, reserve = 40_000 USD, window = month, orElse = gov.Freeze(except = { Const.Materialize, SecurityDisclosure }) ) as OpexBudget use ev.TrustPolicy( source-kind = fin.BillingSource, base = T, vocab = { fin.forecast } ) as BillingTrust use ev.ContestResolution( owner = FinanceLead, vocab = fin.forecast, deadline = 3 d ) as ForecastContest use rz.RealizationEnvelope( holder = Ops, requirement = Search, operation = ops.Scale, admissible = holds fin.headroom(OpexBudget) >= a.delta ) as SearchEnvelope ``` ### A reorg lands in the middle of the week Platform (nine people, two agents) splits into Platform and DevEx. There are 37 open commitments, four powers and an on-call rotation that all have to land somewhere, with work in flight. 1. **Mon 10:00 · person · VPEng · person.** Proposes an amendment: `scope DevEx : org.Team in Engineering`, moving four positions and the CI repositories. *Why:* Creating a scope is constitutional here, so it needs ratification by the CEO. 2. **Mon 10:00 · scripted · compiler.** Explains the diff: 31 commitments move by subject (CI and tooling → DevEx, runtime → Platform); 6 are ambiguous. On-call stays valid: Platform keeps 3 of a minimum 2. *Why:* Consequences are computed before anything is in force. 3. **Mon 10:01 · reasoning · Architect · agent.** Proposes owners for the six ambiguous commitments, with reasons. “Quarantine flaky tests: CI subject, but it blocks deploys → DevEx, Platform watching.” *Why:* Judgment calls, proposed as data, reviewable line by line. 4. **Mon 11:30 · person · CEO · person.** Ratifies. In force at 14:00. *Why:* An effective time, not an effective intention. 5. **Mon 14:00 · event · engine.** The amendment is in force. Four people are now members of DevEx and 36 commitments have new bearers. *Why:* Nobody moved tickets by hand. Bearers follow from the rules. 6. **Mon 14:03 · misfire · Dana · DevEx.** Approves PR #9120 on the Api runtime → misfire: at 14:03 she no longer holds Platform's review power. Her laptop synced at 14:20. *Why:* The log is bitemporal: it records when she acted and when it learned about it. Authority is checked at the time of the act. 7. **Mon 14:03 · scripted · engine.** PR #9120 re-requests review from Platform reviewers. Its deploy clock is unchanged. *Why:* A stale approval is caught, not silently counted. 8. **Mon 14:10 · unknown · engine.** One commitment, “rotate the CI signing key”, has no computable owner. Reassign opens on the VPEng, due in 1 day. *Why:* An unknown owner is itself an owned problem. 9. **Tue 09:00 · person · VPEng · person.** Assigns it to DevEx. *Why:* The last loose end is closed on the record. **Outcome.** No commitment was lost or duplicated, and one stale approval was caught instead of counted. The whole reorg is one diff you can replay to any minute. The rules behind it (northwind.esk · scope Engineering): ```esk norm ReviewCode { power of Platform.Reviewer to decide approve | reject about eng.Change when c.repo in Platform.repos } norm Reassign { obligation of VPEng to persona when unknown org.owner(k) and k is Commitment aim within 1 d: occurred assign(k, _) by VPEng } ``` ## Ten kinds of thing Every specification compiles to records of ten kinds. Teams, workflows, tickets, approvals, budgets, KPIs, databases, agents and LLMs are configurations of these ten. - **Party**: Anything that can act: a person, a program, an LLM agent, a vendor, the engine. - **Scope**: A bounded context: the company, a squad, a contract, an experiment. - **Position**: A seat parties occupy. Rules are addressed to seats, never to people. - **Intent**: What a scope wants: an SLO, a revenue target, a cost ceiling. - **Norm**: A standing rule: obligation, prohibition, permission, power, immunity or counts-as. - **Commitment**: A live obligation created when a norm fires. What you'd call a ticket. - **Capability**: A contract with measurable properties, required by intents, offered by parties. - **Event**: An entry in the append-only log: thinking, deciding or doing, never mixed. - **Claim**: A fact with a source and an expiry: true, false, unknown or contradicted. - **Entity**: A versioned, content-addressed thing: a document, a dataset, a release. ## Four ideas that make it work - **The log is the only state.** Who holds what, which commitments are open, which facts hold, which provider is bound: all computed from one append-only, bitemporal log. Any past moment can be rebuilt exactly. - **Authority is computed.** Every act is checked against the powers in force for that party, in that seat, at that instant. An act without authority is recorded as a misfire and changes nothing. - **Unknown is a first-class answer.** Facts are four-valued and evidence expires. Nothing unknown is ever treated as true, and every unknown gets an owner. - **Learn once, apply everywhere.** What one organization proves about a provider, a pattern or a distilled piece of judgment can be published as evidence and imported by others, under their own trust rules. [How pooling works.](https://endoskeletal.com/learning/) ## Built for software companies - [Organization shapes](https://endoskeletal.com/shapes/): Seed-stage, product-led squads, platform teams, enterprise with compliance. Each as a tree and as code. - [Same outcome, two circuits](https://endoskeletal.com/two-ways/): Continuous deployment vs. a release train, and two more common pairs, side by side and animated. - [Voting a scale-up](https://endoskeletal.com/scale-vote/): A council blocks a recommendation until the cost of not scaling outweighs the cost of scaling. - [Simulating your organization](https://endoskeletal.com/simulate/): Eighteen months in ninety seconds, against a scripted world. You see the outage coming; the organization doesn’t. - [Needs, not vendors](https://endoskeletal.com/needs/): One audit-trail need, nine derived properties, four equivalent implementations nobody would design first. - [Non-obvious solutions](https://endoskeletal.com/solutions/): A backup archive that becomes object storage. A relay and a store that become a queue. Found lawfully, with evidence.