# WSAI service architecture and domain model This document records the reasoning behind WSAI's public service identities and hosted-service architecture. It is an architecture description, not a declaration that every named service is currently deployed. ## Why DNS is decoupled from implementation A public hostname is a product or service identity. It should survive replacement of the software behind it. Creator may begin on one stack and later become a React or other application without changing `creator.wickedspooky.ai`. The same rule applies to hosting, commerce and operations. DNS therefore functions at the product/marketing ingress layer. DNS and TLS direct an approved identity to the current service implementation; they do not define that implementation. ## Domain families **wickedspookyit.com — hosted services.** This family represents services WSAI hosts or manages for customers. `wp.wickedspookyit.com` is the canonical WordPress Multisite hosting/network identity. **wickedspooky.ai — products and applications.** Examples include `creator.wickedspooky.ai`, `crisiscat.wickedspooky.ai`, and `blog.wickedspooky.ai`. These names describe products, not frameworks. **wickedspooky.org — operations and governance.** `operator.wickedspooky.org` is the operational/governance identity. Customer-owned domains are mapped ingress identities to the service they consume. Hosting a WSAI-owned domain on WordPress does not make WordPress the architectural owner of that domain family. ## Managed Domains WSAI intends domain registration/sale, DNS management, TLS, domain mapping and lifecycle management to become a shared platform capability. WordPress hosting and Creator/storefront capabilities can consume it. This permits an offering where WSAI can provide a customer with a managed domain plus the selected hosted application while retaining a clean separation between brand identity and runtime technology. ## WordPress hosting WordPress is designed as a Multisite hosting service from initial deployment, rooted at `wp.wickedspookyit.com`. Public sites use explicit custom-domain mapping. `ArtOfSheri.com` and `SecondActSam.com` are intended as initial mapping proofs before external customer onboarding. WordPress must not wildcard-capture unrelated WSAI hostnames. DNS/ingress ownership remains explicit and fail-closed. The current AWS security foundation uses a private RDS MariaDB database, a least-privilege WordPress database principal, TLS database transport, EC2 instance-role access to AWS Secrets Manager, and a root-controlled volatile secret file under `/run`. The WordPress application does not receive AWS credentials. ## Creator and storefront direction Creator is anchored at `creator.wickedspooky.ai`, while its implementation remains replaceable. The product direction includes a creator storefront/monetization capability similar in product intent to creator-store offerings. The preferred direction combines Creator-integrated commerce with custom mapped domains. A memorable WSAI-branded domain such as `wsai.store` may later act as marketing/discovery ingress to the same service, but the final name and whether commerce becomes a separately deployed service remain intentionally undecided. ## Design consequences - Product names remain stable while implementations evolve. - DNS/TLS/ingress can route multiple public identities to one capability or one identity to a replacement implementation. - Managed Domains is reusable across WordPress, Creator and future services. - Infrastructure hostnames, EC2 instances, containers and proxies are not customer-facing product contracts. - Unknown or unowned hostnames fail closed. - Security, persistence, backup, rollback and observability are service requirements independent of the marketing domain. ## Current WordPress infrastructure decisions The first AWS WordPress hosting deployment uses an Ubuntu EC2 web/application host and a private Amazon RDS MariaDB service. The WordPress database is `wsai_wordpress`; its application principal is `wsai_wordpress_app` and is scoped to that database. RDS secure transport is required and the WordPress client must explicitly use TLS. AWS credentials are not installed as static access keys. The EC2 instance profile authorizes the host to retrieve only the required WordPress secret through a reusable customer-managed IAM policy. The WordPress application/container itself does not receive AWS IAM credentials. The database password is materialized into volatile `/run/wsai/wordpress/db-password`. The systemd retrieval service is enabled and validated with `ProtectHome=yes`, `ProtectSystem=strict`, `PrivateTmp=yes`, `NoNewPrivileges=yes`, and write access limited to `/run/wsai/wordpress`. The password is not placed in Git, Compose environment variables, a persistent `.env`, process arguments, logs or evidence. The host uses the native AWS CLI under `/usr/local/bin/aws`. A Snap-packaged AWS CLI was removed after proving unsuitable for the hardened systemd execution path, leaving one CLI authority and eliminating the redundant dependency. WordPress will be Multisite at initial bootstrap rather than converted from single-site later. The runtime artifact must be version-pinned and its deployed digest recorded for rollback. The exact ingress/runtime implementation remains a separate decision: historical Apache/PHP-FPM work is useful evidence but does not constrain the rebuilt service. Before the deployment is considered certified, the platform must define and prove persistence/backup/recovery for the database, uploads/media, extensions/MU plugins and configuration; application health and startup ordering; explicit custom-domain ownership; and a cold-boot chain from host start through IAM/network readiness, secret materialization, application start, TLS database connection and Multisite health. ## Decision history The architecture deliberately moved away from treating apex domains as WordPress implementation identities. That earlier design made it harder to evolve Creator, Operator and other products independently. The current model keeps product identity stable, makes WordPress one hosted service among several, and turns domain/DNS management into a reusable customer capability rather than an application-specific feature.