How CoreAI And Data Rely On Runtime

Runtime is the operational substrate for the rest of the BullSequana AI platform. CoreAI and Data build on top of it rather than operating independently from it.

CoreAI On Top Of Runtime

CoreAI relies on Runtime for:

• API exposure, through ingress and gateway services
• authentication and access, through the shared identity and security model
• inference execution, through Runtime inference components
• workflow execution, through Runtime workflow engines
• state and artifact storage, through PostgreSQL and Rook-Ceph
• observability, through the shared monitoring, logging, and tracing stack

In practical terms, when a CoreAI service is deployed, Runtime provides most of the platform mechanics that make the service operational.

Data On Top Of Runtime

Data also depends on Runtime for the same foundational concerns:

• secure exposure of user and service endpoints
• identity and access integration
• platform-level observability
• persistent storage services where needed
• GitOps-based deployment and lifecycle management

Data adds enterprise data capabilities, but it still benefits from the same Runtime foundation used elsewhere in the stack.

Why This Layering Helps

This layered dependency model makes the platform easier to evolve:

• Runtime standardizes shared concerns
• CoreAI and Data focus on product capabilities
• use cases can be built without re-solving infrastructure questions each time

That separation is one of the main reasons BullSequana AI remains modular while still behaving like a coherent platform.