Wiicco / Toquis Phased BOM and POV Schema Manual

Purpose

This document defines:

1. The phased bill of materials for the Earthbond POV and production rollout.
2. The operating model where Wiicco builds and controls the secure appliance and Toquis purchases and operates Earthbond workloads on top of it.
3. The exact PostgreSQL schema delta required to harden the POV around deterministic well-log outputs, CRS/ECEF traceability, and audit-grade evidence links.

Commercial structure

Use this operating split:

1. Wiicco builds the secure development and deployment appliance.
2. Toquis purchases the appliance / managed deployment package from Wiicco.
3. Earthbond functionality runs inside that controlled environment.
4. Code, data, credentials, and output artifacts do not leave the lab or appliance except through approved deliverables.

<img src="assets/pov_manual/phase-overview.png" alt="Phased Earthbond and Wiicco build overview" />

Core principle

The defensible IP is the workflow:

1. metadata and contract-first ingest
2. CRS / datum / vertical normalization
3. MD -> TVDSS -> WGS84 -> ECEF transformation chain
4. deterministic event generation
5. evidence-pack traceability
6. controlled output publication

Do not overstaff around generic software layers. For stage 1, the payload is domain interpretation and governed workflow discipline.

Small team recommendation

For the locked lab POV:

1. Platform/backend engineer
2. Geospatial / CRS engineer
3. Frontend / product engineer
4. Infra / storage engineer
5. Geoscientist
6. Geothermal or subsurface engineer

This is enough for a serious POV. Do not build a 20-person org around stage 1.

Locked development lab topology

Remote developers should work into the lab, not pull the lab out to their laptops.

<img src="assets/pov_manual/locked-lab-topology.png" alt="Locked remote development topology" />

Existing hardware role layout

Recommended first layout using the current 3 chassis:

1. One node as storage-first TrueNAS bare metal.
2. Two nodes as Proxmox compute.
3. Add a dedicated GPU node later for OCR / VLM / local LLM workloads.

<img src="assets/pov_manual/existing-hardware-role-layout.png" alt="Existing hardware role layout" />

Phase 0: Reuse current hardware for locked POV lab

Goal

Stand up a secure internal development and validation environment using current hardware only.

Compute / storage roles

1. Node A:

• TrueNAS bare metal
• ZFS pools
• snapshots
• backup target
• archive tier

1. Node B:

• Proxmox compute
• Postgres
• data-plane API
• client/admin web
• workers

1. Node C:

• Proxmox compute
• control plane
• API gateway
• internal Git / CI / registry
• staging / test VMs

BOM

1. Existing 3x chassis
2. Existing Toshiba 16TB SAS drives
3. Existing HBA cards in IT / passthrough mode
4. 2x mirrored boot SSDs or SATADOM per node if not already present
5. Dedicated management network
6. Separate storage and application VLANs
7. UPS with monitored shutdown
8. Internal DNS / reverse proxy / TLS

Software BOM

1. Proxmox VE
2. TrueNAS SCALE
3. PostgreSQL
4. MinIO
5. Internal Git server
6. Internal CI runner
7. Internal container registry
8. Earthbond application stack

Phase 1: POV appliance

Goal

Deliver a controlled appliance that supports:

1. locked development
2. deterministic ingest validation
3. QC cards
4. CRS/ECEF proof
5. bypassed-pay candidate outputs
6. evidence-pack lite

BOM additions

1. Dedicated management switch or isolated management VLAN
2. Internal secrets management
3. Internal package mirrors / caches
4. Backup repository and scheduled snapshot policy
5. Bastion / VPN / MFA access layer
6. Formal monitoring and log retention

Wiicco responsibilities

1. appliance build
2. identity and access controls
3. infrastructure hardening
4. monitoring
5. backup / retention
6. release and update controls

Toquis responsibilities

1. Earthbond application ownership
2. domain logic approval
3. client onboarding
4. output review and acceptance

Phase 2: Production pilot

Goal

Move from POV to client-facing pilot with higher resilience.

BOM additions

1. Dedicated GPU server
2. Second protected storage head or replicated storage target
3. HA reverse proxy pair
4. Monitoring / alerting stack
5. Centralized audit / SIEM export
6. Tape or cold archive path if retention expands

GPU server role

Keep separate from primary storage.

Use for:

1. OCR
2. VLM document extraction
3. local LLM inference
4. classification support
5. batch document parsing

Do not combine heavy GPU inference with the primary storage head.

Phase 3: Production scale

Goal

Broader client load, stronger separation, and formal recovery posture.

BOM additions

1. Dedicated GPU pool or MIG strategy
2. Secondary DR site or replicated protected archive
3. Formal archive tier
4. Segregated admin and client zones
5. Additional compute nodes for batch and realtime workloads

Mac mini role

Mac minis are useful as:

1. secure remote development endpoints
2. remote desktop or remote IDE clients into the lab
3. light local inference or OCR assistants
4. operator workstations

They should not be the core shared platform for:

1. storage
2. primary database
3. shared object storage
4. central orchestration

Recommended software split

1. Proxmox:

• VMs
• app runtime
• CI
• admin services

1. TrueNAS:

• protected storage
• snapshots
• backup
• archive

1. MinIO:

• raw vault
• derived artifacts
• evidence packs
• export bundles

Exact PostgreSQL delta for POV hardening

The current schema already includes:

1. ops.well_logs
2. ops.well_qc_cards
3. ops.well_interpretations
4. ops.well_pay_events
5. ops.well_bypassed_candidates
6. ops.well_data_gaps

The POV still needs harder first-class columns for deterministic well outputs and spatial truth.

Added in migration 0015

ops.well_logs

1. source_crs
2. resolved_epsg
3. epoch
4. vertical_datum
5. transform_status
6. ecef_wellhead_x
7. ecef_wellhead_y
8. ecef_wellhead_z
9. geodetic_lat_wgs84
10. geodetic_lon_wgs84
11. ellipsoidal_height_m

ops.well_pay_events

1. depth_top_tvdss_m
2. depth_base_tvdss_m
3. depth_top_ecef_x
4. depth_top_ecef_y
5. depth_top_ecef_z
6. depth_base_ecef_x
7. depth_base_ecef_y
8. depth_base_ecef_z
9. mean_sw
10. source_crs
11. ecef_transform_applied
12. processing_version

ops.well_bypassed_candidates

1. completion_status
2. cutoffs_applied
3. evidence_pack_id
4. position_confidence
5. cone_radius_p50_m
6. cone_radius_p95_m
7. source_crs
8. ecef_transform_applied
9. processing_version

Constraints and indexes

1. TVDSS ordering check on ops.well_pay_events
2. transform-state index on ops.well_logs
3. ECEF coordinate index on ops.well_logs
4. TVDSS interval index on ops.well_pay_events
5. classification/confidence index on ops.well_bypassed_candidates
6. evidence-pack link index on ops.well_bypassed_candidates

Why this matters

This delta moves the POV from generic result blobs to a clear decision-grade contract:

1. exact spatial anchoring
2. exact transformation provenance
3. exact output traceability
4. exact evidence linkage

Development environment rule

No code leaves the lab.

That means:

1. remote staff connect through VPN / bastion / MFA
2. source control stays internal
3. CI stays internal
4. package mirrors stay internal
5. data and artifacts stay internal
6. deliverables are exported intentionally, not by default

What this means for team size

Because the schema and platform base already exist, the bottleneck is not raw engineering capacity.

The bottleneck is:

1. scope discipline
2. CRS / datum correctness
3. well-log interpretation rules
4. output contract clarity
5. audit-grade reproducibility

That supports a small expert team, not a large layered org.

Immediate next build order

1. enforce the POV schema in APIs and output writers
2. make the ingest validator + QC card the primary landing workflow
3. keep GPU / OCR / broad enrichment behind the core deterministic workflow
4. keep Wiicco appliance controls ahead of “feature sprawl”