Desired State

A desired state is defined declaratively, specifying what the end configuration should be, not how to achieve it. This contrasts with imperative commands that specify exact steps.

• Declarative Example: deployment.spec.replicas: 5 (The system should have 5 replicas).
• Imperative Example: kubectl scale deployment my-model --replicas=5 (A command to scale to 5 replicas).

The orchestrator (e.g., Kubernetes) calculates and executes the necessary actions autonomously to achieve and maintain the declared state.

The core mechanism for maintaining desired state is a control loop. The orchestrator continuously:

1. Observes the current, actual state of the system (e.g., which model version is running on a device).
2. Compares it to the declared desired state (e.g., the version specified in the deployment manifest).
3. Takes corrective action if a drift is detected (e.g., updates the device with the correct model).

This loop ensures self-healing and resilience, automatically correcting failures, network interruptions, or unauthorized changes.

The desired state references specific, immutable and versioned artifacts. In edge AI, these are typically:

• Model artifacts (e.g., model_v2.3.onnx)
• Container images (e.g., inference-server:sha-abc123)
• Configuration files

Once created, these artifacts are never modified. A change to the desired state involves declaring a reference to a new, versioned artifact. This ensures reproducibility, enables easy rollback, and prevents configuration drift.

Actions taken by the orchestrator to achieve the desired state must be idempotent. Applying the same desired state specification multiple times results in the same system condition. This property is critical for reliability:

• Safe retries on transient failures.
• No side effects from repeated reconciliation.
• Consistent outcomes regardless of initial state.

For example, declaring desiredCpu: 500m ensures the container has at least 500 millicores, whether it currently has 200m or 700m. The orchestrator's adjustment actions are idempotent.

The desired state comprehensively defines not just the software component but its required runtime environment and limits, which is vital for resource-constrained edge devices.

Key declarations include:

• Compute: CPU requests/limits, NPU/GPU accelerator selection.
• Memory: RAM and VRAM allocations.
• Storage: Persistent volume claims for model storage.
• Networking: Bandwidth limits, network policies.
• Node Selectors: Constraints to run on devices with specific hardware (e.g., accelerator: arm-npu).

This allows the scheduler to make optimal placement decisions and prevents resource starvation.

The desired state defines how the orchestrator determines if a deployed component is functioning correctly. This is done through probes:

• Liveness Probe: Checks if the container is running. Failure triggers a restart.
• Readiness Probe: Checks if the container is ready to serve traffic (e.g., model loaded, dependencies met). Failure removes the pod from service load balancers.
• Startup Probe: Used for slow-starting containers, disabling liveness/readiness checks until it succeeds.

For an AI inference server, a readiness probe might call a lightweight /health endpoint that verifies the model is loaded and the accelerator is available.

The declarative specification for which machine learning model version should be running, along with its critical runtime parameters. This ensures consistency and reproducibility across a distributed fleet.

• Target Version: fraud-detection-v2.4.1
• Inference Parameters: batch_size: 1, precision: int8
• Resource Limits: cpu: "500m", memory: "256Mi"

The orchestrator (e.g., Kubernetes) compares this declared state against the actual state on each device and performs actions like pulling container images or updating environment variables to reconcile any differences.

A desired state defining the operational readiness and minimum health thresholds for edge devices eligible to run AI workloads. This prevents deployment to unstable nodes.

• Minimum Uptime: 99.5% over a 24-hour window.
• Required Sensors: LiDAR operational, GPS fix acquired.
• System Resources: Available RAM > 512MB, CPU temp < 80°C.

Devices reporting metrics outside these bounds are marked unschedulable, and workloads may be gracefully migrated to healthy nodes to maintain overall system service-level agreements.

A policy that declares where models must be deployed based on data sovereignty laws or latency requirements. The orchestrator places workloads to satisfy these constraints.

• Data Locality: Process EU customer data only on nodes in Frankfurt or Dublin.
• Maximum Latency: Inference P95 < 100ms from sensor to decision.
• Redundancy: Deploy at least 2 replicas per geographic zone.

This is often implemented using node selectors, taints/tolerations, and topology spread constraints in orchestration platforms.

The desired progression for deploying a new model version across the fleet. This declarative policy controls the speed and safety of updates.

• Strategy: RollingUpdate with maxUnavailable: 10%.
• Validation: Canary deployment to 5% of devices, require accuracy > 98%.
• Rollback Trigger: Automatically revert if error rate increases by 2%.

This moves the operational burden from imperative scripts ("update device A, then B") to a declared end-state ("all devices should be on v2, updated safely"), which the system autonomously executes.

A declared security baseline that must be enforced on all devices running AI workloads. The orchestrator audits and enforces this state.

• Image Signing: Only accept containers signed by registry.acme.com.
• Network Policy: Model pod can only communicate with local sensor service on port 8080.
• Secret Access: TLS certificates must be mounted from vault, not embedded.

Drift from this state—such as an unauthorized process accessing the model—triggers alerts or automated remediation, such as pod termination.

A declarative policy for how AI workloads should scale and utilize constrained edge resources, balancing performance with power consumption.

• Scaling Rule: Scale up model replicas when queue depth > 50, scale down when CPU < 40%.
• Power Mode: Between 00:00-06:00, switch model to low-power precision (FP16).
• Batch Optimization: Dynamically adjust inference batch size based on available memory.

The system continuously adjusts runtime parameters to meet this declared efficiency target, which is crucial for battery-powered or thermally constrained edge devices.

Configuration drift is the gradual, unmanaged divergence of a system's runtime configuration from its intended, declared desired state. In edge AI, this can be caused by manual hotfixes, failed partial updates, or environmental interference, leading to unpredictable model behavior and failures.

• Cause: Ad-hoc changes bypassing the declarative source.
• Risk: "It works on my device" syndrome at scale.
• Mitigation: Immutable infrastructure patterns and continuous reconciliation by the orchestrator.

Immutable infrastructure is a deployment paradigm where servers and application components are never modified after deployment. Changes are made by replacing the entire component with a new, versioned instance. This pattern enforces desired state by construction, as the only way to update is to deploy a new, fully-defined artifact.

• Edge Model Deployment: A model update involves deploying a new container image, not patching a running container.
• Benefit: Eliminates drift and guarantees consistency from staging to production.
• Implementation: Used with container images and declarative rollouts.

This is the fundamental paradigm contrast. Declarative configuration (desired state) specifies what the intended system configuration is (e.g., 'run 3 replicas of model-v2'). Imperative commands specify how to achieve it (e.g., 'scale deployment X to 3').

• Declarative (Desired State): Focus on outcome. System determines execution path.
• Imperative: Focus on command sequence. User determines execution path.
• Orchestrator Role: Translates declarative intent into imperative actions internally.