Adoption Phases
A practical path from drop-in outputs to deeper runtime integration, without disrupting existing SDLC, CI/CD, and compliance workflows. Teams can adopt per workload, per product, or per team.
This page describes the design. Today, only the GPU optimization build at adaptwithchameleon.com runs. File-based output is re-established during the first 30 days of funded milestone work, and the OS-hosted runtime, illumin8 and the other Aptivs return when the milestones are complete. Wantware is not about writing or generating code as applications.
The two operating modes
Export Mode
The design lets Essence hand conventional artifacts to existing CI/CD pipelines, scanning tools, and deployment frameworks unchanged, so nothing in your tooling has to change. This is an interface to existing systems, not the purpose of wantware, which is not about writing or generating code as applications. File-based output is re-established during the first 30 days of funded milestone work.
Essence Runtime Mode
Execution occurs dynamically within Essence. Fixed builds may still be generated when required for compliance scanning, validation, or certification workflows, but the primary execution path uses governed runtime rather than static binaries.
The adoption phases
Phase 1 · Export Mode (Fast Path)
By design, Essence hands conventional artifacts to your existing pipeline once file-based output is re-established.
What Plugs In Directly
- Version control: Git, GitHub, GitLab as-is
- Build: Jenkins, GitHub Actions, GitLab CI, Azure DevOps
- Security scanning: SAST, DAST, dependency scanners, license checks
- Artifacts: Nexus, Artifactory, container registries
- Deploy: your current targets (VMs, containers, cloud)
Teams that want immediate compatibility and governance with minimal change.
Phase 2 · Hybrid (Export + Controlled Runtime)
Keep standard builds for compliance where needed, while introducing controlled runtime behaviors for specific workloads.
What Changes
- Two outputs: fixed scan-ready builds plus runtime-optimized execution where appropriate
- Policy gates: choose which workloads are fixed vs adaptive
- Validation: artifacts and proofs generated per pilot workload
- Observability: clearer who / what / when / why audit trails
- Team workflow: collaborative iterations without breaking existing repo discipline
Regulated teams that need a clean compliance path while proving runtime value.
Phase 3 · Essence Runtime Mode (Deep Integration)
Execution occurs dynamically within Essence, with controls for trust, traceability, and operational governance.
What Governed Runtime Enables
- Runtime governance: policies, access controls, and declared-purpose enforcement
- Traceability: lineage and audit across versions, forks, and owners
- Security posture: trust plus validation enforced continuously, not only at build time
- Performance: adaptive optimization per device and execution conditions
- Interoperability: still supports exporting fixed builds when required
Organizations pursuing maximum operational leverage and runtime assurance.
These phases can be adopted per team, per product, or per workload. You don't need a big-bang migration. Compliance workflows can stay in Phase 1 while exploratory pipelines move to Phase 3, all backed by the same Essence source base.
Adoption is a continuum, not a cliff. Start where your risk tolerance and compliance constraints allow, prove value on bounded workloads, and expand the runtime footprint as operational readiness grows.