Skip to main content

Open Resource DiscoverySelf-describing applications and services

An open protocol for decentralized application / service metadata publishing and discovery

Publish and discover connected metadata

Open Resource Discovery (ORD) standardizes how applications and services publish metadata about the resources and capabilities they expose, and how consumers discover it.

Providers can describe and connect APIs, events, data products, AI agents, and other capabilities with shared business context and relationships. Consumers can use this standardized metadata to build catalogs and marketplaces, automate integration workflows, or inspect what is actually available in a tenant-specific runtime landscape.

ORD complements established standards such as OpenAPI and AsyncAPI rather than replacing them, so teams can keep their existing definitions as the source of truth while adding consistent discovery, business context, and cross-resource relationships.

It is an open standard governed by the Linux Foundation / NeoNephos.

ORD provider overviewAn application or service exposes resources and capabilities through ORD and declares dependencies on external resources. The protocols and formats shown are examples.ORD ProviderApplication/ ServiceCapabilitiesFeatures · configurationAPIsREST · MCP · A2AEntity TypesBusiness semanticsData ProductsDelta Sharing · SQLEventsCloudEventsAgentsIntegration DependenciesRequires external APIs / EventsApplication/ ServiceORD Provider APIExpose metadataDetailed definitionsfor example OpenAPI
Protocols and formats shown are examples; ORD supports more.

Why ORD?

Automated Discovery

Publish metadata at the source so catalogs and tools can find and refresh it without manual registration.

The Actual Runtime Landscape

Reveal tenant-specific configuration, extensions, and endpoints, not only static product documentation.

Existing Standards, Connected

Keep OpenAPI, AsyncAPI, and other definitions as the source of truth while ORD adds shared context and relationships.

Extensible Where Needed

Use labels, custom types, and specification extensions for domain-specific needs while retaining a common core.

Quick Start

  1. Understand: Read the ORD introduction to grasp the core concepts.
  2. Explore: Check the example files to see ORD in action.
  3. Implement: Follow the ORD Provider section to publish ORD Documents and expose the ORD Configuration Interface.
  4. Validate: Use the JSON Schema to validate your ORD documents.

What You Can Build

ORD metadata supports both static catalogs and detailed inspection of actual system landscapes:

  • Unified catalogs for APIs, events, data products, agents, and capabilities.
  • Landscape-aware discovery of resources available in a specific tenant.
  • Integration and platform automation based on machine-readable metadata.
  • Developer tools and AI agents grounded in current resource capabilities and relationships.

Design Goals

  • Standardize how providers publish connected metadata and how consumers discover it.
  • Represent both product-level capabilities and the actual, tenant-specific runtime landscape.
  • Enable automated metadata exchange across tools, aggregators, and vendors.
  • Add shared identity, business context, taxonomy, and relationships while preserving established definition formats.
  • Evolve as an open, vendor-neutral, and extensible standard.

Non-Goals

  • Replace established resource definition formats such as OpenAPI and AsyncAPI.
  • Repeat every technical detail already captured in linked resource definitions.
  • Transport fast-changing operational data such as logs, metrics, or business payloads.
  • Grant access to discovered resources or replace their runtime protocols.
  • Mandate a single aggregator, catalog experience, or consumer-facing Discovery API.

Learn More

Explore ORD through the interactive presentation, or visit the Help hub for videos, implementation guidance, examples, and answers to common questions.