How CoreAI And ProAI Rely On Runtime

Runtime is the operational substrate for the rest of the BullSequana AI platform. CoreAI and ProAI 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 MinIO
• 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.

ProAI On Top Of Runtime

ProAI 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

ProAI 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 ProAI 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.