Frequently Asked Questions¶
What is an Engineering Runtime?¶
An Engineering Runtime is a deterministic execution platform for engineering operations.
It provides a consistent execution model that enables Humans, CI/CD systems and AI to execute reusable Engineering Capabilities through Runtime Engines.
What problem does Engineering Runtime solve?¶
Modern engineering platforms provide excellent tools for interacting with individual systems.
Engineering Runtime provides a deterministic execution layer above those platforms, allowing Humans, CI/CD systems and AI to execute reusable Engineering Capabilities through a consistent execution model.
It integrates engineering platforms rather than replacing them.
Is an Engineering Runtime just another CLI?¶
No.
A CLI is a user interface.
An Engineering Runtime is an execution platform responsible for authentication, context, policy, deterministic execution and auditing.
Why separate AI from Engineering Runtime?¶
AI and Engineering Runtime solve different problems.
AI abstracts knowledge and provides Skills for reasoning about engineering intent.
Engineering Runtime abstracts engineering execution through reusable Engineering Capabilities.
Separating reasoning from execution allows the Runtime to remain deterministic, auditable and AI independent.
Why not allow AI to execute shell commands directly?¶
Direct shell execution provides little governance.
An Engineering Runtime introduces authentication, policy evaluation, deterministic execution and auditing before engineering work begins.
Does the Engineering Runtime require AI?¶
No.
The Engineering Runtime can be used directly by:
- Human Engineers
- CI/CD Pipelines
AI simply provides another interface.
Can humans use an Engineering Runtime?¶
Yes.
Engineering Runtimes are designed for:
- Human Engineers
- CI/CD Pipelines
- AI Agents
All consumers share the same execution model.
Is this specific to one AI provider?¶
No.
Engineering Runtime is intentionally AI independent.
Any AI capable of requesting engineering operations can interact with the Runtime.
Does Engineering Runtime replace existing engineering platforms?¶
No.
Engineering Runtime integrates existing engineering platforms rather than replacing them.
Engineering platforms remain responsible for infrastructure, authentication and platform-specific functionality.
Engineering Runtime provides a governed and deterministic execution layer above them.
Does Engineering Runtime replace existing CLIs or SDKs?¶
No.
Engineering Runtime builds upon existing platform-native tools.
It integrates authentication providers, REST APIs, SDKs and command-line tools into a consistent execution model.
Why not call REST APIs directly?¶
REST APIs differ across engineering platforms.
Engineering Runtime provides a consistent execution model regardless of the underlying implementation.
Why use Platform-Native Authentication?¶
Engineering platforms already provide secure authentication mechanisms.
Reusing them reduces complexity while improving compatibility and security.
What is a Runtime Engine?¶
A Runtime Engine is a reusable runtime component responsible for interacting with engineering systems.
Examples include:
- Auth Engine
- REST Engine
- Command Engine
- File Engine
Runtime Engines abstract platform implementation details from Engineering Capabilities.
What is an Engineering Capability?¶
An Engineering Capability is a reusable engineering workflow composed of one or more Runtime Engines.
Capabilities represent engineering knowledge in executable form.
Examples include:
- Create GitHub Repository
- Bootstrap Cloud Project
- Deploy Application
- Restart Kubernetes Deployment
- Upgrade Terraform Module
What is the difference between a Runtime Engine and an Engineering Capability?¶
Runtime Engines provide reusable integration with engineering systems.
Engineering Capabilities compose one or more Runtime Engines to solve engineering problems.
Runtime Engines understand engineering platforms.
Engineering Capabilities understand engineering workflows.
Why build Runtime Engines instead of individual integrations?¶
Runtime Engines provide reusable building blocks.
Once an engineering platform is integrated into the Runtime, multiple Engineering Capabilities can reuse that integration.
This avoids duplicated implementation while improving maintainability.
Why use Engineering Capabilities instead of scripts?¶
Scripts often solve a single problem for a single environment.
Engineering Capabilities represent reusable engineering knowledge that can be executed consistently by Humans, CI/CD systems and AI.
Capabilities are versioned, reusable and composable.
Why does the Runtime need a Runtime Home?¶
The Runtime Home stores runtime configuration and operational state.
It allows the Runtime to prepare itself automatically before execution.
Typical contents include:
- Configuration
- Authentication Sessions
- Installed Capabilities
- Logs
- Runtime Metadata
Why separate Capability Packages from the Runtime?¶
The Runtime performs engineering execution.
Capability Packages describe and distribute Engineering Capabilities.
Separating execution from discovery simplifies both systems.
What is the difference between an Engineering Capability, a Capability Package and the Capability Registry?¶
An Engineering Capability describes a reusable engineering workflow.
A Capability Package is the distributable artifact that contains an Engineering Capability together with its metadata, version and supporting resources.
The Capability Registry stores and distributes Capability Packages for discovery, installation and execution by Engineering Runtime.
Why package Engineering Capabilities?¶
Packaging allows Engineering Capabilities to be versioned, distributed, discovered and installed independently of the Runtime.
This enables Engineering Runtime to keep the Runtime architecture stable while allowing Engineering Capabilities to evolve over time.
The packaging model follows proven concepts used by engineering ecosystems such as Helm Charts, Terraform Modules and container images while adapting them for reusable Engineering Capabilities.
Why introduce a Capability Registry?¶
The Capability Registry provides a centralized location for publishing, discovering, versioning and installing Capability Packages.
Separating the Runtime from the Registry allows Engineering Capabilities to evolve independently while keeping the Runtime lightweight, deterministic and extensible.
Why is deterministic execution important?¶
Engineering operations should produce predictable, repeatable and auditable outcomes regardless of who initiates execution.
Deterministic execution improves reliability, governance and trust.
Is this specific to one enterprise?¶
No.
Enterprise-specific behavior should be expressed through configuration rather than Runtime implementation.
The Runtime remains vendor and organization independent.
Why is Engineering Runtime vendor independent?¶
Engineering Runtime integrates engineering platforms rather than becoming one.
The Runtime remains stable while supporting multiple vendors through Runtime Engines.
Organizations can adopt new engineering platforms without changing the Runtime architecture.
What engineering platforms can Engineering Runtime support?¶
Engineering Runtime is designed to integrate any engineering platform that provides one or more of the following:
- Platform-Native Authentication
- REST APIs
- SDKs
- Command-Line Interfaces
Examples include:
- GitHub
- GitLab
- Kubernetes
- OpenShift
- Docker
- Terraform
- AWS
- Azure
- Google Cloud
- Jira
- Confluence
- Checkmarx
Will the Runtime architecture change over time?¶
The Runtime architecture is intentionally designed to remain stable.
New engineering platforms are integrated through Runtime Engines.
New engineering workflows are added as Engineering Capabilities.
This allows the ecosystem to evolve while preserving a consistent execution model.
Why not build one Runtime for each engineering platform?¶
Engineering teams typically work across many platforms.
A single Runtime provides a consistent execution model while Runtime Engines integrate platform-specific differences.
This reduces complexity for Humans, CI/CD systems and AI.
Is Engineering Runtime a replacement for DevOps?¶
No.
Engineering Runtime complements existing DevOps practices by standardizing how engineering operations are executed.
It works alongside existing engineering platforms, CI/CD systems and operational processes rather than replacing them.
What is the long-term vision for Engineering Runtime?¶
Engineering Runtime aims to become a universal deterministic execution platform for engineering.
The Runtime architecture remains stable while Runtime Engines continue integrating engineering platforms.
Engineering Capabilities continue growing by composing those Runtime Engines into reusable engineering workflows.
Over time, this creates an extensible ecosystem where Humans, CI/CD systems and AI can collaborate through a consistent execution model.