Validation & Rule Suggestions

Strata is design-first: it helps you catch problems and apply best practices before you build the infrastructure. Two actions support this, available in both the Analyze ▾ menu (top bar) and the inspector (right panel): Validate architecture and Suggest rules.

Where to run them

• Analyze ▾ menu — Validate architecture and Suggest rules.
• Inspector panels — at the bottom of the inspector are a Validation panel (with a Run button) and a Rule Suggestions panel (with a Generate button). These are always visible, even when no node is selected.
• Command palette — Validate architecture and Suggest rules (under Tools).

All three trigger the same checks against the current canvas.

Validate the architecture

Run Validate architecture (or click Run in the inspector’s Validation panel) to run a set of best-practice checks across your whole diagram. Results come back as a list of findings, each tagged with a level:

• error — something that is wrong or will not work as drawn.
• warn — a likely problem or a best-practice deviation worth reviewing.
• ok — a check that passed.

When everything passes, the panel reads “No issues found.”

The checks reason over the typed graph — your resources and the relationships between them — rather than just looking at isolated nodes. For example, they understand containment (which subnet an instance sits in, which VPC a subnet belongs to) whether that containment was drawn by hand or reconstructed from an import, and they validate things like CIDR ranges nesting correctly inside their parent network.

What gets checked

Two families of checks run, across AWS, GCP, and Azure:

• Network topology — subnets contained by a VPC, CIDR ranges nesting inside their parent, public subnets routing to an Internet Gateway, NAT gateways in public subnets, load balancers spanning multiple Availability Zones, and so on.
• Security & Well-Architected best practices — read from each resource’s configuration, e.g. public S3 / Cloud Storage / Blob buckets, data not encrypted at rest, sensitive ports (SSH/RDP/database) open to the whole internet, publicly accessible databases, missing backups / point-in-time recovery / deletion protection, IMDSv1 still allowed, and HTTP-only (unencrypted) load-balancer listeners. These fire only on an explicitly insecure value, so secure defaults don’t create noise.

A finding tied to a specific resource is also dotted on that node on the canvas (colour-coded by severity), not just listed in the panel — so you can see at a glance which resources need attention.

Tip: validation runs against the current state of the canvas, so re-run it after making changes.

Suggest rules

Run Suggest rules (or click Generate in the inspector’s Rule Suggestions panel) to generate concrete, best-practice configuration suggestions for the supporting resources your architecture implies — for example:

• Security group ingress rules (e.g. public HTTP/HTTPS to a load balancer, and load-balancer-to-service rules for the targets behind it).
• Route table routes (e.g. an Internet Gateway route for public subnets, a NAT Gateway egress route for private subnets).

Each suggestion is grouped by the resource type and scope it applies to and describes the rule in plain terms (direction, protocol, port, source/target, and a comment explaining why). Use these as a checklist when you turn the design into real infrastructure. If your diagram doesn’t imply any such rules yet, the panel reads “No suggestions yet—add ALB/Service, Subnets, NACLs…”.

A typical workflow

1. Draw or import your architecture.
2. Run Validate architecture and resolve any errors and warnings.
3. Run Suggest rules to see the security-group and routing rules your design implies.
4. Save the diagram once you’re happy with it.

Both run against the current state of the canvas, so re-run them after making changes.