Legacy AWS topology
The previous delivery model is being replaced. All new inquiries are paused. Read Managed Verse →.
In the legacy CLI, a named run combines an isolated VPC, public application routing, private service context, EKS capacity, an EC2 utility backend, S3 lab data, IAM simulation, SSM parameters, and CloudWatch observability. The exact configuration depends on the selected scenario and tier.
The AWS load balancer exposes generated scenario portals and APIs through its own DNS name. Access is constrained to the configured operator CIDR. Private systems and data boundaries give the public surface context without requiring a separate public address for every component.
Provisioning an EKS cluster does not itself install the dedicated telecom services. That runtime has its own installation step and release artifact. This lets infrastructure ownership and application delivery be reviewed separately.
A concrete service dependency
The telecom Kubernetes runtime has a small, explicit dependency chain. A behavior runner makes requests to the customer portal. The portal uses provisioning, and provisioning queries inventory. The runner has no inbound HTTP service.
Customer portal
Exposes customer identity and line information through public application routes.
Provisioning
Resolves customer and line relationships through internal service routes.
Inventory
Supplies the device records associated with those lines.
Readiness follows the same chain, so the portal readiness check also exercises its dependencies. Trace context links the requests across services. In this legacy installation, the Kubernetes target is staged with zero listener weight; public traffic remains on the existing EC2 backend.
Four responsibilities in the reference design
The previous delivery model separates the parts of the reference platform that authorize work, perform work, present the target, and retain evidence. The examples describe their intended security boundaries, independently of the planned Managed Verse offering.
| Plane | Responsibility | Boundary |
|---|---|---|
| Control | Review intent, authorize a run, and manage lifecycle. | Owns policy and assignment, rather than target content. |
| Agent | Execute a candidate within its permitted task and budget. | Must not inherit operator credentials or hidden judging material. |
| Target | Run the exercise systems and synthetic data. | Target output is untrusted input to the candidate. |
| Telemetry | Collect and verify the record used for review. | Must remain independent of candidate claims. |
Scenario meaning and cloud placement
A scenario should describe services, identities, access relationships, data, and expected behavior. Provider placement then explains how those requirements map to concrete infrastructure. Keeping those decisions separate makes it possible to inspect whether a cloud implementation preserves the exercise.
For example, a private inventory service must remain private when its deployment changes. Replacing an AWS service with a similarly named service elsewhere would not prove that its access boundary, evidence, and cleanup behavior remain equivalent.
The repository contains portable planning and provider projection foundations, including local simulation of lifecycle behavior. The legacy CLI described here is AWS specific. Its offline Azure and Google Cloud examples do not specify the underlying provider integrations of planned Managed Verse.
Bind actions to an exact attempt
The evaluation reference architecture connects an agent plan to a specific run, generation, candidate, task, target configuration, and permitted tool set. A target binding maps a permitted operation to a trusted route. The candidate receives an opaque handle rather than authority to choose an arbitrary destination.
A supervisor checks the assignment and budgets. An effect broker checks the requested operation and records its decision. Local signed evidence links the request, execution start, and result so an allowed request is distinguishable from a completed action.
These particular examples are local reference components. Their scope does not specify planned Managed Verse sandboxing, broker delivery or evidence collection. A local signature establishes a narrower fact than a verified cloud execution.
Ownership continues through cleanup
The CLI keeps separate state and Terraform data for each named run. New runs bind account scope, run identity, generation, reviewed plans, and Terraform state checkpoints. Deployment and destruction use reviewed saved artifacts rather than silently substituting a new plan at application time.
After destruction, the CLI checks that the bound Terraform inventory and root outputs are empty before recording the run as destroyed. This is a meaningful closure check for the managed state. It is not an independent scan proving that no resource remains anywhere in the AWS account.
Operators should retain the run state until cleanup is verified and investigate incomplete destruction through the recorded logs. The deployment guide covers the practical workflow; evidence and replay explains what can be established from retained records.