STATUS: INTERNAL — exploratory, non-shareable, assumptions permitted.

ADR — Constitutional Function for Enterprise Intelligence Participation Boundary

Status: Proposed for design review

Date: 29 July 2026

Decision scope: Constitutional Architecture of Enterprise Intelligence

Review posture: Internal architecture decision record. Not share-safe.

Decision question

Which constitutional function should define the boundary through which enterprise representations participate in Enterprise Intelligence?

Candidates:

1. Enterprise Product Publication
2. Enterprise Participation
3. Enterprise Product Contracts

Context

The Arqua website has been evolving toward a clearer constitutional boundary between enterprise content and Enterprise Intelligence.

Enterprise Intelligence must not reason directly over arbitrary enterprise content. It should reason only over governed enterprise representations that have standing to participate.

The open design question is what constitutional abstraction should own that boundary.

Evaluation criteria

Candidate 1 — Enterprise Product Publication

Enterprise Product Publication establishes which accepted enterprise representations are published for participation in Enterprise Intelligence.

Strengths

• Clear implementation action.
• Familiar to data product, platform and catalogue audiences.
• Naturally connects to lifecycle, approval, registry and discoverability.
• Easy to map to platform capabilities such as Purview, Glue, Unity Catalog and catalogues.

Weaknesses

• Publication is an action or lifecycle state, not the enduring constitutional abstraction.
• The term can imply that publication itself creates authority.
• It risks collapsing constitutional standing into an implementation workflow.
• It describes “making available” more than “governed conditions of participation.”
• It does not map as cleanly to the API analogy because “API Publication” is not the constitutional contract; the API Contract is.

Relationship assessment

Summary

Enterprise Product Publication should remain an implementation pattern, not the constitutional responsibility.

Candidate 2 — Enterprise Participation

Enterprise Participation establishes which enterprise representations possess governed standing to participate in Enterprise Intelligence.

Strengths

• Captures the fundamental constitutional question: what is allowed to participate?
• Stronger than publication because it separates standing from lifecycle.
• Clarifies that participation is intentional and governed.
• Works well across content, events, services, knowledge, semantics and decisions.
• Avoids over-identifying the boundary with catalogues or platforms.

Weaknesses

• “Participation” is broad and requires an artefact to become operationally precise.
• It defines the condition but not the governed interface through which participation occurs.
• It may be less concrete for platform teams and implementation audiences.
• It does not fully exploit the API Contract analogy.

Relationship assessment

Summary

Enterprise Participation is a strong constitutional principle, but it benefits from a more precise constitutional artefact that expresses how participation is governed.

Candidate 3 — Enterprise Product Contracts

Enterprise Product Contracts establish the governed contractual boundary through which enterprise representations participate in Enterprise Intelligence.

An Enterprise Product Contract is the governed constitutional agreement through which an enterprise representation becomes a reusable participant in Enterprise Intelligence.

The contract establishes:

• enterprise identity
• ownership
• authority reference
• semantic definition
• participation rules
• lifecycle
• interfaces
• quality
• discoverability
• governance
• policy
• version
• evidence
• operational constraints

The contract does not establish authority. Authority remains with the originating Business Domain, Data Domain or recognised enterprise authority.

Strengths

• Defines a concrete constitutional artefact, not merely an action.
• Cleanly separates authority, participation, publication, discovery and consumption.
• Strongly supports the API analogy:
• Applications integrate through API Contracts.
• Enterprise Intelligence reasons through Enterprise Product Contracts.
• Makes the AI boundary explicit: AI must not reason directly over arbitrary content.
• Provides a stable anchor for registry, graph, streaming, runtime context and platform realisations.
• Allows publication to become an implementation lifecycle rather than the constitutional responsibility.
• Makes “Published Enterprise Product” clearer: it is the active product representation exposed under a contract.
• Strongly supports platform neutrality because Microsoft, AWS and Databricks can implement contracts without owning authority.

Weaknesses

• Introduces a new term that must be applied carefully across the website.
• “Contract” may be misread as a legal contract unless bounded as an architectural contract.
• Requires canonical definitions for contract identity, lifecycle, withdrawal and participation standing.
• Requires careful distinction between Enterprise Product Contract, Publication Pattern, Registry Pattern and Runtime Context Assembly.

Relationship assessment

Summary

Enterprise Product Contracts is the strongest constitutional abstraction. It provides a durable architectural artefact that can govern participation while preserving implementation patterns.

Comparative scoring

Recommended decision

Adopt Enterprise Product Contracts as the constitutional function.

Retain Enterprise Participation as the constitutional principle being established.

Retain Enterprise Product Publication Pattern as the implementation lifecycle that operationalises contracts.

Retain Enterprise Registry Pattern as the discovery surface that advertises contracts.

Recommended hierarchy:

Enterprise Authority
↓
Enterprise Product Contracts
↓
Enterprise Product Publication
↓
Enterprise Registry
↓
Operational Intent
↓
Runtime Context Assembly
↓
Enterprise Coordination
↓
Execution Admissibility
↓
Operational Execution
↓
Outcome Learning

Decision rationale

Enterprise Product Contracts is the strongest constitutional abstraction because it separates five responsibilities that must remain distinct:

1. Authority determines legitimacy.
2. Contracts determine participation.
3. Publication operationalises the contract.
4. Registry advertises the contract.
5. Runtime Context Assembly consumes the contract for a specific Operational Intent.

This separation preserves the constitutional boundary between enterprise content and Enterprise Intelligence.

API analogy

Traditional Enterprise Architecture

Business Capability
↓
API Contract
↓
API
↓
Application

Enterprise Intelligence

Enterprise Representation
↓
Enterprise Product Contract
↓
Published Enterprise Product
↓
Runtime Context Assembly
↓
AI

Applications integrate through API Contracts.

Enterprise Intelligence reasons through Enterprise Product Contracts.

This constitutional separation prevents AI from reasoning directly over arbitrary enterprise content.

Consequences if accepted

If this ADR is accepted, the website should be refactored so that:

• Enterprise Product Contracts is the constitutional function.
• Enterprise Product Publication is an implementation lifecycle and pattern.
• Enterprise Registry advertises Enterprise Product Contracts.
• Runtime Context Assembly discovers Enterprise Product Contracts appropriate to Operational Intent and consumes their published enterprise representations.
• Platform realisations describe how platform technologies implement Enterprise Product Contracts without establishing enterprise authority.
• Canonical definitions include:
• Enterprise Product Contract
• Published Enterprise Product
• Publication Standing
• Participation Standing
• Contract Identity
• Contract Lifecycle
• Contract Withdrawal
• Enterprise Product Publication
• Enterprise Registry

Proposed constitutional law

Decision status

Recommendation: Adopt Enterprise Product Contracts, subject to architecture authority review.

Implementation posture: Do not broadly rename website pages until this ADR is accepted.

Reason: The change affects the constitutional layer and should be approved before full website refactor.