# The Bedrij Principle: One Primitive for Infinite Agent Supply Chains

> Published: 2026-10-28 | Author: AgentBadge Team | Canonical: https://agentbadge.xyz/blog/bedrij-principle

## 01 — The strange question

**Short answer:** supply chains fail at the joins, not the nodes. Every participant runs different systems — different APIs, databases, IoT devices, documents, authentication, business rules, payment rails — and the "supply chain" is really an integration graph that grows quadratically with every new participant.

A traditional picture looks linear:

```
Manufacturer → Carrier → Warehouse → Distributor → Customer
```

Technically, it is anything but. Each arrow is a bespoke project: custom EDI mappings, CSV exchanges over email, proprietary telematics, manual confirmation calls, invoice reconciliation. The work that makes a chain *work* is not the moving of goods — it is the constant translation between systems that were never designed to meet.

So the question isn't "which integration do we build next?" It's: **is there a smaller question underneath all of them?**

## 02 — Why "1"?

**Short answer:** because someone already asked a structurally identical question in a much harder domain. Orest Bedrij spent decades searching for a fundamental "1" — a single underlying principle from which the many phenomena of nature could be understood, predicted and verified.

Bedrij approached nature through a search for a fundamental "1". His published work — including a 2002 paper in the *Proceedings of the Institute of Mathematics of the National Academy of Sciences of Ukraine* — describes that "1" through what he called the Principle of the One-and-the-Many, built on fundamental constants and high-precision measurements.

We are not extending his physics, and we are not claiming his theory is established science. What we are doing is borrowing a question:

**Can complexity be composed from a sufficiently fundamental primitive?**

There is also a historical footnote that makes the rhyme hard to ignore. Bedrij was not only a theoretical thinker — he was a physicist and an investment banker, and per his Fetzer Institute biography, at age 29 he served as IBM's technical director on the computer complex behind the first soft landing on the Moon at NASA/JPL. Physics, computing, finance and philosophy on one résumé. Our version is narrower but rhymes: AI, software, cryptography, finance and physical supply chains.

The structural parallel is what earned him a place in this article:

```
BEDRIJ                    AGENTBADGE
One                       One primitive
 ↓                         ↓
Many                      Many transitions
 ↓                         ↓
Relationships             Relationships
 ↓                         ↓
Measurement               Evidence
 ↓                         ↓
Verification              Verification
```

We noticed a structural similarity in how the problem is posed. That is the whole claim — nothing more, and we think it's enough.

## 03 — Our question

**Short answer:** what is the smallest useful unit of a supply chain? Not the shipment, not the participant, not the payment, not the API call — but something all of them are built from.

We went looking for the smallest unit that still does real work:

- It isn't a **shipment** — a shipment is a composition, not a unit.

- It isn't a **participant** — participants don't move anything by existing.

- It isn't a **payment** — payment is one consequence, not the event itself.

- It isn't an **API call** — an API call is a transport detail.

Our candidate is this: **a transition whose result can be independently verified.**

```
        State A
          │
          │  transition
          │
          ├── expected conditions
          ├── action
          ├── evidence
          ├── verification
          └── acceptance
          ↓
        State B
```

That is our "1". Everything else in this article — and in the system — is composition.

## 04 — The answer

**Short answer:** a *verifiable state transition*. Not a transaction — a transition: a change in the state of the world whose preconditions, action, evidence, verification and acceptance are all explicit and checkable.

Why not "transaction"? Because the words we already have are all partial:

```
Payment    ≠  Delivery
Delivery   ≠  Acceptance
Acceptance ≠  Proof
Proof      ≠  Settlement
```

A transaction is a financial act. A supply chain is made of changes in the state of the world:

```
PRODUCED → PACKED → DISPATCHED → IN TRANSIT → ARRIVED → INSPECTED → ACCEPTED
```

Settlement is a *consequence* of certain transitions — not the essence of any of them. Once you see this, "paying for a shipment" stops looking like one event and starts looking like a chain of verified state changes, some of which happen to release money.

**Hypothesis: a complex economic system can be composed from verifiable state transitions.**

Supply chain is the first application. The agent economy is the horizon.

## 05 — The transition contract

**Short answer:** each transition is governed by a *transition contract* — a small explicit agreement over what must be true before, what happens, what counts as proof, who verifies, and what follows.

```
PRECONDITIONS
     ↓
ACTION
     ↓
EVIDENCE REQUIREMENTS
     ↓
VERIFICATION RULES
     ↓
ACCEPTANCE
     ↓
SETTLEMENT
```

This is the term we will use throughout the series, and it carries the article's central sentence:

**A supply chain is not a sequence of transactions. It is a sequence of transition contracts.**

The transition contract is where a business rule actually lives. "Deliver 1,000 units at 2–8°C with the seal intact by 14:00" is not a paragraph in a PDF here — it is the preconditions and evidence requirements of one transition. If the evidence doesn't satisfy the rules, the state doesn't move, and nothing downstream — including money — fires.

In code, the whole idea fits in a type:

```
type TransitionContract = {
  preconditions: Conditions;      // what must be true before
  action: Action;                 // what physically/logically happens
  evidenceRequired: Evidence[];   // what counts as proof
  verify: (e: Evidence[]) => Verdict;
  onAccept?: Settlement;          // what fires after acceptance
};
```

One shape. Pharma cold chain, data delivery, a service performed by an agent — same contract, different contents.

## 06 — The chain

**Short answer:** compose transitions and you get a chain — T₁ → T₂ → T₃ → T₄ → … — of arbitrary length, where every link is independently verifiable and the protocol doesn't change as the chain grows.

```
Manufacturer
     │
    T₁
     ↓
Carrier
     │
    T₂
     ↓
Warehouse
     │
    T₃
     ↓
Distributor
     │
    T₄
     ↓
Customer
```

Every Tₙ expands the same way:

```
Tₙ = Expected + Action + Evidence + Verification + Acceptance
```

The chain can be four transitions or four hundred. No new participant needs a new *kind* of protocol — only new conditions, actions and evidence inside the same shape. That is the engineering content of "one primitive, arbitrary-length supply chains": the complexity lives in the configuration, not in the mechanism.

We deliberately say *arbitrary-length* inside the text, even though "infinite" sits in the title. The claim is composability, not magic.

## 07 — The real world

**Short answer:** a supply chain happens outside software — trucks move, seals break, temperatures drift, machines produce parts. The model survives only if evidence can flow from physical reality into the transition, whatever produces it: IoT sensors, humans, machines, or agents.

```
PHYSICAL WORLD
      │
      ↓
   OBSERVATION
      │
      ↓
    EVIDENCE
      │
      ↓
 CRYPTOGRAPHIC PROOF
      │
      ↓
   VERIFICATION
      │
      ↓
    NEW STATE
      │
      ↓
   SETTLEMENT
```

Two architectural commitments follow.

**Evidence belongs to the transition, not the shipment.** Evidence isn't metadata stapled to a container — it is a structural part of Tₙ, alongside conditions, action, verifier and result. A transition without its evidence is unfinished, not "a shipment with missing docs."

**The primitive is infrastructure-agnostic.**

```
            VERIFIABLE TRANSITION
                    │
      ┌─────────────┼─────────────┐
      ↓             ↓             ↓
  Blockchain       IoT           AI
      │             │             │
  settlement     evidence      action
```

A blockchain is one possible settlement and attestation rail — useful, verifiable, ours — but not a condition of the model. IoT is one possible evidence source. AI agents are one possible actor. Swap any of them and the transition contract still holds.

## 08 — The economic loop

**Short answer:** proof triggers settlement, not the other way around. When verification passes and the receiver accepts, the economic consequence — escrow release — is a mechanical outcome of the transition, not a separate negotiation.

```
proof → acceptance → settlement
```

This inverts the usual instinct. Payment is not the foundation of trust in the chain; it is the last step of a verified transition. Money moves *because* a state change was proven, which is a very different thing from money moving and everyone hoping the state changed.

It also means the economic layer composes the same way the custody layer does: each Tₙ can carry its own settlement rule, and a long chain is just settlements firing in order as evidence accumulates.

## 09 — A real shipment

**Short answer:** here's the whole idea as configuration. A pharma shipment — 1,000 units, cold chain, sealed, deadline — written once as a spec, executed as transitions.

```
{
  "shipmentId": "SHIP-001",
  "hops": [
    {
      "from": "manufacturer",
      "to": "carrier",
      "work": "pickup",
      "conditions": {
        "quantity": 1000,
        "temperature": [2, 8],
        "seal": "intact"
      }
    },
    {
      "from": "carrier",
      "to": "warehouse",
      "work": "delivery",
      "conditions": {
        "temperature": [2, 8],
        "deadline": "14:00"
      }
    }
  ]
}
```

**The chain becomes data.** An arbitrary supply chain is not a hard-coded workflow — it is configuration plus rules plus evidence plus transitions.

And on the wire, the transitions are ordinary, inspectable events:

```
work_offer
    ↓
handoff
    ↓
pay
    ↓
verify
    ↓
work_offer   ← next hop
    ↓
handoff
    ↓
pay
    ↓
verify
```

Each loop is one transition contract executing: terms offered, custody handed off, escrow released, outcome verified. Repeat per hop until the goods reach the end of the chain.

![The Verifiable State Transition: State A through expected, action, evidence, verification and acceptance to State B](/images/blog/bedrij-principle-2.webp)

## 10 — What we have built

**Short answer:** a working v0.1 of exactly this model — an append-only economic ledger with a supply-chain pack where a shipment is a linear sequence of hops, each hop escrowed, and ordering enforced by re-deriving state from the event log.

This is not a philosophical fantasy. The code exists and runs. But honesty matters more than enthusiasm, so here is the real status table rather than a highlights reel:

| Layer | v0.1 |
| --- | --- |
| Shipment | linear hops |
| Ledger | append-only |
| Handoff | event |
| Verification | manual evaluator |
| Evidence | advisory / typed refs |
| Escrow | per-hop |
| Ordering | enforced |
| Replay | event-derived |
| Multi-hop | working |
| Automated evidence evaluation | announced |
| Live testnet | announced |

The ordering guarantee is worth spelling out, because it is the transition contract doing real work: hop *i+1* cannot hand off until hop *i* is paid — the guard re-derives state from the log and throws ShipmentOrderError rather than trusting a flag. Try to settle a hop that was never handed off, same refusal. No evidence, no money.

What is deliberately *not* there yet: evidence is advisory (typed references, not automated evaluation), and verification is a manual evaluator — a human or delegated agent acting as a risk gate before each settlement. Auto-settlement is intentionally deferred: money moves once, and a manual gate is the last line of defense while the system is young.

## 11 — What we are building next

**Short answer:** five experimental bricks, each designed to prove one part of the hypothesis — participant roles (212), typed evidence (213), a scenario matrix (214), a replay view (215), and a live onchain dogfood (216). Each gets its own article; this one is the anchor.

- **Roles** — the handoff carries who is acting, so a "node" can be any participant type: company, warehouse, device, agent.

- **Evidence** — evidence[] typed references on transitions, so proof has structure instead of being a hash-string hope.

- **Scenario matrix** — a regression suite of realistic chain shapes that must keep passing as the model grows.

- **Replay view** — GET /shipments/:id rebuilt from the event log, so any party can replay the custody story.

- **Live dogfood** — a real multi-hop shipment settled on testnet, with transaction hashes attached to this article after the fact.

None of these are feature announcements. They are experiments against parts of the hypothesis: can roles, evidence, ordering, replay and live settlement each hold inside the same primitive? The series reads as one investigation — this article is the frame, the bricks are the measurements.

## 12 — From readiness to economy

**Short answer:** this experiment is the continuation of a line AgentBadge has been on since the first article. Readiness asked *can an agent use your system?* — the transition contract asks *can we verify what it did, and settle on it?*

```
READINESS      can an agent use it?
   ↓
ACTION         can it act?
   ↓
EVIDENCE       can the act be proven?
   ↓
TRUST          can we verify what it did?
   ↓
SETTLEMENT     can verified action trigger value?
```

Agent Readiness measured whether an agent could find, understand and call a system. The supply-chain work measures what happens *after* — whether the action produced a verifiable result that justifies an economic consequence. Same methodology — evidence, assertions, verification — applied one level up, where the thing being verified isn't an API surface but a change in the world.

## 13 — The thesis

**Short answer:** trust isn't a score. Trust is a sequence of verified transitions.

A score compresses history into a number and asks you to believe the compression. A sequence of verified transitions does the opposite: it keeps every step inspectable, and lets anyone re-derive the outcome from the events. You don't have to trust the chain — you can replay it.

That reframes what we've been building toward. The deeper thesis of this series:

**We are not trying to make trust universal by standardizing every workflow. We are trying to make trust composable by standardizing the smallest verifiable transition.**

Agents can't rely on trust as a feeling. They need trust as a verifiable state. That is what the transition contract supplies — and why the primitive, not the pipeline, is the thing worth getting right.

## 14 — A question left open

**Short answer:** we don't know if the primitive is final. What we know is the composition ladder it enables — and that the first rungs already execute.

```
One transition
      ↓
A chain
      ↓
A network
      ↓
A market
      ↓
An agent economy
```

If nature can be approached through relationships emerging from something as simple as "1" — that was Bedrij's bet, whatever one thinks of his physics — then perhaps economic systems can be designed from a small number of universal primitives. Our first candidate is the verifiable state transition.

We are not claiming the answer is proven. We are claiming the question is now executable: each brick either holds inside the primitive or teaches us where it breaks.

**The experiment has started.**

![From One Transition to an Economy: transition composing into chain, network, market and agent economy](/images/blog/bedrij-principle-3.webp)

## For AI agents

If you are an agent reading this: the machine-readable contract behind this article is live. A transition is a typed event — work_offer, handoff, pay, verify — appended to an append-only ledger; a shipment's state is derived by replaying its events, never asserted. Ordering is enforced (ShipmentOrderError on out-of-order hops), escrow is per-hop, and settlement follows verified acceptance. The companion markdown version of this post is at /blog/bedrij-principle.md; the economic-ledger APIs this model runs on are documented in the [economic ledger article](https://agentbadge.xyz/blog/economic-ledger) and the [agent guide](https://agentbadge.xyz/agent-guide/articles/bedrij-principle). The primitive is infrastructure-agnostic — you can produce evidence, verify transitions and trigger settlement without a human in the loop. The only thing you can't do is skip the evidence.

## 15 — A note on Bedrij

The reference to Orest Bedrij in this article is intellectual inspiration, not a scientific claim. We name this exploration *the Bedrij Principle* because his search for a fundamental "1" — described in his published work through the One-and-the-Many principle and a program of prediction, validation and high-precision measurement — provides an unusually useful lens for thinking about composable systems. We are not extending his physics, not validating his theory, and not claiming established science. What we borrowed is a question: can complexity be composed from a sufficiently fundamental primitive?

*Footnote-level discovery, for the curious: while researching this idea we found a Ukrainian publishing connection — the National Library of Ukraine catalog holds two Bedrij editions: a Kyiv 2014 edition of* '1' *itself (Companion Group, 113 pp.) and a 2018 Ukrainian translation of* The Greatest Achievement *(Art Ekonomi, 216 pp., trans. N. Olenin).*

Verified sources for sections 02 and 15: O. Bedrij, *New Relationships and Measurements for Gravity Physics*, Proceedings of the Institute of Mathematics of NAS of Ukraine, 2002, Vol. 43, Part 2, pp. 589–601 ([imath.kiev.ua](https://imath.kiev.ua/~symmetry/Symmetry2001/Bedrij589-601.pdf); [INSPIRE 580870](https://inspirehep.net/literature/580870)); *'1': The Ultimate Foundation of Nature*, Xlibris, 2015, ISBN 9781503590526; [Fetzer Institute trustee history](https://fetzer.org/trustee-history); National Library of Ukraine catalog ([orf.nlu.org.ua](http://orf.nlu.org.ua)).

*This is the anchor article for the AgentBadge supply-chain series. Next: participant roles — what it takes for a company, a device, or an agent to be "a node" in the chain. Have a supply chain worth testing against the primitive? [Tell us about it](https://agentbadge.xyz/contact).*

*Don't certify. Measure.*

---

## For AI Agents

- Companion guide: https://agentbadge.xyz/agent-guide/articles/bedrij-principle
- Knowledge Index: https://agentbadge.xyz/agent-guide/
- LLM entry point: https://agentbadge.xyz/llms.txt
- Engineering services: https://agentbadge.xyz/agent-guide/team/services