Port Drone Watch: From Oil Sheen to Dispatched Work on the Port's Own Hardware in Germany

Hours of Drone Imagery Answer No One's Question

The authority already flies drones that produce hours of imagery a day across two port sites, yet the question that matters, what is happening right now and who should respond, goes unanswered because the footage outruns every pair of human eyes.

The abstract promised a port authority turning its existing drone flights into detections, dispatched work and a living map, entirely on its own hardware. This chapter states the question that promise answers, the documented cost of leaving it unanswered, and the scenario the design serves.

1.1  The Question and the Ground It Stands On

The authority needs one question answered continuously across its two port sites: what is happening right now, where exactly is it happening, and which named person should respond. Answering it requires data the operation already holds in fragments: hours of drone imagery and still images produced every day by scheduled and on-demand missions, the berth plan and asset register held in its geographic information system, the vessel traffic picture from the automatic identification system (AIS) and the vessel traffic service (VTS), its works records, and the weather observations that decide whether a flight can launch at all. Three regulatory regimes frame every part of the answer. Flights run under the European specific category drone rules, under which operations beyond the open category require operational authorisation tied to assessed risk, so every mission carries a flight authorisation reference and a geofence. Some zones sit inside Seveso perimeters, the European major-hazard regime around sites holding dangerous substances, which imposes approval requirements and responder-within-minutes rules the design must route detections around. And because the cameras photograph people, the whole imagery pipeline stands on the General Data Protection Regulation (GDPR), the European data protection framework: persons in restricted zones are detections to act on and personal data to process lawfully, with retention, signage and a processing map as first-order requirements, not afterthoughts.

1.2  The Documented Cost of Not Knowing

The cost of an unanswered waterline is documented, and it is measured in lives and fines. A peer-reviewed Bayesian network analysis of 505 maritime occupational accident cases traces how such accidents arise (Yu et al. 2025), and the US safety institute NIOSH holds that marine terminal and port workers carry higher fatality, injury and illness rates than other workers (CDC 2024). Pollution carries its own ledger: a shipping company was fined 2 million dollars for a maritime pollution offence in a single prosecution (US Department of Justice 2025), and a US safety investigation established the probable cause of a bulker's crash into a barge (TradeWinds 2021). Against that background, oil sheen that drifts for a day before anyone reviews footage, a person in a restricted zone noticed only in yesterday's recording, and quay damage found at annual inspection rather than at the next flight are not inefficiencies; they are latent incidents. The International Labour Organization now maintains an experimental global register of fatalities at sea covering occupational accidents, persons overboard and health-related deaths (ILO 2025), which is the scale of loss the register exists to reduce.

1.3  The Operation as a Scenario

The operation is a maritime and ports authority in Germany running two port sites, two places with distinct traffic, quays and hazard perimeters. Its drones are a docked network: aircraft that live in automated stations and launch on a schedule or on demand, flown by a retained drone operator under the European specific category. The fleet carries several payload classes, among them a patrol nadir camera, a berth survey camera and an incident response camera, with a thermal payload held as a named annual trial rather than day-one scope. Missions produce hours of imagery and still images every day, in salt air, wind and visibility conditions that ground flights and open multi-day coverage gaps. The people in the loop are few and named by role: flight approvers who grant authorisations, responder roles that own detection classes by domain, security, inspection, spill and vapour response, with shift cover and escalation paths, and the drone operator's own crew. The design draws on five source systems, four of them the port's own or its operator's, and produces eight detection classes: oil sheen, floating debris, moored vessels, berth occupancy, open gates, persons in restricted zones, fender or bollard damage, and smoke or vapour. The chapters that follow turn those flights into answers.

The Drone Footage Never Meets the Berth Plan

The mission system, the GIS berth plan, the vessel traffic feed and the responders' work systems each hold one slice of the port, and the join none of them can make is exactly where oil sheen, trespass, occupancy mismatch and quay damage live.

Chapter 1 set out the question. This chapter explains why no system the operation already runs can answer it.

2.1  What Each System Sees

Port GIS berth plan and asset register the living map builds on the port's own spatial data, which is partial and inconsistent; this project standardises it and publishes the governed layer back

Drone operator mission and fleet system existing docks and drones are retained and integrated, and 'mission data landing in the port's own systems' is a stated requirement

Responders' existing work systems hybrid, as the intake settled it: this system owns the work item and pushes records to the responders' existing systems

Vessel traffic feed (AIS/VTS) moored vessel and berth occupancy detections are checked against the authority's own vessel picture rather than imagery alone

2.2  What None of Them See Together

Each holds one slice, and the question needs all of them in one place at once, which today is done by hand at the cadence of whoever has the time.

Sovereignty and Seveso Shape Every Downstream Choice

Port-owned hardware, the European specific category drone rules, Seveso perimeters and GDPR together force the design's scoping decisions, each of which buys something and costs something this chapter prices in the open.

Chapter 2 showed that the failure is a join failure, not a data failure. This chapter states the goals that shape how the design makes that join, and prices the scoping decisions each goal forces.

3.1  Everything Runs on the Authority's Own Hardware and Survives a Change of Drone Operator

The first constraint is ownership: all compute sits inside the port authority's own environment on its own hardware, and mission data lands in the port's own systems. This is hard in this industry because the drone operator naturally holds missions and imagery in its own estate, and a six-year service will outlive operator contracts. Sovereign here means self-hosted, not small: the design runs per-frame detection at the dock, reasoning on port servers, and the imagery, the models and the detection history belong to the port, so a change of drone operator is a data-handover event the exit obligations are written around, not a rebuild.

3.2  Every Detection Becomes a Work Item with a Named Responder

The second constraint is the loop: people decide every response, and the platform proposes and records. It is hard because responders already live in their own work systems, so the design must own the work item, with its evidence frames, confidence, location and responder finding, and push records outward rather than demand that responders move. The acknowledgement is itself a decision object with reason codes, because the responder's finding is the most valuable data the loop collects.

3.3  Flights Obey the Specific Category and Seveso Perimeters

The third constraint is flight law: every mission runs under the European specific category with an authorisation, a geofence and zones whose approval requirements and responder-within-minutes rules the dispatch logic must honour, and some of those perimeters are Seveso sites. This is hard because the rules bind the design's own plumbing: a detection inside a Seveso zone cannot wait in a generic queue, and a weather grounding must publish what the gap blinded, not leave silence that reads as an absence of findings.

3.4  Persons in Frame Are Governed by GDPR

The fourth constraint is data protection: there is no domestic licence for camera use, and persons in frame are personal data from the moment of capture. This is hard because the simplest architecture, streaming everything and keeping everything, is unlawful. The processing map, retention covenant and signage are first-phase deliverables, retention defaults to days with automatic, demonstrable deletion, and the design improves through memory rather than weight training, so no responder finding ever becomes a training corpus.

3.5  Scoping Decisions Priced in the Open

Three scoping decisions follow from these goals, and each buys something at a stated cost, set out in Table 1.

3.6  What the Design Chose Against

The design also chose against alternatives, each for a stated reason, set out in Table 2; the out-of-scope entries close the list.

One Stack Runs From the Docks to the Decisions

Systems of record stay below, one object model sits in the middle, and five services and eight surfaces sit above, with detection at the dock edge, zero-shot reasoning on port servers and the work surface in the port's own data centre.

The constraints in Chapter 3 fixed the ground: everything runs on the port authority's own hardware, the port's systems stay authoritative, people decide every response, and the service must survive a change of drone operator. This chapter sets the architecture that satisfies all four at once, by placing one object model between the systems the port already runs and the surfaces its people already work at.

4.1  The Pattern and Why It Fits

The pattern is three bands. Below sit the systems of record: the port GIS berth plan and asset register, the drone operator's mission and fleet system, the responders' existing work systems and the vessel traffic feed, each kept exactly where it is, each read and never replaced. In the middle sits one object model, Hyper Ontology v0.9, holding fifteen objects and their typed links. Above it sit five services and eight surfaces, and beside them the agentic work surface where responders and operators ask questions of the map and its memory. The ontology sits beside the systems of record, never in front of them, so the port's GIS and the responders' systems remain the masters of their own facts and the ontology is a governed projection.

Inference is placed in three tiers rather than one. The dock edge box runs per-frame closed-set detection, because hours of daily video cannot cross the dock uplink and detection must survive an uplink loss. The port's site servers run zero-shot passes and evidence triage on selected frames. The port's own data centre runs the frontier work surface model on one node of eight GPUs of the 141 GB class. Figure 3 shows the layers with their counts: five sources, one adapter family, fifteen objects, five services, eight surfaces and five models.

4.2  The Stack Stage by Stage

Table 3 walks the same stack stage by stage, naming the component responsible at each stage, so an engineer can trace any guarantee to the part that provides it.

Fifteen Objects Turn Drone Frames Into One Argument

Fifteen objects and their typed links let a query walk from a frame to a detection to a berth to a responder role, a journey across mission, asset, actor and record that no document store can make.

The stack placed one object model at its centre and named it as the place where the port's argument is held. This chapter opens that model: fifteen objects, their typed links, the human loop that lives inside them and the posture that keeps them the port's own.

5.1  Every Object and the Links Between Them

The fifteen objects divide into six kinds. Two are events: Mission and Construction Work. Four are records: Detection, Work Item, Flight Authorisation and Coverage Statement. Three are sites: Berth, Dock Station and Restricted Zone. Three are assets: Vessel, Quay Asset and Drone. Two are actors: Responder Role and Drone Operator. One is a measure: Weather Observation. Figure 4 shows every object and every typed link between them, with the Mission object, the one the most links reach, in focus.

The links are what make the model an argument rather than a filing system. A Mission is launched from a Dock Station and crosses Restricted Zones under a Flight Authorisation. A Detection is produced by a mission and carries its frames and timestamps. A Work Item is dispatched to a responder role. A Vessel occupies a Berth, and the Berth sits on a Quay Asset, and Construction Work progresses on that same quay. A Coverage Statement declares which detection classes a weather grounding blinded, so an absence of findings is never mistaken for an absence of events. This matters because port work is dangerous work: workers in marine terminals and port operations have higher fatality, injury and illness rates than other workers (CDC 2024), and a damage finding that cannot reach a named responder is a finding the port does not have.

The payoff is the query. When an operator asks what changed on a quay since last week, the walk goes from the Quay Asset to its Berths, to the Vessels occupying them, to the Construction Work recorded against it, to the Detections confirmed on it, to the responder findings behind each, all in one traversal across mission, asset, actor and record. A document store cannot make this journey: it can find documents that mention the quay, but each hop to the vessel, the work package or the responder is another lookup with no guaranteed linkage, and the joins must be written in advance for every question rather than expressed once as typed links.

5.2  The Human Loop and the Hosting Posture

The human loop lives in the status vocabularies. A Detection is Proposed until a responder confirms it, rejects it or merges it with an earlier finding. A Work Item is Dispatched, then Acknowledged with reason codes, then Resolved or Closed no action. Acknowledgement is itself a decision object, so acknowledge rate, ignore rate and action rate are measurable from the first week, and the disagreement path is built before the agreement path. The system proposes and records; people decide every response, and its automatic acts are limited to confirmation re-flights and notification escalation.

The hosting posture follows the constraints. Every object, every frame and every model runs on the port authority's own hardware inside its own boundary. Identity is issued through Keycloak to named people in named roles. The single external link is the controlled ingest of the drone operator's mission data. The one write path into the object model runs through the adapter tier and the surfaces used by authenticated responders. The loop learns from what responders found through agentic memory, never by training weights, so the detection history and the improvement both belong to the port and survive a change of drone operator.

5.3  One Object in Its Recorded Form

The Mission object, in its recorded form, shows how the model carries the dock station, the flight authorisation, the zones crossed and the imagery hours behind every flight.

{ "id": "mission", "label": "Mission", "kind": "event", "anchored_in": "The drone operator's mission and fleet system", "properties": [ "Scheduled or on demand", "Dock Station", "Flight authorisation reference", "Geofence zones crossed", "Imagery hours produced" ], "status_vocabulary": [ "Planned", "Authorised", "In flight", "Complete", "Aborted", "Grounded by weather" ], "links": [ { "to": "dock-station", "label": "launched from" }, { "to": "restricted-zone", "label": "crosses" }, { "to": "flight-authorisation", "label": "authorised by" } ] }

Every Source Enters Through an Adapter, Never Directly

Five named source systems, from the drone operator's mission and fleet system to the vessel traffic feed, reach the object model only through the integration adapter family, which holds the guarantees the port's own systems stay authoritative.

Chapter 5 described what the object model holds and who writes to it. This chapter describes how data gets there: five named source systems, one adapter family, and an event backbone that keeps every frame, event and record ordered, timestamped and replayable.

6.1  Five Sources and Their Provenance

Five source systems feed the model, and Figure 5 maps each to its provenance class and its adapter path. The port GIS berth plan and asset register is an authority-provenance source, read only: the living map builds on it, and this project standardises it and publishes the governed layer back, so the port's own spatial data becomes the deliverable rather than being replaced by a bought one. The drone operator's mission and fleet system is an authority-provenance source, read only: the docks and drones are retained, and mission data landing in the port's own systems is a stated requirement, so flights, telemetry and imagery flow in through a controlled ingest. The responders' existing work systems are authority-provenance, read for status: this system owns the work item and pushes records out to them, so responders keep working in their own tools. The vessel traffic feed, AIS and VTS, is domain-typical provenance, read only: moored vessel and berth occupancy detections are checked against the authority's own vessel picture rather than imagery alone. The fifth source, the port's works register and weather feed, has its provenance confirmed at the interface survey before it is committed.

6.2  What the Adapter Tier Guarantees

One family, the integration adapter, stands between every source and the object model, and it carries five guarantees. First, authority: the port's systems remain the masters of their facts, and the ontology is a projection, so a berth plan revision in GIS supersedes the projected berth, never the reverse. Second, provenance: every event is stamped with its source system and provenance class, so any detection can be traced to the mission, frame and model version that produced it. Third, isolation: schema drift in a source is absorbed in the adapter, not in the object model. Fourth, replay: because adapters write to the log, any object can be rebuilt from recorded events. Fifth, fallback: if the drone operator's interfaces prove closed or undocumented, an interface survey in the first workstream either opens them or falls back to dock-side capture of the video stream with telemetry by file drop, and the guarantee that mission data reaches the port's own systems holds either way.

6.3  The Event Backbone

Apache Kafka 4.3, running in KRaft mode without a separate coordination service, is the backbone every adapter writes to. Ordering is per partition key: events for one mission and one asset are strictly ordered, which is what lets a detection cite the frame that produced it and a work item cite the detection. Delivery is at-least-once, and writes into the object model are idempotent, keyed on mission and frame timestamps, so a replayed event creates no duplicate detection. Buffering lives at the dock: the edge box under K3s retains events and MediaMTX recordings locally through an uplink loss, so detection continues and the backlog resynchronises when the link returns, which is the doctrine that detection survives an uplink loss. Replication runs between brokers in the port's own data centre, inside the boundary. Model and artifact updates arrive through Harbor as an air-gapped registry, so nothing enters by ad hoc transfer. All of it rides one clock: linuxptp with chrony, disciplined by an OCP Time Card grandmaster, keeps drone frames, telemetry and vessel traffic records aligned, and Prometheus, Grafana and Loki watch the backbone's lag and health so a silent gap becomes an alarm, not a coverage hole discovered later.

Detection Belongs at the Dock, Reasoning on Port Servers

Per-frame closed-set detection runs on the dock's edge box because pixels cannot cross the uplink and detection must survive its loss, while zero-shot passes, evidence triage and the frontier work surface run on the port's own servers under an explicit latency budget.

Chapter 6 described how every source enters through the integration adapter, so that missions, imagery references, vessel positions and responder records all arrive as governed events in one backbone. This chapter describes where the thinking happens: which model runs on which tier of the authority's own hardware, how fast each answer must arrive, and what survives when the dock's uplink, its power or its update path fails.

7.1  Three Tiers and the Arithmetic That Places Them

The design runs inference on three tiers, and Figure 6 sets them side by side. The first tier is the dock's edge box, an edge AI compute module of the GPU class sized by the dock site survey against salt air, wind and temperature. It runs the per-frame closed-set detector, RF-DETR, over the retained drone fleet's camera streams for moored vessels, buoys, persons, vehicles and gates, together with the Roboflow trackers for motion and association, all orchestrated as containers under K3s with MediaMTX handling ingest and recording. Per-frame detection belongs here for one reason: hours of video and still imagery every day cannot cross the dock uplink, so the pixels are examined where they land and only events and evidence crops travel onward.

The second tier is the site server at each port site, running one to four cards of the 48 GB PCIe inference server class, air-cooled. It runs OWLv2 for zero-shot, open-vocabulary passes over selected frames, covering oil sheen, floating debris, smoke or vapour and damage cues, and Ministral 3 8B under vLLM for evidence-crop triage and work item drafting. Ministral 3 8B at FP8 occupies about 12 GB, which fits the 48 GB card with room for concurrent requests; it is treated strictly as a describer and reader of evidence, never a localiser, because position comes from drone GNSS telemetry resolved against the standardised berth plan.

The third tier is the central node the authority owns: one node of eight GPUs of the 141 GB HBM class, 1,128 GB in total, running GLM 5.3 as the agentic work surface over the ontology and memory. The sizing line is explicit: 753 billion parameters at FP8, one byte per parameter, is 753 GB of weights; the 1.2 planning factor for KV cache and activations raises the requirement to 904 GB; the node's 1,128 GB holds it, leaving roughly 375 GB beside the weights for KV cache and activations.

7.2  The Latency Budget

The budget is stated as three classes of answer rather than one number. Per-frame detection must keep pace with the camera stream itself, because a detector that falls behind the frames it is given produces a delayed picture of a moving port. Detection-to-dispatch for persons in restricted zones and Seveso perimeter events carries the responder-within-minutes rule, and the design routes those work items by the zone's own rule; the stakes behind that budget are documented, since workers in marine terminals and port operations carry higher fatality, injury and illness rates than other workers (CDC 2024). Queries on the work surface, such as what changed on a quay since last week, are answered at conversational speed from the ontology and memory on the central node.

7.3  What Crosses the Boundary, and What Fails Gracefully

What crosses the network boundary is deliberately small: detection events, evidence crops, telemetry and health signals cross it; pixels do not. When the uplink fails, the dock keeps detecting, and the Kafka backbone buffers events on the dock side for delivery and resynchronisation when the link returns. When power fails, Network UPS Tools with the IP-rated dock enclosure and PoE budgeting carries the edge box through the interruption and reports its state. When the update path fails, the air-gapped Harbor artifact and model registry on the authority's own infrastructure holds the last good versions, and the site falls back to them rather than to silence. Weather grounding is treated the same way honestly: each grounding day publishes a coverage statement naming the detection classes that went blind, so responders never mistake a coverage gap for an absence of findings.

Open Licences Decide What the Port Can Own

Five models, four under Apache 2.0 and one under a bespoke licence that permits the authority's internal use, run entirely on hardware the authority owns, so no weight, no frame and no detection record ever leaves with a change of drone operator.

Chapter 7 placed each inference tier on the authority's own hardware and drew the latency budget each answer must meet. This chapter names the five models that occupy those tiers, states the licence behind each one, and shows in Figure 7 and Table 4 why every choice leaves the authority holding its own weights, its own frames and its own detection history.

8.1  Five Models and the Licences That Let the Port Own Them

Figure 7 stacks the five models against their tiers. GLM 5.3 is the frontier model of the register, 753 billion parameters served at FP8, and its role is the agentic work surface and ontology maintenance on the central node. Its bespoke licence grants commercial use, fine tuning and redistribution, with a security-review trigger that applies only to model-as-a-service operators above 10 billion US dollars in group revenue, a threshold far above a port authority's purely internal use. It was chosen because the requirement's own words commit a command centre where people decide every response and operators can ask what changed on a quay, and under the pinned system of context architecture that surface runs on the ontology and memory rather than on any external service.

RF-DETR runs per-frame closed-set detection on drone imagery at the dock, covering moored vessels, buoys, persons, vehicles and gates. Its Apache-2.0 licence allows the authority to hold and redistribute the weights outright, and its checkpoints are small: about 61 to 68 MB at 16 bit from Nano to Large, about 254 MB for 2XL. OWLv2 carries the zero-shot open-vocabulary role on the port's site servers, detecting oil sheen, floating debris, smoke or vapour and damage cues on selected frames without port-specific training; it is Apache-2.0 as well, at about 310 MB for the base checkpoint and about 875 MB for the large at 16 bit. Ministral 3 8B drafts work item text beside the evidence frames at the site tier; it is Apache-2.0 from a European publisher, a deliberate fit for an EU public buyer, occupies about 12 GB at FP8 on the 48 GB PCIe class, and is bounded as a describer and reader, never a localiser. Roboflow trackers complete the stack at the dock: clean-room SORT, ByteTrack, OC-SORT and BoT-SORT implementations behind one Apache-2.0 interface, chosen on the port's own labelled drone clips, doing motion and association only with no re-identification branch.

8.2  The Model and Equipment Register

Table 4 gathers the models, the hardware classes and sizing rules, the sensing, the patterns the design stands on, and the ground it runs on, so that the authority can audit every row as a thing it holds. The pattern rows matter as much as the model rows: system of context is the pinned primary architecture, memory rather than weight training is how the loop learns, and the rule that events and evidence crops cross the boundary while pixels stay at the dock is what makes the whole register operable.

Pilot Flights Come Before Any Detection Is Trusted

Four phases carrying twenty items move the service from two pilot missions on the port's own imagery to a six-year operation, and no detection class rolls out below its measured floor.

Chapter 8 fixed the model register and the licences that let the authority hold its own weights. This chapter lays out the path from two pilot missions on the port's own imagery to a six-year operation: four phases carrying twenty items, a gate on each phase that can stop the work cheaply, and the measurements that decide whether any detection class earns the responders' trust.

9.1  Four Phases, Twenty Items, Four Gates

Phase 1 carries ten items across four workstreams: detection-to-dispatch, the flight-to-detection pipeline, the living map and port standards, and the responder loop and learning. Its items include standing up agentic memory over responder outcomes, standardising the berth plan and asset register for the quays the pilot missions cover, and mapping responder roles with their dispatch rules. Its exit gate is the dock-side edge inference hardware in place. Phase 2 carries four items across three workstreams and rolls out the first port site's mission set; its items include geofencing the Seveso perimeters with gate approvals and routing Seveso detections to a responder within minutes. Phase 3 carries four items across four workstreams: extending detections to the second port site, pushing work records into the responders' existing systems, and learning from what responders found. Its exit gate is port ownership secured through a supplier change. Phase 4 carries two items across the responder loop and the sovereign platform workstreams: running annual trial projects, beginning with the thermal night payload, without rebuilding the platform, and operating the six-year service on the port authority's own hardware. Figure 8 sets the four phases side by side with their item counts, workstreams and gates. Requirement coverage is complete: of the four requirements in the authority's ask, four are covered in full, none partial and none a gap.

9.2  What the Rollout Measures

Pilot acceptance is measured on the port's own two missions, because pretrained and zero-shot detectors are unproven on this port's imagery until its own drones fly it. No detection class rolls out below its measured floor, and the floor must hold under drift with an operator-owned tuning path. On the responder side, acknowledgement is a decision object with reason codes, so the acknowledge rate, the ignore rate and the action rate are reported from the first dispatched work item onward; the disagreement path is built before the agreement path. Weather grounding days are measured honestly through the pilot, and every gap publishes a coverage statement naming its blind classes, so a grounded fleet reads as a coverage gap rather than an absence of findings. Berth occupancy detections are checked against the authority's own vessel picture rather than imagery alone.

9.3  Failure Modes

Each failure mode below has a designed answer, and the answers are items inside the phases rather than promises beside them, as Table 5 records.

9.4  Lessons

Publish the gaps you cannot fly through. A detection system that goes quiet in bad weather teaches responders to read silence as safety, so the coverage statement is a first-class object with its own status vocabulary, published by default and superseded only by a newer statement for the same area and period.

Measure acceptance on the authority's own imagery. Vendor benchmarks on other ports' footage settle nothing here, which is why the pilot's two missions on this port's own quays are the acceptance basis and why every rollout is tied to a measured floor rather than a claimed one.

Make acknowledgement a decision, not a reflex. Responders in port operations already carry higher fatality and injury rates than most other workers (CDC 2024), so a work item that is rubber-stamped wastes their attention and corrupts the loop the service learns from; reason codes on every acknowledgement keep the learning honest.

9.5  What Is Still Open

Three questions remain open. The weather source is to confirm, either the port's own weather station or the national meteo service, and settling it fixes the go or no-go basis recorded on every weather observation. The works register and the vessel traffic system are both to confirm as sources, and settling them decides whether construction work and vessel objects are anchored in live feeds or in opening balances. The edge silicon and its serving runtimes are fixed only at the dock site survey, and settling that question fixes the per-frame detection budget at the dock. None of the three blocks the pilot; each blocks a later phase, which is why each sits behind a gate.

The Detection History Survives a Change of Operator

The authority owns the object model, the open weights, the imagery and the full decision record, and the drone operator object carries the exit handover obligations that make a supplier change a non-event for the service.

Chapter 9 showed how the service earns trust phase by phase and what each gate measures. This chapter settles the question the gates protect: who owns what the service produces, and why a change of drone operator is a contract event rather than a rebuild.

10.1  Who Owns What the Design Builds

The object model is the authority's. Its fifteen objects, the typed links between them and the standardised berth plan they sit on are built from the port's own GIS data inside this project, and the governed layer is published back to the port's systems as its own spatial standard, so the living map is a port asset and not a vendor fixture. The weights are the authority's. Every model in the register arrives under a licence that permits the port to hold and run it: the vision detectors and the site-tier language model under Apache 2.0, the frontier work-surface model under its bespoke licence with commercial and internal use granted. Nothing is trained into weights under the pinned architecture, so there are no fine-tunes to lose or re-license; every threshold, routing rule and confidence band lives in memory as data the port owns and can export. The decision record is the authority's. Every detection with its frames and confidence, every work item with its named responder and finding, every flight authorisation and every coverage statement is a recorded object, and the six-year history they accumulate is the evidence base the next decision reads. The boundary is the authority's. All processing runs on the port authority's own hardware inside its own environment; imagery crosses no external service, retention defaults to days with automatic deletion, and the processing map is a phase-one item rather than a later disclosure. The drone operator object carries the exit obligations that make this hold: the operator's name, the authorisations held under the European specific category, the contract end date and the exit handover obligations, with a status vocabulary that moves from in contract through notice period to changed. When it changes, the missions, drones and stations change with it; the detections, the responders' findings and the map they are anchored to do not.

10.2  The Offer Behind the Design

CodeNinja builds the shape this paper describes: Adaptive Operations turns the retained drone fleet's imagery into detections of physical behaviour, from oil sheen and smoke to berth occupancy and quay wall damage; Decision Systems ranks every detection into a work item that a named responder decides on, with the decision recorded; Hyper Ontology holds the fifteen-object model that anchors every detection to a real quay, berth or asset; Hyper Pragma is the work surface where the authority's own people build agents over that model and its memory; and Sovereign Infrastructure is the reason the whole service runs on the authority's own hardware under open-weight licences inside its own boundary. The design itself was produced on Praxis, CodeNinja's platform for designing physical AI systems, and every choice in it traces to the recorded reading the next chapter shows.

The Port Owns the Eyes It Already Flies

Taken in one view, the design is a projection over the port's own systems: drones and docks the authority already runs feed frames to an edge box at the quay, detections rise into a fifteen-object model that links every finding to its berth, its asset, its mission, its responder and its history, and five services push work items into the systems responders already use while the port's own servers hold every weight and every record. Nothing sits in front of the systems of record, and no automatic act goes beyond a confirmation re-flight or a notification escalation.

The same shape travels: any operator with retained drone flights, a partial spatial register and existing responder systems can stand it up, provided it standardises its own spatial data instead of buying a replacement, commits to edge-first detection where the dock uplink is thin, keeps learning in memory rather than in weights, and writes the supplier exit obligations into the service contract from the first day.

Praxis Recorded Every Choice This Design Stands On

Every choice in this paper, from the edge-first placement to the memory-over-weights doctrine, traces back to recorded reading on Praxis, and this chapter shows the trail from ask to equipment.

Chapter 10 closed the ownership question and named the offer behind the design. This chapter turns inward and shows how the design was reasoned: what Praxis was asked, what it read, and how each recorded choice became a pattern the paper stands on. Every design in this series is produced on Praxis, CodeNinja's platform for designing physical AI systems, and this chapter lets a reader trace any choice in the paper back to the recorded reading that justified it, as Figure 9 shows.

11.1  Contextualising the Ask

The ask, in the authority's requirement's own words, was a docked drone network across two port sites turned into a detection-to-dispatch system: scheduled and on-demand missions, oil sheen, berth occupancy, persons in restricted zones, quay wall damage and works progress detected on the imagery, every detection a work item with a named responder, a living map of the port, imagery and models owned by the port and surviving a change of drone operator, under the EU specific category drone rules, Seveso and GDPR. Praxis assigned it to the Physical AI family and the maritime and ports industry, with the country, Germany, stated by the authority's requirement itself. What was in the room were the recorded briefs, intake answers, stack and hardware shelves and model register entries listed in the source trail; of 616 shelf records listed, 150 were read in full, and each is available on request.

11.2  The Eight Lenses

Praxis reasoned the ask through eight lenses, each contributing what Table 6 records; a lens that returned nothing is shown as a gap rather than smoothed over.

11.3  Patterns Adopted and Set Aside

Four patterns were adopted. Edge-first per-frame detection at the dock, with events and evidence crops crossing the boundary rather than pixels, because hours of daily video cannot cross the dock uplink and detection must survive its loss. Memory over weights, because the pinned architecture trains nothing and improvement must survive a supplier change without a training run. The ontology as a projection beside the systems of record, so the port's GIS and the responders' systems stay authoritative. Standardising the port's own berth plan rather than buying a berth-management product, because the requirement asks for occupancy against the port's own plan. Set aside with reasons: streaming all video to central servers, rejected on uplink arithmetic; fine-tuning into weights, rejected by the architecture; fixed and thermal cameras as day-one scope, thermal being a named annual trial and cameras being payloads on the retained fleet; tag and anchor positioning for people, rejected because drone telemetry against the standardised berth plan geo-locates every detection; and a one-way data diode, rejected because no operational technology control zone is crossed.

11.4  Where the Reasoning Lands

The equipment classes the reasoning lands on are the 141 GB HBM GPU class, one node of eight cards holding the frontier work-surface model at FP8 with the planning factor and KV cache beside the weights; the 48 GB PCIe inference server class at the site tier, one to four air-cooled cards running the zero-shot passes and the site language model; the open grandmaster time card with linuxptp and chrony, holding one clock across sensors and systems; and the rugged enclosure, mounting and power class with network UPS tools at the dock. Everything shown in this paper, from the doctrines to the model register to these classes, was recorded reading on Praxis, and nothing in it is inferred.