The Praxys Substrate: the foundation beneath the platform

That distinction matters. A runtime answers questions such as "How does this service start, recover, and receive traffic?" The substrate answers lower-level questions: "What does a storage provider guarantee?", "How should a distributed lock behave?", and "How do we integrate a new payment or AI provider without teaching every service its API?"

Generic foundations, not product workflows

Praxys needs databases, caches, queues, storage, authentication, telemetry, feature flags, distributed locks, cloud orchestration, payment processing, LLM access, and more. The easy path is to solve each concern inside the first service that needs it. That creates duplicated integrations, subtly different failure handling, and deep coupling to a vendor or product workflow.

The substrate takes the opposite approach. Each package owns a narrow technical responsibility and deliberately avoids encoding higher-level product behavior. It can define generic concepts such as identities, scopes, and capabilities, but it does not know how a particular Praxys product is sold, configured, or operated. Product packages and runtime packages build on these primitives; the foundational dependency never points back up to them.

This separation makes the lower layer stable. A service can rely on a common error vocabulary, lifecycle semantics, and security-oriented contracts without importing another service's business logic.

Contracts first, integrations second

The defining pattern in the substrate is ports and adapters. A core package establishes a typed contract — the port — for a capability such as storage, a database, a cache, an LLM provider, an orchestrator, or a payment service. It defines operations, results, error codes, lifecycle expectations, and, where needed, capability flags.

The wider substrate then supplies implementations of those contracts. Some are in-memory or local implementations, intended for deterministic tests and zero-configuration development. Others are integration adapters for services such as Postgres, cloud storage, payment processors, or model providers. Application code depends on the contract; deployment composition chooses the adapter.

This is not abstraction for its own sake. A file-persisting service works with the storage contract, not an S3 client. A local test can use an in-memory store; production can use an object-storage adapter. The service retains the same behavior and error handling while the environment changes underneath it.

Many substrate contracts include reusable conformance harnesses. An adapter is not interchangeable merely because it has similarly named methods; it is tested against the behavior the contract promises. This establishes a common bar for lifecycle, error mapping, cancellation, ordering, and other details that often become production incidents when left implicit. Many provider adapters already have that shared-harness coverage across the substrate's backend abstractions; coverage is not universal and should be checked per adapter.

What the substrate contains

The substrate spans a broad set of technical concerns, organised into focused domains:

• Foundation and protocol provide typed errors, result types, clocks, configuration, cryptography, identifiers, codecs, versioning, and wire contracts.
• Data, storage, and transport define ports for relational and vector data, caches, object storage, search, HTTP, queues, pub/sub, and cross-channel messaging.
• Security and policy provide authentication and authorization primitives, secrets, signing, PII controls, egress rules, rate limits, quotas, budgets, circuit breakers, and locks.
• Operational mechanics cover logging, tracing, metrics, deployment plans, cloud and compute orchestration, workflows, process communication, and test tooling.
• Domain-level contracts extend the same model to LLMs, payments, and commerce capabilities such as inventory, tax, fulfillment, subscriptions, and accounting.

The same discipline that makes a cache provider replaceable also makes it possible to integrate complex external systems without spreading their quirks throughout the product. Provider-specific details stay at the adapter boundary; applications work with a deliberate, typed model.

How the layers fit together

⤢ enlarge

×

The important relationship is not a rigid stack of services; it is the direction of dependency. Applications and the runtime consume stable substrate contracts. Integration adapters implement them. Foundation packages sit at the base, keeping the shared vocabulary small and dependable.

Why this is a platform advantage

This architecture creates leverage. When we improve a shared error model, harden an egress policy, or make tracing more useful, every consumer inherits the improvement. When we add a provider, we add an adapter rather than rework every service that needs the capability. Teams can test locally with reliable in-memory implementations instead of recreating production for every change.

More importantly, the substrate gives Praxys a disciplined way to grow. Complex systems do not stay reliable merely by accumulating integrations. They remain reliable when the contracts beneath those integrations are explicit, tested, and consistent. That is the role of the Praxys Substrate: the technical foundation that lets the runtime, our own products, and the applications we host evolve without sacrificing engineering rigor.