Docs
A short, honest guide to getting a good plan out of infra god — and reading what comes back. For how the plans are made trustworthy, see the trust page.
Write a good prompt
- Describe the app in a sentence or two — what it does, plus the runtime, framework, and database if you know them.
- State your scale (traffic or data volume), budget priority, and any compliance (HIPAA / PCI / GDPR). These genuinely change the architecture.
- Set an availability target (e.g. 99.9%) so it recommends the right redundancy — multi-AZ, replicas, failover.
- Pick your cloud, or let it recommend one from your stack; choose Terraform, or CloudFormation on AWS.
- Name any existing infrastructure to reuse (a VPC, an account) so the plan wires into what you already run.
- More specific input gives a more right-sized, better-cited plan — the specificity meter in the tool nudges you toward the fields that matter.
What each part of the output means
- Architecture
- The design in plain language — an overview, a component table, and the data flow — with inline [Source N] citations on factual claims.
- Sources
- The numbered [Source N] references, each linking to an official documentation URL on the cloud provider's own site.
- Validation
- A visible ✓ / ✗ checklist: a quality review of the architecture and a Well-Architected-style security review of the code, shown pass or fail.
- Infrastructure as code
- Deployable Terraform (or CloudFormation on AWS), generated section by section, assembled deterministically, and checked for zero dangling references — copy it or download it.
- Deploy guide
- The exact CLI / console steps to provision and ship the stack on your chosen cloud.
- Manifest
- A downloadable record of the run — your inputs, the docs-corpus version, the model IDs, and pinned provider versions — so the result can be traced and regenerated.
- Estimated footprint
- An estimated energy and CO₂e figure for the compute that produced the plan, shown with its formula and sources — an estimate, not a measurement.
Limits, honestly
- Not "guaranteed to deploy." Grounded, cited, validated, and consistency-checked are necessary conditions for a good plan — not a promise that `terraform apply` or `cloudformation deploy` succeeds in your specific account, region, or quota.
- A citation verifies a FACT — that a service exists or supports a feature — not that the chosen service is the OPTIMAL fit for your workload. The architecture judgment is still yours to review.
- Terraform is syntax- and consistency-checked in the request path, not fully `terraform validate`-d with providers (that runs in our CI gate). cfn-lint gives CloudFormation deeper schema linting in-path — an honest asymmetry, not parity.
- The validator is advisory: it flags gaps (see the failed Azure run on the proof page) rather than blocking the result.
- Energy and carbon figures are transparent estimates with their formula and sources shown — not measurements.