Adaptive vs Scan-Ready Modes
Essence supports two execution postures: scan-ready: static artifacts that behave like conventional software, and adaptive: governed runtime that optimizes within explicit policy bounds. The choice is per workload, not platform-wide.
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.
Scan-ready gives you point-in-time assurance. Adaptive gives you continuous assurance. Neither is universally better; they serve different workloads and different risk postures.
Scan-Ready Mode
The workload behaves like a conventional build output: a fixed artifact scanned, signed, and deployed. Runtime behavior is bounded by what the binary was compiled to do. Assurance derives from analyzing the artifact itself.
What Scan-Ready Is Good At
- Static analysis: SAST, SCA, license, vulnerability scans all apply directly
- Compliance certification: maps cleanly onto existing audit frameworks
- Reproducible builds: the same inputs produce the same artifact, verifiable by anyone
- Pipeline portability: any CI/CD can produce, sign, and deploy it
- Predictability: runtime behavior is the behavior the binary was compiled for
What Scan-Ready Gives Up
- Runtime optimization opportunities
- Continuous purpose enforcement
- Behavior-level telemetry beyond standard logs
- Adaptive response to runtime conditions
Adaptive Mode
The workload runs under governed runtime. Declared purpose, policy enforcement, and runtime monitoring apply continuously. The platform can adapt execution (within policy bounds) to environment, load, and declared intent.
What Adaptive Is Good At
- Dynamic optimization: runtime tuning within policy-allowed behavior
- Purpose enforcement: runtime checks against declared intent
- Policy controls: allow / deny / conditional behaviors applied while running
- Telemetry depth: richer execution traces tied to policies and purposes
- Continuous assurance: trust is checked during execution, not only at build
What Adaptive Requires
- Runtime environment that supports the governed execution model
- Policies authored to express the allowed behaviors
- Monitoring pipelines that consume runtime telemetry
- Organizational readiness to operate the continuous-assurance model
Capability comparison
| Capability | Scan-Ready | Adaptive |
|---|---|---|
| Static review & scanning | Native | Available on exported snapshots |
| Compliance certification | Native | Via exported certification bundles |
| Runtime optimization | Limited to build-time | Continuous within policy bounds |
| Purpose enforcement | Not applicable | Continuous at runtime |
| Behavioral telemetry | Standard logs | Policy-tied audit events |
| Incident forensics | Log reconstruction | Execution lineage with purpose trail |
| Operational overhead | Minimal | Policy authoring + monitoring pipeline |
Mixing modes per workload
A single organization often runs both modes simultaneously, each for the workloads where it earns its place:
Typical Scan-Ready Workloads
- Regulated transaction processing
- Customer-facing services under strict change-control
- Long-lived batch jobs with stable behavior
- Workloads requiring audit-style reproducibility
Typical Adaptive Workloads
- AI/agent services with declared-purpose boundaries
- Analytics pipelines that benefit from runtime optimization
- Internal developer platforms where operational telemetry matters
- Multi-tenant workloads with strong per-tenant scoping requirements
Pick the mode that matches the workload's risk posture and operational value. Scan-ready is honest and predictable and plays well with existing frameworks. Adaptive is continuously governed and better fits workloads where behavior (not just the compiled artifact) is the thing that needs assurance.