Skip to content


The Lucd federated modeling capability operates with a core facet of the FATE project; pipelines. FATE pipelines allow users to combine and parameterize components of their Machine Learning model. For example, a model may include a DataIO component (loading data into the model) which feeds into a Logistic Regression component. However, we have abstracted away some of the base layers of constructing a pipeline to make the Lucd user’s life easier. We build necessary components for loading a federated VDS into a pipeline (Readers & DataIO) and apply federated feature engineering components. We then hand the partially constructed pipeline to the user’s model python script as an argument. Once they select a federated VDS from the GUI when starting a training job, we automatically load and pass it into their modeling components. Essentially, this means that writing a Lucd FATE model and uploading it to our system involves few simple steps:

  • Ensure VDS has a feature titled id , e.g.
  • Set the model initiator's role & party ID on the pipeline. The initiator must be set to your local federate.
  • Set the active roles (guest/host/arbiter) participating in the job on the pipeline.
  • Instantiate, parameterize, and add remaining desired modeling components to the pipeline (such as a Logistic Regression & Evaluation component).

The user will then return the pipeline object & information about the role/party configuration. The completed pipeline is then submitted to the local federate’s configured FATE Flow server, thus completing the development and launching of a FATE model training job from within the Lucd platform.

Common and known errors when developing FATE models include: - improper role/party configuration in the pipeline by the user - improper parameterization of input/output between components - networking issues with rabbitmq

Lucd FATE modeling currently supports horizontal datasets run with the following models:

Each has been developed and tested to the standards of FATE provided example pipelines.

Examples illustrating how to use the FATE modeling capability can be found within The Lucd Model Shop.

Main Function

The main function is intended to contain code for building FATE Pipeline models. More information on FATE Pipelines can be found here. The LMF sends args from the GUI, a partially completed Pipeline object with a Reader component, a DataIO component pre-configured with the user’s selected VDS, and components for any supported / selected federated feature engineering operations. It also provides a handle to the “final_component” for integration with the user’s modeling components inside of the main function. In turn, the main function must add components to the partially completed pipe, pulling the as input to the new components being added, then return two objects:

  • The completed pipe object (uncompiled; no need to call pipe.compile())
  • A dictionary of role to party id list mappings; {"guest": [9999], "host": [10000], "arbiter": [9999]}
def main(args, pipe, final_component):
    """Function used by LMF for training and analyzing FATE Pipeline models.

            args (list): List of parameters selected within the JedAI client upon train job initialization.
            pipe (FATE PipeLine): A partially completed FATE Pipeline.
            final_component (FATE component): A handle to the last component added to the partially completed Pipeline.

            Pipeline object (for training),
            Role / party id mapping dictionary object (for properly monitoring and handling the Pipeline)

JedAI FATE model visibility

After starting a FATE model training, the Lucd platform actively retrieves metrics and status information from the local federate and surfaces them to the Unity client.

If the job fails, any available error messages will be surfaced to the user through the Training object status block just as it occurs with non-FATE models (i.e., PyTorch, TensorFlow, Sklearn.) Note that as FATE models train within separate servers running alongside the Lucd backend and separate federates, it is possible to reach a failure mode within those servers/federates requiring manual inspection of the deployment.

If the job succeeds, users will see metric data and plots generated by the model training displayed within the JedAI Unity client. The available metrics and plots depend on the type of model trained and the data accessible. Examples include loss curves, accuracy curves, ROC curves, mean squared error, precision & recall, and several other metrics. Note that unavailable information includes metrics related to portions of your federated model trained in other federates, but users may log into the other federates via JedAI to see available data (which is also true of FATEBoard).