How C3 AI Applications Are Structured
This page walks through a turbine monitoring application to show how the platform components described in the Platform Overview work together. The application collects live sensor data, analyzes it for early signs of equipment issues, and recommends preventive actions based on those predictions.
This is a simplified example, but predictive maintenance is a supported use case on the C3 Agentic AI Platform. For full application documentation, go to Documentation > Applications and find the C3 AI Reliability application docs.
Packages
On the C3 Agentic AI Platform, applications are organized into packages. A package is a named, versioned unit with its own manifest that declares which other packages and platform libraries it depends on. Packages can depend on other packages, so Types and logic defined in one package are available to any package that takes a dependency on it.
A turbine monitoring application might include a package for the data model, one for data integration, one for machine learning, one for the React UI, and one for the agent layer. Another application, such as one focused on supply chain or process optimization, could take a dependency on the data model package and reuse the asset and sensor Types without duplicating them.
For more detail on how packages are structured and what files they contain, see Package structure overview.
Data model
The data model defines the entities the application works with. For the turbine monitoring application, this includes the asset hierarchy: wind farms, facilities, and individual turbines. It also includes sensors attached to turbines, the measurements those sensors produce, failure modes the application monitors, and the work orders maintenance crews generate when an issue is confirmed.
Each entity is a Type. A Type declares its fields, its relationships to other Types, and the methods it exposes. The C3 Agentic AI Platform is language-agnostic: you implement method logic in the language that fits your team and your use case. Relationships between Types can be temporal, so the application tracks not just the current state of an asset but its full history: which sensors it has had, which models have scored it, and which work orders have been raised against it.
The data model also includes Types for the outputs that drive maintenance operations: predicted time to failure, failure mode classification, and recommended actions.
For more on the Type System, see C3 AI Type System overview.
Data integration
The application pulls sensor telemetry from a historian and work order records from a maintenance management system. Each source has its own schema. Field names, data types, and granularity may not match the application's internal data model. Data integration handles the mapping.
Data Fusion, the visual canvas-based workspace in C3 AI Studio, is the recommended way to configure these pipelines. You connect to the source system, describe the shape of its data, and map fields to the Types in your data model. Data Fusion manages scheduling, incremental loading, and validation. Sensor readings flow into the measurement Types. Work orders flow into the work order Type. For teams that prefer to configure pipelines by authoring Type and transformation definitions directly, both approaches produce the same result.
The application also ingests unstructured content, such as maintenance manuals and inspection reports, through a separate pipeline that processes and embeds the content into a vector store, making it available to the agent layer for retrieval.
For more on data integration, see Data Fusion overview, Build a data integration pipeline, and Unstructured data pipelines.
Machine learning
The machine learning layer scores asset health and predicts failures. For each failure mode the application monitors, a model is trained on historical sensor readings and maintenance outcomes. The platform manages feature engineering and materializes the results for training and inference.
When a new model outperforms the one in production, it goes through a validation workflow before promotion. The platform tracks which model version is active for each failure mode and routes inference to the correct version automatically. Scores write back to the asset Type, where the UI and the agent layer read them. When a score crosses a threshold, the application can trigger a downstream step: creating a work order, notifying a scheduler, or surfacing an alert in the dashboard.
For more on machine learning, see ML pipelines, Feature Store, and Model development workflow.
User interface
The UI package contains the React pages and components that maintenance crews, engineers, and schedulers use. A fleet health dashboard shows current risk scores across all assets. A detail page for each turbine surfaces sensor trends, active alerts, and open work orders. A case management view lets engineers triage alerts and track recommended actions.
The platform's UI component library provides pre-built, platform-aware building blocks that connect to backend Types and handle data fetching and role-based access. These include data grids, time-series charts, filterable lists, and forms. Each user interaction calls a named method on a platform Type through the platform's API gateway. There is no separate API layer to build or maintain.
For more on building application UI, see UI component library overview and Build your application UI.
Agents and agentic workflows
The agent layer lets maintenance engineers interact with the application in natural language. An engineer can ask which turbines are most at risk this week, request an explanation of why a specific turbine scored high, or ask what parts are on hand for a likely repair. The agent answers by calling tools that read from the same data the dashboard displays: risk scores, sensor readings, work order history, and parts inventory.
Agent tools are Types. Each tool has a description that the model reads to decide when to use it, and a method implementation that queries your data. Agentic workflows extend this further. A workflow can move an alert from detection to scheduled maintenance. The agent confirms the failure mode, checks parts availability, drafts a work order, and routes it to a scheduler for approval. The sequence combines agent reasoning with structured data operations and a human decision point, and it produces an auditable record of every step.
For more on agents and workflows, see Agents and tools overview and Agentic workflows overview.
Elastic compute
Applications run inside isolated environments that package the full application definition: Types, pipelines, models, schedules, and interfaces.
Each environment uses the same model definition, maintains its own data and configuration, and runs jobs in its own compute pool. This setup allows development and testing to happen independently of production. New Types or changes to ingestion logic can be deployed to Dev, validated in Test, and promoted to Prod without reconfiguring infrastructure or touching unrelated applications.
Jobs for ingestion, feature computation, and model scoring are scheduled by the platform. The platform handles failures, retries, and logging automatically.
C3 Code
C3 Code is a natural language development environment for the C3 Agentic AI Platform. You can describe what you want to build and iterate through follow-up prompts rather than authoring each file by hand. A developer familiar with the concepts on this page can prompt their way to the same result, rather than writing each artifact from scratch.
For example: "Build a wind turbine monitoring application. Include an asset hierarchy for wind farms and individual turbines, sensor ingestion from a historian, a fleet health dashboard with risk scores, per-turbine detail pages showing sensor trends and alerts, and a conversational agent that can answer questions about asset health."
For more, see C3 Code overview.
See also
Platform Overview Learn about the core components of the C3 Agentic AI Platform and the application suites built on top of it.
Learn how to build your own application Start building with the C3 AI Type System and other core platform components.