Commerce Has a Shape
The data blind spot
The industry has built enormous infrastructure for analyzing the past, and almost nothing for operating on the present.
Data lakes, data meshes, data platforms, data strategies — billions invested, all looking backward. What the industry calls "data" records what happened. It does not represent what is happening right now, and it is rarely a faithful model of the real world it claims to describe. It is flattened, extracted, and stripped of the causal structure that gave it meaning. Consider why Tesla's Full Self Driving works today: it captures the full sensory state of the road at the moment of a driver's decision — cameras, sensors, response, all with their causal relationships intact. Most enterprise "data" has no such property. Businesses don't need better analytics on yesterday. They need to operate on today.
Operating on the present means understanding cause and effect as it happens. In the business world, cause and effect flows through value chains — growers, wholesalers, retailers, consumers. These chains have a structure: who supplies whom, what flows where, who depends on what. This structure is real, stable, and universal. But our digital infrastructure has no concept of it. APIs connect systems that each handle a partial aggregate of business capabilities — useful, but blind to the chain they serve. Databases store records, but records of what? Rows in tables with no direct correspondence to entities in the real world. The cause and effect that runs through every economy has no representation in our software.
The consequence is familiar. Platforms like Amazon, Uber, and Booking.com emerged to fill the gap. Each does the same thing: match demand and supply. But each does it for a single niche, in a single direction, 1:1. They intermediate because the infrastructure can't connect businesses directly. The rent they extract is a tax on missing infrastructure.
Value chains have a shape, and that shape can be made digitally operational
Every participant in a value chain sees the world from their own perspective — and that's the key to making the chain digitally operational. Two people look at the same weather forecast — one sees kitesurfing conditions, the other sees a perfect afternoon to sit in the sun with a drink. The weather is the same. Their perspective on it is different. We navigate this effortlessly. Our data structures do not.
In the business world, perspective is everywhere. A flower grower has buyers. A wholesaler is one of those buyers — but from the wholesaler's own perspective, they're a company with a warehouse, a delivery schedule, and suppliers of their own. The underlying real-world thing is the same. Each business sees it through its own lens and cares about different attributes. This is what we call a domain. Every participant in a value chain operates in their own domain — their own bounded perspective on reality. The grower's domain knows about flowers, harvests, and buyers. The wholesaler's domain knows about suppliers, stock, and retailers. Both are valid. Both are partial.
The question is: how do these domains connect? The wholesaler declares: "I am one of the grower's buyers." That single declaration does three things at once.
First, it establishes a shared source of truth. The kitesurfer and the sunbather share the same weather — temperature, wind speed, UV index. But each interprets it differently: the kitesurfer adds "not kitesurfable", the sunbather adds "perfect afternoon". The facts are shared; the perspective is their own. The same holds here: the wholesaler inherits the grower's attributes and adds its own on top.
Second, it creates a directional guarantee. When a customer places an order in a restaurant, that order must also exist from the restaurant's perspective — the customer is king. Whatever is true from the customer's side is guaranteed to be reflected on the restaurant's side. This is what makes supply-demand matching structural: changes flow along the chain in a defined direction.
Third, it enables shared identity. When the kitesurfer and sunbather discuss "the weather," they need to know it's the same weather on the same day. Likewise, when the grower's buyer and the wholesaler's company refer to the same real-world business, the system knows — not through ID mapping tables or integration middleware, but as a consequence of the declared relationship.
Daisy calls this directed inheritance. A domain declares its position in a value chain, and the infrastructure takes care of the rest. No API contracts. No field mapping. No integration middleware. The connection is a structural fact about the value chain, not a technical bridge between systems.
What does that mean in practice? Chains compose. The grower connects to the wholesaler. The wholesaler connects to the retailer. The retailer connects to the consumer. Each declares inheritance from their own perspective. The value chain assembles itself — bottom-up, without central coordination, without a canonical data model that everyone must agree on.
Remember: the goal is to operate on the present, not analyze the past. That means the value chain must stay live. When something changes in one domain — a new harvest, a cancelled order, a price update — every connected domain needs to know. Not through polling or batch synchronization, but instantly, as a consequence of the change itself. A state change is an event. If nothing changed, there is no event. The structure of the value chain determines where each event flows. No routing tables, no message brokers, no pub/sub configuration — the structure of the chain is the event routing.
This is not a theoretical framework. The value chain — its domains, their perspectives, and the inheritance between them — can be expressed in a modeling language, compiled into a working structure, and executed as live infrastructure.
What this enables
Today, most engineering effort goes into infrastructure. Integration, storage, data pipelines, event routing, identity management — the plumbing that connects things but adds no business value. Teams spend months wiring systems together, and when the business changes, the wiring has to change with it. The infrastructure is the bottleneck. When the value chain is the infrastructure, that bottleneck disappears. Integration, storage, data contracts — all of it is derived from the model. If the model is correct, the infrastructure is correct. What's left is the only part that ever mattered: the value you add.
Anyone — a person, a business, or an autonomous agent — can plug into a value chain anywhere and start adding value. The mechanism is the same at every scale. A startup sees an opportunity in an existing value chain — growers need to reach retailers, but there's no wholesaler connecting them. The startup creates a domain, declares its position, and it's connected. Event routing, shared identity, inherited attributes — all come from the structure. The barrier to entering a value chain drops from "build integrations to every partner" to "declare your position in the chain."
A hospital group wants its departments — intake, diagnostics, treatment, billing — to share state in real time. This isn't a different problem. Departments are domains. The same directed inheritance that connects businesses across a supply chain connects departments within one organization. No middleware, no ESB, no point-to-point integrations. The hospital gets event-driven integration from the same model that could later connect it to insurers, pharmacies, and referring clinics. The scale changes. The mechanism doesn't.
We built it
Daisy is not a concept or a roadmap. It is a working system. Everything is derived from the model — the runtime, the API surface, the event routing, the SDK. Change the model, the system adjusts. There is no hand-wired infrastructure to maintain.
The only hard part is modelling your value chain. This is the same thinking that every business eventually has to do — understanding its own structure, its partners, and how value flows between them. The difference is that traditionally this thinking happens as an afterthought, when integration projects run over budget and data migrations break. Daisy moves it to the front, where it belongs. And even then, it is forgiving. Daisy is designed to evolve. The model doesn't need to be perfect on day one — adjust the model, and the system adjusts with it. An AI-assisted builder helps you model your business through conversation and scaffolds a working application on top of it.
From a model, Daisy resolves the full structure — the domains, their perspectives, and the inheritance between them. A runtime executes it: live state, real-time events, shared identity across domains. Generated SDKs in TypeScript, Rust, and Python give you a typed interface to your value chain.
The local implementation is proven. Whether you're an enthusiast exploring the concept, a startup entering a value chain, or an enterprise connecting departments — Daisy provides everything needed to get started.
When agents join the value chain
If the value chain is digitally operational, agents can act on it directly — and that changes everything. Autonomous agents are increasingly acting on behalf of businesses and consumers — ordering supplies, finding providers, responding to demand. Today, these agents operate by calling APIs: discovering endpoints, parsing documentation, mapping data formats. Every connection is bespoke. But when the value chain has structure, agents don't need to reverse-engineer every partner. They navigate the value chain. They see where supply exists, declare their position, and connect. The agent doesn't integrate — it participates.
More importantly, agents can act on events. When a customer places an order, when inventory drops below a threshold, when a supplier updates availability — these events flow through the value chain in real time. An agent listening on the chain can respond immediately, without polling, without scraping, without calling APIs on a timer. The value chain tells the agent what happened. The agent decides what to do.
And because agents operate within the scope of the model, they are structurally safe. An agent in Daisy can only interact with the domains and types the model defines. It cannot leak credentials, access systems outside its domain, or take actions the model doesn't allow. Safety is not a guardrail bolted on after the fact — it is a consequence of the structure.
The destination
Value chains don't live on one server. They span businesses, geographies, and jurisdictions — and that is where Daisy is headed. Today, Daisy operates as a local runtime with all building blocks proven: domains, directed inheritance, live state, event routing, shared identity. All working. But the destination is bigger. The architecture is designed for federation: each domain runs independently, connected through a shared structure. A world model — the composed view of all connected domains — where any business or agent can discover and participate in any value chain. Where consent governs what flows where. Where a startup in Jakarta can plug into a supply chain that starts in Rotterdam, because the structure is open and the rails are shared.
Connection means growth. That has been true since the first trade routes. The local runtime is the proof that the building blocks work. Federation is the destination.