Enterprise Registry Pattern

A Reference Architecture for Enterprise Participation Discovery

Category: Enterprise Implementation Patterns

Status: Reference Architecture Version 1.0

Author: Arqua

Classification: Public

Source baseline: Reference Architecture Version 1.0 / July 2026

Last Updated: 17 September 2026

Web clarification: 17 September 2026 — Participation-discovery responsibilities, intent-directed RCA formation and qualification, registration and evidence limits, SCIA reference-versus-implementation relationships, navigation and review criteria clarified. An at-a-glance explanation is added. The original Reference Architecture Version 1.0 / July 2026 provenance and implementation-pattern standing are retained.

Architectural question: How do enterprise capabilities advertise participation in Enterprise Intelligence without becoming enterprise ownership?

Source role: Enterprise Implementation Pattern for governed participation discovery. The EIA capstone governs integrated relationships and the enterprise vocabulary governs shared definitions. This pattern does not grant publication standing or prescribe a vendor product.

Capstone architecture: Enterprise Intelligence Architecture

Enterprise vocabulary: Enterprise Intelligence Architecture — Canonical Definitions

Executive summary

Enterprise Intelligence requires continuous discovery of enterprise participation.

Business Domains cannot assemble Runtime Context if they cannot discover:

• enterprise products
• runtime services
• semantic services
• identity services
• policy services
• graph products
• event products
• execution services
• AI capabilities

The Enterprise Registry provides this capability.

It advertises enterprise participation.

It does not become enterprise ownership.

Enterprise Participation establishes participation.

Enterprise Product Publication operationalises participation.

The Enterprise Registry advertises participation.

The Enterprise Registry names the architectural responsibility for governed participation discovery, not a particular catalogue product. Metadata, data, API and service catalogues may implement or contribute to that responsibility when the required governance and discovery conditions are met. Their mere presence does not establish publication standing or current fitness for use.

Purpose

The Enterprise Registry enables Runtime Context Assembly and the Enterprise Control Plane to discover governed enterprise capabilities without hard-coded integration.

It supports:

• Runtime Context Assembly
• Operational Assembly
• Enterprise Control Plane
• Enterprise Coordination
• Platform Realisations
• Enterprise AI
• Enterprise Knowledge Graph
• Enterprise Streaming
• SCIA Runtime

The Registry provides a governed participation-discovery layer. It allows enterprise capabilities to describe how they may be discovered, interpreted, invoked, constrained, related and used within Enterprise Intelligence.

The Enterprise Registry becomes the authoritative discovery surface for Published Enterprise Products and registered enterprise capabilities.

Constitutional position

The Enterprise Registry contributes discoverability across multiple architectural responsibilities.

It replaces none of them.

It allows constitutional capabilities, implementation patterns and platform realisations to find governed participants without hard-coded knowledge of every product, service, graph, event stream or execution capability.

Architectural principles

ERP-1 — Participation, not ownership

The Registry advertises participation rather than ownership.

A Registry Entry describes how a capability participates in Enterprise Intelligence. It does not transfer authority, stewardship or enterprise accountability to the Registry.

Enterprise Participation establishes participation. Enterprise Product Publication operationalises participation. The Registry advertises standing.

ERP-2 — Enterprise products remain authoritative

Enterprise products remain authoritative.

The Registry advertises enterprise products and their participation characteristics. It does not become the source of truth for their content, meaning, state or stewardship.

ERP-3 — Every discoverable capability has an owner

Every discoverable capability has an owner.

A capability should not participate anonymously. Ownership, authority and accountability must remain visible through the Registry Entry.

ERP-4 — Technology-independent meaning

Semantic meaning remains independent of registry technology.

The Registry may reference semantic definitions, ontologies, glossaries or semantic services. It does not define enterprise meaning merely because it stores or exposes metadata.

ERP-5 — Governed discovery

Discovery remains governed.

The Registry should expose only what is permissible, classified, authorised and appropriate for the consuming purpose.

ERP-6 — Continuous discoverability

Participation is continuously discoverable.

Enterprise Intelligence requires discovery to evolve as products, services, policies, graphs, events and AI capabilities change.

ERP-7 — Registered runtime services

Runtime services are registered rather than hard-coded.

Runtime Context Assembly and the Enterprise Control Plane should discover services through governed registry participation rather than static integration assumptions.

ERP-8 — Technology catalogues contribute, not replace

Technology catalogues contribute to the Enterprise Registry but do not replace it.

Microsoft Purview, AWS Glue Catalog, Databricks Unity Catalog, Neo4j, Kafka and other platforms may contribute metadata or assets. The Enterprise Registry remains the architectural participation-discovery responsibility.

What Can Be Registered?

The Registry advertises participation.

Examples include:

• Published Enterprise Products
• Business Domains
• Data Domains
• Graph Products
• Event Products
• Runtime Services
• Semantic Services
• Identity Services
• Authority Services
• Policy Services
• Execution Services
• AI Services
• Digital Twins
• Operational APIs
• Documents
• Platform Services

Anything that participates in Enterprise Intelligence should be discoverable.

Registration does not mean central ownership or publication standing. It means that the capability has a governed way to advertise its identity, owner, purpose, interface, authority, constraints, relationships and participation characteristics after participation has been established.

The examples identify kinds of participants, products and discovery context; they do not grant standing to every document, API or capability of those kinds. Domain and owner descriptions identify accountable participants. Information and service contributions to Runtime Context Assembly still require their applicable publication standing and governed interfaces. Historical or inactive entries, where retained, must not be presented as currently eligible offerings merely because they remain searchable.

Registry Entries

Each Registry Entry should advertise:

• Enterprise Identity
• Name
• Owner
• Domain
• Purpose
• Authority
• Interface
• Schema
• Semantic Definition
• Version
• Quality
• Classification
• Runtime Characteristics
• Relationships
• Dependencies
• Policy
• Availability
• Confidence
• Participation Constraints

The Registry describes participation rather than implementation.

A Registry Entry should help consuming capabilities understand whether a participant is relevant, authoritative, permissible, current, available and fit for the intended enterprise purpose.

Advertised authority, availability, quality, confidence and lifecycle information must be read with its source, scope, version and currency. A description of a condition is not proof that the condition holds at the moment of use. Discovery identifies candidates; the applicable access, publication and qualification responsibilities determine what may actually be consumed and relied upon.

Owners and registry maintainers should keep discovery information aligned with governed source changes, including suspension or withdrawal. A changed listing or notice alone does not prove that affected interfaces or consumers have applied the change. A search returning no result establishes only that no match was returned within its scope, visibility and currency; it does not prove enterprise-wide non-existence.

Runtime Context Assembly

A consuming capability uses Operational Intent, bounded through Intent Scope, to guide a discovery request. The Registry returns candidate Published Enterprise Products and descriptions of governed capabilities, subject to discovery permissions and the scope of the request. It does not generate intent or confer publication standing.

Runtime Context Assembly selects eligible products and forms Candidate Operational Understanding with an Assembly Manifest. It performs Context Qualification within RCA and records the qualification outcome in a Qualified Context Manifest. Qualified Operational Understanding results only where reliance is supported for the declared use. Identity, authority, semantic and other applicable resolutions support these responsibilities; their mention here is not a prescribed peer-service deployment sequence.

The Registry supports discovery; it neither assembles nor qualifies operational understanding. A relevant discovery result does not establish access entitlement, present-purpose fitness or execution permission. A discoverable Service Product remains subject to its applicable invocation and consequence controls.

Enterprise Control Plane

The Enterprise Control Plane continuously discovers runtime capabilities through the Enterprise Registry.

Runtime services should be registered rather than statically configured.

The Enterprise Registry therefore enables dynamic Enterprise Intelligence.

It allows the Enterprise Control Plane to discover participating runtime services, policy services, semantic services, authority services, identity services, graph products, event products and execution services as governed enterprise capabilities rather than fixed platform endpoints.

Relationship to Enterprise Products

Every Source-Aligned Enterprise Product should publish a Registry Entry.

The Registry advertises:

• ownership
• interfaces
• events
• graph projections
• semantic participation
• Runtime Context participation
• AI participation

Enterprise Products remain authoritative.

The Registry advertises them.

A Source-Aligned Enterprise Product remains responsible for its enterprise representation, quality, provenance, authority and stewardship. The Registry makes its participation discoverable without taking ownership of the product.

Relationship to Platform Technologies

Technology Contributions

Microsoft Purview

Contributes metadata.

Does not become the Enterprise Registry.

AWS Glue Catalog

Contributes metadata.

Does not become the Enterprise Registry.

Databricks Unity Catalog

Contributes governed assets.

Does not become the Enterprise Registry.

Neo4j

Contributes graph metadata.

Does not become the Enterprise Registry.

Kafka

Registers Enterprise Event Products.

Does not become the Enterprise Registry.

SCIA Runtime — reference-architecture relationship

An implemented Execution Admissibility capability may be advertised through a governed Service Product. SCIA Runtime is the runtime reference architecture within EAA; it is not a vendor platform, a deployed endpoint or the operational executor merely because its reference is listed.

Technology platforms may provide catalogues, metadata stores, lineage services, event registries, graph metadata or runtime service descriptions. These are technology contributions to participation discovery. Those technology contributions do not by themselves establish enterprise participation standing.

Architectural responsibility view

Standing and advertisement: Enterprise Participation establishes the governed-entry responsibility; Enterprise Product Publication operationalises participation standing; the Enterprise Registry advertises eligible offerings and their conditions without taking ownership.

Intent and discovery: Operational Intent and Intent Scope guide a consumer's discovery request. The Registry supplies candidate descriptions and references. Intent is not an output of the Registry.

Formation and qualification: RCA selects governed inputs, forms a candidate and Assembly Manifest, and qualifies the candidate with the outcome recorded in a Qualified Context Manifest. Qualified understanding exists only where reliance is supported for the intended use.

Consequence and evidence: Neither a listing nor qualification grants execution permission. Applicable execution-admissibility controls remain distinct, and evidence of actual use and outcome is not supplied merely by discovering a product. These are responsibility relationships, not a mandatory pipeline or a claim that every proposed action executes.

Relationship to Enterprise Knowledge Graph

The Enterprise Knowledge Graph represents governed enterprise relationships.

The Enterprise Registry advertises enterprise participation.

These are complementary architectural responsibilities.

The Registry discovers.

The Graph relates.

The Enterprise Knowledge Graph may represent relationships between registered capabilities, but it does not replace participation discovery. The Registry may advertise graph products, but it does not become the graph.

Relationship to SCIA Runtime

SCIA Runtime is the runtime reference architecture for Execution Admissibility within EAA. An organisation may implement an admissibility capability and make its governed service discoverable through the Enterprise Registry. Discovering the reference architecture is not discovery of an implemented service unless such an implementation is separately identified.

The Registry advertises the service and its participation conditions; the implemented admissibility capability evaluates the proposed action at its applicable consequence boundary. Operational execution remains a separate responsibility. Neither registration nor a discovery response grants permission to execute or proves that an admissibility control has been applied.

The Registry does not evaluate admissibility, establish the underlying authority or execute the action. Its own operations remain subject to applicable controls where they bind consequence.

Future Registry Extensions

Future implementation patterns may specialise this pattern into:

• Enterprise Product Registry — Coming Soon
• Runtime Service Registry — Coming Soon
• Policy Registry — Coming Soon
• Semantic Registry — Coming Soon
• Execution Registry — Coming Soon
• AI Capability Registry — Coming Soon
• Graph Registry — Coming Soon
• Event Registry — Coming Soon

These extensions should preserve the architectural separation between discovery, ownership, runtime qualification and execution authority.

Non-goals

The Enterprise Registry does not:

• replace enterprise ownership
• replace Enterprise Knowledge Graph
• replace Runtime Context Assembly
• replace semantic governance
• replace technology catalogues
• replace Institutional Memory
• become the Enterprise Control Plane

The Registry provides enterprise participation discovery.

Cross references

This pattern should be read with:

• Enterprise Knowledge Graph Pattern
• Source-Aligned Product Pattern
• Semantic Projection Pattern
• Runtime Context Assembly
• The Enterprise Control Plane
• Constitutional Runtime Services
• Enterprise Streaming Pattern
• Execution Admissibility Pattern
• SCIA Runtime Reference Architecture
• Enterprise Intelligence Framework

These references define the constitutional, implementation and runtime context in which enterprise participation discovery operates.

Pattern navigation

This is a reading path among related patterns, not a mandatory runtime sequence, deployment order or requirement to use one platform.

Source-Aligned Product Pattern
↓
Semantic Projection Pattern
↓
Enterprise Knowledge Graph Pattern
↓
Graph Projection and Interchange Pattern
↓
Enterprise Registry Pattern
↓
Enterprise Streaming Pattern
↓
Runtime Context Pattern

Validation

Before publishing, verify:

• The Registry is consistently described as the participation-discovery layer, not the authority that grants participation standing.
• The Registry never becomes enterprise ownership.
• Runtime Context Assembly discovers participants through the Registry.
• Enterprise Products remain authoritative.
• Platform catalogues are described as contributors rather than replacements.
• Enterprise Knowledge Graph and Enterprise Registry have clearly different responsibilities.
• SCIA Runtime is described as the runtime reference within EAA; any discoverable implemented admissibility service is distinguished from that reference and from operational execution.
• Constitutional responsibilities remain distinct.
• Discovery results retain their source, scope and currency; metadata claims and empty searches are not overstated as current operational proof or complete enterprise coverage.
• Publication standing, access entitlement, purpose-specific qualification and execution permission remain distinct.

Boundary statement

This page is an Enterprise Implementation Pattern. It is not a Constitutional Architecture paper.

It does not define a metadata catalogue, data catalogue, API catalogue or service registry as the architecture.

It does not modify the authority of Enterprise Products, Enterprise Representation Intelligence, Institutional Memory, Runtime Context Assembly, Enterprise Coordination, the Enterprise Control Plane or SCIA Runtime.

It does not assert that registry technology provides legal compliance, regulatory assurance, operational assurance or automated decision authority.

Human and organisational accountability remains with the institution applying the pattern.

Conclusion

Enterprise Intelligence requires continuous discovery of enterprise participation.

The Enterprise Registry provides this capability by advertising enterprise products, runtime services, graph products, event products and execution services without assuming ownership of those capabilities.

This architectural separation enables Runtime Context Assembly, Enterprise Control Plane orchestration and platform independence while preserving authoritative enterprise ownership.

The Enterprise Registry provides the participation-discovery responsibility within Enterprise Intelligence; catalogue technology may realise that responsibility without becoming the source of enterprise authority.