Executive Summary

The Thesis

The Coconut Rhinoceros Beetle (CRB) represents one of the most significant biosecurity threats facing Hawaiʻi's palm populations. Current response programs share a common architecture: inspect individual trees, confirm damage, treat confirmed cases. This tree-centric approach has predictable failure modes at scale—coverage gaps, no persistence, no verification, and no population intelligence.

SkyGuard inverts this model. Instead of treating trees one at a time based on manual inspection, SkyGuard tracks the infestation itself through systematic aerial surveillance, automated detection, and verified outcomes. The result is a program that can scale coverage without scaling headcount, and—critically—can demonstrate whether interventions are working.

What Changes

Treatment Doctrine

SkyGuard is designed for contexts where the dominant risk is uncontrolled spread. In this framing, under-treatment is the failure mode. The system is calibrated to favor recall over precision—treating more suspected palms is generally preferable to missing infestations that seed new clusters.

The Opportunity

The immediate beachhead is municipal CRB response in Hawaiʻi. The City & County of Honolulu represents a single, well-defined customer with active biosecurity coordination needs and an existing relationship with Tethra Systems.

Why Now

SkyGuard is possible because five technology areas have matured simultaneously:

1. High-resolution aerial imaging with stable radiometric calibration
2. RTK positioning enabling consistent georegistration across surveys
3. Production photogrammetry producing reliable survey products
4. Practical ML pipelines for segmentation and interpretable scoring
5. Operational drone execution with detailed logging and compliance controls

No single technology is novel. The value is in the system architecture that integrates these components into an operational program with measurable outcomes.

What Success Looks Like

A successful pilot produces:

• Consistent coverage and processing latency
• Stable registry performance across survey cycles
• Measured detection accuracy (PPV/recall) on calibration samples
• Outcome reporting for treated cohorts with explicit denominators
• Evidence packets suitable for stakeholder accountability

SkyGuard does not promise eradication. It promises measurable progress with defensible methodology.

The Problem

Why CRB is a Hard Biosecurity Problem

The Coconut Rhinoceros Beetle presents a structural challenge that current response architectures are not designed to solve.

The detection delay problem: Observable frond damage—the characteristic V-cuts that trigger human recognition—typically appears well after initial infestation. By the time damage is visible, beetles have already bred and dispersed. Programs that respond to visible damage are always fighting the previous generation's spread.

Note: SkyGuard enables earlier detection than complaint-driven discovery by systematically surveying the full footprint rather than waiting for reports. This is not a claim of pre-symptomatic detection—imaging still requires visible indicators, but systematic coverage finds them sooner than reactive programs.

The coverage problem: Beetles are mobile and opportunistic. Breeding sites include mulch piles, green waste, dead palms, and other decaying organic matter spread across diverse land uses. No feasible inspection program can monitor every potential site continuously.

The verification problem: Traditional programs treat palms and assume effectiveness. Without systematic outcome tracking, there is no way to determine whether treatments are actually reducing infestation pressure or merely consuming resources.

Why "Treating Trees" Fails at Scale

A tree-centric workflow—inspect, confirm, treat—has predictable failure modes:

Coverage Gaps

Inspectors cannot be everywhere. A 50,000-palm footprint with monthly coverage would require an estimated 8-12 full-time inspectors just to maintain pre-treatment confirmation. (Illustrative: assumes ~150-200 palms/inspector/day, 20 working days/month, including travel and documentation time.) Activity spreads in the uninspected gaps.

No Persistence

Without stable palm identifiers, there is no way to link observations over time. Each survey is an isolated snapshot. Treatment history, outcome trajectories, and longitudinal patterns are invisible.

No Verification

When a palm is treated, the program cannot systematically determine whether the treatment worked. "Success" is asserted rather than measured.

No Population Intelligence

Tree-centric programs cannot answer population-level questions: Where is activity concentrating? Is prevalence increasing or decreasing? What is the program's actual effectiveness rate?

What a Modern Program Requires

The Solution

What SkyGuard Is

SkyGuard is a precision biosecurity operations platform. It combines repeatable aerial imaging with automated analysis to produce treatment queues and verified outcomes.

The system does not track individual beetles. It tracks infestation indicators at the palm level and produces population-level intelligence that is operationally useful and programmatically defensible.

Core Operating Loop

Sense

Repeatable aerial surveys capture high-resolution RGB imagery (multispectral optional) on a defined cadence. RTK positioning ensures consistent georegistration across survey cycles.

Analyze

Survey imagery flows through an automated pipeline: Palm crown segmentation creates or updates registry entries. Multi-modal detection extracts damage and stress indicators. Fusion model produces calibrated risk scores per palm. Risk scores are explainable via feature attribution.

Treat

Treatment targeting is threshold-based: Palms above the configured risk threshold enter a treatment queue. Nearby palms are clustered into treatment zones. Mission packages are generated with compliance constraints. Human operators approve batches and licensed applicators execute.

Verify

Follow-up imaging enables outcome measurement: Treated palms are re-observed in T+30, T+60, and T+90 windows (±5-10 days based on survey cadence). Composite and risk-based outcome scores classify response. Confounders (drought, storm, other pests) are flagged and excluded. Outcome distributions are reported with explicit denominators.

Learn

Calibration sampling and verified outcomes close the loop: Independent inspections measure detection accuracy (PPV/recall). Outcome data informs model recalibration. Threshold governance responds to measured performance.

Human-in-the-Loop Governance

SkyGuard is explicitly not autonomous. Humans retain authority at key control points:

AI Query Interface (Phase 2)

SkyGuard's architecture supports a natural language query layer powered by a local LLM, enabling operators to interact with program data conversationally and generate narrative summaries on demand. This capability is planned for Phase 2 deployment after core pipeline validation.

How It Works

The LLM is grounded in actual data—it queries the live registry, risk scores, and treatment history, then formats results into functional narrative summaries. No external API calls; all processing stays on-prem.

Example Queries

Design Principles

• Grounded responses: All answers derived from database queries, not model training
• Functional narrative: Clear summaries optimized for operational use, not prose quality
• On-prem processing: Local LLM keeps data in-house, no external API dependencies
• Domain-tuned: Fine-tuned on CRB/biosecurity vocabulary and report formats
• Query restrictions: Text-to-SQL limited to SELECT operations on authorized views; no data modification permitted via natural language interface

Note: Core detection, treatment, and outcome tracking functionality operates independently of the AI query interface. The LLM layer enhances usability but is not on the critical path for program operations.

What SkyGuard Is Not

Business Model & Moat

Why This Is a Business

A detection model is not a product. The market value exists where:

• Decisions translate into field operations
• Outcomes are verified and reported
• Performance is measured and defended
• The system improves with operational data

SkyGuard's product is the operating system for biosecurity response—not a point solution, but an integrated platform that captures value across the entire operational loop.

Revenue Model

Platform Subscription (Annual)

Recurring revenue for core platform access: Palm registry and risk scoring engine, program dashboards and reporting, audit trail and evidence packet generation, model monitoring and calibration tooling, governance tooling.

Operations Services (Variable)

Usage-based revenue scaling with program footprint: Survey operations (per survey or per acre), processing and analysis (per survey cycle), mission packaging and reconciliation (per batch), verification reporting.

Professional Services (As-Needed)

High-value services for program maturity: Calibration sampling coordination, compliance documentation, model customization, training.

Competitive Moat

1. Data Moat: Longitudinal Registry + Outcomes

SkyGuard creates a unique dataset that cannot be quickly replicated: persistent palm IDs across survey cycles, linked treatments and verified outcomes, calibration labels with known denominators, temporal patterns revealing population dynamics.

2. Defensibility Moat: Auditability + Evidence Packets

Municipal programs face stakeholder scrutiny. SkyGuard's value increases when accountability is demanded: every decision is traceable to inputs and rules, immutable logs prevent post-hoc modification, evidence packets support per-palm defense.

3. Governance Moat: Decision Contract

SkyGuard's threshold-based decision contract makes the program: Tunable (operators adjust the precision/recall tradeoff), Consistent (same inputs produce same outputs), Reviewable (decision rules are explicit and auditable), Transferable (staff turnover doesn't break institutional knowledge).

4. Execution Moat: Operations Playbook

Scaled biosecurity programs are won or lost on execution: repeatable survey SOPs with QA gates, mission packaging with compliance constraints, exception handling with documented escalation, verification protocols with outcome classification.

5. Relationship Moat: Early Adopter Access

The existing relationship with City & County of Honolulu provides: reduced time-to-pilot, real operational context for development, credibility with adjacent stakeholders, reference customer for expansion.

Unit Economics (Illustrative)

At pilot scale (50,000 palms, monthly surveys):

Roadmap & Risks

Validation Pathway

SkyGuard follows a pilot-gated roadmap. Each phase produces specific evidence artifacts before advancing.

Phase 0: Bench Validation (4-8 weeks)

Goal: Demonstrate pipeline reproducibility on representative Hawaiʻi imagery.

Phase 1: Pilot Launch (Month 1-3)

Goal: Establish operational tempo and baseline program metrics.

Phase 2: Verification Emergence (Month 4-6)

Goal: Begin outcome measurement with first T+90 cohorts.

Phase 3: Scale Proof (Month 7-12)

Goal: Use outcome data to recalibrate and prove scalability.

Key Risks and Mitigations

Claims SkyGuard Will Not Make

Success Criteria

Appendix A: Canonical Definitions

These definitions are authoritative throughout the SkyGuard system. Terms are defined once here and not redefined elsewhere.

Core Entities

Palm

A single palm tree instance in the registry with: palm_id (stable UUID), geometry (crown polygon), first_observed, status (Active | Removed | Merged | Split).

Survey

A complete imaging collection over a defined footprint with: survey_id, footprint, captured_at, sensor_config, qa_status.

Risk and Decision

Risk Score

A calibrated likelihood score in [0.0, 1.0] representing the probability of active CRB damage requiring treatment. Generated by the fusion model from imaging-derived features. Calibrated on the monthly Stream A Audit sample; calibration is monitored for drift and recalibrated as needed.

Treatment Threshold

The risk score cutoff above which palms enter the treatment queue. Operator-configurable. Default: 0.6.

Holdout Period

Minimum time after treatment before a palm can be re-queued. Default: 90 days.

Detection Metrics

Positive Predictive Value (PPV)

The proportion of palms flagged as above-threshold that are confirmed positive by Level 4A ground-truth (RCI or physical inspection). Computed on the monthly Stream A Audit sample.

PPV = True Positives / (True Positives + False Positives)

Recall (Sensitivity)

The proportion of truly infested palms (confirmed by Level 4A ground-truth) that the model correctly flagged as above-threshold. Computed on the monthly Stream A Audit sample.

Recall = True Positives / (True Positives + False Negatives)

Ground-Truth Definition

A palm is "truly infested" if Level 4A verification (RCI or physical inspection with evidence package) confirms active CRB damage. Stream A Audit sample provides the denominator for both metrics.

Evidence Levels

Outcome Categories

Delta Conventions

Δrisk = risk_T+90 - risk_pre (Negative = improvement)

Δcomposite = weighted combination (Positive = improvement)

Interpretation: Lower risk scores are better (reduced infestation likelihood). Higher composite scores are better (improved overall health). The sign conventions are opposite because risk measures "badness" while composite measures "goodness."

Appendix B: Technical Architecture

This appendix describes the system architecture at a level suitable for engineering estimation and implementation planning.

Design Principles

1. Geospatial-first: Store and index data in PostGIS; design pipelines around spatial features
2. Immutable, versioned artifacts: Each run (survey, model, risk scoring) must be reproducible and traceable
3. Closed-loop governance: Program managers set thresholds; licensed applicators execute; all actions are auditable
4. Evidence and metrics: Report denominators and missingness; avoid over-claiming
5. Separation of concerns: Keep sensing, processing, scoring, mission packaging, execution and verification modular

System Topology

Data Model (Core Tables)

-- Palm Registry
palm (palm_id UUID PK, geometry POLYGON, centroid POINT,
      first_observed TIMESTAMP, last_observed TIMESTAMP,
      status VARCHAR, cultivar VARCHAR, height_m FLOAT)

-- Survey Metadata  
survey (survey_id UUID PK, footprint POLYGON, captured_at TIMESTAMP,
        sensor_config JSONB, processing_ver VARCHAR, qa_status JSONB)

-- Per-Palm Observations
observation (obs_id UUID PK, palm_id FK, survey_id FK,
             features JSONB, risk_score FLOAT, shap_factors JSONB)

-- Treatment Operations
treatment_queue (queue_id UUID PK, threshold FLOAT, model_version VARCHAR)
mission (mission_id UUID PK, batch_id UUID, targets JSONB, route JSONB,
         constraints JSONB, approved_by VARCHAR, approved_at TIMESTAMP)
execution_log (log_id UUID PK, mission_id FK, flight_track LINESTRING,
               events JSONB, weather_snap JSONB, exceptions JSONB)

-- Verification & Audit
verification (palm_id FK, treatment_id UUID, t30/t60/t90_score FLOAT,
              outcome_class VARCHAR, composite_delta FLOAT)
audit_event (event_id UUID PK, timestamp, actor, action, object_id,
             payload JSONB, prev_hash VARCHAR, event_hash VARCHAR)

Pipeline Stages (Detailed)

Stage 1: Ingest

• Upload raw frames to object storage with lifecycle rules
• Extract EXIF/XMP metadata (GPS, camera settings)
• Compute per-frame quality metrics (blur, exposure, coverage)
• Build spatial footprint index
• Record ingestion event with hash in audit log

Stage 2: Photogrammetry

• Invoke containerized engine (Pix4D/ODM)
• Generate orthomosaic with RTK georegistration
• Extract CHM from structure-from-motion
• Compute reflectance products (if MS enabled)
• QA gates: coverage ≥95%, blur score, registration RMSE
• Attestation report with pass/fail stored in event log

Stage 3: Palm Detection

• Tile orthomosaic into 512×512 chips
• Run U-Net segmentation (EfficientNet-B4 encoder)
• Post-process: threshold, connected components, polygon simplification
• Filter by area (2-100 m²) and circularity (>0.4)
• Merge overlapping polygons across tile boundaries

Stage 4: Damage Classification

• Extract 256×256 crown crops per detected palm
• Run V-cut CNN classifier (ResNet-50 backbone)
• Escalation: if confidence 0.4-0.8, retrieve raw frames for re-eval
• Compute spectral indices (NDVI, NDRE, GNDVI, SAVI)
• Aggregate per-crown statistics (mean, std, percentiles)

Stage 5: Risk Scoring

• Assemble feature vector (~50 features): damage, spectral, temporal, spatial, structural
• Run XGBoost inference
• Apply isotonic calibration for probability alignment
• Compute SHAP values for top-5 feature attribution
• Store scores and explanations in observation table

Stage 6: Registry Matching

• Spatial proximity matching (configurable threshold: 2-5m)
• Shape signature comparison (Fourier descriptors)
• Neighborhood graph consistency check
• Height consistency validation from CHM
• Handle merge/split cases with confidence scoring
• Low-confidence matches flagged for manual review

Stage 7: Mission Generation

• Filter: score ≥ threshold AND outside holdout period
• Cluster nearby targets (DBSCAN or grid-based)
• Route optimization (OR-Tools / OSRM)
• Attach constraint snapshot (geofences, weather limits, credentials)
• Generate mission JSON with schema version
• Hold for program manager batch approval

Stage 8: Execution & Reconciliation

• Applicator uploads flight track + application events via API/CLI
• Spatial join: planned targets vs. executed positions
• Compute success rate, flag deviations
• Exception codes: ACCESS_DENIED, OBSTRUCTION, SAFETY_ABORT, WEATHER_ABORT
• Push missed targets back to queue or schedule manual inspection

Stage 9: Verification

• Schedule T+30/60/90 follow-up surveys automatically
• Run change detection: pre vs. post imagery
• Compute risk delta and composite delta
• Apply outcome classification rules
• Flag confounders (drought, storm, pruning, other pests)
• Generate evidence packets per treated palm

Stage 10: Model Maintenance

• Stratified sampling for ground-truth acquisition
• Compute PPV, recall, calibration curves on sample
• Monitor feature and score distribution drift
• Automated retraining when drift exceeds threshold
• Canary deployment: test new model on subset before rollout
• Threshold adjustment guidance based on PPV/recall tradeoffs

Infrastructure Decision Trees

Cloud vs. On-Prem

RGB vs. Multispectral

Photogrammetry Software

Orchestration Tool

Security & Compliance Controls

• Authentication: OAuth 2.0 / JWT for API access
• RBAC: Program Manager, Data Lead, Field Operator roles
• Encryption: TLS for transit, AES-256 for storage
• Audit Trail: Hash-chained event log (Merkle tree optional)
• Credential Checks: Applicator license validation before mission release
• Data Retention: Raw imagery 12-24 months; processed data 5+ years; audit logs indefinite

AI Query Interface Architecture (Phase 2)

SkyGuard's architecture supports a local LLM for natural language data queries and narrative summary generation. This capability is planned for Phase 2 deployment after core pipeline validation.

System Flow

Components

Security Constraints

• Query restrictions: Text-to-SQL limited to SELECT operations only; no INSERT/UPDATE/DELETE permitted
• Authorized views: LLM queries execute against restricted database views, not raw tables
• Audit logging: All LLM-generated queries logged with user context

Note: Core pipeline functionality operates independently. LLM interface enhances data accessibility but is not a critical path dependency.

Appendix C: Detection Pipeline

This appendix details the sensing, segmentation, and scoring components of the SkyGuard detection system.

Survey Specifications

RGB Imaging

Multispectral (Optional Phase)

Palm Crown Segmentation

Data Annotation

• Select representative orthomosaics across zones and conditions
• Label palm crowns using QGIS or dedicated labeling platform
• Target: 12,000+ annotated crowns for initial training
• Include edge cases: overlapping crowns, shadows, partial visibility

Model Architecture

Primary model: U-Net with EfficientNet-B4 encoder

Post-Processing Pipeline

1. Threshold binary mask at 0.5
2. Connected component labeling
3. Contour extraction
4. Polygon simplification (Douglas-Peucker)
5. Filter by area: min 2m², max 100m²
6. Filter by circularity: >0.4
7. Merge overlapping polygons from adjacent tiles

V-Cut Detection (Damage Classification)

Training Data

• Crown crops labeled: healthy, damaged, confounded
• Confounded class includes: wind damage, nutrient stress, mechanical pruning
• Target: 3,000+ labeled examples per class

Model Architecture

Primary model: CNN classifier (ResNet-50 backbone)

Escalation Protocol

When V-cut confidence is in uncertain range (0.4-0.8):

1. Retrieve all raw frames overlapping crown centroid
2. Select top-3 by: lowest blur, best sun angle, highest overlap
3. Extract high-resolution crops from raw frames
4. Re-run inference on raw crops
5. Use max score if any crop >0.7; min score if all <0.3
6. Otherwise flag for calibration sampling

Spectral Analysis

Vegetation Indices

Per-Crown Aggregation

For each crown polygon, extract from raster:

• Mean, standard deviation
• 10th and 90th percentiles
• Anomaly score vs. neighborhood baseline

Risk Score Fusion

Feature Vector (~50 features)

XGBoost Configuration

• Objective: binary logistic
• Calibration: isotonic regression post-hoc
• Explainability: SHAP TreeExplainer
• Output: calibrated probability [0, 1] + top-5 feature drivers

Performance Targets

Appendix D: Verification & Truth Budget

This appendix describes the outcome verification system and the calibration sampling strategy that provides biological anchoring for program claims.

The Verification Problem

Imaging-based detection and outcome tracking is self-referential: if the model is systematically wrong, outcomes classified by model outputs would not detect the error.

The Truth Budget solves this by allocating a bounded monthly investment in independent biological verification that provides ground truth for model calibration and outcome anchoring.

Operational Monitoring Cadence

Key insight: Verification is not a special follow-up activity—it happens automatically as part of the regular survey cadence.

How It Actually Works

Data Model

-- Per-palm treatment history
palm.last_treatment_date    -- most recent treatment timestamp
palm.last_treatment_id      -- links to treatment record
palm.treatment_count        -- total treatments received

-- When each survey processes:
FOR each palm WITH last_treatment_date:
  days_since = survey.date - palm.last_treatment_date
  
  IF days_since BETWEEN 25-40:  bucket = 'T+30'
  IF days_since BETWEEN 55-70:  bucket = 'T+60'  
  IF days_since BETWEEN 85-100: bucket = 'T+90'
  
  -- Compute outcome metrics at this observation point
  delta_risk = current_risk - pre_treatment_risk
  delta_composite = weighted_outcome_score(current, pre)

Why This Matters

• No special flights: Verification piggybacks on routine surveys
• Natural variance handled: Actual days (28, 32, 35) classified into windows
• Continuous tracking: Every survey updates outcome status for all treated palms
• Asset-level history: Full treatment timeline per palm, not just snapshots

Truth Budget Architecture

Three-Stream Allocation (~200 inspections/month)

Remote Close Inspection (RCI)

Inspection drones capturing crown-level evidence. RCI is the default Level 4A verification modality.

RCI Independence Specification

Outcome Classification

Stratified Estimator Specification

• Stratum Weights: Proportional to registry counts per stratum
• Stream Treatment: Stream A for PPV/recall; B+C tracked separately
• Variance: Per-stratum Wilson interval; linearized aggregation
• Finite Population Correction: Applied when sample >5% of stratum

Appendix E: Data Governance

This appendix describes the data governance framework, audit trail architecture, and compliance controls that make SkyGuard operations defensible.

Why Auditability Is First-Class

Biosecurity operations face scrutiny from: regulators (aviation, pesticide), community stakeholders, program funders, interagency partners, media and public interest groups.

SkyGuard is designed so that every decision is traceable, every action is logged, and every claim is supported by documented evidence.

Immutable Event Logging

All operational events are recorded in an append-only log with hash chaining:

• Survey ingestion and QA attestation
• Registry match/create decisions
• Model version used for scoring
• Threshold snapshot used for queueing
• Batch approval actions (who/when/what)
• Mission package generation and release
• Execution logs and reconciliation deltas
• Verification outcomes and confounder flags

Implementation note: For Phase 1, the audit_event table with hash chaining provides the required immutability guarantees. Kafka or equivalent streaming infrastructure can be added in Phase 2 if real-time event processing or external integration requires it. The audit properties (append-only, hash-linked, tamper-evident) are preserved in either implementation.

Evidence Packets

Each treated palm produces a complete evidence packet containing:

• Palm ID and registry history
• Pre-treatment imagery and features
• Risk score with SHAP explanation
• Mission target record with constraints
• Execution trace excerpt
• T+30/60/90 verification outcomes

Data Integrity and Recovery

SkyGuard data is protected through layered backup and recovery mechanisms:

Full backup and recovery specifications in Appendix B.

System Boundary

SkyGuard provides detection, targeting, and verification. The following remain operator responsibility:

Appendix F: Validation Plan

This appendix provides detailed validation gates, evidence artifacts, and go/no-go criteria for each phase of SkyGuard deployment.

What "Ready" Means

SkyGuard is "ready for program use" when it produces decision-grade outputs on schedule, with known error bounds, and with defensible records.

Validation Phases

Phase 0: Bench Validation (4-8 weeks)

Exit criteria: Processing latency meets requirement; QA gates functional; audit log integrity verified.

Phase 1: Pilot Launch (Month 1-3)

Exit criteria: ≥95% coverage completion; processing latency stable; mission reconciliation within tolerance.

Phase 2: Verification Emergence (Month 4-6)

Exit criteria: Monthly outcome reports without manual rework; confounders documented.

Phase 3: Scale Proof (Month 7-12)

Exit criteria: Model improvement demonstrated; sustained operations with defined staffing; evidence quality supports public reporting.

Go/No-Go Decision Framework

Hard Stops

• Audit log integrity failure
• Unacceptable coverage gaps
• Credential/compliance failure
• Pipeline non-reproducibility

Performance Floors

• PPV minimum: <30% sustained → Halt operations
• Recall minimum: <70% sustained → Threshold adjustment required
• Verification missingness: >25% → Coverage remediation required

Appendix G: Implementation Stack

This appendix provides a reference implementation architecture and sprint-based development plan for engineering estimation.

Component Selection Matrix

Development Sprints (2-week cycles)

Sprint 0: Kickoff & Design

• Stakeholder workshops with municipal partners, pilots, applicators
• Sensor selection: RGB vs. multispectral decision
• Draft flight SOPs (altitude, speed, overlap, geofencing)
• Infrastructure selection: cloud vs. on-prem
• Define naming conventions for survey IDs, model versions
• Sketch initial database schema

Sprint 1: Data Plane Setup

• Provision object storage with access policies and lifecycle rules
• Deploy PostgreSQL + PostGIS; create base tables
• Implement event log (append-only table or Kafka)
• Write ingestion scripts (upload + log events)
• Configure automated backups and restoration runbook

Sprint 2: Photogrammetry Pipeline

• Containerize photogrammetry engine (Docker)
• Build ortho generation wrapper script
• Implement QA metrics: blur, exposure, coverage gaps
• Create attestation logging for audit trail
• Define reflight vs. accept thresholds

Sprint 3: Palm Detection

• Data annotation: label palm crowns in QGIS
• Train U-Net segmentation model (PyTorch)
• Package model for inference (TorchScript/ONNX)
• Build inference pipeline → crown polygons → PostGIS
• Implement registry insertion service

Sprint 4: Damage Classification

• Create labeled dataset: healthy / damaged / confounded
• Train CNN classifier (ResNet-50, transfer learning)
• Implement spectral index computation (GDAL/Rasterio)
• Integrate features into unified per-palm feature set

Sprint 5: Risk Scoring

• Assemble ~50 feature vector per palm
• Train XGBoost fusion model
• Apply isotonic calibration
• Integrate SHAP for explainability
• Implement configurable threshold + holdout logic

Sprint 6: Registry Matching

• Develop matching algorithm (spatial + shape + spectral)
• Handle merge/split cases with confidence scoring
• Implement registry update service with event logging
• Create unit tests with synthetic edge cases

Sprint 7: Mission Generation

• Implement clustering (DBSCAN / grid-based)
• Integrate routing optimization (OR-Tools)
• Define mission JSON schema with constraints
• Build mission generator service
• Create approval API endpoints

Sprint 8: API & Dashboard

• Design REST API (FastAPI) with OpenAPI spec
• Implement OAuth/JWT authentication + RBAC
• Build React frontend with routing and state
• Integrate Mapbox for spatial visualization
• Create approval screens and threshold controls

Sprint 9: Execution Logging

• Define execution log schema (GPS track, events, weather)
• Build upload API + CLI tool for applicators
• Implement reconciliation service (planned vs. actual)
• Create exception handling workflow
• Add execution stats to dashboard

Sprint 10: Verification & Outcome Tracking

• Add treatment tracking fields to palm table (last_treatment_date, last_treatment_id)
• Implement days_since_treatment calculation on each survey run
• Build window bucketing logic (T+30/60/90 based on actual elapsed days)
• Implement change detection: pre-treatment vs. current observation
• Build outcome classifier with category rules
• Add confounder detection (drought, storm, pruning flags)
• Generate evidence packets per treated palm
• Track "Not Yet Observable" status for recent treatments

Sprint 11: Model Maintenance

• Design stratified sampling for ground-truth
• Build PPV/recall/calibration dashboards
• Implement drift monitoring with alerts
• Automate retraining pipeline with MLflow
• Create canary deployment workflow

Sprint 12: Governance Hardening

• Implement hash-chained immutable audit log
• Finalize RBAC across all endpoints
• Compliance review with legal counsel
• Define data retention policies and scripts
• Document incident response procedures

Sprint 13: AI Query Interface (Phase 2)

Phase 2 enhancement—not required for core pipeline operations. Schedule after Phase 1 validation.

• Select and deploy local LLM (Llama 3 / Mistral, 7B-13B range)
• Set up inference server (vLLM or llama.cpp with GPU/CPU quantization)
• Build text-to-SQL layer for common query patterns (SELECT-only)
• Implement data grounding: inject query results into prompt
• Create narrative templates for standard summaries (zone, treatment, outcome)
• Implement query security: authorized views, audit logging
• Build export pipeline (narrative → PDF/CSV)
• User acceptance testing with program managers

Deployment Configurations

Docker Compose (Development)

services:
  db:
    image: postgis/postgis:15-3.3
    volumes: [pgdata:/var/lib/postgresql/data]
    
  minio:
    image: minio/minio
    command: server /data --console-address ":9001"
    
  api:
    build: {context: ., dockerfile: Dockerfile.api}
    depends_on: [db, minio]
    
  worker:
    build: {context: ., dockerfile: Dockerfile.pipeline}
    deploy:
      resources:
        reservations:
          devices: [{capabilities: [gpu]}]

Kubernetes (Production)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: skyguard-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: skyguard/api:latest
        resources:
          requests: {memory: 512Mi, cpu: 500m}
          limits: {memory: 1Gi, cpu: 1000m}

Cost Estimation (Fully Loaded)

Note: This estimate includes software licenses and higher storage/network assumptions. See Appendix B for cloud-infrastructure-only baseline.

Note: LLM query interface is Phase 2. Phase 1 focuses on core detection/treatment/outcome pipeline.

Build vs. Buy Summary

Core IP (Build In-House)

• Registry persistence and matching logic
• Risk scoring + threshold decision contract
• Verification and outcome classification
• Compliance-by-design mission packaging
• Immutable audit trail architecture
• Calibration sampling and drift monitoring

Commodity (Buy / Integrate)

• Photogrammetry engine
• Cloud infrastructure
• Mapping and visualization
• Routing optimization libraries

Appendix H: References

This appendix provides references supporting background claims and technical approaches.

CRB Biology and Impact

Bedford, G.O. (1980). Biology, ecology, and control of palm rhinoceros beetles. Annual Review of Entomology, 25(1), 309-339.

Gressitt, J.L. (1953). The coconut rhinoceros beetle with particular reference to Palau Islands. Bernice P. Bishop Museum Bulletin, 212.

Hawaiʻi Department of Agriculture (HDOA). CRB Response Program materials (various).

Remote Sensing and Tree Detection

Weinstein, B.G., et al. (2019). Individual tree-crown detection in RGB imagery using semi-supervised deep learning neural networks. Remote Sensing, 11(11), 1309.

Osco, L.P., et al. (2020). A review on deep learning in UAV remote sensing. International Journal of Applied Earth Observation and Geoinformation, 102, 102456.

Machine Learning Methods

Chen, T., & Guestrin, C. (2016). XGBoost: A scalable tree boosting system. Proceedings of KDD, 785-794.

Lundberg, S.M., & Lee, S.I. (2017). A unified approach to interpreting model predictions. NeurIPS, 30.

Ronneberger, O., et al. (2015). U-Net: Convolutional networks for biomedical image segmentation. MICCAI, 234-241.

Software and Tools

This reference list will be expanded as the program develops.