System Interaction Map (Integrated vs Not Integrated)

This map explains how the platform currently interacts end-to-end and where modules are still partial.

1) Runtime topology

2) Upload and point-cloud flow (implemented)

1. Client UI uploads file by POST /uploads/direct (or /uploads/presign).
2. Data API writes object to MinIO and session metadata to ops.upload_sessions.
3. Client queues ingest via POST /jobs/ingest.
4. Data API enqueues job in ops.jobs (pointcloud_process).
5. worker-ingest claims job, processes LAS/LAZ, runs CRS/ECEF validation, stores result in ops.job_results.
6. Metadata APIs expose processed outputs:

• GET /projects/{project_id}/metadata
• GET /projects/{project_id}/metadata/{job_id}

1. Client WebGL viewer loads selected metadata rows and renders points.

3) Storage browsing flow (implemented)

1. Client UI Review Uploaded calls:

• GET /projects/{project_id}/uploads
• GET /bucket/list?prefix=<project>/raw/

1. Finder UI converts object keys into folder-level entries.
2. Selected file can be pushed into object_key input for ingest/export.
3. Admin UI manages storage by API:

• GET /storage/objects
• DELETE /storage/object
• DELETE /storage/prefix

4) Export and 2D map flow (implemented)

1. Client queues export via POST /jobs/export/autodesk (pts|asc|csv|jsonl).
2. worker-ingest exports artifacts and uploads to MinIO under derived/.../autodesk/.
3. GET /jobs/status returns artifact object keys.
4. For ASC, GET /maps/terrain/preview builds hillshade + contours for 2D map overlays.

5) Well data processing visibility flow (implemented)

1. Datasets are uploaded with metadata tags (source_tag, processing_stage, dataset_kind).
2. Register jobs are created by POST /processing-datasets/jobs/register.
3. UI shows live status via GET /projects/{project_id}/processing-datasets.
4. Audit compare run uses POST /projects/{project_id}/processing/audit-validate.

6) Well-log interpretation flow (partially implemented)

Implemented:

1. Queue APIs exist:

• POST /well-logs/jobs/normalize
• POST /well-logs/jobs/interpret
• POST /well-logs/jobs/bypassed-pay

1. worker-ingest has handlers for all three job types.
2. Query APIs exist for QC/status/portfolio summary.

Not yet fully integrated in UI:

1. Client web does not yet have a dedicated well-log stage runner page.
2. Status-pack/report visualization is still API-first.

7) Open-data scraper flow (implemented with practical limits)

Implemented:

1. data-scraper/search, download, and statistics endpoints.
2. Auto-search can trigger from processed upload metadata centroid.

Limits:

1. Protected-source downloads still require manual/human handling.
2. Some WCR/OCR source links return HTML/non-PDF and are correctly marked failed.

8) Modules currently present but still lightweight/stubbed

1. worker-crs: currently only processes crs_check queue events at a basic level.
2. worker-audit: evidence pack generation exists, but advanced lineage packaging remains limited.
3. Risk engine (commercial/pressure/profit scoring), uncertainty cone, and seismic tie-in are still planned.

9) Data stores and ownership

1. Postgres/PostGIS stores operational records (ops.*) and audit/core schemas.
2. MinIO stores raw and derived artifacts.
3. Client data should remain tenant-scoped.
4. Open/public data can be retained as global platform asset class (policy goal defined, incremental implementation).

10) What is connected vs disconnected right now

Connected:

1. Upload -> ingest -> metadata -> viewer.
2. Export -> object storage -> 2D map preview.
3. Processing dataset status -> audit validation UI.
4. Admin storage management via API.

Disconnected or partially connected:

1. Well-log lifecycle is not fully represented in client UI workflows.
2. Risk scoring + uncertainty cone + seismic overlays are not yet an operational runtime path.
3. Protected-source queue UX is not yet first-class in the web apps.