System Context

See Alfred's scope, actors, external systems, and capability boundary.

Alfred is the control plane for Headout's domain and certificate operations. It accepts authenticated intent, records a durable execution, serializes shared infrastructure changes, and reports progress independently of the original HTTP request.

Responsibilities

Alfred owns the control-plane contract around infrastructure work:

  • authenticate principals and authorize workflow-specific permissions;
  • validate workflow input through shared Zod schemas;
  • deduplicate requests by idempotency key and normalized logical identity;
  • queue commands that cannot safely run concurrently;
  • start, resume, cancel, and inspect durable Workflow SDK runs;
  • project execution stages and publish stable domain events;
  • preserve enough mutation history to compensate supported workflows.

Alfred does not replace the provider control planes. ACM remains authoritative for certificate state, Route53 for DNS, CloudFront for distributions, ELB for listeners, Google API Keys for browser referrers, and ArgoCD for GitOps convergence. Alfred coordinates those systems and records the intent and result of each bounded mutation.

System Boundaries

BoundaryAlfred ownsExternal system owns
APIauthentication, authorization, validation, idempotency, execution resourcesclient retry and terminal-state polling
Workflowordering, durable control flow, waits, hooks, child runsWorkflow SDK persistence mechanics
AWSmutation plan, safety checks, receipts, compensationresource state and provider-side propagation
GitOpsrepository change and convergence intentmerge policy and ArgoCD reconciliation
Notificationsoutbox event and Zendesk update attemptsubscriber availability and ticket lifecycle

The public contract ends at executions and events. A provider operation may finish while the overall workflow is still waiting for another system, so clients should not infer completion from ACM, CloudFront, or GitHub alone.

Workflow Capability Boundary

Alfred's durable runtime implements five public workflows: onboard-domain, add-certificate, add-domain, add-subdomain, and update-lambda-version. Onboarding finalization recovery, certificate and onboarding rollback, Maps-only onboarding recovery, and Lambda version restoration also run as explicit durable workflows tied to a source execution.

These are the only workflow triggers in the client OpenAPI contract. Health, observability, audit, API-key, and administrative endpoints have a separate operator contract. Slack, GitHub, and Zendesk hooks remain adapter ingress and are not client SDK operations. Check Service Capabilities for the current boundary and Workflow Reference for lifecycle behavior.

Consistency Contract

onboard-domain, add-domain, and add-certificate mutate shared AWS infrastructure. Their root commands and applicable continuation, rollback, and finalization-recovery commands use the global aws-infrastructure lane. Lambda version updates use a separate lane derived from target and environment; conflicting versions in one active lane are rejected rather than queued.

Only one root execution owns that lane at a time. Valid work that cannot start immediately remains queued instead of being rejected. Recovery for the active owner takes precedence when it is required to return infrastructure to a stable state.

This lane controls Alfred's mutations, not every actor with AWS credentials. Provider readiness checks, drift checks, and mutation receipts still protect against state changing outside Alfred.