Architecture

Ported from the gis_tenancy full documentation pack and adapted to the gist 21-model superset (v0.2). Diagram sources live under asset/diagrams/.

Architectural intent

gist is a specialised DSLCore application with a lightweight spatial engine. It should remain understandable, deterministic and easy to reset for repeated demonstrations. The GIS portal reports spatial facts; the Orchestrator decides coordination.

System context

flowchart LR
    USER[Portal Users]
    GIS[GIS Tenancy Portal - gist]
    ORCH[DSLCore Orchestrator]
    ROAD[Road Management App]
    MINING[Mining / Lease App]
    ENV[Environmental App]
    UTIL[Utility Coordination App]
    USER --> GIS
    GIS -->|Spatial event under disclosure profile| ORCH
    ORCH --> ROAD
    ORCH --> MINING
    ORCH --> ENV
    ORCH --> UTIL

Initial technology profile

DSLCore generated application
        │
        ├── Flask / application services
        ├── SQLAlchemy / persistence
        ├── SQLite            (apps/gist/data/gist.db)
        ├── GeoJSON geometry  (stored EPSG:4326)
        ├── Shapely spatial evaluation (analysis EPSG:7856)  ── Phase 2
        ├── Jinja2 / HTMX
        └── Leaflet map UI    (/spatialfeature/map)

Logical components

flowchart TD
    UI[Leaflet / HTMX Portal UI]
    APP[DSLCore Application Services]
    AUTH[Tenant & Permission Service]
    SHARE[Layer Share & Disclosure Enforcement]
    SPATIAL[Spatial Engine / Shapely - EPSG:7856]
    RULES[Rule Engine + Triggers]
    EVENTS[Spatial Event Queue]
    DELIV[Event Delivery - idempotent, retrying]
    RECON[Reconciliation]
    AUDIT[Audit Service]
    DB[(SQLite / GeoJSON)]
    ORCH[Orchestrator]
    UI --> APP
    APP --> AUTH
    AUTH --> SHARE
    APP --> DB
    APP --> SPATIAL
    SPATIAL --> RULES
    RULES --> EVENTS
    EVENTS --> DELIV
    SHARE --> DELIV
    DELIV --> ORCH
    DELIV --> RECON
    RECON --> ORCH
    APP --> AUDIT
    AUDIT --> DB
  • Portal UI — tenant context, map rendering, layer visibility, feature search/selection, feature details, relationship display, event display, manual simulation controls.
  • Application service layer — CRUD, tenant filtering, permission enforcement, feature validation, spatial-evaluation orchestration, event generation, import/export, audit recording.
  • Spatial engine — predicates intersects, within, contains, near (distance) first; touches, crosses, overlaps, buffered proximity later. Metric operations transform to EPSG:7856 (see page 06).
  • Layer share & disclosure enforcement — the two models the starter pack lacked: LayerShare sets what an access grant permits across tenants; DisclosureProfile sets what a disclosed payload may contain. Nothing crosses a tenant boundary except through these.
  • Rule engine + triggers — rules are configuration, not hard-coded branches; a TriggerDefinition says which events to watch and which actions to run.
  • Event subsystem — create event IDs, materialise payloads, persist queue state, deliver via EventDelivery (idempotency + retry), acknowledge, reconcile.
  • Audit subsystem — who, tenant, entity, action, before/after state, correlation, timestamp.

Deployment model

Docker network
  ├── gis-portal (gist, :5080)
  ├── orchestrator (:8000)
  ├── roads-app
  ├── mining-app
  ├── environmental-app
  └── utility-app

gist still operates standalone when the Orchestrator is unavailable — events persist, delivery is marked failed, and replay is possible (see page 07).

Boundary rule

GIS Portal:   "RP-2026-001 intersects ML-1032"
Orchestrator: "Transport, Mining and the regulator must be informed;
               a coordination case is required."

The GIS portal reports spatial facts; it does not become the enterprise coordination engine.

Future evolution

SQLite + GeoJSON  →  SpatiaLite  →  PostgreSQL + PostGIS  →  ArcGIS / QGIS / WFS / WMS adapters