Publish an Immutable Release
Turn an approved preview into a traceable release without rebuilding or silently changing the artifact.
System map · Day 12
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — People and product entry points · Identity and policy · Generated application plane
HelixWorks control plane
Source-backed today
Approves one content-addressed application release rather than publishing a mutable branch or tag.
Delivery and desired state
Ahead — Git desired state · Argo CD reconciliation
CI and immutable artifacts
Source-backed today
Carries the exact artifact digest and build evidence from generation into the publish decision.
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths · Kubernetes or EKS control plane
Compute and traffic
Covered — Worker compute · Platform service workloadsAhead — Ambient mesh data plane
Generated app workloads
Source-backed today
Runs the approved artifact without changing its bytes between review and deployment.
Storage and evidence
Covered — Evidence and observabilityAhead — Infrastructure state · Cluster desired and live state
Product data and artifacts
Source-backed today
Preserves the immutable release record, artifact reference, approval, and publication status.
The enterprise problem and today’s slice
Enterprise problem: A customer can approve a HelixWorks preview, yet a publish pipeline that rebuilds from a mutable branch may expose different code, prompts, dependencies, or policies to end users. Whole-course context: The incoming evidence is a content-addressed artifact and provider collaborator state; today creates the local release record. Today’s slice: We bind owner authority, artifact digest, idempotency key, runtime payload, and audit action, while treating approval, signature, environment policy, DNS/TLS, and generated-app visibility as unimplemented production gates. End-of-day evidence: The restart/multi-instance test proves one release for a repeated key, and runtime plus audit records carry its artifact and release IDs; there is no live production endpoint proof. Still unsolved: Approval and promotion controls, subsequent change, rollback, and production operations remain deferred.
Customer outcome and implementation focus
The customer outcome is a reviewable publish an immutable release change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
Build service, image registry, release controller, and publication gateway; CI runners and runtime workloads; registry/object storage and release database; cache: not involved because a digest is the authoritative identity.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Build and publish an immutable release
Promote bytes, not branch names
A branch or mutable image tag can point at different content over time, which destroys the chain from review to deployment. The current model publishes the latest content-addressed artifact with an idempotency key; it does not implement the proposed ApplicationRelease custom resource, approval receipt, signature verification, or production promotion gate. Read the exact operation in services/control_plane/domain.py.
def publish(self, project: Project, actor: str, idempotency_key: str) -> dict[str, str]:
self._owner(project, actor)
if not idempotency_key:
raise ValueError("Idempotency-Key required")
existing = next((release for release in project.releases if release["idempotency_key"] == idempotency_key), None)
if existing:
return existing
Key takeaways
Publication is a policy-bound routing transition to an already reviewed immutable artifact.
- Approval must bind digest, environment, and policy version.
- Runtime readiness and customer response are stronger evidence than a successful pipeline.
- A denied candidate must leave the prior release observably healthy.
Checklist
A release is publishable only when review and runtime identity remain connected.
- [ ] Artifact is addressed by digest and signature result is recorded
- [ ] Approval binds exact inputs and target environment
- [ ] Provider, runtime, and generated-app authorizations remain separate
- [ ] Positive response and denied-candidate evidence include immutable IDs