Platform Structure

The Arda Platform is the complete set of resources that together support the operation of Arda Products. Its top-level elements are:

• Source Repositories: GitHub Organization and repositories containing source code and documentation.
• Artifact Repositories: Library, image, and package repositories for build, deploy, and configuration artifacts.
• Platform Runtime: Cloud resources (compute, storage, networking, ingress/egress) that directly run Arda products.
• DevOps Pipelines: Logic and resources that transform source code into artifacts and deploy them.
• Platform OAM: Resources supporting Operations, Administration, and Maintenance of all platform elements.

This document covers the Platform Runtime structure.

Runtime Platform Containment Hierarchy

The Runtime Platform is organized in a strict five-level containment hierarchy:

Level	Element	Description
1	Root Services	Resources shared across the entire Runtime Platform: root DNS domains, cloud credentials, licenses, API keys
2	Infrastructure	Resources shared across Purposes due to cost, complexity, or vendor restrictions: VPC networks, parameter/secret stores, EKS cluster
3	Partition	Resources dedicated to a specific Purpose: DB cluster, Cognito, API Gateway
4	Component	Minimal deployable unit: one Helm chart per module. Accesses only its Partition, the underlying Infrastructure, and Root Services
5	Resource	Minimal unit of the underlying Cloud Provider: CloudFormation stacks, AWS resources, Helm charts

Environment is not a structural element but a shortcut name for all resources a Component can access upon deployment — the combination of a specific Partition, its Infrastructure, and Root Services. An Environment is the target of every deployment operation.

The Concept of Purpose

A Purpose is the combination of processes, activities, and policies serving a goal of Arda’s organization. Purposes inform which Infrastructures and Partitions are created. Standard purposes:

• dev — active feature development and testing
• staging — pre-production evaluation and integration testing
• demo — showcasing capabilities to prospective and current customers
• prod — revenue-generating live operations

Naming Conventions

Simple Names

A Simple Name is a string matching ^[a-zA-Z0-9][a-zA-Z0-9]{0,31}$, with case-insensitive equality for uniqueness evaluation.

Element	Scope
Infrastructure	Unique within the Platform
Partition	Unique within its Infrastructure (use purpose names: prod, dev, stage)
Component	Unique within its Partition; strongly recommended to be globally unique because the same component name designates the same capabilities across all environments
Resource	Unique within the Platform (inherit uniqueness from CDK containment hierarchy)

Fully Qualified Names (FQN)

A FQN concatenates Simple Names in order: Infrastructure-Partition-Component-Resource. Root is implicit. The separator is - (hyphen) except:

• Postgres resources use _ (underscore)
• DNS resources use . (dot) in reverse composition order
• URL paths use / (slash)

An Environment name is the FQN of its Infrastructure and Partition: Alpha002-dev.

Cross-Component Access

Partitions contain multiple Components. Cross-component access is restricted to explicitly designed API endpoints. Direct resource sharing between Components is prohibited without an architectural decision record.