Add deployment controls checklist

Architecture-Deployment-Controls-Checklist.md

@@ -0,0 +1,67 @@
+# EVOLV Deployment Controls Checklist
+
+This page translates the EVOLV architecture into deployment controls that can be checked during implementation, review, FAT/SAT, and audit preparation.
+
+It is not a legal compliance certificate. It is the operational checklist that helps turn the architecture into demonstrable control.
+
+## How To Use This Page
+
+For each deployment:
+
+- mark whether the control is implemented
+- record the evidence location
+- record the responsible owner
+- track open gaps before production release
+
+## Control Checklist
+
+| Control Area | Required Control | Why It Matters | Evidence To Keep |
+|---|---|---|---|
+| Network segmentation | Edge, site, and central layers are separated by defined network boundaries. | Supports OT/IT separation and reduces blast radius. | Network diagrams, firewall rules, VLAN or conduit definitions. |
+| No direct field exposure | PLCs and field-edge runtimes are not exposed as public or enterprise-facing endpoints. | Protects lower operational layers from unnecessary attack surface. | Access matrix, ingress configuration, API gateway design. |
+| Central ingress only | External APIs terminate centrally and are mediated before any downward action. | Enforces policy, logging, and safer integration boundaries. | API gateway config, reverse-proxy config, architecture review notes. |
+| IAM and access control | Human and service access is authenticated and role-scoped. | Required for controlled operations and traceability. | IAM configuration, role matrix, account review records. |
+| Secret handling | Secrets are not stored in tracked manifests; env files or secret-injection mechanisms are used. | Prevents credential leakage and supports safer rotation. | Secret inventory, compose/env config, rotation procedure. |
+| Patch and update process | There is a documented process for platform, OS, Node-RED, and dependency updates. | Required for lifecycle security and operational hygiene. | Patch policy, maintenance log, release records. |
+| Release traceability | Runtime deployments map to versioned source, commits, and release artifacts. | Supports auditability and controlled rollback. | Git commit references, build artifacts, deployment records. |
+| Local resilience | Local Node-RED and local InfluxDB remain usable during central outage. | Supports essential-service continuity and digital-twin/local monitoring use cases. | Outage test results, failover procedure, site acceptance records. |
+| Site resilience | Site layer can continue plant-local operation when central connectivity is lost. | Avoids central single-point dependence. | Network-loss test evidence, continuity plan, site operating procedure. |
+| Backup and recovery | Backups exist for config, telemetry where required, and critical platform state. | Supports recovery and resilience obligations. | Backup policy, restore test logs, retention schedule. |
+| Logging and audit | Security-relevant and operationally critical actions are logged with retention rules. | Supports incident response, review, and accountability. | Logging policy, sample logs, SIEM or retention config. |
+| Incident response | Operators know how to detect, escalate, contain, and recover from incidents. | Needed to translate architecture into operational resilience. | Incident runbook, contact tree, exercise records. |
+| Data retention | Retention is defined for raw, reconstructed, and summarized telemetry by signal class. | Prevents ambiguity around smart storage and regulatory evidence. | Retention policy, telemetry class matrix, Influx retention config. |
+| Reconstruction policy | Smart-storage signals have explicit fidelity and reconstruction rules. | Prevents opaque analytics and compliance disputes. | Signal policy document, reconstruction thresholds, validation results. |
+| Config authority | `tagcodering` or approved configuration services are identified as the source of truth. | Prevents uncontrolled config drift across flows and sites. | Config ownership record, schema documentation, API contract. |
+| Change governance | Config and runtime changes require approval, versioning, and rollback path. | Reduces unsafe ad hoc plant changes. | Change tickets, deployment approvals, rollback notes. |
+| Site commissioning evidence | FAT/SAT and commissioning checks include security and resilience controls, not only functionality. | Confirms architecture is implemented, not just described. | FAT/SAT reports, commissioning checklist, defect log. |
+
+## Minimum Pre-Go-Live Gate
+
+Before a site goes live, the minimum gate should confirm:
+
+- segmentation is implemented
+- field assets are not directly exposed
+- central ingress and IAM are configured
+- local/site outage behavior is tested
+- secret handling is clean
+- backup and restore have been tested
+- retention and smart-storage policy are documented
+- configuration authority is identified
+
+## Suggested Status Model
+
+Use one of these statuses per control:
+
+- `implemented`
+- `partially implemented`
+- `planned`
+- `not started`
+- `not applicable`
+
+## Related Pages
+
+- [Platform Overview](Architecture-Platform-Overview)
+- [Security and Access Boundaries](Architecture-Security-and-Access-Boundaries)
+- [Security and Regulatory Mapping](Architecture-Security-and-Regulatory-Mapping)
+- [Telemetry and Smart Storage](Architecture-Telemetry-and-Smart-Storage)
+- [Configuration Model and Tagcodering](Architecture-Configuration-Model-and-Tagcodering)

Home.md

@@ -57,6 +57,7 @@ Architecture pages:
 - [Telemetry and Smart Storage](Architecture-Telemetry-and-Smart-Storage)
 - [Security and Access Boundaries](Architecture-Security-and-Access-Boundaries)
 - [Security and Regulatory Mapping](Architecture-Security-and-Regulatory-Mapping)
+- [Deployment Controls Checklist](Architecture-Deployment-Controls-Checklist)
 - [Configuration Model and Tagcodering](Architecture-Configuration-Model-and-Tagcodering)
 
 ```mermaid