Verified, not guessed
Three runs from production, unedited. A plain-English request goes in; a deterministic Terraform build comes out — but only when every gate passes. When the build can't be guaranteed, deplovox declines and says so. What you're looking at is the rigor, not a rendered demo.
A Flask API on Fargate with Postgres
Deploy a single Flask reporting API on AWS Fargate with a PostgreSQL database behind a load balancer.
What it built
- One VPC — public + private subnets, single NAT gateway
- ECS Fargate service (2 tasks) behind an Application Load Balancer
- RDS PostgreSQL (db.t4g.medium) in private subnets
- Security groups chained ALB → app → database (least privilege)
- Amazon ECR repository + a CloudWatch CPU alarm on the service
Gates that passed
- terraform validate — passed — the generated template validates clean (1 pass, 0 errors).
- Consistency — 0 dangling references — every module output is referenced; no orphaned resources.
- Reconciliation — 0 blocking, 0 warnings — the services requested equal the services provisioned.
- Database wired by secret field, not blob — the DB password is injected as the RDS-managed secret's :password:: field — never the whole JSON secret.
- Deployability 100% · manual intervention Low — the confidence read is computed from the artifact, not asserted by a model.
| NAT gateway (single) | $32.85 | aws.amazon.com |
| Application Load Balancer | $16.43 | aws.amazon.com |
| RDS db.t4g.medium | $47.45 | aws.amazon.com |
| RDS storage, 20 GB | $2.30 | aws.amazon.com |
| Fargate 2 × 0.5 vCPU / 1.0 GB | $36.04 | aws.amazon.com |
Fixed-cost floor of always-on resources only (us-east-1, on-demand). Usage-based charges — data transfer, requests, storage growth — are additional and not included. A floor, not a full bill.
Service-verified citations
Storefront + API + worker, one shared database
Deploy a Remix storefront frontend, a Spring Boot catalog backend API, and a background worker for order-confirmation emails, all sharing one PostgreSQL database, behind an Application Load Balancer with /api path routing.
What it built
- Three Fargate services — frontend, backend (API), worker — in one VPC and one ECS cluster
- One Application Load Balancer: a target group per HTTP service, /api/* routed to the backend
- The worker runs off the load balancer — no public ingress to the background tier
- One shared RDS PostgreSQL, one SQS queue (+ dead-letter queue), SES for transactional email
- The shared database is wired into the API and worker only — the frontend receives no credentials
Gates that passed
- Three services present — no silent collapse — frontend + backend + worker are each emitted as their own ECS service; the deterministic guard rejects a collapse into one.
- ALB /api/* → backend, per-service target groups — path-based routing is verified in the emitted template.
- Worker has no load balancer — the background tier is not publicly reachable.
- Shared datastore wired into api + worker only — DB_HOST and the :password:: secret field are injected into the data-plane services — the frontend gets nothing.
- terraform validate + 0 blocking reconciliation — 100% completeness, Low manual intervention.
Service-verified citations
A separate database per service
A SolidStart frontend and a NestJS backend, where each service owns its own separate PostgreSQL database.
Why it declined. The deterministic builder models one shared datastore wired into the data plane. A separate database per service is a genuinely different topology it does not model.
Why that's the point. So it declines — rather than quietly hand back a shared database you never asked for. When the deterministic path can't guarantee the shape you described, it steps aside instead of guessing. The guarantee is never faked to widen coverage.
You still get an answer. The request still gets an answer: a general-purpose LLM plan takes over, clearly labeled as a best-effort draft — not presented with the verified badge the two builds above carry.
How every run is checked
The verified badge isn't a vibe — it's a specific set of gates that all have to pass before you see a build.
It builds deterministically first
For covered shapes, the Terraform is assembled by code from a vetted, version-pinned module set — not written token-by-token by a model. Same request, same bytes, every time.
Then it checks its own work
terraform validate, a consistency pass that fails on any dangling reference, and a reconciliation that confirms the services you asked for are the services actually provisioned — and are wired to each other.
It grounds every citation
Each cited service is matched against official AWS documentation. Citations it can't verify are downgraded or labeled, never left standing as if confirmed.
It prices to a sourced floor
The monthly cost is computed from published AWS pricing, line by line, each with its source — presented as a fixed floor with the usage caveat stated, not a number to trust blindly.
And it declines when it can't be sure
Outside the covered shapes, deplovox hands off to a labeled LLM draft rather than shipping a confident-looking guess. The verified badge means verified.
What we don't claim
- Not a claim that these are the only right architectures — they're one sound, buildable answer to each request.
- The cost figure is a fixed-resource floor, not a full bill; usage-based charges are additional and stated as such.
- The declined run is not a failure — it's the boundary working. Coverage is deliberately narrow so the verified badge stays honest.
Want the stress test instead of the highlight reel? See the nine-run proof matrix — the same complex app built nine times across AWS, Azure, and GCP — and how the pipeline works on the trust page.