II. Declared Context

The Requirement

All execution requirements must be explicitly defined and version-locked within The Asset.

The Problem

“It works on my machine” is not a bug report. It is a failure to define your asset properly.

Many teams have adopted containerisation, which is a step in the right direction. But if your application relies on infrastructure managed by a separate ops team via tickets or out-of-band requests, you have not declared your execution context. The Asset remains incomplete.

The Practice

A hermetic asset declares everything required to execute:

• Container definitions (Dockerfile) specifying exact base images
• Infrastructure-as-Code (main.tf, pulumi/, helm/) living in the same repository
• Runtime configuration versioned alongside the code
• Environment requirements made explicit

If you consume shared modules from a platform team, the declaration of those modules and their pinned versions must live within your asset. The platform team provides the building blocks; you assemble them.

The Litmus Test

If all existing infrastructure was destroyed, could you redeploy from The Asset alone? If recovery requires manual steps, tribal knowledge, or ticket queues, your context is not fully declared.

What This Enables

The Asset defines its own reality. Any infrastructure drift is corrected at deploy time because the desired state is versioned with the code. Disaster recovery becomes boring: you simply redeploy The Asset.

Environments stop being pets that require careful nurturing. They become disposable resources, reproducible anywhere, anytime, exactly as defined.