StackToIT Migration Intelligence Workspace

Executive lens: the sections are in the order this reader usually wants, and Architecture and Engineering Evidence are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Architect lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Platform lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Security lens: the sections are in the order this reader usually wants, and Costs and Migration Plan are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Application owner lens: the sections are in the order this reader usually wants, and Engineering Evidence is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Programme lens: the sections are in the order this reader usually wants, and Engineering Evidence is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

FinOps lens: the sections are in the order this reader usually wants, and Architecture and Engineering Evidence are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Engineering lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Evidence

The counts, versions and sources behind every statement in this workspace.

Evidence counts (over the 93 units listed on the Architecture page)
Units with at least one evidence reference	90
Evidence references	376
Findings	213: 1 critical, 115 warning, 42 info; 55 of the findings are on units a count or for_each of zero switches off and are counted apart from the severities of the active units: 45 warning, 10 info
Units whose target is offered in a region by a catalogue snapshot	17

Where each unit leads to

Every unit leads from its source through its intent and its plan to the blocks of the draft and the checks over them. A stage that reads unsupported is not produced by this build (the blocks of that family are written by a generator that records them without an intent or a plan); one that reads not available is produced by this build and made nothing in this run; none means nothing applies at the stage, and the reason is in workspace.json (units[].refs). None of these is a finding of no risk. A unit whose evidence coverage is not traced has no evidence drawer.

Units by family and state at each stage (93 units; 38 lead to a block of the draft, 53 blocks, 64 links)
Family	Units	Evidence drawers	source	intent	plan	hcl	validation
`AWS_SECURITY_GROUP`	15	15	ESTABLISHED 15	ESTABLISHED 12 NONE 3	ESTABLISHED 1 OPEN 6 NONE 8	ESTABLISHED 7 NONE 8	ESTABLISHED 12 NONE 3
`AWS_ROUTING`	6	6	ESTABLISHED 6	ESTABLISHED 2 NONE 4	NONE 6	NONE 6	ESTABLISHED 2 NONE 4
`AWS_IDENTITY_ATTACH`	5	5	ESTABLISHED 5	ESTABLISHED 5	OPEN 5	ESTABLISHED 5	ESTABLISHED 5
`LOG_SOURCE`	6	6	ESTABLISHED 6	ESTABLISHED 2 NONE 4	OPEN 1 NONE 5	ESTABLISHED 1 NONE 5	ESTABLISHED 1 NONE 5
`LEGACY_GENERATOR`	61	25	ESTABLISHED 61	NONE 30 UNSUPPORTED 31	NONE 30 UNSUPPORTED 31	ESTABLISHED 25 NONE 36	NONE 30 UNSUPPORTED 31

A unit id is its Terraform address: renaming a resource in the source is a new unit. Continuity of a unit across a rename is not built (a semantic fingerprint is a later item).
An id names an object and holds no run: the same estate gives the same ids in every run. The JSON pointer into a file of the report is valid for the run named in header.run.
A line is given only for a block of the draft that parses as HCL. A block the draft writes as a comment has a file and no line, and a block the report could not place has neither.
A hop that reads UNSUPPORTED is not produced by this build; one that reads NOT_AVAILABLE is produced by this build and made nothing in this run. Neither is a finding of no risk.

The reverse table (which unit every block of the draft comes from, with its file and line) is evidence_index.targets in engineering/evidence-index.json; workspace.json states how many entries it has. A block written as a comment has a file and no line; no line is ever invented. A block that has a comment in the draft ends it with a # trace: TR-... line; the reverse table gives that id (trace_id, the anchor of the block's section) and its file (trace_file, engineering/trace/<draft file>.md, one for each file of the draft), the section holds the whole comment the generators wrote for the block, and engineering/trace-index.csv lists them all.

Findings that repeat on several units

213 finding records. 19 groups hold 166 of them: findings of the same check, severity, message and evidence on two or more units, shown once with every unit they concern. 47 are on one unit only. A group is a view: the records stay in assessment.json, a group has no status, and nothing in it is accepted. Findings that differ in wording or severity are never merged.

dynamodb-secondary-indexes · info · 3 units, 3 records

Secondary indexes become MongoDB indexes on the collection; projections and the eventual consistency of global secondary indexes do not carry over.

Units: module.dependencies.module.dynamodb_carts.aws_dynamodb_table.autoscaled, module.dependencies.module.dynamodb_carts.aws_dynamodb_table.autoscaled_gsi_ignore, module.dependencies.module.dynamodb_carts.aws_dynamodb_table.this

ecs-service-discovery · warning · 5 units, 5 records

Services find each other through Cloud Map / Service Connect; on SKE this becomes Kubernetes Services and DNS.

Evidence: https://registry.terraform.io/providers/stackitcloud/stackit/0.116.0/docs/resources/ske_cluster

Units: module.retail_app_ecs.module.carts_service.aws_ecs_service.this, module.retail_app_ecs.module.catalog_service.aws_ecs_service.this, module.retail_app_ecs.module.checkout_service.aws_ecs_service.this, module.retail_app_ecs.module.orders_service.aws_ecs_service.this, module.retail_app_ecs.module.ui_service.aws_ecs_service.this

iam-inline-kms · info · 2 units, 2 records

A policy of this role grants KMS actions. STACKIT KMS access comes from role assignments on an organisation, folder, project or service account, not on a key ring or key (stackit_kms_key has no policy or grant attribute in the pinned STACKIT provider), so a per-key permission widens to every key of the project. What to decide: which identities may use and which may administer keys, and whether keys that need different access move to their own project.

Evidence: https://docs.stackit.cloud/platform/access-and-identity/roles-permissions/roles-permissions/, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/authorization_project_role_assignment, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/kms_key

Units: module.retail_app_ecs.module.catalog_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.orders_service.aws_iam_role.task_execution_role

iam-inline-secrets · info · 2 units, 2 records

A policy of this role reads or writes secrets or parameters. STACKIT Secrets Manager grants access with role bindings on the instance and on secret groups (stackit_secretsmanager_instance_role_binding_v1, stackit_secretsmanager_secret_group_role_binding_v1; documented roles Secrets Manager Reader and Admin) and with users that carry credentials. What to decide: per secret group, which identity reads and which writes. One more limit exists per instance: a source-address list (stackit_secretsmanager_instance acls, IP addresses or CIDR ranges that may reach the instance), the nearest thing to an aws:SourceIp condition; there is no per-identity or per-secret condition.

Evidence: https://docs.stackit.cloud/products/security/secrets-manager/how-tos/kms-encryption-in-the-secrets-manager/, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/secretsmanager_instance, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/secretsmanager_instance_role_binding_v1

Units: module.retail_app_ecs.module.catalog_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.orders_service.aws_iam_role.task_execution_role

iam-managed-customer-policy · info · 3 units, 3 records

This attachment names a customer-managed policy of this estate (an aws_iam_policy), not an AWS-managed one. STACKIT has no managed-policy object to attach: the permissions become role assignments of the service account (stackit_authorization_project_role_assignment: resource_id, role, subject), decided from the policy's document, whose shape is reported on the policy itself (a Deny, a Condition and sts:AssumeRole are UNSUPPORTED there; the service families s3, kms, secrets, logs, ec2 and iam name the STACKIT role or credential). What to decide: the roles of this role's service account from the findings of every policy attached here, and whether one policy shared by several roles becomes one set of role assignments or several.

Evidence: https://docs.stackit.cloud/platform/access-and-identity/roles-permissions/custom-roles/, https://docs.stackit.cloud/platform/access-and-identity/roles-permissions/roles-permissions/, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/authorization_project_custom_role, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/authorization_project_role_assignment

Units: module.retail_app_ecs.module.catalog_service.aws_iam_role.task_role, module.retail_app_ecs.module.orders_service.aws_iam_role.task_role, module.retail_app_ecs.module.ui_service.aws_iam_role.task_role

iam-managed-customer-policy · info · 2 units, 2 records

Units: module.retail_app_ecs.module.carts_service.aws_iam_role.task_role, module.retail_app_ecs.module.checkout_service.aws_iam_role.task_role

iam-managed-ecs · info · 5 units, 5 records

Managed policy of an ECS role (AWS: task execution pulls images from ECR and writes CloudWatch Logs; the container-instance role registers hosts with ECS). STACKIT has no ECS: image pull is a registry credential (Container Registry roles, Guest is read-only) and log shipping a platform or credential setting (stackit_logs_access_token); no STACKIT role replaces these grants. Container Registry: STACKIT offers this service. A public STACKIT API exists for it. The pinned Terraform provider has no resource for it. StackToIT does not draft automation for it yet; extra implementation is needed. (schema checked 2026-10-11: none of the 115 resource types of the pinned STACKIT provider), so the pull credential is not drafted (project roles: docs.stackit.cloud, updated Jul 2, 2026). What to decide: the registry pull credential and the log destination of the replacing workload.

Evidence: STACKIT provider schema 0.119.0, https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerServiceforEC2Role.html, https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSTaskExecutionRolePolicy.html, https://docs.stackit.cloud/products/developer-platform/container-registry/how-tos/securing-access-with-role-based-access-control-_rbac_/, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/logs_access_token

Units: module.retail_app_ecs.module.carts_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.catalog_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.checkout_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.orders_service.aws_iam_role.task_execution_role, module.retail_app_ecs.module.ui_service.aws_iam_role.task_execution_role

iam-trust-service-workload · info · 10 units, 10 records

Trust policy: lambda.amazonaws.com or ecs-tasks.amazonaws.com assumes this role, so an application workload (a Lambda function or an ECS task) runs as it. On STACKIT the workload runs as a service account (stackit_service_account) and nothing assumes it: it authenticates with a service account key (stackit_service_account_key, key flow) or, on SKE, by Workload Identity Federation (a federated identity provider on the account). What to decide: key or federation, and the roles of the attached policies (see the permission findings of this unit).

Evidence: https://docs.stackit.cloud/platform/access-and-identity/service-accounts/, https://docs.stackit.cloud/platform/access-and-identity/service-accounts/authentication-flows/, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/service_account, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/service_account_federated_identity_provider, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/service_account_key

linked-dependency-unread · warning · 2 units, 2 records

This unit names module.dependencies.module.dynamodb_carts.aws_dynamodb_table.this (aws_dynamodb_table), whose own decision the target does not carry (it is REDESIGN), and the semantic contract of aws_iam_role does not read aws_dynamodb_table, so what the reference becomes is not assessed.

Units: module.retail_app_ecs.module.carts_service.aws_iam_role.task_role, module.retail_app_ecs.module.checkout_service.aws_iam_role.task_role

role-aws-service-principal · info · 2 units, 2 records

This is a service role used by AWS itself (EKS control plane, RDS monitoring, flow logs, CloudWatch Logs delivery, CloudTrail). STACKIT managed services run without customer-side service roles; the role usually disappears rather than being migrated.

Evidence: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html

Units: module.dependencies.module.catalog_rds.aws_iam_role.rds_enhanced_monitoring, module.dependencies.module.orders_rds.aws_iam_role.rds_enhanced_monitoring

secret-cmk · info · 2 units, 2 records

The secret is encrypted with a customer-managed KMS key. STACKIT Secrets Manager can encrypt with a customer-chosen key too, but the AWS key does not move: the instance's kms_key block (stackit_secretsmanager_instance: key_id, key_ring_id, key_version, service_account_email) names a STACKIT KMS key, one key for all secret values of the instance. The draft sets that block only when every source of the shared instance is an AWS secret that references the same drafted key; otherwise it does not set it and names the key NOT CARRIED with the reason. Decide whether to create the key (stackit_kms_keyring, stackit_kms_key) and a service account with at least the Secrets Manager Reader role in the same project and region, put the kms_key block on the instance, and which secrets share an instance when they used different keys (one key per instance, not per secret). Without the block the instance uses STACKIT's default encryption.

Evidence: https://docs.stackit.cloud/products/security/secrets-manager/how-tos/kms-encryption-in-the-secrets-manager/, https://github.com/stackitcloud/stackit-api-specifications/blob/main/services/secrets-manager/v1/secrets-manager.json, https://registry.terraform.io/providers/stackitcloud/stackit/0.117.0/docs/resources/secretsmanager_instance

Units: module.retail_app_ecs.aws_secretsmanager_secret.catalog_db, module.retail_app_ecs.aws_secretsmanager_secret.catalog_opensearch

sg-egress-restricted · warning · 8 units, 8 records

The source restricts egress (the AWS provider removes AWS's default allow-all egress rule; only the listed egress rules apply). Every new STACKIT security group gets two default egress rules, IPv4 and IPv6, with no ip range (any address), no protocol and no port restriction (the test of 2026-10-07, 2026-10-07: API read-back of a new group, docs concepts page), that stackit_security_group (the pinned STACKIT provider) does not manage — as generated, the draft allows all egress. After apply, delete them (stackit security-group rule list / delete --security-group-id <id>), or egress is wider than in the source.

Evidence: tested on a STACKIT project on 2026-10-07, https://docs.stackit.cloud/products/network/core-networking/security-groups/basics/concepts/, https://github.com/stackitcloud/terraform-provider-stackit/blob/v0.120.0/docs/resources/security_group.md

Units: module.dependencies.aws_security_group.catalog_opensearch_sg, module.dependencies.aws_security_group.mq, module.dependencies.module.catalog_opensearch.aws_security_group.this, module.dependencies.module.catalog_rds.aws_security_group.this, module.dependencies.module.checkout_elasticache_redis.module.aws_security_group.aws_security_group.default, module.dependencies.module.orders_rds.aws_security_group.this, module.retail_app_ecs.module.alb.aws_security_group.this, module.retail_app_ecs.module.alb_sg.aws_security_group.this

sg-rule-not-rendered · warning · 6 units, 6 records

At least one rule of this group is not in the draft as the source has it. The plan withholds it, holds it as a commented-out rule until a value or a decision is filled in, writes it with a fact that decides what it allows not carried exactly, or cannot name it at all because the source has more rules than are visible statically (a dynamic block over a collection, a count or a rule list that is not known until apply, or a list with a hidden member: the plan's INCOMPLETE action says which set and why, the draft's TODO "rules beyond the known set" names it, and only the known rules are drafted). Typical causes: a protocol, port or source whose value is known only at apply time or comes from a root variable; a source group that is a choice between groups or not a group of the draft; a protocol with no STACKIT counterpart; an ICMP type with every code; an ICMP or ICMPv6 rule whose range is of the other IP family (the API answers HTTP 400, the test of 2026-10-08); a tcp or udp rule with a negative port, a port above 65535, a reversed range, or port 0 only (STACKIT stores no port range for 0 to 0, so the rule would match every port). A tcp or udp range that starts at port 0 and ends below 65535 is written from port 1 (the STACKIT API rejects a range that starts at 0; tested on a STACKIT project on 2026-10-07): port 0 itself is not carried. A stackit_security_group_rule without protocol, port_range or source allows everything (the pinned STACKIT provider), so such a rule is never widened; re-create it with the values it needs (the plan names each one).

Evidence: tested on a STACKIT project on 2026-10-07, tested on a STACKIT project on 2026-10-08, https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_IpPermission.html, https://registry.terraform.io/providers/stackitcloud/stackit/0.116.0/docs/resources/security_group_rule

source-provider-unpinned · warning · 93 units, 93 records

No lock file entry pins aws (>= 3.0, >= 3.29, >= 4.18, >= 4.30, >= 4.59, >= 5.64, >= 5.79, ~> 5.0): the version the plan would use is not proven, so the knowledge base (checked against 5.100.0) is not taken as proof of it (stated once for the whole estate, with the units it covers and the rest of the words)

topology-route-table-not-drafted · warning · 2 units, 2 records

This route table is created with count or for_each. What the draft makes of it follows the decision of this unit. A table that STACKIT's default routing replaces (the cases of a table with only internet or NAT routes in a project outside a Network Area) is not drafted at all, whatever its count: no routing table is made and none is to be attached, and this warning only records that the table is repeated. A table the decision keeps as a routing table of its own (rt-custom) is made only where the source names, instance by instance, which route and which subnet belongs to which instance (a table created with count whose routes and associations name the table by their own count.index): one routing table for each instance, with the routes the draft carries in each, attached to no network, and none at all when the draft carries none of the routes. Where the source does not name them, the draft makes none (which instance a route belongs to is not decided). For a table the decision keeps, nothing in the draft states which VPC the table belonged to (the routing table the draft writes, stackit_routing_table, belongs to a Network Area; the experimental stackit_vpc_routing_table of the pinned provider takes a vpc_id, but the draft writes none): the table, its routes and the subnets it is associated with are re-created or attached by hand once the VPC architecture is decided.

Evidence: https://docs.stackit.cloud/products/network/core-networking/network-area/basics/routing-tables/, https://github.com/stackitcloud/terraform-provider-stackit/blob/v0.120.0/docs/resources/routing_table.md

Units: module.vpc.module.vpc.aws_route_table.private, module.vpc.module.vpc.aws_route_table.public

topology-vpc-unproven · warning · 2 units, 2 records

The project can be taken as one VPC's boundary only if every resource that names a VPC provably names the estate's one, and this estate does not show it: the VPC this subnet names, or the VPC another resource of the estate names (a network ACL, a flow log, a peering connection, a Cloud Control subnet, ...), is a literal id, a variable, a data source, an attribute of a VPC other than its id (its arn, its owner id, ...) or an expression the scan cannot reduce to one reference to the VPC the estate creates (or the estate creates no VPC of its own). A unit placed in a subnet that the scan cannot show is one of the estate's (a server, load balancer, function or NAT gateway in a subnet given by a variable, a data source or a literal id) is in the same position: it may stand in another VPC. The draft puts every network, security group and routing table in the one var.project_id and cannot say that they all belong to one VPC. Confirm which VPC each of them is in, and whether the networks of another VPC belong in this project or in a project of their own joined through a Network Area. No unit of the VPC topology is automation-eligible until then (gate blocker TOPOLOGY:vpc-unproven).

Evidence: https://docs.stackit.cloud/products/network/core-networking/basics/architecture/, https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/

Units: module.vpc.module.vpc.aws_subnet.private, module.vpc.module.vpc.aws_subnet.public

topology-vpc-unproven · warning · 12 units, 12 records

The project can be taken as one VPC's boundary only if every resource that names a VPC provably names the estate's one, and this estate does not show it: the VPC this security group names, or the VPC another resource of the estate names (a network ACL, a flow log, a peering connection, a Cloud Control subnet, ...), is a literal id, a variable, a data source, an attribute of a VPC other than its id (its arn, its owner id, ...) or an expression the scan cannot reduce to one reference to the VPC the estate creates (or the estate creates no VPC of its own). A unit placed in a subnet that the scan cannot show is one of the estate's (a server, load balancer, function or NAT gateway in a subnet given by a variable, a data source or a literal id) is in the same position: it may stand in another VPC. The draft puts every network, security group and routing table in the one var.project_id and cannot say that they all belong to one VPC. Confirm which VPC each of them is in, and whether the networks of another VPC belong in this project or in a project of their own joined through a Network Area. No unit of the VPC topology is automation-eligible until then (gate blocker TOPOLOGY:vpc-unproven).

Evidence: https://docs.stackit.cloud/products/network/core-networking/basics/architecture/, https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/

Units: module.dependencies.aws_security_group.catalog_opensearch_sg, module.dependencies.aws_security_group.mq, module.dependencies.module.catalog_rds.aws_security_group.this, module.dependencies.module.checkout_elasticache_redis.module.aws_security_group.aws_security_group.cbd, module.dependencies.module.orders_rds.aws_security_group.this, module.retail_app_ecs.module.alb.aws_security_group.this, module.retail_app_ecs.module.alb_sg.aws_security_group.this_name_prefix, module.retail_app_ecs.module.carts_service.aws_security_group.this, module.retail_app_ecs.module.catalog_service.aws_security_group.this, module.retail_app_ecs.module.checkout_service.aws_security_group.this, module.retail_app_ecs.module.orders_service.aws_security_group.this, module.retail_app_ecs.module.ui_service.aws_security_group.this

topology-vpc-unproven · warning · 3 units, 3 records

The project can be taken as one VPC's boundary only if every resource that names a VPC provably names the estate's one, and this estate does not show it: a resource of the estate (a subnet, route table, security group, network ACL, flow log, peering connection, a Cloud Control twin of those, ...) names a VPC by a literal id, a variable, a data source, an attribute of a VPC other than its id (its arn, its owner id, ...) or an expression the scan cannot reduce to one reference to the VPC the estate creates (or the estate creates no VPC of its own). A unit placed in a subnet that the scan cannot show is one of the estate's (a server, load balancer, function or NAT gateway in a subnet given by a variable, a data source or a literal id) is in the same position: it may stand in another VPC. The draft puts every network, security group and routing table in the one var.project_id and cannot say that they all belong to one VPC. Confirm which VPC each of them is in, and whether the networks of another VPC belong in this project or in a project of their own joined through a Network Area. No unit of the VPC topology is automation-eligible until then (gate blocker TOPOLOGY:vpc-unproven).

Evidence: https://docs.stackit.cloud/products/network/core-networking/basics/architecture/, https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/

Units: module.vpc.module.vpc.aws_internet_gateway.this, module.vpc.module.vpc.aws_nat_gateway.this, module.vpc.module.vpc.aws_vpc.this

topology-vpc-unproven · warning · 2 units, 2 records

The project can be taken as one VPC's boundary only if every resource that names a VPC provably names the estate's one, and this estate does not show it: the VPC this route table names, or the VPC another resource of the estate names (a network ACL, a flow log, a peering connection, a Cloud Control subnet, ...), is a literal id, a variable, a data source, an attribute of a VPC other than its id (its arn, its owner id, ...) or an expression the scan cannot reduce to one reference to the VPC the estate creates (or the estate creates no VPC of its own). A unit placed in a subnet that the scan cannot show is one of the estate's (a server, load balancer, function or NAT gateway in a subnet given by a variable, a data source or a literal id) is in the same position: it may stand in another VPC. The draft puts every network, security group and routing table in the one var.project_id and cannot say that they all belong to one VPC. Confirm which VPC each of them is in, and whether the networks of another VPC belong in this project or in a project of their own joined through a Network Area. No unit of the VPC topology is automation-eligible until then (gate blocker TOPOLOGY:vpc-unproven).

Evidence: https://docs.stackit.cloud/products/network/core-networking/basics/architecture/, https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/

Units: module.vpc.module.vpc.aws_route_table.private, module.vpc.module.vpc.aws_route_table.public

Property accounting (every setting the source states, checked against the draft)
Units accounted	38
Units without a draft block	11
Meaningful settings	404
Settings not accounted for	0 in 0 units
Settings the draft names as not carried	209

Global verification of the draft: twelve invariants: eight integrity invariants over the files the converter returns and the plans of every family, and four product invariants (the source providers, the application compatibility contracts, the emitted target types and the property accounting). A draft that fails one is not written. Pending is not a pass: it is decided later or not decidable here.
Invariant	Verdict	Read	What it rests on
`GLOBAL_RESOURCE_UNIQUENESS`	PASS	134	121 addressable blocks in the final files and 13 resources of the plans, every address once
`NO_UNPLANNED_RESOURCE`	PASS	53	53 resource blocks: 13 resources of a plan, 40 written by a registered legacy generator, none unplanned legacy.data-services: 12 resource(s) written by a registered legacy generator legacy.identity: 20 resource(s) written by a registered legacy generator legacy.kubernetes: 1 resource(s) written by a registered legacy generator legacy.load-balancing: 1 resource(s) written by a registered legacy generator legacy.network: 2 resource(s) written by a registered legacy generator legacy.secrets-and-keys: 4 resource(s) written by a registered legacy generator
`NO_UNPLANNED_REFERENCE`	PASS	37	37 references between resources: every one is written, and the references of plan resources are stated by their plan; 1 reference(s) to an instance nothing proves are required selector variables with an open decision, none a concrete index (legacy to legacy: 32, plan to plan: 5) legacy to legacy: 32 plan to plan: 5
`NO_UNRESOLVED_REQUIRED_FIELD`	PASS	155	155 required arguments of the resources written: every one is written (a value, a reference or a declared variable) or declared as a target gap
`NO_SECURITY_WIDENING`	PASS	35	35 grant-defining attributes of the rules and routes written, each equal to the plan, none added (files against the plan; whether the plan carries everything the source allows is said by the unit findings and the NOT CARRIED lines, not by this check)
`ALL_OUTPUTS_SAME_RUN`	PASS	47	47 artefacts carry the run id that manifest.json carries assurance/compliance-evidence.csv: carries no run id by design, bound to the run by its sha256 in the manifest assurance/equivalence-ledger.csv: carries no run id by design, bound to the run by its sha256 in the manifest assurance/evidence-ledger.csv: carries no run id by design, bound to the run by its sha256 in the manifest engineering/not-carried-summary.csv: carries no run id by design, bound to the run by its sha256 in the manifest engineering/not-carried.csv: carries no run id by design, bound to the run by its sha256 in the manifest engineering/review-edges.csv: carries no run id by design, bound to the run by its sha256 in the manifest engineering/review.csv: carries no run id by design, bound to the run by its sha256 in the manifest financial/mapping.csv: carries no run id by design, bound to the run by its sha256 in the manifest financial/priced-resources.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/actions.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/application-chain.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/applications.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/data-movement.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/decisions.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/source-target.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/waves.csv: carries no run id by design, bound to the run by its sha256 in the manifest migration/work-board.csv: carries no run id by design, bound to the run by its sha256 in the manifest
`VARIABLE_IDENTITY_PRESERVED`	PASS	29	20 variable references are exactly the variable the plan states, and the 9 variables read are declared as the plan declares them (type and description) var.project_id: type compared, description not: the converter declares project_id once for every family, and the plan's own description of it is not written
`NO_ORPHAN_MANUAL_ACTION`	PASS	21	21 manual actions and decisions, each naming a unit of the assessment
`SOURCE_PROVIDER_MATCHES_SCHEMA_OR_IS_UNVERIFIED`	PASS	93	93 units of a source provider: 0 verified against a compatibility record, 93 explicitly not verified through a root record, 0 stated by their provider row
`APPLICATION_READY_IMPLIES_REQUIRED_ENV_SECRETS_DEPENDENCIES`	PASS	5	5 application contract(s): none is stated ready (READY_FOR_VALIDATION or CUSTOMER_ATTESTED) while a required environment value, secret, dependency rebinding or data store item is not attested (0 ready, 4 not ready with required items open)
`ALL_EMITTED_TARGET_TYPES_CLASSIFIED`	PASS	53	53 resource and data blocks of 24 type(s) in the final files, every STACKIT type classified by the target catalogue
`ALL_UNACCOUNTED_PROPERTIES_EXPLICIT`	PASS	404	404 meaningful properties of 38 generated units each end as accounted by a contract, consumed, a wired reference, a placement decision or named NOT CARRIED; none is UNACCOUNTED

Validation matrix: What has been established about this draft, row by row, and what has not. Nothing here approves the draft, asserts that it is equivalent to the source, or says it is safe to apply.
Check	State	What it rests on	What it is about	Recorded in
Source completeness	PARTIAL	source status RUNTIME_TOPOLOGY_PARTIAL	how much of the source configuration StackToIT read; not whether what it read is correct	assessment.json /summary/source_status
Draft generation	GENERATED	the draft is in terraform/	whether a STACKIT draft was written for this run	manifest.json /draft
StackToIT draft checks	PASSED	100 checks, none found a violation	StackToIT's own checks of the plan and the rendered text of the families it writes from a plan; not what OpenTofu or STACKIT would say	workspace.json /units
Global invariants	PASSED	12 of 12 invariants PASS	eight consistency checks over the files of the draft and the plans, ALL_OUTPUTS_SAME_RUN among them, and one product check that no meaningful source property is left without a stated fate (ALL_UNACCOUNTED_PROPERTIES_EXPLICIT); not a check of target behaviour	manifest.json /verification
OpenTofu validation	PASSED	tofu init -backend=false and tofu validate accepted the draft; tofu 1.13.1	static validation of the draft against the pinned provider schema — not target behaviour, not approval	manifest.json /validation/tofu_validate
Output schema validation	PASSED	verified at publish: every JSON file that has a schema is validated against it (see run_verification in manifest.json)	the machine-readable output files that have a schema, against the schemas recorded in manifest.json	manifest.json /run_verification
STACKIT plan	NOT RUN	this build runs no plan against a STACKIT project	a plan of the draft against a live STACKIT project: whether the provider accepts the values and what it would create	not assessed in this build
Architect approval	NOT PROVIDED	no review decision is recorded for this run	a named architect's decision on the draft; StackToIT records none	not assessed in this build
Semantic equivalence	NOT ASSESSED	this build has no measure for it	whether the target behaves like the source; StackToIT assesses units and settings one by one and makes no statement about the whole	not assessed in this build
Safe to apply	NOT ASSERTED	StackToIT never asserts it	whether the draft can be applied to a live project without harm; StackToIT never asserts this	not assessed in this build

Identity transition

The direction from static long-lived secrets to short-lived workload identity is followed only where the evidence supports it. This table states the facts of the source and what stays open; it makes no statement about whether federation is an option for any workload. Privilege delta, break-glass access and human identity are not assessed for any row.

Workloads that run as an identity or are one (5)
Unit	Source type	Identities the source names	Static credential	Federation facts	Target attachment	Workload identity federation	State
`module.retail_app_ecs.module.carts_service.aws_ecs_service.this`	`aws_ecs_service`	`module.retail_app_ecs.module.carts_service.aws_ecs_task_definition.this#execution_role_arn` (execution, role, known) `module.retail_app_ecs.module.carts_service.aws_ecs_task_definition.this#task_role_arn` (task, role, known)	not assessed	none stated	open	not assessed	Decision required
`module.retail_app_ecs.module.catalog_service.aws_ecs_service.this`	`aws_ecs_service`	`module.retail_app_ecs.module.catalog_service.aws_ecs_task_definition.this#execution_role_arn` (execution, role, known) `module.retail_app_ecs.module.catalog_service.aws_ecs_task_definition.this#task_role_arn` (task, role, known)	not assessed	none stated	open	not assessed	Decision required
`module.retail_app_ecs.module.checkout_service.aws_ecs_service.this`	`aws_ecs_service`	`module.retail_app_ecs.module.checkout_service.aws_ecs_task_definition.this#execution_role_arn` (execution, role, known) `module.retail_app_ecs.module.checkout_service.aws_ecs_task_definition.this#task_role_arn` (task, role, known)	not assessed	none stated	open	not assessed	Decision required
`module.retail_app_ecs.module.orders_service.aws_ecs_service.this`	`aws_ecs_service`	`module.retail_app_ecs.module.orders_service.aws_ecs_task_definition.this#execution_role_arn` (execution, role, known) `module.retail_app_ecs.module.orders_service.aws_ecs_task_definition.this#task_role_arn` (task, role, known)	not assessed	none stated	open	not assessed	Decision required
`module.retail_app_ecs.module.ui_service.aws_ecs_service.this`	`aws_ecs_service`	`module.retail_app_ecs.module.ui_service.aws_ecs_task_definition.this#execution_role_arn` (execution, role, known) `module.retail_app_ecs.module.ui_service.aws_ecs_task_definition.this#task_role_arn` (task, role, known)	not assessed	none stated	open	not assessed	Decision required

module.retail_app_ecs.module.carts_service.aws_ecs_service.this: what the row says

The identity plan does not attach a service account to this workload exactly; the attachment is a decision of a person. The plan holds manual actions or open decisions for it; they are listed as items. Privilege delta, break-glass access and human identity are not assessed.

Items: the step "Decide how module.retail_app_ecs.module.carts_service.aws_ecs_service.this…" the step "Decide how module.retail_app_ecs.module.carts_service.aws_ecs_service.this gets…"

module.retail_app_ecs.module.catalog_service.aws_ecs_service.this: what the row says

Items: the step "Decide how module.retail_app_ecs.module.catalog_service.aws_ecs_service.this…" the step "Decide how module.retail_app_ecs.module.catalog_service.aws_ecs_service.this…"

module.retail_app_ecs.module.checkout_service.aws_ecs_service.this: what the row says

Items: the step "Decide how module.retail_app_ecs.module.checkout_service.aws_ecs_service.this…" the step "Decide how module.retail_app_ecs.module.checkout_service.aws_ecs_service.this…"

module.retail_app_ecs.module.orders_service.aws_ecs_service.this: what the row says

Items: the step "Decide how module.retail_app_ecs.module.orders_service.aws_ecs_service.this…" the step "Decide how module.retail_app_ecs.module.orders_service.aws_ecs_service.this…"

module.retail_app_ecs.module.ui_service.aws_ecs_service.this: what the row says

Items: the step "Decide how module.retail_app_ecs.module.ui_service.aws_ecs_service.this pulls…" the step "Decide how module.retail_app_ecs.module.ui_service.aws_ecs_service.this gets…"

Workload identity federation is not assessed as an option for any workload. A row states an OIDC issuer where the source names one, as a fact of the source, and never that federation can replace a key.
A static credential is named only where the knowledge base reads a machine user with access keys on the unit. A scan that finds no key cannot say a workload has none, so the absence of a credential is never written.
Privilege delta, break-glass access and human identity are not assessed for any row.
A workload that names no identity in the source has no row, and a run whose draft held no identity intents lists only the units that are an identity themselves.
The block states what the identity plan holds open. It does not attach, grant or federate anything.

The two ledgers

Two files in this report folder hold the rows behind the statements of this workspace as a spreadsheet. A row never states more than the assessment, the plans or the knowledge base state.

assurance/equivalence-ledger.csv: the equivalence ledger, 980 rows, one per unit and semantic that the source states and one per unit and property for the properties the draft does not carry, no semantic accounts for or that are critical and still open.
assurance/evidence-ledger.csv: the evidence ledger, 479 rows, one per document the other blocks cite, with the date it was checked and the date after which it is to be checked again. Evidence that states no such dates is undated, never current.

Limits of the equivalence ledger:

Grain: one row per source unit and semantic of the assessment that the source states or may state (UNIT_SEMANTIC), plus one row per source unit and property for each of three lists the assessment names: properties the draft does not carry, properties no semantic accounts for, and critical properties still open (UNIT_PROPERTY). A property named by more than one list has one row per list. A row for every source property is not possible yet: the assessment does not record which properties a generator reads.
Vocabulary v1: the disposition column prints the words the contracts and the property accounting use today. LEDGER means the contract hands the semantic to the semantic ledger of the draft; PRESERVED and TRANSFORMED appear only where the contract result or the draft's plan ledger states them.
intent_id, target_capability and target_resource are stated only for a semantic that a family written from a plan (security groups, routing tables) carries through the plan's own ledger; for every other row they are not recorded.
target_effective_behavior is NOT_ASSESSED on every row: the behaviour of the target is evidenced per field of a plan resource (units[].behavior_evidence), and a semantic is not a field.
residual_risk, required_action and decision_id are stated only for a critical semantic that is open; they are the sentences and the record that the Decisions section already shows, quoted whole. A sentence that names a record internal to the product is not quoted, and its column is not recorded.
invalidated_by names the inputs of the whole run (manifest.json invalidation) that, when they change, invalidate the row; no row has an invalidation of its own.
evidence_refs name rows of evidence_ledger. Evidence that names a record internal to the product is not listed, and evidence that states no check date and no date to check it again is listed UNDATED, never CURRENT.
3898 semantics of the contracts that the source does not state (it observed no) are not listed: the source has nothing there to carry. The kernel claims of assessment.json count them the same way (absent_claims).

Versions
Knowledge base	0.384.0
STACKIT Terraform provider	0.121.0
Assessment format	0.24.0

Source providers read
Provider	Locked version	Knowledge base checked against	State	Identity evidence
aws	not locked	5.100.0	not pinned	pinned registry (PINNED_REGISTRY)
random	not locked		not verified	identity not established (UNVERIFIED)

Source: partly decided only at plan time. 8 unit(s) have a count/for_each that is not known statically; whether and how often they exist is decided at plan time