Callable Data Infrastructure: The Universal Paradigm

Data exists today in one of two states. It is at rest — sitting in a file system, a database row, an object store, waiting to be read by whatever process next requires it. Or it is in transit — streaming between services, replicating across regions, flowing through pipelines that move it from where it was produced to where it will be consumed. The entire architecture of modern computing is built upon this binary. Storage and transport. Disks and networks. Persistence and delivery.

Callable Data Infrastructure introduces a third state. Data that is neither at rest nor in transit, but callable — existing as live tool surfaces that respond to intent. The data is not fetched from a location. It is not streamed to a consumer. It is invoked. A system that needs a merchant's product catalog does not query a database or read a file. It calls products_list(collection, filters) and receives precisely the data the current operation requires, at the moment it requires it, in the shape the operation demands. The data is not stored and then retrieved. It is callable and then called. The distinction is not semantic. It is architectural, and it changes everything downstream.

The protocol that makes this possible is the Model Context Protocol — MCP — which defines a standard interface through which any client can discover and invoke tool surfaces exposed by any server. MCP was designed for AI model context, but its architecture is universally applicable. A tool is a typed function with a name, a description, an input schema, and a return value. A server exposes tools. A client discovers and calls them. The protocol handles transport, authentication, and capability negotiation. What CDI recognizes is that when you take a data domain — products, transactions, documents, metrics, configurations — and expose it as a set of typed MCP tools, you have not merely created an API. You have changed the ontological status of the data itself. The data has become callable. It has acquired agency, discoverability, and intent-responsiveness that static storage and streaming transport cannot provide.

This document specifies CDI as a universal paradigm — not a product, not a feature, not a vertical application, but an architectural philosophy that applies to every system that produces, consumes, or mediates data. The specification defines the core principles, the reference architecture, the implementation patterns, and the domains of application that together constitute the full potential of Callable Data Infrastructure as the foundational layer of the LeMay technology ecosystem and, in time, of the broader computing landscape.

Any data domain that can be described as a set of typed operations over a bounded schema can be made callable. This is the foundational axiom. Products have types, identifiers, attributes, and relationships. Transactions have parties, amounts, timestamps, and states. Documents have content, metadata, versions, and access controls. Metrics have dimensions, measures, time ranges, and aggregation functions. In every case, the operations a consumer performs against the data — list, get, search, aggregate, mutate — can be expressed as typed tool definitions with input schemas and return types. If the operations can be expressed as tools, the data domain can be served as a CDI endpoint. The question is never whether data can be made callable. The question is whether the callability has been built.

Callable data belongs to the entity that produced it. The CDI provider operates the infrastructure; the CDI provider does not own the data. A merchant's per-store CDI server bears the merchant's name, holds the merchant's data, runs under the merchant's authority. LeMay is the service provider that provisions it, maintains it, and connects it to consuming systems. The merchant can export it, migrate it, or shut it down. The data is theirs. The callability is the service.

This principle is not a legal formality. It is a structural requirement that governs the entire architecture. CDI servers must support full data export in standard formats. CDI servers must support migration to alternative providers. CDI servers must honor deletion requests completely and verifiably. The sovereignty principle ensures that CDI occupies the infrastructure layer — the layer that does not get uninstalled because uninstalling it means the lights go off — without crossing into the data ownership layer that would make it extractive rather than additive.

The fastest system is the one carrying the least data. CDI does not optimize data access. CDI eliminates data residency from systems that should not carry it. A Shopify store carrying ten thousand products, hundreds of collections, years of metafield accumulation, campaign analytics from a dozen apps, and thousands of file assets is paying a data weight tax on every page render. The typical speed optimization app compresses an image, saves 200 kilobytes, shaves 50 milliseconds. CDI removes the data entirely. The file does not load slower. It does not load at all. It is not there. It exists in the merchant's CDI server, callable when needed and invisible when not. The difference between compressing a two-megabyte file to 800 kilobytes and removing the two-megabyte file entirely is not marginal. It is categorical.

Data is loaded by intent, not by architecture. In a traditional system, the runtime loads everything that might be needed because it cannot know in advance what will be needed. A page render pulls the full product catalog, the full navigation tree, the full theme settings, because any of them might be referenced by any component. CDI inverts this. Nothing is loaded until intent is declared. The component that needs the product title calls product_get(id, fields: ['title']) and receives precisely the title. The component that needs the navigation tree calls navigation_tree(menu_handle) and receives precisely the tree. The data surface responds to intent rather than anticipating demand, and the consuming system carries only what it has explicitly asked for.

Callable data is self-describing. Every CDI server exposes its tool manifest through the standard MCP tools/list endpoint. A client connecting to a CDI server discovers, without prior configuration, every data domain the server holds, every operation available against each domain, every input parameter and return type. The data does not merely exist in a callable state — it advertises its own callability. An AI agent connecting to a merchant's CDI server instantly knows that products, collections, metafields, campaigns, audiences, and analytics are available, understands the schema of each, and can begin calling immediately. No documentation required. No integration engineering. The data describes itself through its tool surface, and the consumer discovers what is available through the protocol's native capability negotiation.

CDI servers compose. A system that connects to multiple CDI servers inherits the union of their tool surfaces. An AI agent connected to a merchant's commerce CDI server and a financial CDI server and a publishing CDI server can orchestrate operations across all three without custom integration between them. The MCP protocol handles multiplexed connections natively. Each server is an independent, sovereign data domain. The composition happens at the client layer, where intent maps to calls across whatever CDI servers hold the relevant data. This is the architectural equivalent of Unix pipes — small, focused, composable primitives that combine to accomplish what no monolithic system could achieve alone.

A CDI server is an MCP server whose tool surface represents a data domain. It is not a database with an API layer. It is not a cache. It is not a proxy. It is a semantic interface to data that understands the domain it serves. A commerce CDI server does not expose generic get(key) and set(key, value) operations. It exposes products_list(collection, filters, pagination), product_get(id, fields), metafields_for(resource_type, resource_id), collections_search(query), inventory_levels(location, sku). The tool surface mirrors the domain model, and the tool names, descriptions, and schemas carry enough semantic information that any MCP client — human-directed or autonomous — can discover and use them without prior knowledge of the underlying data store.

The persistence layer beneath a CDI server is an implementation detail invisible to consumers. The reference implementation uses SQLite in WAL mode for single-tenant deployments and PostgreSQL for multi-tenant deployments. The data is organized by domain — products, orders, customers, content, analytics — with each domain indexed for the access patterns its tool surface supports. Full-text search is provided through SQLite FTS5 or PostgreSQL tsvector. Binary assets are stored on disk or in object storage with references in the primary store. The consumer never knows or cares whether the data lives in SQLite, PostgreSQL, S3, or a flat file. The consumer calls the tool. The CDI server resolves the call to data. The abstraction is complete.

A CDI provider operates CDI servers as a managed service. LeMay is the first CDI provider. The provider handles provisioning — when a new merchant installs LeMay Commerce, a CDI server is created bearing the merchant's store name. The provider handles data migration — the initial population of the CDI server from the source system's existing data. The provider handles synchronization — ongoing replication of changes between the source system and the CDI server to maintain consistency. The provider handles scaling — ensuring the CDI server can handle the read volume the merchant's operations generate. The provider handles backup, versioning, monitoring, and lifecycle management. The merchant sees a named server in their dashboard with status indicators and domain breakdowns. The provider sees an infrastructure fleet.

CDI adoption begins with migration. The migration engine audits the source system — in the reference case, a Shopify store — and inventories every data artifact: products, collections, metafields, files, assets, script tags, theme settings, analytics history, campaign data, audience segments, app-generated content. Each artifact is classified by domain, assessed for migration eligibility, and flagged for any dependency that would prevent removal from the source system. The engine then executes a phased migration: copy the data into the CDI server, verify integrity through domain-specific validation, update the consuming application to call the CDI server instead of the source system, and finally zero out the source-side artifacts that are no longer needed. The store gets lighter. The data gets callable. The process is reversible at every phase.

Source systems do not stop producing data after migration. A Shopify merchant continues to add products, receive orders, update inventory. The synchronization layer maintains bidirectional consistency between the source system and the CDI server. Webhooks from the source system trigger incremental updates to the CDI server. Mutations initiated through the CDI server's tool surface propagate back to the source system where required. Conflict resolution follows a source-of-truth hierarchy: for domains where the source system is authoritative (active orders, checkout state), the source system wins. For domains where the CDI server is authoritative (analytics history, campaign archives, AI-generated content), the CDI server wins. The hierarchy is configurable per domain per deployment.

CDI servers support both MCP transport modes. STDIO transport serves local deployments — a CDI server running as a sidecar process alongside the consuming application, communicating through standard input and output with zero network overhead. Streamable HTTP transport serves remote deployments — a CDI server running on LeMay infrastructure, accessible over HTTPS with session management, authentication, and multiplexed connections. The transport selection is transparent to the consumer. The tool surface is identical regardless of whether the CDI server is local or remote. A development environment might run a local CDI server for latency-critical operations while connecting to a remote CDI server for shared team data. The architecture does not care. The protocol abstracts the transport. The data is callable either way.

Commerce is the origin domain — the use case that generated the CDI insight. Every Shopify store accumulates data weight over time: product metadata, collection hierarchies, metafields from installed apps, campaign analytics, audience segments, file assets, theme configurations. This accumulated weight participates in every page render whether or not the current page needs it. For a Shopify Plus store serving global traffic with ten thousand products and dozens of installed apps, the data weight tax is not marginal — it is the primary constraint on storefront performance.

A commerce CDI server holds the complete data model of the merchant's store: products with variants, images, and inventory; collections with rules and membership; customers with purchase history and segments; orders with line items, fulfillments, and refunds; metafields organized by resource type; file assets indexed by type and usage; campaign data with performance metrics; audience definitions with behavioral criteria. Each domain is exposed through typed tools that mirror Shopify's data model but serve from local infrastructure at read speeds that Shopify's API round-trips cannot match. The store retains only what it must — the storefront theme, the checkout flow, the absolute minimum for rendering. Everything else is callable.

The performance impact is not incremental. It is architectural. Every concurrent visitor pays the data weight tax independently. One thousand simultaneous sessions on a store carrying 200 megabytes of file-resident data means 200 gigabytes of aggregate data weight in play. Strip 90 percent of that data into the CDI server and the store's infrastructure scales under load with a fundamentally different cost curve. The merchant does not get a faster store. The merchant gets a store that handles Black Friday traffic without buckling under its own accumulated weight.

The most immediate non-commerce application of CDI is the development environment itself. Claude Code, the agentic coding tool that LeMay uses as a core execution partner, suffers from a fundamental constraint: context window degradation. Every file loaded into the context, every conversation turn retained, every tool result cached fills the finite context window. Performance degrades. Nuance is lost. The /compact command summarizes earlier context, but summarization is lossy. The session eventually reaches a state where the model's effective reasoning capacity is consumed by the weight of accumulated context rather than applied to the task at hand.

CDI solves this with the same logic it applies to commerce. The codebase should not live in the context window. A development CDI server holds the entire project as callable data domains: module_get(path) returns the source code of a specific module. dependency_graph(entrypoint) returns the dependency tree from a given entry point. test_results(suite, run_id) returns the results of a specific test execution. git_history(file, range) returns the commit history for a file within a date range. architecture_decisions(since_timestamp) returns decisions recorded since a given time. The context window stops being a storage constraint and becomes purely a reasoning workspace. The model calls what it needs, reasons over it, and releases it. The data never accumulates in the window because it was never loaded — it was called.

The Boris Protocol — five parallel Claude Code sessions operating on independent git worktrees — gains a coordination substrate it currently lacks. A shared development CDI server exposes session_state(session_id), interface_contracts(module), active_refactors(since_timestamp). Each session calls the slice of shared state it needs to stay aligned with the others without carrying the full state of all five sessions simultaneously. The CDI server is the memory that no individual session possesses, available to every session that calls it.

The autonomous financial management system under construction for family-member account management generates and consumes substantial state: transaction histories across five Mercury envelope-budgeted accounts, vendor records with recurring patterns, bill parsing results from Gmail, forecast models with projection windows, budget status per envelope. In the current architecture, the Cloudflare Worker automation engine must assemble this state from multiple sources on every execution cycle.

A financial CDI server consolidates the entire financial picture into a callable surface: transactions(account, date_range, category) returns filtered transaction sets. vendor_profile(name) returns the complete relationship history with a vendor including recurring amounts and payment patterns. budget_status(envelope) returns current balance, burn rate, and days until depletion. forecast(months_ahead, scenario) returns projected balances under specified assumptions. The Cloudflare Worker becomes stateless. It carries no data. It calls what it needs from the CDI server, executes the automation logic, and writes results back. The Worker weighs nothing because the intelligence lives in what it calls, not in what it carries.

Drok — the sovereign post-quantum code platform with private-by-default Vaults — is architecturally pre-aligned with CDI. A Vault is already conceptually a CDI endpoint. The code does not sit in a file system waiting to be cloned. Under CDI, it becomes callable. vault_file(path, version) returns the content of a specific file at a specific version. vault_search(query, scope) returns search results across the Vault's content. vault_diff(commit_a, commit_b, path) returns the precise difference between two points in history. vault_structure(depth) returns the directory tree to a specified depth.

An AI agent working on a Drok project does not clone the repository. It calls the data it needs for the current task. The Vault becomes a CDI endpoint, and Drok becomes the first code platform built natively on callable data rather than file-system replication. The implications for security are significant: the code never exists in its entirety outside the Vault. An agent working on a single module calls only that module. The attack surface is reduced to the data that was actually called, not the data that was available to be called. Callable data is inherently more secure than replicated data because the consumer never possesses more than what it explicitly requested.

The Commonwealth Times, publishing.lemay.app, and the broader LeMay publishing house with its 50/50 royalty structure accumulate content that follows the same pattern as commerce data: articles, drafts, editorial calendars, subscriber analytics, royalty calculations, author portfolios, issue archives. A publishing CDI server holds the entire publication as callable data domains: articles(status, date_range, author) returns filtered article sets. subscriber_metrics(period, segment) returns audience analytics. royalty_balance(author, period) returns earned royalties for an author within a period. editorial_calendar(month) returns the planned content for a given month. issue_archive(volume, number) returns a complete back issue.

The publishing platform stays light. The editor loads only the article being edited. The dashboard calls only the metrics being displayed. The royalty calculator calls only the transactions it needs to compute. No bulk ingestion of the entire publication state on every page load — the identical architectural advantage identified for Shopify merchants, applied to the publishing vertical. Every publication LeMay operates becomes a CDI endpoint, and the publishing platform becomes a thin presentation layer over callable data rather than a monolithic content management system carrying the weight of everything it has ever published.

LeMay produces institutional documents governed by the SCOTUS/GPO/OFR formatting standard — specifications, protocols, formal correspondence, legal instruments. This corpus of documents constitutes institutional memory that is currently scattered across file systems, conversation histories, and manual reference. A documentation CDI server makes the corpus callable: specification(identifier) returns CDI-SPEC-001 or MTP-SPEC-001 or RSO-SPEC-001 in its complete form. specifications_search(query, domain) returns matching specifications across the institutional corpus. formatting_standard(element) returns the precise formatting requirement for a given document element. precedent(topic) returns prior institutional positions on a given topic.

An agent producing a new specification can call the documentation CDI server to discover existing specifications in the same domain, retrieve the formatting standard for every element, reference prior positions on related topics, and ensure consistency with the institutional voice. The documentation corpus stops being a reference library that must be manually consulted and becomes a callable knowledge base that participates actively in the production of new documents.

The Architect Bridge — deployed at architect-bridge.vercel.app as a Redis-backed bidirectional orchestration layer between Claude Desktop and Claude Code — is an early implementation of a pattern that CDI generalizes. The Bridge holds instructions and reports as transient state. CDI replaces this with a persistent, callable orchestration surface: instruction(id) returns a specific instruction with its metadata. reports(session, since) returns reports from a given session since a timestamp. orchestration_state() returns the current state of all active sessions. task_queue(priority) returns pending tasks ordered by priority.

The implication is that agent orchestration itself becomes a CDI domain. Multi-agent systems — whether the Boris Protocol's five parallel sessions or a fleet of autonomous task agents — coordinate through a shared CDI server that holds the orchestration state as callable data. No agent carries the full orchestration state. Every agent calls the slice it needs. The orchestration CDI server is the shared consciousness of the agent fleet, and its tool surface is the language through which agents discover what the others have done, are doing, and intend to do.

LeMay's long-term trajectory targets all sixteen CISA critical infrastructure sectors. CDI provides the data architecture for every one of them. Energy sector monitoring generates telemetry that is callable: sensor_readings(grid_segment, time_range). Healthcare generates patient and facility data that is callable: facility_status(region, metric). Financial services generate transaction and risk data that is callable: risk_assessment(portfolio, scenario). Transportation generates logistics and routing data that is callable: fleet_status(region, vehicle_type). In every sector, the same pattern holds: the data domain can be expressed as typed operations over a bounded schema, the operations can be exposed as MCP tools, and the consuming systems become lighter, faster, and more capable when they call data by intent rather than loading it by architecture.

CDI is not a product that must be rebuilt for each sector. It is a paradigm that must be applied to each sector. The CDI server implementation varies — a commerce CDI server understands Shopify's data model, a healthcare CDI server understands HL7 FHIR, a financial CDI server understands transaction semantics — but the architectural pattern is invariant. Data becomes callable. Consumers become lighter. The CDI provider operates the infrastructure. The data owner retains sovereignty. The protocol is MCP. The paradigm is CDI.

The complete CDI implementation consists of seven layers, each serving a distinct function in the transformation of static data into callable infrastructure.

The domain model defines the bounded schema of the data domain and the typed operations consumers can perform against it. For commerce, the domain model includes products, collections, customers, orders, metafields, files, campaigns, audiences, analytics, inventory, shipping, and payments — each with its attributes, relationships, and valid operations. The domain model is specified independently of the persistence layer and the transport layer. It is the contract between the CDI server and its consumers, expressed as MCP tool definitions with JSON Schema input schemas and documented return types.

The persistence layer stores the data in whatever form optimizes for the access patterns the domain model defines. SQLite in WAL mode for single-tenant deployments. PostgreSQL with domain-specific indexes for multi-tenant deployments. Object storage for binary assets. Full-text search indexes for content domains. Time-series storage for metrics and analytics. The persistence layer is invisible to consumers. It exists solely to serve the tool surface above it with minimal latency and maximum reliability.

The tool surface is the MCP server implementation that exposes the domain model as callable tools. Each tool maps to one or more persistence layer operations, handles input validation, applies access controls, executes the query or mutation, and returns typed results. The tool surface is the identity of the CDI server — it is what consumers discover, what they call, and what they build against. A well-designed tool surface is self-documenting through its tool names, descriptions, and schemas; a consumer connecting for the first time should understand what data is available and how to access it without external documentation.

The synchronization layer maintains consistency between the CDI server and external source systems. Webhook receivers process events from source systems and apply incremental updates to the persistence layer. Outbound propagation sends mutations initiated through the CDI tool surface back to source systems where required. Conflict resolution rules, configurable per domain, determine which system is authoritative when changes conflict. The synchronization layer ensures that the CDI server is not a stale copy but a live, consistent representation of the data it serves.

The migration layer handles the initial population of the CDI server from external source systems and the ongoing onboarding of new data domains. It includes the audit engine that inventories source system artifacts, the classification engine that assigns artifacts to CDI domains, the transfer engine that moves data from source to CDI server with integrity verification, and the cutover engine that redirects consumers from source system access to CDI tool calls. Migration is phased, reversible, and domain-granular — a merchant can migrate products and analytics without migrating orders and checkout state.

The access control layer governs who can call what. CDI servers support token-based authentication with scope-limited access. A merchant's administrative interface has full read-write access to all domains. The commerce application has read access to all domains and write access to domains it is authorized to mutate. A third-party integration has access only to the domains the merchant has explicitly granted. Access control operates at the tool level — individual tools can be restricted by role, by token scope, or by domain policy. The sovereignty principle requires that the data owner controls access grants, not the CDI provider.

The observability layer provides visibility into CDI server operations: which tools are being called, how frequently, by which consumers, with what latency, with what error rates. The observability data is itself a CDI domain — callable through tools like call_volume(tool, time_range), latency_percentiles(tool, window), error_rate(consumer, period). The CDI provider uses observability data to manage the fleet. The data owner uses it to understand how their data is being consumed. The observability layer closes the loop: data about data access becomes callable data, and the CDI paradigm applies to itself.

CDI occupies the infrastructure layer. Infrastructure pricing is understood by every business that has ever paid for hosting, storage, or bandwidth. The CDI pricing model reflects this: a per-server monthly fee that covers provisioning, maintenance, synchronization, scaling, and support. The merchant pays for managed data infrastructure the same way they pay Shopify for managed commerce infrastructure. Two layers, one store, both managed, neither competing with the other.

The pricing structure scales with the data domain. A small store with fifty products and basic analytics pays for a lightweight CDI server. A Shopify Plus enterprise with ten thousand products, global audiences, and years of campaign history pays for a CDI server with higher storage, faster synchronization, and dedicated compute. The tiers are defined by data volume, domain count, synchronization frequency, and read throughput — not by feature gates that withhold capability from lower-paying customers. Every tier gets the same tool surface. The infrastructure beneath it scales.

The economic argument to the merchant is not that CDI is a new expense. It is that CDI replaces expenses the merchant is already paying: speed optimization apps that compress images and delete duplicates for marginal gains, data management apps that organize metafields, analytics apps that duplicate store data into external dashboards. CDI consolidates these functions into a single infrastructure layer that makes the store faster by architectural elimination rather than marginal optimization. The merchant does not pay more. The merchant pays once for an infrastructure service that does what five apps used to do separately and does it better because it operates at the architectural layer rather than the application layer.

For LeMay, the CDI economic model transforms the revenue structure from application-layer subscription revenue — which faces churn pressure every budget cycle — to infrastructure-layer subscription revenue, which faces churn pressure only when the merchant is willing to accept the performance regression that comes with removing the infrastructure. An app gets uninstalled. Infrastructure gets depended upon. The distinction is the difference between a SaaS business and a platform business, and CDI is the mechanism that effects the transition.

CDI is the unifying layer of the LeMay technology ecosystem. Every product LeMay builds generates data that something else needs to consume. LeMay Commerce generates merchant data consumed by the Ads vertical, the Marketing vertical, and the merchant's own analytics. ASTRAL generates task execution data consumed by monitoring dashboards and dependent workflows. The Mercury financial automation generates transaction and forecast data consumed by budget management and reporting. The publishing platform generates content and subscriber data consumed by editorial tools and royalty calculations. Drok generates code and project data consumed by AI agents and developer tools.

Without CDI, each of these consumption relationships requires a custom integration — an API, a shared database, a file exchange, a message queue. Each integration is built once, maintained forever, and debugged whenever either end changes. The integration surface grows combinatorially with the number of products and the number of consumption relationships between them.

With CDI, every product operates a CDI server. Every consumer calls the CDI servers that hold the data it needs. The integration surface is the MCP protocol — standard, versioned, documented, and identical across every product. Adding a new product to the ecosystem means standing up a new CDI server with the product's domain model. Every existing consumer can discover and call it immediately. The integration cost is zero because there is no integration. There is only the protocol, and the protocol is the same everywhere.

This is the infrastructure thesis that makes LeMay a platform rather than a portfolio. A portfolio is a collection of products that share a brand. A platform is a collection of products that share an infrastructure layer — and the infrastructure layer is what makes the collection more valuable than the sum of its parts. CDI is that layer. It is the connective tissue that transforms a set of independent products into a unified technology ecosystem where data flows by intent, consumers stay light, and every new product makes every existing product more capable by expanding the callable data surface available to all of them.

No competitor has named this category because no competitor has recognized that MCP creates it. Snowflake, Databricks, and the data warehouse vendors sell storage and query infrastructure — data at rest, accessed through SQL. Kafka, Confluent, and the streaming vendors sell transport infrastructure — data in transit, accessed through consumer subscriptions. CDN providers sell content delivery — static assets cached at the edge. API gateway providers sell request routing — proxied access to existing services.

None of them sell callable data. None of them have recognized that MCP creates a third state for data that is architecturally distinct from storage and transport. None of them have built per-entity CDI servers that expose domain-specific tool surfaces tailored to the data model of the entity they serve. None of them have positioned the elimination of data residency from consuming systems as the primary value proposition rather than the optimization of data access within those systems.

LeMay's competitive advantage is temporal: the category exists now, the protocol that enables it exists now, and the first mover defines the terms. CDI is three letters that sound like they have always existed — sitting naturally next to CDN, CLI, API — because the concept they describe is fundamental enough that the industry will eventually recognize it whether LeMay names it or not. The advantage of naming it first is that LeMay defines what CDI means, what a CDI server looks like, what a CDI provider does, and what the standard of quality is. The category starts here.

Callable Data Infrastructure is not a feature of LeMay Commerce. It is not an optimization strategy for Shopify stores. It is not a product that serves a single vertical or a single customer segment. It is the architectural philosophy upon which every product LeMay builds will stand — the recognition that data, when made callable, transforms every system it touches. The store gets lighter. The development environment gets smarter. The financial automation gets stateless. The code platform gets more secure. The publishing house gets more responsive. The agent fleet gets coordinated. The institutional documentation gets searchable. Every sector, every product, every consumption relationship in the entire LeMay ecosystem becomes faster, lighter, and more capable the moment its data becomes callable rather than loaded.

The protocol is MCP. The paradigm is CDI. The provider is LeMay. The category is new. The answer was built before the question was fully articulated — in a conversation about a Shopify memory server that became, upon examination, the foundational infrastructure thesis of the entire company.

CDI. Callable Data Infrastructure. The data is not at rest. The data is not in transit. The data is callable. And that changes everything.

Invented in USA. Made in the Commonwealth of Massachusetts.

Pro Republica Aedificamus.