Eclipse Enactum

Monday, October 12, 2026 - 05:36 by Thanasis Kotsi…
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Community Review
Background

Data-intensive applications increasingly distribute their processing between cloud platforms, edge servers and devices close to data sources. Their operating conditions change as demand varies, nodes join or leave, and network or resource availability fluctuates. Application owners must balance response time, resource use, energy consumption and deployment constraints across this heterogeneous infrastructure.

The ENACT research project addresses this problem through a Cognitive Computing Continuum (CCC): a software framework that combines infrastructure models and AI-assisted decisions with application adaptation. Its approach operates at two levels. Infrastructure-level adaptation determines where workloads should run and which resources they need. Application-level adaptation monitors application behavior and requests changes to execution, resource allocation or placement when policies require them.

ENACT has developed its open source results within Eclipse Research Labs. Eclipse Enactum carries this work into a sustained community project, making the reusable framework available beyond the research consortium. ENACT scenarios in sports media processing, cultural-event content delivery and mobility digital twins provide concrete requirements and integration examples for the software.

Scope

Eclipse Enactum provides software for modeling, deploying and adapting distributed applications across edge and cloud resources. It combines resource models and telemetry with predictive and learning-based scheduling. It supports deployment, resource provisioning and runtime application adaptation through interoperable services. Application models, developer libraries and data and policy interfaces enable integration with the framework. The scope includes supporting, documentation, examples and tests, and excludes underlying cloud platforms proprietary pilot applications and unrelated general-purpose AI or data-management products.

Description

Eclipse Enactum helps application teams respond to changing demand and resource availability across edge and cloud infrastructure while balancing performance, resource use and energy consumption. Its modular services let developers reuse and extend forecasting, scheduling and application-control capabilities. The framework connects infrastructure models with predictive models, learning-based scheduling and application controllers.

In detail, Eclipse Enactum provides a modular framework for developing and operating applications whose components run across heterogeneous edge and cloud resources. The initial execution technology is Kubernetes, with REST interfaces and containerised services supporting component integration.

The Dynamic Graph Modeller (DGM) represents resources, application components and their relationships. The AI Forecaster uses telemetry histories to predict metrics such as CPU usage, memory demand, latency and power consumption. The scheduling research includes deep reinforcement learning (DRL) with graph neural networks (GNN). These methods evaluate candidate placements using performance, energy and resource constraints.

The Application Controller (AC) connects application requirements and runtime observations to deployment decisions. The Orchestrator obtains the deployment plan generated from the AI layer. The Orchestrator translates the plan into Kubernetes operations, applies the requested configuration and coordinates with Zero-Touch Provisioning (ZTP) when new nodes are needed. The provisioning service uses a central server and agents in remote networks, integrating with MAAS and Cloud-Init to discover and configure resources.

The ENACT Application Programming Model (APM) supplies component-specific Java libraries distributed through Maven Central. The SDK provides higher-level library access and an Eclipse IDE plugin with component discovery and code-generation support. The Eclipse Enactum namespace convention is org.eclipse.enactum for Java packages and Maven group identifiers. The initial-contribution inventory identifies the corresponding libraries and tooling. Python integration is part of the roadmap.

Data Manager and Data Access and Sharing Interfaces provide the architectural basis for storing and exchanging telemetry, metadata and training data, including connector-based data sharing. The AI Act Compliance Checker assesses system descriptions and supporting documents. Ιts documented implementation uses hosted LLM and Azure storage services, with instructions on how to use third party hosts and storage services.

Why Here?

ENACT already uses Eclipse Research Labs as the collaboration environment for its open source components. Its vision identifies the transition from Research Labs to an Eclipse project as the route for sustaining selected results beyond the research project. Enactum would continue that work through public development, shared maintenance and participation by developers outside the original consortium.

The project brings Eclipse reusable software and integration experience for combining graph-based infrastructure modelling, predictive scheduling, application adaptation and distributed data access. Its APM and SDK also provide a direct connection to the Eclipse IDE developer experience.

Additionally, Eclipse provides a neutral setting in which this work can acquire maintainers, receive external review and evolve through public roadmaps and releases. The intended outcome is a usable open source framework whose development can continue independently of the duration of a single funded project.

Future Work

The proposed roadmap for the next twelve to eighteen months focuses on integration, reliability and adoption:

 

Consolidate the framework. Align component interfaces and deployment descriptors, provide repeatable installation instructions, container builds, examples and integration tests for a complete deployment-and-adaptation workflow.

 

Validate scheduling decisions. Benchmark learning-based approaches against Kubernetes scheduling and documented baselines using pilot-derived workloads. Measure application latency, resource utilisation, energy use, constraint violations and decision overhead under changing demand and node availability.

 

Improve predictive adaptation. Refine forecasts and anomaly detection with richer telemetry, strengthen their connection to scheduling, and develop model retraining and evaluation workflows with the Virtual Training Environment.

 

Extend deployment and developer support. Develop and validate cross-cluster replication and migration, broaden APM and SDK coverage and progress Python integration, improve error handling, recovery and policy-service integration.

 

Build an external contributor community. Publish a contribution guide and public issue backlog, provide runnable tutorials, organise technical demonstrations and invite application developers and infrastructure operators to test the framework.

Project Scheduling

The project begins in incubation following a successful creation review. The indicative schedule below uses creation as month 0 and is independent of the ENACT grant timetable. No official release is issued until intellectual property (IP) due diligence on the initial contribution and required dependencies is approved and applicable Eclipse review requirements are met. 

Period

Proposed milestone

Months 0–2

After a successful creation review: provision the project infrastructure, push the selected code to the official repositories, then initiate the initial-contribution IP review. Establish repository metadata, public contribution guidance and baseline builds. 

Months 2–4

 Produce an integrated development milestone with reproducible deployment instructions and an example application. Record supported configurations and known limitations, and progress IP review during incubation. 

Months 4–8

Strengthen integration tests, telemetry and recovery, progress the prioritised cross-cluster and SDK enhancements.

Months 8–12

Target the first official incubating release, subject to approved initial-contribution and dependency IP due diligence, technical readiness and applicable review requirements. Expand contributor onboarding and examples.

Months 12–18

Continue releases and model improvements. Target a graduation review within months 12–18, subject to demonstrated open development, sustainable community participation and fulfillment of Eclipse graduation criteria. 

Interested Parties
  • Centre for Research and Technology Hellas (CERTH): Research-project coordination, reference architecture and cognitive AI models. 
  • Universitat Politècnica de València (UPV): Learning-based scheduling, graph methods and orchestration evaluation. 
  • Information Catalyst (ICE): Reference architecture, controller services and framework integration. 
  • Eclipse Foundation Europe: Open source governance, contribution practices and community development. 
  • UNPARALLEL Innovation: Orchestrator development, integration and deployment workflows. 
  • DunavNET: AI trustworthiness and documentation-assessment tooling. 
  • Siemens Romania: Provisioning services, application programming libraries and developer tooling. 
Initial Contribution

The initial contribution to Eclipse Enactum consists of selected software components and supporting assets developed by the Horizon Europe ENACT consortium. The component inventory below identifies the proposed contribution. Eclipse Enactum is the distinct name for the continuing open source project. 

The software supports management and orchestration of distributed applications and heterogeneous resources across the CCC. Component inclusion is subject to Apache Software License 2.0 and the conditions identified below. 

Core Framework Components 

  1. AI Act Compliance Checker: Assists AI system providers with risk categorization and documentation assessment using an LLM, exposing results through a REST API. The initial implementation uses Azure-based storage, document processing and an Azure-integrated LLM workflow. Architectural guidance and instructions for extending these integration layers to support third-party providers and alternative document sources through configurable interfaces and modular adapters are provided in the README of this project.
  2. AI Forecaster: Predicts workload and resource conditions from monitoring and historical data. Forecasts and anomaly-detection outputs support proactive application management, resource allocation and orchestration. 
  3. Application Controller: Manages distributed applications at runtime, including resource requests, availability, autoscaling, container enablement and load balancing, using telemetry to support adaptation. 
  4. Application Manager: Coordinates application lifecycle and deployment operations and interactions with other framework components. 
  5. Application Programming Model: Supplies developer-facing abstractions and client libraries for expressing application requirements and accessing framework services. 
  6. Data Access and Sharing Interfaces: Supports controlled access to distributed data sources and exchange between applications and services across computing layers. 
  7. Data Manager: Stores and manages application data and associated metadata in forms accessible to other framework components. 
  8. DRL+GNN Agent: Combines reinforcement learning and graph-based machine learning to generate workload-placement decisions from infrastructure state and application requirements, including quality-of-service constraints. It supports model inference and retraining. 
  9. Dynamic Graph Modeller: Maintains a graph representation of resources, applications and their relationships for discovery, application management, security analysis and optimization. 
  10. Software Development Kit: Provides reusable libraries and an Eclipse IDE plugin for developing applications and integrating them with framework services. 
  11. Orchestrator: Translates AI-generated deployment plans into specifications for the target clusters and coordinates deployment across heterogeneous infrastructure. 
  12. Zero-Touch Provisioning: Automates discovery, preparation and configuration of resources across heterogeneous environments. 

  

Supporting Infrastructure and Integration Assets 

Supporting integration and deployment assets include: 

  1. Container images and container build configurations 
  2. Kubernetes deployment resources and manifests 
  3. Component integration and configuration resources 
  4. Monitoring and telemetry integration
  5. Example applications and deployment scenarios and 
  6. Resources developed to support ENACT testbeds and use-case validation. 

  

Models, Artifacts and Documentation 

Associated models and documentation include: 

  1. Application and deployment models 
  2. API specifications and interface definitions 
  3. Deployment and configuration examples 
  4. Technical and user documentation 
  5. Test resources and integration scenarios and 
  6. Examples and demonstrators developed during the ENACT project. 

  

Development Languages and Tools 

The ENACT codebase is composed of independently deployable and interoperable components implemented using technologies appropriate to their respective functions. Principal technologies used across the existing codebase include: 

  1. Java and the Spring ecosystem for application and control services; 
  2. Python for modeling, optimization, AI, telemetry, and supporting services; 
  3. REST-based interfaces for inter-component communication 
  4. containerization using Docker-compatible technologies 
  5. Kubernetes and Kubernetes APIs for deployment and management across continuum infrastructure and 
  6. standard cloud-native monitoring, configuration, and deployment technologies. 

  

Existing Community and Code Ownership 

The ENACT consortium provides the initial developer and user community through its work on architecture, implementation, integration, testing and validation. The Interested Parties section summarizes the participating organizations and their areas of involvement. 

Copyright remains with the respective organizations and contributors that developed each component. 

  

Third-Party Libraries and Licenses 

The ENACT software components make use of a range of established open-source third-party libraries and frameworks appropriate to their individual implementations. The principal third-party dependencies identified within the existing codebase include: 

  1. Spring Boot — Apache License 2.0 
  2. Spring Framework — Apache License 2.0 
  3. Jackson — Apache License 2.0 
  4. Jackson Datatype JSR310 (Java Specification Request 310 date and time support) — Apache License 2.0 
  5. Kubernetes Java Client — Apache License 2.0 
  6. Fabric8 Kubernetes Client — Apache License 2.0 
  7. Micrometer — Apache License 2.0 
  8. H2 Database Engine — Mozilla Public License 2.0 / Eclipse Public License 1.0 
  9. PostgreSQL https://jdbc.postgresql.org/ — BSD 2-Clause License 

The ENACT codebase comprises multiple independently developed components using different implementation technologies and dependency sets. The dependencies listed above represent the main third-party libraries identified within the existing software and are not intended to constitute an exhaustive software Bill of Materials. The project team periodically runs the Eclipse https://github.com/eclipse/dash-licenses and resolves issues as they are identified. 

In addition to libraries incorporated directly into individual components, ENACT integrates with a range of external open-source platforms and cloud-native technologies, including Kubernetes, container runtimes, PostgreSQL, MinIO object storage, and Eclipse Dataspace Components (EDC). These external technologies support deployment, data management, orchestration, and integration across the Cognitive Computing Continuum and will be considered separately, where applicable, during the dependency and intellectual property review.

Source Repository Type