Fields — Application Substrate
Building
Solve the hard plumbing once.
Every distributed system re-implements the same machinery before it ships a feature — dispatch, tenancy, data access, workflow, eventing, security, observability, and now AI. Fields makes those decisions once, correctly, so applications built on it inherit them by default — and teams build the domain that differentiates them instead of the plumbing underneath it.
Where it sits
The layer in between.
Fields is not a replacement for Kubernetes, Service Fabric, or Dapr — and it isn't an application either. The orchestrator runs the infrastructure; your applications express the domain; Fields is the fabric in the middle that they are built on and inherit from.
It is opinionated by design — that is what lets the fabric carry the cross-cutting weight. The same domain code runs as a modular monolith or a fleet of services without rewrites, because the transport is a registration choice, not an architecture.
The opinions
What the fabric carries.
Service facets
Services are C# interfaces. Dispatch, layering, and location transparency are handled by the substrate — the same call resolves in-process or across the network by registration, not rewrite.
Closed architecture
Dependencies flow one way, down through the layers, and the runtime enforces it. A call that breaks the layering is rejected at dispatch, not in review.
Data facets
One API across document, relational, search, and analytics stores. Swapping the backing store is a registration change, not a code change.
Flow
Multi-step work as graphs: workflows that run to a terminal with saga compensation, and continuums — standing, stream-fed graphs that never stop.
AI-native
Inference and MCP ride the same dispatch, auth, and telemetry surface as every other call. Facet methods become agent tools by attribute, not by side integration.
Cross-cutting by default
Observability, security, multi-tenancy, scheduling, and resilient egress are properties of the fabric. Every service gets them the same way — quality stops depending on which team built which service.
The method, executable
A method in a book is advice.
Fields makes the same method operate. The discipline on our maxims page — decompose by volatility, closed layering, design the project to build the system — is enforced by the runtime, checkable by tools, and applied by design-phase agents, with a person owning the gates.
That matters more now, not less: construction has become cheap, and agents will build whatever they are pointed at — fast, including the wrong decomposition. The bottleneck moves to structure. Fields is the guardrails: the judgment a person supplies once becomes the rails everything built afterward runs on.
Lineage: the method is the IDesign Method — Juval Löwy, Righting Software. Making it executable is ours.
Where it stands
Substantial and running: ~1,100 tests passing across the platform libraries, core components stable, provider adapters in beta, and a complete sample system — a field-service dispatcher with a working UI — that launches with one command, no containers required. A north star, not a destination.
Built by the practice, not apart from it.
The discipline on this page is the same one we bring to client work — the maxims, the movements, the same standard of structure.