Engineering / implementation notes
The handoffs are part of the product.
From a shape on an image to a job on a customer-owned GPU, useful software depends on explicit boundaries. These notes explain the data paths, control paths and recovery choices inside software built at AlgoFly.
Engineering by Nitin Rai at AlgoFly. Follow each design through its product page and implementation article.
01 / Vision data
Keep the label attached to the pixels it describes.
DataHub treats an annotation as image-relative data. Canvas editing, saved geometry and dataset exports share a source identity, so a visually correct shape cannot silently become a label for different pixels.
- 01
Image source
Pixels + source revision
- 02
Annotate
Boxes, polygons, masks and points
- 03
Review
Committed labels versus live previews
- 04
Version
Selected data, classes and splits
- 05
Export
Target-specific geometry contract
- 06
Consume
Trainer, SDK or downstream tool
Why this boundary exists
Separate collaborative previews from committed annotations. Source-image changes stage pixels and thumbnails, then validate the associated geometry before publication.
What to account for
Format support is explicit. A detection export does not preserve every mask, hole, pose or OCR field.
02 / Customer-owned compute
Run the workload on your own GPU workers.
A DataHub worker is a customer-controlled machine running the agent and Docker. It connects outbound to the gateway, reports its hardware and claims authorized work. It does not need an inbound public worker port or PortHub to receive jobs.
- 01
Project run
Version, export and configuration
- 02
Gateway
Authorization + admission checks
- 03
Outbound agent
Heartbeat and compatible job claim
- 04
Local Docker
Pinned environment + working data
- 05
Delivery
Logs, checkpoints and artifacts
- 06
Run record
Acknowledged outputs and status
Why this boundary exists
The application owns experiment identity; the worker supplies compute. Registration binds a worker credential to an agent instance. A fresh capability report and resource admission determine whether a job can start. Claim tokens and epochs fence worker updates.
What to account for
Source-reviewed capability; no live worker fleet or available capacity is asserted here. Several workers can execute separate jobs or sweep trials. Connecting them does not automatically distribute one training run across machines. CUDA support depends on the device, driver, runtime and recipe.
03 / Model operations
Make training and evaluation inspectable handoffs.
Training references a prepared dataset and a configured environment. Artifacts remain connected to their run; conversion and evaluation check the identity and shape contracts they need instead of assuming any model file is interchangeable.
- 01
Dataset version
Frozen selection and class meaning
- 02
Run submission
Configuration + retry identity
- 03
Worker claim
Fenced execution ownership
- 04
Artifacts
Outputs with checksums and lineage
- 05
Convert / infer
Adapter and target constraints
- 06
Evaluate
Held-out data + explicit class map
Why this boundary exists
Keep admission estimates separate from the saved configuration. Treat compute completion and output delivery as different stages so a network interruption does not automatically justify repeating compute.
What to account for
Evaluation and conversion support is adapter-specific. Available CPU execution does not imply a CPU fallback for every GPU recipe.
04 / Private connectivity
Resolve the machine. Authorize the application.
PortHub’s Linux private runtime combines virtual addresses and private names with explicit application access. ICE-selected paths and certificate-pinned DTLS carry private traffic; gateway compatibility paths have their own transport boundary.
- 01
Enrolled identity
Machine + application grants
- 02
Private name
Resolve an owned destination
- 03
Policy
Compile permitted routes
- 04
ICE negotiation
Candidate and reachability checks
- 05
DTLS path
Pinned peer transport
- 06
Flow routing
Route selection and relay fallback
Why this boundary exists
A reachable peer is not automatically an authorized service. Existing flows retain their selected route while background quality observations can inform new flows.
What to account for
This describes the implemented Linux private runtime. It is not a claim that every operating system or every WAN topology has identical support.
05 / Public forwarding
Keep the payload out of the database.
PortHub embeds Rathole-compatible public forwarding in its Rust gateway. An agent opens a tunnel over the existing HTTP(S) listener; the edge streams service payloads between sockets.
- 01
Local service
Application on an owned machine
- 02
Native agent
Embedded forwarding session
- 03
HTTP(S) tunnel
WebSocket control / transport
- 04
Rust edge
Pooled data connections
- 05
Published route
Assigned port or web binding
- 06
Visitor
Explicitly exposed application
Why this boundary exists
MongoDB and Redis support control-plane state; they do not carry the forwarded payload. Configuration reloads can remove services and revoke tokens without restarting unrelated services.
What to account for
Rathole compatibility is embedded in the gateway and agent. It does not require a separate Rathole executable, and public forwarding is distinct from private-peer ICE route selection.
06 / Edge observations
Separate an empty room from a silent sensor.
HomeSense connects supported mmWave sensors, ESP firmware and MQTT observations to a presence state machine. A transport message carries enough freshness information to distinguish a new physical sample from a repeated packet.
- 01
mmWave sensor
UART presence and range
- 02
ESP firmware
Parse and track actual samples
- 03
MQTT snapshot
Boot, sequence, age and health
- 04
Server state
Occupancy and health separately
- 05
Home profile
Context and approval gates
- 06
History
Presence, events and energy views
Why this boundary exists
Do not turn sensor silence into a confident occupancy conclusion. Profile and approval logic sits above observations; energy views add context without making every device a control target.
What to account for
Sensor support and timing preferences are installation-specific. This is an engineering architecture, not a safety certification or a promised detection accuracy.
07 / Audio and input
Stream the audio; recognize complete phrases.
Voice Keyboard sends continuous PCM transport chunks from the browser. Silero VAD chooses utterance boundaries; completed utterances become ordinary Whisper transcription requests before text is joined and routed to a selected receiver.
- 01
Browser audio
16 kHz mono PCM
- 02
Transport chunks
Continuous binary audio
- 03
Silero VAD
Speech and utterance boundaries
- 04
Whisper request
Queued WAV transcription
- 05
Text joiner
Context and seam handling
- 06
Selected receiver
Desktop input or ESP32 keyboard
Why this boundary exists
Transport streaming and recognizer-token streaming are different mechanisms. A shared inference semaphore controls model concurrency, while room and receiver selection determine where input goes.
What to account for
The inspected implementation uses utterance-level recognition. It does not implement speculative Whisper token streaming or a stable-prefix overlap decoder. The inference semaphore limits model concurrency; it does not by itself bound the utterance backlog.
Bring the system boundary into the conversation.
Start with your data, existing infrastructure and the decisions your users need to make. We can discuss what belongs at the edge, on your machines and in the application.