A Reference Architecture for Enterprise Participation Discovery
Category: Enterprise Implementation Patterns
Status: Reference Architecture Version 1.0
Author: Arqua
Classification: Public
Last Updated: July 2026
Architectural question: How do enterprise capabilities advertise participation in Enterprise Intelligence without becoming enterprise ownership?
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.
The Enterprise Registry is not a metadata catalogue, data catalogue, API catalogue or service registry. Technology catalogues may contribute to it, but they do not replace the architectural responsibility of enterprise participation discovery.
Architectural Thesis
Enterprise Intelligence depends upon discoverable participation.
The Enterprise Registry enables authoritative enterprise capabilities to advertise how they participate in Enterprise Intelligence.
The Registry does not become enterprise knowledge.
It enables enterprise discovery.
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 layer. It allows enterprise capabilities to describe how they may be discovered, interpreted, invoked, constrained, related and used within Enterprise Intelligence.
Constitutional position
Constitutional Responsibility | Enterprise Registry Contribution |
Enterprise Representation Intelligence | Product discovery |
Runtime Context Assembly | Capability discovery |
Enterprise Control Plane | Runtime service discovery |
Semantic Resolution | Semantic service discovery |
Enterprise Coordination | Participant discovery |
Execution Admissibility | Execution service discovery |
Institutional Memory | Knowledge product discovery |
The Enterprise Registry contributes discoverability across multiple constitutional 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.
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 layer.
What Can Be Registered?
The Registry advertises participation.
Examples include:
- 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. It means that the capability has a governed way to advertise its identity, owner, purpose, interface, authority, constraints, relationships and participation characteristics.
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.
Runtime Context Assembly
Runtime Context Assembly begins with Operational Intent.
Operational Intent queries the Enterprise Registry.
The Registry identifies candidate enterprise participants.
Runtime Context Assembly then performs:
- Authority Resolution
- Identity Resolution
- Semantic Resolution
- Operational Assembly
- Context Qualification
The Registry supports discovery.
It does not assemble Runtime Context.
Runtime Context Assembly determines which discovered participants are relevant, authorised, semantically consistent and operationally qualified for a specific purpose.
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
Registers Execution Admissibility Services.
Does not become the Enterprise Registry.
Technology platforms may provide catalogues, metadata stores, lineage services, event registries, graph metadata or runtime service descriptions. These are technology contributions to participation discovery. They do not define the enterprise participation layer.
Architecture diagram
Enterprise Products
Runtime Services
Graph Products
Event Products
Policy Services
Identity Services
Execution Services
AI Services
│
▼
Enterprise Registry
│
▼
Operational Intent
│
▼
Runtime Context Assembly
│
▼
Qualified Operational UnderstandingThe Enterprise Registry enables discovery.
Runtime Context Assembly determines operational relevance.
The Registry identifies candidate participants. Runtime Context Assembly qualifies them for purpose, authority, identity, semantics, policy and operational conditions before they become part of Qualified Operational Understanding.
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 registers its Execution Admissibility capability through the Enterprise Registry.
Operational systems discover admissibility services through the Registry.
The Registry advertises.
SCIA executes.
The Registry does not evaluate admissibility, determine authority or control execution. It enables systems and runtime services to discover the relevant Execution Admissibility capability and participation constraints.
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
- No access
- The Enterprise Control Plane
- Constitutional Runtime Services
- Enterprise Streaming Pattern
- Execution Admissibility Pattern
- SCIA Runtime
- Enterprise Intelligence Framework
These references define the constitutional, implementation and runtime context in which enterprise participation discovery operates.
Pattern navigation
Source-Aligned Product Pattern
↓
Semantic Projection Pattern
↓
Enterprise Knowledge Graph Pattern
↓
Graph Projection and Interchange Pattern
↓
Enterprise Registry Pattern
↓
Enterprise Streaming Pattern
↓
Runtime Context PatternValidation
Before publishing, verify:
- The Registry is consistently described as the enterprise participation layer.
- 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 registering execution capabilities rather than becoming the Registry.
- Constitutional responsibilities 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 therefore becomes the participation layer of Enterprise Intelligence rather than another enterprise catalogue.