Adoption Maturity Model
A four-stage model for where teams typically enter Wantware and how they progress as operational readiness grows. Each stage earns its place — advancement isn't automatic, and workloads at different stages can coexist.
Stage 1 · Build-Time Assurance
Where Teams Enter
Teams running existing SDLC and compliance workflows adopt Wantware as a generator for standard build outputs. The toolchain stays the same; Essence produces source and artifacts that flow through existing CI/CD.
What's in Place
- Exported artifacts pass through standard pipelines (Git, Jenkins, SAST/DAST)
- SBOM, scan reports, and signed builds for every release
- No runtime changes required
- No new monitoring pipeline to operate
What Success Looks Like
- First workloads shipped without operational disruption
- Compliance posture unchanged or improved
- Team comfortable with the generator workflow
Stage 2 · Trust Certification
What Changes
Teams begin producing signed, portable certification bundles per release. This turns audit evidence into a distributable artifact — reducing questionnaire overhead and compressing vendor-security review cycles.
What's in Place
- Signed bundles per release: SBOM, scan reports, attestations, policy snapshots
- Bundles delivered to enterprise customers on procurement review
- Bundles sampled for continuous compliance review
- Incident response procedures reference bundles for affected versions
What Success Looks Like
- Vendor questionnaire time reduced measurably
- Audit evidence gathering less manual
- Incident response faster because bundles exist before incidents
Stage 3 · Governed Runtime
What Changes
Selected workloads move to governed runtime execution with declared purpose, policy enforcement, and runtime monitoring. This is where the continuous-assurance model starts delivering operational value beyond build-time checks.
What's in Place
- Workloads declare purpose at execution time
- Policy gates at deploy-time and runtime
- Drift detection on live workloads
- Mixed-mode operation: scan-ready for regulated, adaptive where value is clear
What Success Looks Like
- At least one critical workload operating in governed runtime
- Policy violations detected and handled in production
- Runtime optimization producing measurable performance or cost outcomes
Stage 4 · Full Execution Telemetry
What Changes
Governed runtime scales to the workload footprint that benefits from it. Telemetry feeds the SIEM continuously, evidence bundles regenerate on schedule, and governance reporting is derived directly from execution — not reconstructed from fragmented logs.
What's in Place
- Policy-linked audit events stream continuously to SIEM / observability
- Scheduled evidence exports for compliance windows
- Incident bundles generated automatically for flagged events
- Governance dashboards derived from live event streams
- Cross-workload reporting on policy, purpose, and drift
What Success Looks Like
- Compliance review cycles shortened substantially vs Stage 1
- Audit questions answered from the event stream rather than from bespoke queries
- Incident mean-time-to-respond materially improved
- Risk posture describable in terms of policies and purposes, not just identities and resources
Progression at a glance
| Stage | Defining Characteristic | Typical Time-to-Enter | Primary Value |
|---|---|---|---|
| 1 · Build-Time Assurance | Export Mode in existing pipelines | Weeks | Zero-disruption adoption |
| 2 · Trust Certification | Signed, portable evidence bundles | Quarter | Faster vendor reviews, better audit evidence |
| 3 · Governed Runtime | Purpose, policy, drift detection per workload | Quarters | Continuous assurance on selected workloads |
| 4 · Full Execution Telemetry | Governance derived directly from runtime | Year+ | Compliance as a property of execution, not a reconstruction |
How to use this model
As a Starting Point
Most teams don't know where to enter. Stage 1 is almost always the right starting point — it validates the generator workflow without taking on runtime risk. Skip Stage 1 only if the team already has strong runtime-governance practice on non-Essence workloads.
As a Roadmap
Each stage has concrete "in place" and "success" markers, so progression is objective rather than aspirational. Teams can plan a quarter-by-quarter or year-by-year journey with clear gates between stages.
As a Conversation
The model helps engineering, security, and compliance speak the same language about adoption. Instead of debating whether to "use Essence," teams can debate which stage they're at, what it would take to advance, and which workloads should advance first.
Adoption compounds. Each stage makes the next stage cheaper — Stage 1's bundles feed Stage 2's certification process, Stage 2's bundles inform Stage 3's policy authoring, Stage 3's runtime feeds Stage 4's continuous telemetry. Teams that stop at Stage 1 still get value; teams that progress get more value per workload.