The OMI spec is under heavy development, and every piece of it is subject to change. We are documenting the core primitives for sovereign application lifecycles. Join us in defining the v1.0 draft.
Documentation
Core Services

Core Services

The Core Services constitute the “Operational Backbone” of an OMI application. In a traditional architecture, you would spend 80% of your time hard-coding identity, billing, and discovery into every microservice. In the OMI swarm, these functions are delegated to a set of standardized, high-trust providers.

Think of it this way: if Domain Services (CMS, CRM, etc.) are the “rooms” in your house where life happens, the Core Services are the plumbing, electricity, and the deed to the property.

The “What”: The Backbone Components

ServiceRoleCore Responsibility
App RegistryThe LibrarianActs as a “Service DNS.” It stores the AppID, the Master Public Key, and the current location/keys of all bound Domain Services.
Auth ProviderThe Trust AnchorManages user identities and issues the cryptographic tokens that Domain Services use to verify “Who” is making a request.
Operational ServicesThe Back OfficeIncludes specialized providers for Billing (usage metrics), Logging (error tracking), Audit (history) etc.

The “Why”: Breaking the Silo Cycle

  1. Unified Identity (No more “Login” logic) By using a Core Auth Provider, individual Domain Services never see a password. They simply verify a signature against a public key fetched from the App Registry. This removes the need to rebuild user-management tables for every new feature.

  2. Zero-Trust Discovery Because the App Registry is the source of truth, services don’t need to be “hard-wired” to each other. If you move your CMS to a new server, you update the Registry once, and the entire swarm knows where to find it.

  3. Out-of-the-Box Governance Core services enforce the “Operational Context.” When a Domain Service joins the swarm, it is told exactly where to send its logs and how to report its billing. The developer doesn’t “configure” the service; the swarm injects the configuration.

The Sovereign Advantage: Unlike traditional SaaS, you aren’t locked into a specific core provider. If you don’t like your Logging provider, you swap the pointer in your App Registry, and the entire swarm begins reporting to the new provider instantly.

How they interact: The “Swarm” Workflow

  1. Identity: The developer registers the AppID in the App Registry.
  2. Trust: The developer designates an Auth Provider as the primary trust anchor.
  3. Operation: The developer sets the “Backbone” (Logging/Billing) in the Registry.
  4. Binding: Domain Services handshake with the Registry to receive this “Operational Context” and go live.
Outcome: You stop writing “Glue Code.” Your Domain Services become pure functional blocks that focus entirely on your business logic, while the Core Services handle the heavy lifting of security and scale.