Metadata Limitations

Metadata describes data. It doesn't encode business rules that systems can execute against.

What Metadata Provides

Standard data catalogs store:

Column names and types

Table descriptions

Lineage (upstream/downstream dependencies)

Tags and classifications

Ownership and documentation

Example:

table: orders
description: "Customer purchase transactions"
columns:
  - name: amount
    type: decimal
    description: "Order total in USD"

Standard metadata tells you what the data means. When agents query without context, they can't validate whether their generated queries follow current business rules.

What's Missing

Executable business rules:

table: orders
rules:
  revenue_calculation:
    exclude_types: ["refund", "crypto", "test"]
    valid_from: "2024-01-01"
    currency: "USD"
    aggregation: "SUM"

  valid_joins:
    customers:
      key: "verified_customer_id"
      cardinality: "many-to-one"
      required: true

Systems query these rules before execution, enabling dynamic workflows that adapt to changing business rules.

The Difference

Descriptive metadata: "This field is revenue"

Executable context: "Revenue excludes these types, uses this aggregation, and is valid from this date"

Descriptive metadata: "This table links to customers"

Executable context: "Join only on verified_customer_id, expect many-to-one, fail if customer is missing"

Why This Matters

Executable rules let systems validate decisions before execution. Without queryable business logic, teams resort to embedding business logic in SQL, creating maintenance debt.