The role of SKIM in DaFab system architecture

Introduction: Turning a Copernicus data scale archive into something you can search

Copernicus has grown into an archive where the limiting factor is rarely the availability of pixels, but the ability to find the right ones. To do so, users still have to start from copernicus product descriptors (e.g. Sentinel-2 tile, date, processing level, etc…) and only later test whether the data contains the signal of interest. DaFab system addresses this gap by generating secondary, AI‑derived metadata at scale and exposing it as a discovery surface, so that users can begin with a thematic question instead of beginning with file selection (e.g. “How many agriculture parcels are there ?” in smart-agriculture thematic and “Where can I find water anomalies ?” for water-analysis one).

In our previous DaFab post, we introduced the overall multi-site orchestration vision. This entry focuses on a specific architectural building block: integrating Karmada with Argo Workflows to enable multi-cluster and multi-site workflow execution driven by rule-based placement. The key outcome is that workflow steps can be dispatched to different Kubernetes clusters (sites) based on explicit rules that reflect data locality and computing resource availability goals, without changing how users author workflows.

Navigating Strategic Pivots and Technical Milestones

DaFab has now reached half of its length, an ideal time to look back in the rear-view mirror and to reassess our roadmap. After 18 month of work we can claim substantial advancements across DaFab work packages, demonstrating agility and a solid technical foundation, despite facing initial challenges such as delayed deliverables and staffing issues. The project has successfully established a robust management structure, implemented a significant technological pivot, and achieved initial technical milestones, laying the groundwork for its full deployment.