⚙️ Architecture Catalog¶

The Architecture Catalog is the read-only discovery layer for metadata-defined executable architecture.

It helps users understand:

which Source Systems and SourceDatasets exist
how sources are expected to enter the platform
what TargetDatasets exist
why they exist
how they are defined
how they are connected
how they are controlled
where execution evidence is available
how architecture flows from sources into RAW and across target layers
where Source Ingestion Readiness needs attention
how portfolio posture looks across governance and execution evidence
which serving-layer datasets are ready for trusted consumption
which architecture quality and governance signals need attention
where metadata-defined Quality Review can check loaded target data
where modeled references can be checked against loaded target data

The Catalog does not edit metadata and does not execute loads.

🔧 1. Purpose¶

elevata treats architecture as executable metadata.

The Architecture Catalog provides a structured way to discover that architecture without entering editing or execution workflows.

It complements Architecture Control:

Architecture Catalog
  = What exists, why it exists, how it is defined, how it is connected,
    how it is controlled, where its execution evidence is,
    how sources hand off into RAW, and how portfolio posture looks across the architecture.

Architecture Control
  = Review, approve, preview, execute and inspect execution evidence.

This separation keeps discovery, control and execution responsibilities clear.

🔧 2. Target Dataset Workspace¶

The Architecture Catalog Target Datasets workspace provides a compact inventory of TargetDatasets.

It supports filtering by:

dataset key and name
schema / layer
owner
active status
system-managed status
materialization type
incremental strategy
query logic
Portfolio worklist signals

Each catalog row shows:

dataset key
description
schema / layer
effective materialization type
incremental strategy
lifecycle status
management mode
ownership
upstream and downstream counts
metadata health
query logic
direct navigation links
entry point to Catalog Portfolio
entry point to Catalog Source Systems
entry point to Catalog Data Products
entry point to Catalog Insights
entry point to Catalog Map

The workspace links to:

dataset details
lineage
query contract
Architecture Control
Catalog detail
Catalog Portfolio
Catalog Source Systems
Catalog Data Products
Catalog Insights
Catalog Map

🔧 3. Catalog Source Systems¶

Architecture Catalog Source Systems provide the read-only source-side lens of the metadata-defined architecture.

They answer:

Which Source Systems and SourceDatasets exist, how are they expected to enter
the platform, and where does Source Ingestion Readiness need attention?

The view groups SourceDatasets by Source System and shows:

Source System name and short name
source type
declared native, external or no-ingestion mode
lifecycle state
SourceDataset count
ready, attention, not-applicable and unavailable counts
blocking and warning diagnostic counts
RAW landing intent
linked RAW TargetDatasets
integrated SourceColumn count
compact primary findings

Datasets requiring attention are visible first. Ready and not-applicable datasets remain available through bounded expanders that show only hidden rows.

The view supports filtering by search term, readiness state, Source System, source type and declared ingestion mode. Dataset names link to SourceDataset detail pages, where the complete diagnostic explanation is available.

Readiness remains owned by the central Source Ingestion Readiness service. The Catalog view only aggregates and presents those results.

For more details, see Architecture Catalog Source Systems.

🔧 4. Catalog Portfolio¶

The Architecture Catalog Portfolio provides a read-only executive lens across metadata-defined executable architecture.

It answers the portfolio-level question:

What is the overall architecture posture across readiness, ownership,
contracts, health, review state, execution evidence and layers?

The Portfolio shows:

active dataset coverage
ownership coverage
contract coverage
metadata health clearance
Architecture Control review clearance
Architecture Execution Record evidence coverage
Source ingestion readiness distribution
Source System and SourceDataset counts
Source readiness blocking and warning findings
Data Product readiness distribution
aggregated attention areas
layer-level ownership, contract, health, execution evidence and custom query signals

Portfolio metrics are aggregated posture signals rather than dataset lists.
When a metric needs action, its button opens a filtered Catalog worklist with the affected TargetDatasets. Users can then inspect each dataset in Catalog Detail and navigate to the existing Details, Contract, Lineage or Architecture Control entry points.

Portfolio layer rows link to filtered Catalog layer views.

The Portfolio does not edit metadata, create approvals, check approvals or execute loads.

🔧 5. Catalog Insights¶

Architecture Catalog Insights provide read-only architecture quality and governance signals across TargetDatasets.

Insights summarize:

datasets without assigned ownership
datasets with metadata health issues
datasets with metadata health warnings
datasets with custom query logic
datasets without downstream consumers
inactive datasets with downstream consumers
datasets without Architecture Execution Record evidence

Insight cards show compact dataset lists and can expand to reveal all matching datasets.

Each dataset entry links back to the Catalog detail view, where dataset-specific insight signals are shown in context.

Catalog Insights do not create approvals, check approvals, execute loads, delete execution records, or mutate metadata.

🔧 6. Catalog Data Products¶

Architecture Catalog Data Products provide a read-only consumer-readiness perspective for serving-layer datasets.

They help users understand which metadata-defined architecture objects are ready for trusted consumption by combining existing signals from:

ownership
metadata health
query contract columns
upstream and downstream relationships
Architecture Control review state
latest Architecture Execution Record evidence
lifecycle status
query logic transparency

Readiness is shown through transparent groups:

Consumption-ready
Review recommended
Not consumption-ready

Catalog Data Products focus on the serving layer. Bizcore remains the business logic implementation layer and stays visible in the Architecture Catalog, Catalog Insights and Catalog Maps without being presented as a consumer-facing Data Product.

Catalog detail pages also show dataset-specific Consumer Readiness, so users can understand why a dataset is ready for consumption or why it belongs to a non-consumer architecture layer.

Catalog Data Products derive readiness from existing architecture metadata. They do not edit metadata, request access or execute loads.

🔧 7. Catalog Map¶

The Architecture Catalog Map provides a read-only architecture lens from Source Systems and SourceDatasets into RAW, then across target layers and direct TargetDataset dependencies.

It helps users understand:

which SourceDatasets map to RAW TargetDatasets
which sources intentionally require no RAW landing
where a required RAW target is missing or ambiguous
how datasets are distributed across architecture layers
how populated layers connect to each other
which direct TargetDataset dependencies cross layer boundaries
where custom query logic appears in layer context
which datasets and dependency examples explain each architecture transition

The Catalog Map includes:

Source-to-RAW handoff summary across Source Systems, SourceDatasets and RAW TargetDatasets
mapped, no-landing and attention posture per Source System
direct links to SourceDataset and RAW TargetDataset details
layer summary cards grouped by schema / layer
layer flow overview for populated target architecture layers
TargetDataset layer dependency matrix
layer transition groups with expandable dependency examples
dataset links to Catalog detail pages and lineage pages

Source-to-RAW handoffs reuse Source Ingestion Readiness and modeled RAW input links. The target-layer dependency matrix remains limited to direct TargetDataset dependencies, so Source Systems are not treated as TargetSchemas.

The Catalog Map does not replace the dedicated lineage view and does not introduce graph editing, source connectivity, execution controls or metadata mutations.

🔧 8. Catalog Detail View¶

The Catalog detail view summarizes one TargetDataset as an architecture object.

It displays:

architecture summary
ownership
metadata health findings
latest Architecture Execution Record summary
upstream inputs
downstream consumers
column contract signals
dataset-specific Consumer Readiness
dataset-specific Catalog insight signals
Architecture Control review status summary
on-demand Architecture Quality Review for loaded target data
on-demand Reference Integrity Review for datasets with modeled outgoing references

The detail view remains read-only. Editing stays on the dataset detail and scoped metadata pages. Execution and approval workflows stay in Architecture Control.

🔧 9. Architecture Quality Review¶

For loaded TargetDatasets, the Catalog detail view can run a read-only Architecture Quality Review on demand.

The review derives deterministic checks from existing metadata and evaluates the currently loaded target data through dialect-rendered SQL.

The first review scope includes:

NOT NULL violations for non-nullable TargetColumns
duplicate key examples for surrogate-key columns
duplicate key examples for business-key columns
empty dataset advisory checks
blank string business-key advisory checks

The review output is bounded and diagnostic. Passed checks can be expanded into a compact grouped detail view. Findings show limited examples so users can understand the issue without turning Catalog Detail into a data browser.

Architecture Quality Review does not edit metadata, execute loads, create approvals, persist review history, repair data, insert default members, insert inferred members, apply Default Member Fallback, or act as an execution gate.

Future Architecture Control gates may use selected quality signals explicitly, but the Catalog review remains read-only.

🔧 10. Reference Integrity¶

For datasets with modeled outgoing references, the Catalog detail view can run a read-only Reference Integrity Review on demand.

The review checks the selected dataset as the child side of modeled TargetDatasetReferences and reports missing parent examples from the currently loaded target data.

Returned examples are proven findings, not statistical samples. Each example means that a complete child key combination exists without a matching parent key combination.

The panel is hidden for datasets without outgoing references, because there is no modeled reference to check.

Reference Integrity Review does not edit metadata, execute loads, create approvals, persist review history, insert default members, insert inferred members, apply Default Member Fallback, or repair data automatically.

Controlled Reference Members are handled by load execution, not by the Catalog. When a modeled TargetDatasetReference explicitly enables inferred members, a child dataset load may create missing parent members in the referenced rawcore dataset. When default_member_fallback_enabled is enabled, load execution may map still-unresolved child reference keys to the referenced dataset's default member.

For more details, see Reference Integrity.

🔧 11. Review Status¶

For TargetDataset scopes, the Catalog detail view surfaces the Architecture Control review status as a read-only summary.

The review status summary includes:

review state
review message
report fingerprint reference
architecture change indicator
policy status
link to the selected Architecture Control scope

Catalog detail pages use the existing Architecture Control review status contract. They do not create approvals and do not run approval checks.

🔧 12. Execution Evidence¶

For TargetDataset scopes, the Catalog detail view surfaces the latest Architecture Execution Record summary when one exists.

The evidence summary includes:

execution status
start timestamp
duration
dependency mode
compact record fingerprint
link to Architecture Control execution history

Architecture Execution Records remain stored, filtered, downloaded and governed through Architecture Control.

The Catalog shows the latest evidence reference in dataset context without duplicating the execution history workspace.

🔧 13. Lineage and Contract Signals¶

The Catalog shows direct upstream and downstream relationships.

Upstream inputs can be:

source datasets
target datasets

Downstream consumers are TargetDatasets that directly consume the selected dataset.

Column contract signals show:

ordinal position
target column name
datatype
nullability
system role
lineage origin
lifecycle status

This makes the dataset structure inspectable without replacing dedicated lineage, query contract or metadata editing pages.

🔧 14. Governance Boundary¶

The Architecture Catalog is a discovery surface.

It does not:

connect to source systems
resolve source secrets
read source files or call REST endpoints
import source metadata
edit ingestion configuration
create Approval Artifacts
check approvals
request access
execute loads
run Architecture Quality Review automatically
run Reference Integrity Review automatically
treat Catalog diagnostics as execution gates
insert default members
insert inferred members
delete execution records
mutate metadata

Architecture Control remains responsible for approval state, execution preview, controlled execution, execution records, execution history and retention cleanup. Controlled load execution remains responsible for enabled default member, inferred member and Default Member Fallback handling. Architecture Quality Review and Reference Integrity Review are Catalog diagnostics, not mutating workflows. Reference-parent readiness is an execution dependency, not a Catalog mutation or lineage edit.