Meaning lives behind the canvas.
Resources, relationships, boundaries, and assumptions are intended to remain explicit and versionable.
Reviewable Architecture as Code for AWS
Diagram as Code, finally realized.
Cloud Markup is being built around a typed, versioned architecture graph, not the canvas, as the source of truth. The planned workflow connects deterministic validation with revision-bound Terraform, diagrams, findings, and evidence, while customer-owned systems retain credentials, approvals, state, and deployment authority.
For cloud architects, platform engineers, software teams, and everyone accountable for the handoff.
01Typed architecture graphVersioned meaning behind the visual
02Deterministic validationRules remain the acceptance authority
03No customer AWS access keysDelivery stays customer-owned
Why Cloud Markup
A cloud diagram should be more than a picture.
Most diagramming tools help teams communicate a visual. Cloud Markup is designed to preserve the architecture behind that visual, evaluate accepted changes with deterministic rules, and produce implementation artifacts that identify the same reviewed revision.
| Architecture concern | General-purpose diagramming | Cloud Markup |
|---|---|---|
| Primary outcome | Visual communication | Reviewable AWS architecture and handoff |
| Source of truth | Shapes, connectors, or diagram code | Typed, versioned semantic graph |
| AI role | Create or revise visual content | Planned proposals for user review and deterministic evaluation |
| Handoff | Diagrams and documentation | Planned artifacts tied to one reviewed revision |
Rules, not model confidence.
Accepted changes are designed to pass through versioned checks whose outcomes can be reviewed and reproduced.
Artifacts identify what they represent.
Planned diagrams, Terraform, findings, and evidence point back to the exact architecture revision.
Your systems keep deployment authority.
The intended boundary keeps credentials, approvals, state, and apply operations outside Cloud Markup.
The planned workflow
From intent to a reviewable architecture package.
One versioned path is intended to connect architecture decisions, validation, and the artifacts a delivery team reviews next.
-
01
Describe
Choose a deliberate starting point.
Begin with a blank canvas or curated pattern. AI-assisted proposals will appear only after model evaluation and production activation.
-
02
Design
Shape typed AWS architecture.
Configure typed AWS resources, valid relationships, network boundaries, workload behavior, and explicit assumptions.
-
03
Validate
Resolve what will matter later.
Evaluate accepted changes with planned versioned rules for structure, networking, security, cost-sensitive decisions, and IaC readiness.
-
04
Freeze and export
Hand off one exact revision.
Create a planned immutable revision and review its Terraform, diagrams, metadata, findings, evidence, and supported starter artifacts together.
Product walkthrough 01
From workload intent to a validated architecture revision
A 60-90 second product walkthrough will appear here after the application reaches production beta.
What it will show: a supported starting pattern, typed configuration, a reviewed change, deterministic validation, and the frozen revision identifier.
DEMO 01Intent to validated revision
Recording pending
Planned AWS scope
Focused AWS coverage, documented honestly.
Cloud Markup is being built for curated correctness, not a decorative service catalog. Initial work focuses on resources and relationships that can be validated and generated honestly. Verified beta coverage will be published from production behavior.
Application edge
API Gateway, Lambda, Cognito, IAM, and CloudWatch
Target scopeData and storage
DynamoDB and S3-backed application and event patterns
Target scopeNetwork boundaries
VPCs, subnets, routing, NAT, and security-group relationships
Target scopeEvents and workflow
SQS, DLQ, SNS, EventBridge, and supported Step Functions tasks
Target scopeScope standard: unsupported combinations should fail clearly. Production-beta behavior, not a marketing catalog, will determine the published support matrix.
Revision-bound artifacts
One exact revision. Multiple reviewable artifacts.
The planned export workflow assembles outputs a team can inspect before its own delivery systems decide what happens next. Each artifact identifies the architecture revision it represents.
Planned review package
- Terraform for supported patterns
- SVG and PNG architecture diagrams
- Metadata and revision manifest
- Validation findings and evidence
- Supported starter artifacts
Product walkthrough 02
From validated revision to customer-owned handoff
A 60-90 second artifact-review walkthrough will appear here after export behavior is production-ready.
What it will show: the same revision identity across Terraform, diagrams, metadata, findings, provenance, and a reviewable package with no hidden deployment step.
DEMO 02Validated artifact handoff
Recording pending
Trust is a product behavior
AI proposes. Deterministic rules decide what can be accepted.
Model-assisted creation is planned. AI would produce reviewable proposal data; it would not deploy infrastructure, access customer AWS credentials, or silently become architecture truth. Accepted changes are designed to follow the same versioned validation path as manual changes.
Proposals stay proposals.
A person is intended to review model-assisted changes before they enter the accepted architecture.
Validation remains reproducible.
Versioned deterministic rules, not a language model, are designed to remain the acceptance authority.
No hidden apply.
The intended boundary leaves credentials, approvals, state, and deployment inside customer-owned systems.
A product from Bluegrass Cloud
Cloud Markup carries Bluegrass Cloud's emphasis on explicit scope, ownership, validation, and handoff into a focused software product.
Questions, answered
What teams should know before product access opens.
Cloud Markup is in launch-readiness work. These answers describe the intended product boundary; production access and integrations remain subject to verification and release approval.
What is Cloud Markup?
Cloud Markup is being built as a reviewable AWS Architecture-as-Code workspace centered on a typed, versioned model, deterministic validation, and revision-bound artifacts.
How is it different from a general-purpose diagramming tool?
General-purpose tools emphasize visual communication. Cloud Markup is designed to make the architecture graph the source of truth and keep planned implementation artifacts tied to a reviewed revision.
Will Cloud Markup deploy infrastructure to AWS?
No hidden deployment step is part of the intended product boundary. Customer-owned systems retain AWS credentials, approvals, state, and deployment authority.
How is AI intended to participate?
Model assistance is planned to produce reviewable proposals. A person would approve changes, and deterministic domain rules would remain the validation authority.
What outputs are planned?
The planned export path is designed to assemble Terraform for supported patterns, diagrams, metadata, a revision manifest, findings, evidence, and supported starter artifacts.
What AWS scope is being evaluated?
Initial work focuses on curated application-edge, data, network, identity, event, and workflow patterns. Verified production-beta behavior will determine the published support matrix.
What does launch readiness mean?
The public application, signup, pricing, checkout, and third-party model access are not active today. Product access will be linked here only after release approval and a real signup or purchase path exist.
Build from architecture, not approximation
Make the handoff point to one exact architecture.
Cloud Markup is still in launch-readiness work. Explore the planned workflow now; product access will appear here when the production beta and its signup or purchase path are ready.
Review the planned workflow Review the planned AWS scope