ReeferVision is an AI-first monitoring and automation platform for marine reef systems — beginning with serious reef keepers and designed to expand into commercial coral aquaculture. This page describes the proposed production platform that Google Cloud credits would help us build and validate. It is separate from the lightweight public website and pilot-interest form that support validation today. Where something is roadmap rather than running, we say so.
System overview
Three zones: an edge hub at each aquarium, a Google Cloud pipeline for ingestion, storage, and ML, and client apps for the people who own the tanks. Telemetry flows up over authenticated HTTPS; graded alerts and bounded, signed automation commands flow back down. Safety-critical actions remain on the hub so flood protection works without connectivity.
Beta transport: hub → authenticated HTTPS → Cloud Run → Pub/Sub. Cloud Run is not an MQTT broker. If the fleet later requires persistent bidirectional MQTT, a separate broker tier on GKE, Compute Engine, or a managed MQTT provider will be introduced without changing the downstream event pipeline.
Service mapping
| Service | Role in ReeferVision | Why this service |
|---|---|---|
| Cloud Run | HTTPS ingestion, alert grading, and command APIs. Stateless containers validate device signatures and schemas, publish accepted events, orchestrate inference, and expose command polling. | Request-based autoscaling suits a small beta fleet. The beta transport is HTTPS; raw MQTT would require a separate broker tier. |
| Pub/Sub | Durable event backbone. Shared topics for telemetry, frames, model results, and commands fan one event out to independent consumers. | At-least-once delivery keeps pipeline stages decoupled. Events carry immutable IDs for deduplication; optional ordering uses the tank ID as the ordering key. |
| BigQuery | Historical telemetry warehouse. Readings are partitioned by observation time and clustered by organisation, tank, and sensor. BigQuery ML builds per-tank baselines and short-horizon forecasts. | SQL-first analysis lets a small team validate useful statistical models before moving only workloads that need custom ML into Vertex AI. |
| Cloud Storage | Frame archive and training datasets. Short-lived, object-specific signed URLs let hubs upload camera frames without receiving broad bucket credentials. | Lifecycle rules control retention and cost; object events can queue new frames for inference and annotation. |
| Vertex AI | Coral-vision training and inference. Transfer learning on consented, annotated beta frames; model registration, evaluation, batch scoring, and online endpoints where latency justifies them. | Managed training and serving reduce MLOps overhead. Evaluation is separated by tank and time window to prevent neighbouring frames inflating accuracy. |
| Firestore | Canonical live app state. Latest readings, active alerts, maintenance state, and command acknowledgements sync to authorised clients in real time. | Firestore serves current product state; BigQuery remains the system for complete high-frequency history. |
| Firebase Auth | Human identity. Owner, technician, and facility-operator sign-in, with tokens used by the API and Firestore Security Rules. | User authentication is kept separate from hub identity so people and hardware have different privileges and revocation paths. |
| FCM | User notification channel. Sends a compact graded-alert notification containing an alert ID to iOS, Android, and web clients. | FCM prompts the app to fetch the canonical Firestore alert; it is never the safety-control or automation-command channel. |
| Firebase Hosting | Web dashboard delivery. CDN-backed hosting for the future authenticated dashboard's static assets. | Keeps client delivery simple while Cloud Run remains responsible for trusted backend logic. |
| Secret Manager | Server-side secrets. Third-party API keys, webhook credentials, and other secrets used by trusted cloud workloads. | Hub private keys stay on the device, preferably in secure hardware; they are not distributed from Secret Manager. |
| IAM | Least-privilege cloud access. A separate service identity and narrowly scoped role for each pipeline stage. | A compromised service should not gain broad access to telemetry, users, models, storage, or signing operations. |
| Cloud KMS | Command signing. Protects the asymmetric cloud signing key used for bounded automation commands. | The hub verifies the signature, expiry, command ID, and local safety envelope before acting; the private cloud key is not exposed to application code. |
| Monitoring / Logging | Operational evidence. Structured logs, metrics, uptime checks, SLOs, and alerts for hub silence, ingestion latency, backlog, model failures, and unacknowledged commands. | A monitoring product must detect when its own data path is unhealthy, while excluding device secrets and unnecessary personal data from logs. |
Data flow
ML approach
We are pre-launch. The roadmap below is staged so the product is useful from day one with statistics, and the AI deepens as the beta fleet generates training data — every annotated frame and labelled incident from beta tanks feeds the next model iteration.
Per-tank baselines and drift detection in BigQuery ML: resampled pH and temperature cycles, dosing rhythms, evaporation curves, prediction intervals, and sensor cross-validation. No deep learning is required to deliver the first useful warnings.
Transfer learning on a vision backbone, fine-tuned with consented, annotated frames from beta tanks: polyp extension, colour shift, and tissue recession against each colony's history. Validation holds out whole tanks and time windows; success is measured by precision, recall, calibration, and false alerts per tank-week.
Opt-in, anonymised cross-tank learning: equipment failure signatures (heater oscillation, pump wear), bad-batch detection for consumables, and richer priors for every new tank's cold start.
These are workload units, not a claim that 100 tanks are already deployed. The application cost model will combine the beta ramp with measured event size, average frame size, retention, training frequency, and chosen Vertex AI serving mode.
Beyond the hobby
The same pipeline monitors a 200 L living-room reef and a 40-raceway coral aquaculture facility — the difference is fleet size, not architecture. Commercial coral farming, public aquaria, and reef-restoration nurseries all run the same loop: water chemistry, livestock health, equipment, intervention. Shared Pub/Sub topics carry organisation and tank identifiers; BigQuery partitions history by observation time and clusters it by organisation, tank, and sensor. A facility is therefore many authorised tanks under one organisation, without creating a topic or table for every tank or re-platforming the core pipeline.