Consumption: how the data is used — APIs, contracts, and access

What it is

Consumption is the “how do I use this data?” layer of a governed data product. It includes the APIs or endpoints that expose the data (REST, GraphQL, webhooks, streaming), the contracts (schema, SLA, freshness guarantees), and the rules for who can access what. A governed data product isn’t complete when it’s stored — it’s complete when it can be consumed reliably by downstream apps, analytics, and AI. Without consumption, data might as well not exist for those consumers.

How it’s made

Consumption for a governed data product is built and documented as follows:

• Interface definition. You define one or more ways to access the asset: e.g. “GET /context/orders/{order_id}” returns the process graph for that order; “GET /context/customers/{customer_id}” returns the customer 360. Each endpoint is documented with request/response schema (often the same schema as the asset’s definition), auth requirements, and rate limits.
• Contract and SLA (declarative). The asset’s contract declares freshness targets (e.g. “eventual consistency, < 30s from source”), availability goals (e.g. “99.9% uptime”), and schema stability (e.g. “backward-compatible changes only”). These fields are declarative metadata — they communicate intent and expectations to consumers but are not enforced at runtime by the platform. Monitoring and alerting can be configured against these targets separately.
• Access and entitlements. Consumption is gated by governance: who (user, app, or API key) can call which endpoint, for which scope (e.g. which org or project). Entitlements are checked at request time and logged for audit. So “consumption” isn’t just the API — it’s the API plus the policy that governs who can use it.

Example consumption metadata for an Orders context asset:

{
  "asset_id": "orders-context",
  "consumption": {
    "endpoints": [
      {
        "method": "GET",
        "path": "/context/orders/{order_id}",
        "description": "Full process graph for order (entities + links + decision traces)",
        "response_schema_ref": "#/schemas/OrderContext",
        "auth": "Bearer token or API key",
        "rate_limit": "100/min per client"
      },
      {
        "method": "GET",
        "path": "/context/customers/{customer_id}",
        "description": "Customer 360 for customer_id"
      }
    ],
    "contract": {
      "freshness": "Eventual, typically < 30s from source event",
      "availability": "99.9%",
      "schema_versioning": "Backward-compatible; breaking changes in new major version"
    }
  }
}

In Loxtep, consumption interfaces are explicitly created via the platform API or SDK — they are not auto-generated when a governed data product is created. You define each consumption endpoint, its contract, and access rules intentionally for each access pattern. The same product might be consumed via a REST API for apps and via a streaming or query interface for AI — all are part of the product’s consumption layer and are documented and governed together.

Consumption enables activation

Consumption isn’t just read-only. When your governed data product is consumable via APIs, webhooks, or streams, you can activate on it: use the data to trigger actions. For example, run a workflow when an order is refunded, trigger a campaign when a customer segment changes, or route a support ticket when context updates. In data terminology, activation means using data to trigger actions; consumption is what makes it possible. Without clear consumption interfaces and contracts, you can’t reliably activate on your data — so making the product consumable is the first step to making it activatable.

Why it matters for governed data products and AI

A governed data product that isn’t consumable is unusable. By making consumption a first-class part of the product (with clear endpoints, contracts, and access), you ensure that every consumer — human, app, or AI — knows how to use the data and what to expect. In Loxtep, every governed data product includes consumption interfaces and contracts so the context we deliver is not only discoverable but usable in a reliable, governed way.