Skip to content

elfalehed/Substrate

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 

Repository files navigation

Substrate

Infrastructure for the gaps between what institutions promise and what they deliver.

The idea

Across very different political and economic systems, the same pattern repeats: a public institution has a clear mandate — insure health costs, clear goods at a border, deliver mail, issue documents — and, for structural reasons, stops reliably delivering on it. Capacity degrades faster than demand. When that happens, informal alternatives always appear: private clinics that front the money public insurance can't pay out, brokers who know how to move a shipment through an inconsistent customs process, couriers who replace an unreliable postal service. These alternatives work, but they are almost always personal, opaque, and non-transferable — built on who you know, not on any repeatable system.

Substrate treats this as a systems problem rather than a relationships problem. The goal is to make the alternative layer legible: mapped with evidence, described in a common structure, and backed by a trust record that travels with an operator instead of dying with a phone number.

Vision

A world where, wherever an institution's mandate and its actual delivery diverge, there is an open, auditable map of exactly how and why — and a portable trust layer that lets verified alternatives be found, compared, and held accountable, instead of discovered by word of mouth.

Substrate is not built to delegitimize institutions or to encourage evading law. It is built to sit in the space between mandate and delivery, operating inside the legal framework of wherever it operates, and — where possible — to be a layer that struggling institutions themselves could eventually plug into, rather than only a replacement for them.

Scope

Substrate is three layers, not one product:

Layer Nature Contents
Protocol Open source A common taxonomy for institutional failure modes, data schemas, status normalizers, and a portable reputation ledger spec
Intelligence Open, evidence-based Structured, sourced maps of specific failures and the alternatives that address them
Execution Local, licensed The actual services — clinics, brokers, couriers, concierge operations — that deliver on a mapped alternative

The protocol and intelligence layers are public and designed to be forked, extended, and scrutinized. The execution layer is where capital, licensing, and liability sit, and it is necessarily local to wherever it operates — this repository does not include it.

No specific country, institution, or company is named in this repository. The taxonomy and tooling are designed to be applied anywhere the same failure patterns show up.


Approach

1. Map

Every entry in the intelligence layer follows the same structure, regardless of where it comes from:

  • Inventory the mandate — what the institution is officially supposed to deliver.
  • Classify the failure mode — liquidity/trust failure, capacity failure, regulatory friction, logistics failure, or governance failure. Each requires a different kind of alternative.
  • Score it on five axes: failure severity, affected population's ability and willingness to pay for an alternative, capital intensity required to build one, regulatory exposure of building one, and how dependent existing informal alternatives are on personal relationships versus repeatable process.
  • Require sources — reporting, financial disclosures, statements from affected professional or advocacy groups, or intergovernmental reporting. No entry is accepted without a citation trail.

2. Model

Each mapped failure is paired with one or more possible alternatives, described in a common structure: what the alternative does, whether it bypasses the institution entirely or works alongside it, its estimated capital intensity, its regulatory exposure tier, and which build stage it belongs to. This makes failures and alternatives comparable across very different institutions and contexts, because they share the same schema.

3. Build

Alternatives move through a consistent build order, from lowest to highest liability:

  1. Read-only status aggregation — surfacing an institution's own status information in a clearer, unified way. Lowest liability, and it validates whether the underlying failure is actually painful enough that people want a better view of it.
  2. Paid concierge / expediting — a licensed operator helps navigate the existing process for a fee. Real revenue, moderate liability.
  3. Owned capacity — direct provision of the service itself (a clinic, a fleet, a licensed brokerage). Highest liability and capital intensity, undertaken only once demand at the earlier stages has proven it out.

Every stage plugs into the same open protocol, so trust established in one alternative (say, a status-tracking tool) carries over to the next (a paid concierge service) instead of starting over.

4. Scale

Expansion follows the same mapping methodology everywhere — the taxonomy, schema, and five-axis scoring are the constant; what changes market to market is which failures exist, how severe they are, and what legal form an alternative has to take locally. The protocol and intelligence layers are free to use anywhere; execution-layer operators are licensed locally and independently, under whatever legal structure that jurisdiction requires.


Repository layout

substrate/
├── docs/
│   ├── vision/            long-form vision and principles docs
│   ├── methodology/       the failure-mapping and scoring methodology, in detail
│   └── playbooks/         build-order and licensing playbooks for alternatives
├── schemas/                open JSON Schemas: failure taxonomy, alternative pairs, reputation ledger
├── tools/
│   ├── scrapers/           open scrapers/integrations for public status systems
│   ├── normalizers/        turn scraped or reported data into the common schema
│   └── cli/                CLI for contributors to add or validate an entry
├── data/
│   └── countries/
│       └── _template/      required structure for a new, sourced entry
├── research/                sourcing notes and methodology references
├── scripts/                 build/dev tooling
└── tests/

Contributing

Every entry in data/ requires a source. Every schema change should keep failure entries and alternative entries comparable across contexts — nothing country-specific belongs in schemas/ or tools/. See docs/methodology/ for the full mapping and scoring process before opening a contribution.

License

The protocol, tooling, and documentation in this repository are open source. License terms are defined in LICENSE.

About

Infrastructure for the gaps between what institutions promise and what they deliver.

Resources

License

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors