C3 AI Documentation Home

Package Management Overview

As you begin developing on the C3 Agentic AI Platform, one of the first concepts to understand is how C3 applications are structured. Every C3 Agentic AI Platform application is built from one or more packages, which act as modular building blocks that can be developed, versioned, and shared across your organization.

A package in the C3 Agentic AI Platform is a way to bundle code and resources so other applications can use them. For example, in a maintenance context, packages could include data models for assets and sensors, logic for condition monitoring, and dashboards for tracking equipment health.

What you need to know about packages:

  • You develop packages locally, publish them as versioned artifacts, and then other applications can import them.
  • Each package needs a manifest file to identify it, and can include source code, tests, configuration, and other resources.
  • Package structure in C3 AI is flexible, but there are conventions that help you organize your project by triggering built-in automations.

Understand packages

C3 AI packages use directory structure as a mechanism for simplifying application development. Each directory serves a specific purpose, triggering different automations when files are placed in the correct locations.

Package structure

A typical package includes these directories:

Command Line
windFarmApp/
  src/                        # Application logic
  ui/                         # Frontend code
  config/                     # Environment config
  metadata/                   # Platform integration
  seed/                       # Initial data
  data/                       # Reference data
  test/                       # Tests
  windFarmApp.c3pkg.json      # Dependency file at the root of the directory

Each directory enables specific C3 Agnetic AI Platform features:

  • src/: Core application logic with Type definitions and implementations.
  • ui/: Frontend components and pages.
  • config/: Environment-specific configurations that vary by deployment environment (e.g., database credentials, API endpoints).
  • metadata/: Configuration data that doesn't change in production and is referenced from code (e.g., UI routes, translations, roles, metrics).
  • seed/: Initial data that populates the database on first deployment and can be modified by users after deployment to fit their environment.
  • data/: Data for entity types or Persistable types; not automatically provisioned like seed data.
  • test/: Automated tests that mirror your source structure.

Package examples

In a maintenance context, a wind farm application might use two packages:

  • An Equipment Monitoring package containing turbine models, failure prediction, and alert dashboards
  • A Performance Analytics package containing efficiency calculations and trend visualizations

Here's how these packages would be structured:

flowchart TD A[Wind Farm App] --> P1[Equipment Monitoring] & P2[Performance Analytics] P1 --> S1[src/] S1 --> A1[asset/] & SE1[sensor/] & AL1[alert/] A1 --> A1F["Asset.c3typ Asset.js"] SE1 --> SE1F["Sensor.c3typ Sensor.js"] AL1 --> AL1F["Alert.c3typ Alert.js"] P1 --> U1[ui/] U1 --> C1[components/] & PG1[pages/] C1 --> C1F["AssetCard.jsx AlertList.jsx"] PG1 --> PG1F["Dashboard.jsx"] P2 --> S2[src/] S2 --> P2A[performance/] & M2[metric/] P2A --> P2AF["Performance.c3typ Performance.js"] M2 --> M2F["Metric.c3typ Metric.js"] P2 --> U2[ui/] U2 --> C2[components/] & PG2[pages/] C2 --> C2F["PerformanceChart.jsx MetricDisplay.jsx"] PG2 --> PG2F["Analytics.jsx"]

The Equipment Monitoring package includes everything needed for real-time monitoring: types for representing turbines and sensors, methods for predicting failures and handling alerts, and a dashboard UI for operators.

The Performance Analytics package focuses on efficiency tracking with its own types for metrics, methods for trend analysis, and visualization components.

These feature sets can then be reused in other applications, like a Solar Farm or Battery Storage system that needs similar monitoring and analytics capabilities.

Package lifecycle

Packages need to be created and published to be reused. Let's follow our Wind Farm application's packages through this process:

Create

You start by creating packages within your application, each focused on a specific business capability. In our Wind Farm example, we have packages for monitoring equipment health and analyzing performance:

flowchart TD A[Wind Farm App] --> M[Equipment Monitoring] & P[Performance Analytics]

Publish

Once your packages are ready for sharing, you publish them as artifacts. An artifact is a versioned snapshot of your package that includes all its code, configuration, and resources. This versioning ensures other applications can depend on specific, stable versions of your packages:

flowchart TD M[Equipment Monitoring] --> |publish| MA[Monitoring Artifact] P[Performance Analytics] --> |publish| PA[Analytics Artifact]

Reuse

Published artifacts become available to other applications in your organization. For example, a Solar Farm application might need the same equipment monitoring and performance analysis capabilities. Instead of building these features from scratch, it can import the existing artifacts:

flowchart TD S[Solar Farm App] --> |import| MA[Monitoring Artifact] S --> |import| PA[Analytics Artifact]

This lifecycle enables you to build a library of reusable features across your organization. As you develop new applications, you can combine existing packages in different ways to quickly implement common functionality while focusing your development efforts on unique requirements.

Artifacts only become available to you once they're published to the C3 AI Agentic Platform and you have the necessary permissions to import them.

Was this page helpful?