Configuration Manager

The Configuration Manager acts as a single source of truth, storing all critical parameters for a federated learning job. This includes:

• Model Hyperparameters: Learning rate, batch size, optimizer type (e.g., SGD, Adam), and number of local epochs.
• Training Configuration: Loss functions, evaluation metrics, and convergence criteria.
• System Parameters: Client selection thresholds, round timeout limits, and secure aggregation protocol settings.
• Environment Variables: Paths to data loaders, logging levels, and API endpoints. By centralizing these settings, it eliminates configuration drift between the server and heterogeneous clients.

Before any configuration is distributed, the manager validates it against a strict schema or contract. This prevents runtime failures by catching errors early. Key validations include:

• Data Type Checking: Ensuring a learning rate is a float, not a string.
• Range Validation: Confirming a batch size is positive and within client memory limits.
• Dependency Validation: Verifying that all required parameters for a chosen optimizer are present.
• Compliance Checks: Enforcing that configurations adhere to privacy budgets (e.g., differential privacy noise scales) or regulatory constraints. This gatekeeping function is critical for system stability.

The manager is responsible for pushing validated configurations to all relevant components at the start of a training round or job. This involves:

• Client-Specific Adaptation: Tailoring global configurations for individual client capabilities (e.g., reducing batch size for a memory-constrained device).
• Versioned Rollouts: Managing staged deployments of new configurations for A/B testing or canary analysis.
• Hot Reload Support: Allowing certain parameters to be updated between rounds without restarting the entire job, enabling adaptive hyperparameter tuning. Distribution is typically done via secure APIs or through the Federated SDK installed on clients.

Every configuration change is immutably logged and versioned. This is essential for:

• Reproducibility: Exactly recreating the conditions of any past federated learning job.
• Rollback Capability: Quickly reverting to a known-good configuration if a new version causes performance degradation.
• Compliance Auditing: Providing a verifiable record of all parameters used in a job, which is crucial for regulated industries like healthcare (HIPAA) and finance (GDPR). The audit trail links configuration versions to specific model artifacts in the Model Registry, creating a complete lineage.

The Configuration Manager does not operate in isolation; it provides critical data to other orchestrator modules:

• Round Coordinator: Supplies the training task configuration for the current round.
• Client Selection Module: Provides criteria (e.g., minimum compute resources) used to filter eligible devices.
• Secure Aggregation Orchestrator: Delivers cryptographic parameters and key exchange settings.
• Heterogeneity Handler: Informs the handler of client-specific configuration adaptations. This deep integration ensures all components operate from a consistent operational blueprint.

A key responsibility is abstracting away the complexity of the client's local environment. The manager provides clients with a complete, executable task package. This includes:

• Resolved Parameters: All placeholders are filled with concrete values.
• Serialized Model Initialization: The initial global model weights, often sourced from the Model Registry.
• Data Loader Specifications: Instructions for accessing and preprocessing the local dataset in a consistent manner. This abstraction allows the Federated SDK on the client device to focus solely on local training execution, simplifying client-side logic and reducing errors.

The Configuration Manager acts as the single source of truth for all parameters governing a federated job. It stores:

• Global model architecture (e.g., PyTorch model definition, TensorFlow graph)
• Training hyperparameters (learning rate, batch size, optimizer type)
• Client task specifications (number of local epochs, data loader configuration)
• Aggregation algorithm settings (e.g., FedAvg weighting, FedProx mu parameter) This prevents configuration drift and ensures all participants train an identical model structure with consistent settings.

The manager dynamically pushes configuration payloads to selected clients at the start of each training round. This enables:

• A/B testing of hyperparameters across different client cohorts.
• Rolling updates to training logic without restarting the entire federated job.
• Context-aware configuration where settings are tailored based on client profiles (e.g., different batch sizes for high- vs. low-memory devices). The distribution mechanism is typically versioned and idempotent, allowing clients to cache configurations and verify integrity.

Before distribution, the Configuration Manager validates all settings against a strict schema definition. This ensures:

• Type safety (e.g., learning rate is a float, model class is a valid string).
• Constraint checking (e.g., local epochs > 0, privacy budget epsilon > 0).
• Regulatory compliance by enforcing approved model architectures or privacy-preserving techniques (e.g., mandatory gradient clipping for differential privacy). Invalid configurations are rejected, preventing faulty training rounds that could waste resources or compromise model integrity.

The Configuration Manager is a core dependency for multiple orchestrator services:

• Round Coordinator: Retrieves the active configuration for the current training round.
• Client Manager: Provides device-specific configuration overrides based on client capabilities.
• Model Registry: Links configuration versions to specific model checkpoints and artifacts.
• Task Scheduler: May use configuration complexity to estimate client task duration for scheduling. This tight integration ensures the entire system operates from a unified, consistent set of parameters.

All configurations are immutably versioned. This provides critical operational control:

• Audit trail: Every federated learning round is executed with a specific, recorded configuration version.
• Reproducibility: Any round can be precisely recreated by specifying its configuration hash.
• Safe rollback: If a new configuration causes training divergence or client failures, the orchestrator can instantly revert to a previous, stable version. Versioning is essential for maintaining a deterministic and debuggable training lifecycle.

Configuration management is implemented differently across federated learning frameworks:

• Flower: Uses a ServerConfig and ClientConfig object passed to the start_server and client functions, often defined in Python code.
• TensorFlow Federated (TFF): Employs tff.backends.native execution contexts and tff.program structures to encapsulate federated computations and their configurations.
• PySyft / OpenMined: Leverages protocol-specific message schemas and serialization to communicate training plans and configurations between nodes.
• IBM Federated Learning: Features a centralized Aggregator with a configuration file (JSON/YAML) defining the model, training, and aggregation parameters.

The central software platform that manages the entire federated learning lifecycle. It coordinates all other components, including the Configuration Manager, to execute training jobs across a distributed network. Its core responsibilities are:

• Job Scheduling: Initiating and sequencing training rounds.
• Component Coordination: Managing the Client Manager, Aggregator, and Configuration Manager.
• Lifecycle Management: Overseeing model training from initialization to deployment.
• System Health Monitoring: Ensuring the overall stability of the federated network.

A module responsible for the discovery, authentication, and state management of all participating edge devices. It maintains a real-time registry of available clients, profiling their capabilities (compute, memory, network) to inform the Configuration Manager and selection algorithms. Key functions include:

• Device Registration & Authentication: Securely onboarding new clients.
• Capability Profiling: Cataloging device specs (e.g., RAM: 4GB, Framework: PyTorch Mobile).
• Health & Availability Tracking: Monitoring which clients are online and ready for training.
• Lifecycle State: Managing client status (idle, training, updating, offline).

A centralized versioned repository for all model artifacts and metadata. It stores the global model checkpoints, client model versions, and associated configurations distributed by the Configuration Manager. It ensures reproducibility and rollback capability. Core features are:

• Artifact Storage: Hosting model binaries, weights, and architecture definitions.
• Version Control: Tagging models with unique identifiers (e.g., global_model:v2.1).
• Metadata Tracking: Logging hyperparameters, training metrics, and lineage data.
• Access Control: Governing which components or users can retrieve specific model versions.

The component that executes a single federated learning round from start to finish. It relies on configurations from the Configuration Manager to define the round's parameters. Its operational loop is:

1. Client Selection: Uses criteria (from config) to choose participants.
2. Task Dispatch: Sends the current global model and training configuration to selected clients.
3. Update Collection: Waits for and receives local model updates.
4. Aggregation Triggering: Passes collected updates to the Central Aggregator. It ensures each round adheres to the defined job configuration.

The server-side algorithm that combines client updates into a new global model. It executes the aggregation logic (e.g., Federated Averaging) defined and parameterized by the Configuration Manager. Its primary functions are:

• Update Aggregation: Applying mathematical operations (weighted averaging) to client gradients or weights.
• Algorithm Execution: Running the specific aggregation rule (e.g., FedAvg, FedProx).
• Secure Coordination: Working with a Secure Aggregation Orchestrator if cryptographic protocols are enabled.
• Model Output: Producing the updated global model for the next round.

A component that determines the timing and resource allocation for federated tasks across heterogeneous clients. It uses policies defined in the system configuration to optimize for efficiency and fairness. It handles:

• Priority Queuing: Managing multiple concurrent federated jobs.
• Resource-Aware Dispatching: Scheduling tasks based on client battery, connectivity, and compute load.
• Fairness Enforcement: Implementing strategies (e.g., round-robin, weighted selection) to prevent client starvation.
• Conflict Resolution: Deciding which job runs if resources are contested.