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.
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.