From CDD API to a Living Machine Learning Loop

Scientific teams often have useful data in a chemistry and discovery platform, but the platform is not always the right place for every report, analysis, or application. The useful pattern is to connect the systems rather than force one system to do everything.

A CDD API can provide the structured boundary. Inputs enter through validated API calls. Structured exports land in a data store the engineering team can query, monitor, and use for downstream work. The result is a current reporting layer without losing the source system scientists already use.

Structured input and export

The first step is an explicit data contract. Define the entities, fields, identifiers, units, and relationships that can be written to the CDD system. Validate payloads before they are accepted, record the source of each change, and make retries safe so a failed request does not create duplicate records.

The export path follows the same discipline. Pull the records needed for reporting, preserve source identifiers and timestamps, and write normalized tables to Postgres or the team's existing analytical store. Keep raw and normalized forms so a report can be traced back to the source response.

Reports that stay current

A scheduled pipeline can refresh materialized reports multiple times per hour. Watermarks, execution state, retry handling, and health checks make the refresh observable. When a run fails, operators can see what stopped, what data was affected, and whether the next run can safely continue.

Materialized views make the result useful to scientists. They can combine assay results, compound metadata, protocol context, and data quality flags into views designed for actual questions rather than raw API responses. Refresh tooling and changed-run audits keep the reports current without asking people to rebuild them by hand.

Chat and applications on the same data

Once the exported data is structured and current, it can support more than dashboards. An MCP integration can give an AI chat interface controlled access to approved tables and tools. The assistant can answer questions, explain report changes, and help navigate results while permissions, query scope, and source references remain explicit.

The same data can power custom reports and applications: scientist workbenches, review queues, readout catalogs, operational status pages, and focused analysis tools. Each surface uses the data model that the pipeline maintains instead of creating another disconnected copy.

Closing the learning loop

A machine learning loop needs more than a model endpoint. It needs stable features, labeled outcomes, versioned training data, evaluation results, and a way to record feedback from scientists. The exported reporting layer can provide the consistent inputs, while review applications capture corrections and new labels.

That makes improvement part of the system. New data is ingested, reports are refreshed, scientists review and annotate results, and the next model or rule set can be evaluated against a known history. The loop remains useful because every step has an owner, a status, and a record.

Build around the systems people already use

This architecture does not require replacing the CDD platform or asking scientists to work in a new tool for every task. It adds a controlled integration layer, a current analytical store, and applications that meet the team where the work happens.

LabACT helps teams automate the data movement, collaborate with scientists and informatics teams, and transform the exported data into reports, applications, and learning systems that can grow with the research program.

Managed cloud delivery

The application is only part of the system. We can manage the AWS foundation around it with CloudFormation and Rain templates, repeatable environment configuration, and source-controlled infrastructure changes.

EventBridge schedules and routes work. Lambda handles focused processing steps. ECR stores versioned container images for services and jobs. Together with IAM, CloudWatch, deployment checks, and operational runbooks, these services provide a managed path from code change to monitored production workflow.

The exact AWS design depends on the team's existing account structure and operating practices. The goal is a deployment system that is repeatable, observable, and understandable to the engineers who will support it.