docs: add HIPAA-ready positioning for architecture and pitch

- clarify BEDS is compliance-friendly architecture, not certification
- add healthcare/regulated deployment framing to visual brief
- document controls BEDS provides vs contract implementation responsibilities
- update wiki index description for regulated-deployment positioning

wiki/02-architecture.md

@@ -158,3 +158,27 @@ BEDS has no node types in code. All nodes run the same binary. The configuration
 - Whether this node is in production mode (fatal IPL failures) or development mode (non-fatal)
 
 Changing a node's role means changing its config file and restarting. No code changes. No redeployment.
+
+## Compliance-Oriented Deployment Pattern
+
+BEDS can be used as the architecture baseline for regulated workloads (including healthcare contracts) because it enforces transport and execution boundaries by design.
+
+Important framing:
+
+- BEDS is not a compliance certification
+- BEDS is a control-friendly runtime architecture
+- Final compliance posture depends on infrastructure, policy, and operational practice
+
+Why this architecture helps:
+
+- AMQP-first messaging centralizes request flow and transport governance
+- Template-driven dispatch limits ad hoc query behavior in application code
+- Class -> Schema -> Base I/O layering keeps business logic separate from storage concerns
+- Event lineage enables request-chain reconstruction for audits and incident review
+
+What must be added in deployment for HIPAA-class programs:
+
+- At-rest encryption and key lifecycle controls
+- Strong service identity and TLS policy in production
+- Access governance, least privilege, and operator accountability
+- Log retention, backup/restore validation, and incident response processes