Abstract: Disclosed are various embodiments for garbage collection for object-based storage systems. A first set of objects stored by an object storage service that have been accessed within a previously defined date range is identified. Then, a second set of objects stored by the object storage service is identified based at least in part on a relationship to one or more objects in the first set of objects. Next, a third set of objects stored by the object storage service that have been created prior to a predefined date is identified. Then, a subset of objects which are members of the third set of objects and not members of the first set of objects or the second set of objects is identified. Finally, a retention action is performed on individual members of the subset of objects based at least in part on a retention policy.

Abstract: Disclosed are various embodiments for using a distributed ledger to track the evolution or deployment of feature sets for machine-learning. A registration request is received from a first node of a distributed ledger, the registration request comprising a code hash representing a feature set generator and a data hash representing a data set. The registration request is then relayed to a second node of the distributed ledger for approval by the second node. Next, an approval for the registration request is received from the second node. Subsequently, an entry in the distributed ledger comprising the code hash and the data hash is created.

Abstract: Disclosed are various approaches for managing the status of machine-learning models using distributed ledgers. A registration request for a machine-learning model can be received. The registration request can include a model name for the machine-learning model, a version identifier for the machine-learning model, a network address from which the machine-learning model can be retrieved, a source code hash for a source code version of the machine learning model, and a runtime hash for a binary executable version of the machine-learning model. A registration identifier can then be created based at least in part on the source code hash and the runtime hash. Subsequently, an entry in the distributed ledger can be created for the machine-learning model. The entry can include the registration identifier, the model name, the model version, the network address, the source code hash, and the runtime hash.

Abstract: Disclosed are various embodiments for garbage collection for object-based storage systems. A first set of objects stored by an object storage service that have been accessed within a previously defined date range is identified. Then, a second set of objects stored by the object storage service is identified based at least in part on a relationship to one or more objects in the first set of objects. Next, a third set of objects stored by the object storage service that have been created prior to a predefined date is identified. Then, a subset of objects which are members of the third set of objects and not members of the first set of objects or the second set of objects is identified. Finally, a retention action is performed on individual members of the subset of objects based at least in part on a retention policy.

Abstract: Disclosed are various approaches for managing the status of machine-learning models using distributed ledgers. A registration request for a machine-learning model can be received. The registration request can include a model name for the machine-learning model, a version identifier for the machine-learning model, a network address from which the machine-learning model can be retrieved, a source code hash for a source code version of the machine learning model, and a runtime hash for a binary executable version of the machine-learning model. A registration identifier can then be created based at least in part on the source code hash and the runtime hash. Subsequently, an entry in the distributed ledger can be created for the machine-learning model. The entry can include the registration identifier, the model name, the model version, the network address, the source code hash, and the runtime hash.

Abstract: A system for data migration is disclosed. The system may receive a migration request comprising a source file path and a target file location. The system may capture source file metadata based on the source file path and the migration request. The system may transfer a source file from a first data environment to an intermediate data environment via a first transfer process. The system may transfer the source file from the intermediate data environment to a second data environment via a second transfer process.

Abstract: The method includes receiving historical data from a first data source; analyzing the historical data for a desired characteristic; determining a representative value for the desired characteristic of the historical data; determining a first data expectation for the historical data based on the representative value; transmitting the first data expectation to a first data recipient; receiving first incoming data from the first data source; analyzing the desired characteristic of the first incoming data; determining a first incoming data value for the desired characteristic for the first incoming data; comparing the first incoming data value and the representative value; determining a first difference between the first incoming data value and the representative value; and/or comparing the first difference to a difference threshold which indicates whether a difference between an incoming data value and the representative value is significant.

Abstract: A system for data migration is disclosed. The system may receive a migration request comprising a source file path and a target file location. The system may capture source file metadata based on the source file path and the migration request. The system may transfer a source file from a first data environment to an intermediate data environment via a first transfer process. The system may transfer the source file from the intermediate data environment to a second data environment via a second transfer process.

Abstract: A system for generating graphical relationship maps is disclosed. The system may receive a search request. The system may generate a relationship map data based on linked data elements of at least one of a structured data set, an unstructured data set, and a hybrid data set comprising structured and unstructured data. The system may display a graphical relationship map including an entity type icon based on the relationship map data and the search request.

Abstract: The method includes receiving historical data from a first data source; analyzing the historical data for a desired characteristic; determining a representative value for the desired characteristic of the historical data; determining a first data expectation for the historical data based on the representative value; transmitting the first data expectation to a first data recipient; receiving first incoming data from the first data source; analyzing the desired characteristic of the first incoming data; determining a first incoming data value for the desired characteristic for the first incoming data; comparing the first incoming data value and the representative value; determining a first difference between the first incoming data value and the representative value; and/or comparing the first difference to a difference threshold which indicates whether a difference between an incoming data value and the representative value is significant.

Abstract: Systems and methods for identity-based interconnected transactions are disclosed. The system may receive an interconnected transaction request comprising a first financial subsystem identifier, a second financial subsystem identifier, and a transaction request. The first financial subsystem and the second financial subsystem may not be in direct communication with each other. The first financial subsystem may write the interconnected transaction request to an interconnected transaction ledger. The second financial subsystem may retrieve the interconnected transaction request from the interconnected transaction ledger. In response to retrieving the interconnected transaction request the second financial subsystem may complete the transaction request.