Runtime Context¶
Introduction¶
Authentication answers an important question.
Who is performing the operation?
Engineering execution requires another equally important question.
Where should the operation execute?
This is the responsibility of Runtime Context.
Runtime Context captures the execution state required by Engineering Runtime before any Engineering Capability executes.
Without Runtime Context, engineering operations become ambiguous, error-prone and non-deterministic.
Examples include:
- Deploying to the wrong Kubernetes cluster
- Updating the wrong cloud project
- Creating repositories in the wrong GitHub organization
- Executing against the wrong environment
Engineering Runtime always executes Engineering Capabilities within an explicit Runtime Context.
What is Runtime Context?¶
Runtime Context represents the current engineering environment for execution.
It defines the execution state shared across one or more engineering platforms.
Examples include:
- GitHub Organization
- Cloud Project
- Kubernetes Context
- Kubernetes Namespace
- Jira Workspace
- Security Platform Tenant
- Environment
- Region
Runtime Context allows Runtime Commands to express engineering intent while the Runtime supplies the execution state.
Why Runtime Context?¶
Without Runtime Context, every command must repeatedly specify execution details.
Example:
Provider
Organization
Project
Cluster
Namespace
Region
Most engineering commands become configuration rather than intent.
Instead, Runtime Context captures this information once.
Runtime Commands then focus only on engineering intent.
Runtime Context vs Provider Context¶
Engineering platforms already provide their own context mechanisms.
| Platform | Native Context |
|---|---|
| Kubernetes | kubeconfig Context |
| Google Cloud | Project, Region |
| AWS | Profile |
| Azure | Subscription |
| GitHub | Organization |
| Docker | Docker Context |
Engineering Runtime does not replace these contexts.
Instead, Runtime Context orchestrates them into a single engineering execution context.
Runtime Context Architecture¶
Engineering Runtime
↓
Runtime Context
↓
GitHub Context
Cloud Context
Kubernetes Context
Jira Context
Security Platform Context
↓
Engineering Capability
↓
Runtime Engines
Runtime Context becomes the single source of execution state while Runtime Engines interact with engineering platforms.
Runtime Context Example¶
A Runtime Context might contain:
name: development
github:
organization: engineering
cloud:
project: engineering-dev
kubernetes:
context: development
namespace: applications
jira:
workspace: engineering
environment: development
region: australia-southeast1
Engineering Capabilities consume Runtime Context without requiring every command to repeat these values.
Runtime Context Lifecycle¶
Every engineering operation follows the same sequence.
Authenticate
↓
Load Runtime Context
↓
Resolve Provider Contexts
↓
Validate Policy
↓
Execute Engineering Capability
↓
Audit
Execution should never begin without a validated Runtime Context.
Runtime Context Switching¶
Engineering teams frequently work across multiple environments.
Examples include:
- Development
- Test
- Staging
- Production
Instead of specifying these targets on every command, Runtime Context manages the active engineering environment.
Example:
runtime context use development
Subsequent Runtime Commands automatically execute using the selected Runtime Context.
Runtime Context Validation¶
Before execution, Engineering Runtime validates the active Runtime Context.
Typical validation includes:
- Context exists
- Required provider configuration exists
- Authentication is valid
- Target environment is reachable
- Policy allows execution
Only after successful validation does execution continue.
Runtime Context and Engineering Capabilities¶
Engineering Capabilities should never hardcode execution targets.
Instead they consume Runtime Context.
Engineering Capability
↓
Runtime Context
↓
Runtime Engines
↓
Engineering Systems
This allows Engineering Capabilities to remain reusable across environments.
Human, CI/CD and AI¶
Every consumer follows the same execution model.
Human
↓
Runtime Context
↓
Engineering Runtime
↓
Runtime Engines
↓
Engineering Systems
CI/CD
↓
Runtime Context
↓
Engineering Runtime
↓
Runtime Engines
↓
Engineering Systems
AI
↓
Runtime Context
↓
Engineering Runtime
↓
Runtime Engines
↓
Engineering Systems
Different consumers.
Same Runtime Context.
Same deterministic execution.
Runtime Context vs Configuration¶
These are different concepts.
Configuration defines how Engineering Runtime behaves.
Examples include:
- Runtime Home
- Capability Registry
- Logging
- Policy Configuration
Runtime Context defines where Engineering Runtime executes.
Examples include:
- GitHub Organization
- Cloud Project
- Kubernetes Context
- Namespace
- Environment
Keeping Configuration and Runtime Context separate simplifies the Runtime architecture.
Benefits¶
Runtime Context provides:
- Simpler Runtime Commands
- Deterministic execution
- Cross-provider execution state
- Reduced command complexity
- Safer engineering operations
- Consistent execution
- Better governance
Design Principle¶
Runtime Context captures execution state so Runtime Commands express engineering intent.
Looking Ahead¶
Once Runtime Context has been established, the next responsibility is determining whether an Engineering Capability is allowed to execute.
The next article introduces Policy-Driven Engineering Execution.
Conclusion¶
Authentication identifies who is executing.
Runtime Context identifies where execution occurs.
Engineering Capabilities express what should happen.
Runtime Engines determine how engineering platforms are accessed.
Together they provide deterministic engineering execution.
Design Principle¶
Authenticate. Load Runtime Context. Execute Engineering Intent.
Next Article¶
Policy-Driven Engineering Execution