# Scoping Rules for Spatial Products

Enterprise spatial data platforms require deterministic scoping mechanisms to prevent architectural bleed, enforce domain autonomy, and guarantee predictable data product delivery. When transitioning from monolithic GIS repositories to a federated architecture, scoping rules establish the immutable contract between domain teams, platform infrastructure, and downstream consumers. Building upon the foundational principles outlined in Geospatial Data Mesh Fundamentals, this procedural guide defines the implementation patterns, configuration logic, and operational guardrails required to deploy spatial products at scale. The framework enforces strict architectural separation while enabling cross-domain interoperability through standardized routing, security boundaries, and measurable service-level agreements.

Figure — Scoping rules as policy-as-code: a manifest must clear CRS, extent, and resolution gates before it can publish to the mesh.

flowchart TB
  M["Product manifest"]
  C1{"CRS in allowlist?"}
  C2{"Bounding box within domain extent?"}
  C3{"Resolution within limit?"}
  DENY["Reject publication"]
  PUB["Publish to mesh"]
  M --> C1
  C1 -->|"no"| DENY
  C1 -->|"yes"| C2
  C2 -->|"no"| DENY
  C2 -->|"yes"| C3
  C3 -->|"no"| DENY
  C3 -->|"yes"| PUB

# 1. Deterministic Domain Routing & Boundary Enforcement

Domain-driven spatial architecture mandates explicit boundary enforcement at the network, storage, and compute layers. Traditional centralized GIS architectures often rely on shared schema registries and monolithic processing pipelines, which introduce implicit coupling and unpredictable latency. A federated mesh requires each spatial domain to own its compute topology, storage tiering, and access contracts. As detailed in Spatial Domain Boundary Design, isolating domain-specific coordinate reference systems (CRS), topology rules, and ingestion pipelines is non-negotiable for platform stability.

To implement strict separation, configure domain-scoped routing policies using an API gateway or service mesh sidecar. Each spatial product must expose a dedicated ingress endpoint mapped to a domain-specific virtual network. Routing rules should evaluate spatial metadata headers to direct requests to the correct compute cluster. Cross-domain geometry transformations must be rejected at the edge unless explicitly authorized through a federated transformation policy.

Production-Ready Routing Configuration (Envoy/Istio VirtualService):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: spatial-domain-router
  namespace: platform-gateway
spec:
  hosts:
  - api.spatial-platform.internal
  http:
  - match:
    - headers:
        x-spatial-domain:
          exact: "hydrology"
        x-crs-code:
          exact: "EPSG:4326"
    route:
    - destination:
        host: hydrology-processor.hydrology.svc.cluster.local
        port:
          number: 8080
    # Idempotent fallback: reject unauthorized CRS transformations
    fault:
      delay:
        percentage: 0
      abort:
        httpStatus: 400
        percentage: 0
    headers:
      request:
        remove: ["x-geometry-type"] # Prevent implicit schema coupling

Deploy this configuration via GitOps to ensure idempotent state reconciliation. Any drift between declared routing policies and active mesh state should trigger automated remediation pipelines.

# 2. Idempotent Productization & Cataloging Contracts

Spatial datasets transition from raw assets to consumable products only when governed by explicit product contracts. Applying Product Thinking for GIS Datasets requires treating each spatial output as a versioned, SLA-bound artifact rather than an ad hoc export. The cataloging layer must enforce strict metadata schemas that differentiate between raw telemetry, processed derivatives, and analytical aggregates.

Metadata cataloging for raster/vector products must implement a dual-index strategy: spatial indexing (quadtree, R-tree, or H3) for query routing, and semantic indexing for business context discovery. Catalog registration workflows must be idempotent to prevent duplicate entries during pipeline retries or network partitions.

Declarative Catalog Registration Pipeline (ArgoCD/CI):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: catalog-sync-hydrology
spec:
  project: data-mesh
  source:
    repoURL: https://git.platform.internal/spatial-catalogs.git
    targetRevision: main
    path: hydrology/v1.4.0
    plugin:
      name: spatial-catalog-validator
      env:
      - name: VALIDATE_SCHEMA
        value: "iso-19115-3"
      - name: ENFORCE_IDEMPOTENCY
        value: "true"
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - RespectIgnoreDifferences=true

The catalog validator must enforce schema compliance, verify spatial extent boundaries, and bind SLA metrics (e.g., max_query_latency_ms, refresh_frequency_hours) to the product manifest. Failed validations halt promotion to the production registry and emit structured alerts to the domain steward.

# 3. Security Policy Enforcement & Zero-Trust Access

Platform engineering standards require that spatial products operate under zero-trust principles. Security policies must be evaluated at the ingress, compute, and storage layers using policy-as-code. Row-level and column-level spatial filtering should be enforced dynamically based on consumer identity, clearance level, and requested bounding box.

Open Policy Agent (OPA) Rego Policy for Spatial Extent Filtering:

package spatial.access

import rego.v1

default allow = false

allow if {
    # Verify consumer role matches domain clearance
    input.user.roles[_] == input.resource.domain_role
    # Enforce spatial extent boundary compliance
    input.request.bbox.latitude_max <= input.resource.max_lat
    input.request.bbox.latitude_min >= input.resource.min_lat
    # Reject high-resolution raster access without explicit approval
    resolution_authorized
}

# High-resolution rasters (sub-metre) require an explicit approval grant
resolution_authorized if {
    input.resource.resolution_meters >= 1.0
}

resolution_authorized if {
    input.user.approvals[_] == "high-res-spatial"
}

Policies must be compiled and distributed via a centralized policy registry. Enforcement should be integrated into the service mesh sidecar or data plane proxy to ensure consistent evaluation across all spatial product endpoints. For standardized error responses and compliance reporting, align policy outputs with the OGC API - Features specification.

# 4. Diagnostic Workflows & Observability Guardrails

Deterministic scoping requires measurable observability. Platform teams must implement structured diagnostic workflows to identify routing failures, catalog sync drift, and policy denials. All spatial product endpoints should emit OpenTelemetry traces enriched with spatial metadata (crs_code, geometry_type, spatial_extent_hash).

Structured Diagnostic Matrix:

Diagnostic workflows must be automated where possible. Implement health probes that validate spatial index integrity and policy compliance on a scheduled cadence. Alert thresholds should be tied directly to product SLAs rather than generic infrastructure metrics.

# 5. Cross-Domain Governance & Lifecycle Management

Spatial products operate within a continuous lifecycle: ingestion, processing, publication, consumption, and deprecation. Cross-team governance workflows must enforce deterministic versioning strategies, audit trails, and backward-compatible deprecation paths. Major CRS changes, topology rule updates, or schema migrations require coordinated rollout windows and consumer notification periods.

Versioning should follow semantic conventions extended for spatial context (e.g., v1.2.0-EPSG32633). Deprecation workflows must be idempotent: marking a product as deprecated should automatically route legacy consumers to a migration endpoint while preserving historical query access for a defined retention period. All lifecycle transitions must be logged to an immutable audit ledger, enabling compliance verification and root-cause analysis.

For comprehensive implementation patterns governing these transitions, refer to Defining scoping rules for enterprise spatial products. Platform engineers should integrate lifecycle state machines into CI/CD pipelines, ensuring that no spatial product reaches production without passing automated boundary validation, security policy evaluation, and catalog compliance checks.

By enforcing deterministic routing, idempotent cataloging, zero-trust security, and structured diagnostics, enterprise spatial platforms achieve predictable delivery at scale. Scoping rules are not merely architectural guidelines; they are executable contracts that guarantee domain autonomy, consumer reliability, and platform resilience.