# Overview

Source: https://docs.settlemint.com/docs/architects/operability
Overview map for operating DALP deployments: telemetry, PostgreSQL persistence, workflow durability, high availability handoffs, and failure behavior.




## Operability overview [#operability-overview]

DALP operability connects four production concerns: visibility, durable state, recovery planning, and failure handling. This overview routes production-readiness reviews to the evidence each reader needs.

Operators use telemetry to detect incidents. PostgreSQL and workflow checkpoints preserve state. High availability patterns set recovery targets. Failure-mode guidance shows whether the platform retries, fails over, blocks unsafe work, or needs manual intervention.

Start here when you need the operating model rather than a deployment recipe. Buyers use this section to assess resilience. Operators use it to plan support. Security reviewers can check monitoring, access controls, and recovery responsibilities through the same evidence chain.

| Reader             | Start with                                                           | Direct answer                                                                                           |
| ------------------ | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Buyers             | [High availability](/docs/architects/self-hosting/high-availability) | Resilience depends on the selected deployment pattern, measured recovery targets, and restore evidence. |
| Operators          | [Observability](/docs/architects/operability/observability)          | Enabled telemetry gives the team metrics, logs, traces, dashboards, and alerts for incident response.   |
| Data owners        | [Database](/docs/architects/operability/database)                    | PostgreSQL stores application, workflow, indexed chain, and audit data that must survive disruption.    |
| Security reviewers | [Failure modes](/docs/architects/operability/failure-modes)          | Security-sensitive operations fail closed when required checks cannot finish.                           |

## What this section covers [#what-this-section-covers]

DALP keeps deployments observable and durable. Recovery depends on deployment telemetry, PostgreSQL application stores, workflow checkpoints, transaction checkpoints, component failure behavior, and the selected high availability pattern.

Each operating concern has a clear split between what DALP documents and what the deployment operator owns:

| Concern              | DALP documents                                                                                                  | Deployment operator owns                                                                                                       |
| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Telemetry            | Signals emitted by platform components and the observability chart components that can collect and display them | Enabling the stack, configuring sinks, alert routing, retention, dashboard access, and incident response                       |
| State and recovery   | Data domains, workflow checkpoints, idempotent retry behaviour, and recovery patterns                           | PostgreSQL topology, backups, restore drills, infrastructure failover, measured RTO/RPO, and access controls                   |
| Failure handling     | Component degradation behaviour, retry paths, failover paths, and fail-closed controls                          | Runbooks, escalation paths, external dependency restoration, and manual approvals when a provider or policy gate requires them |
| Asset control policy | Where operability evidence supports audits and production readiness                                             | Asset rules, custody policy approvals, compliance policy design, and business workflow changes                                 |

This section does not define asset issuance design, compliance rule authoring, custody policy governance, chain validator or RPC provider service levels, legal retention commitments, or privacy programme design. It does not define bridge behaviour or non-EVM network support. For those decisions, see the product pages, compliance documentation, custody guides, and integration references.

## Operating model [#operating-model]

DALP's operating model has four linked concerns:

1. Visibility: when the observability stack is enabled, operators inspect platform health through metrics, logs, traces, and dashboards with configured alerting.
2. Persistence: PostgreSQL stores application data including identity records, asset configuration, indexed chain state, workflow state, and audit records.
3. Recovery planning: self-hosted deployments choose a high availability pattern, assign owners, and measure actual recovery time against the agreed RTO and RPO through restore drills.
4. Failure handling: workflow checkpoints, idempotent processing, and fail-closed controls contain failures to the affected component or workflow when the platform can continue safely; retries and failover handle recoverable cases automatically.

<Mermaid
  chart="`flowchart TD
  intake[Operator or reviewer question]
  visibility[Visibility<br/>metrics, logs, traces, dashboards, alerts]
  state[Durable state<br/>PostgreSQL, indexed chain state, workflow checkpoints]
  availability[Recovery planning<br/>HA pattern, RTO, RPO, restore drills]
  failures[Failure handling<br/>retry, failover, fail closed, manual intervention]
  evidence[Operational evidence<br/>alerts, backups, checkpoints, incident runbooks]

  intake --> visibility
  intake --> state
  intake --> availability
  visibility --> evidence
  state --> evidence
  availability --> evidence
  failures --> evidence
  evidence --> failures

`"
/>

These concerns work together. Telemetry tells operators which component or chain is affected. PostgreSQL and the Workflow Engine preserve state across restarts and failovers. High availability pages define the selected recovery pattern and recovery targets. The failure-mode catalog identifies whether the expected path is automatic retry, failover, manual intervention, or restoring an external dependency.

## Evidence chain [#evidence-chain]

For production reviews, treat these pages as an evidence chain rather than isolated references:

1. Observability shows what your deployment can detect.
2. PostgreSQL and workflow checkpoints show which state survives restart, failover, or restore.
3. High availability planning shows the recovery pattern and your measured recovery targets.
4. Failure-mode guidance shows what the platform retries, what it blocks, and what you must restore.

That chain helps you separate platform behaviour from deployment responsibilities without turning the overview into an incident runbook.

## Review path [#review-path]

Use the operability pages as a sequence when you need to prove production readiness.

| Question                                                        | Evidence to inspect                                                                              | Page                                                                 |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- |
| How will the team know something is unhealthy?                  | Metrics, logs, traces, dashboards, alert labels, and deployment telemetry configuration          | [Observability](/docs/architects/operability/observability)          |
| Which state must survive restart, failover, or restore?         | PostgreSQL data domains, database HA, backup layers, audit logging, and access controls          | [Database](/docs/architects/operability/database)                    |
| Which recovery target drives the infrastructure design?         | Cloud-native, hot-warm, hot-cold, or hot-hot pattern; RTO, RPO, measured recovery time, drills   | [High availability](/docs/architects/self-hosting/high-availability) |
| What happens when a dependency or component is unavailable?     | Component failure modes, degraded behavior, detection path, retry or manual recovery expectation | [Failure modes](/docs/architects/operability/failure-modes)          |
| Which transaction or signing state can resume after disruption? | Workflow checkpointing, idempotent processing, signing durability, and transaction retry paths   | [Signing flow](/docs/architects/flows/signing-flow)                  |

## Key reliability characteristics [#key-reliability-characteristics]

| Characteristic        | Operator value                                        | Related page                                                                  |
| --------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------- |
| Workflow durability   | Restarts can resume from the last recorded checkpoint | [Workflow Engine](/docs/architects/components/infrastructure/workflow-engine) |
| Idempotent processing | Retries avoid duplicate transaction or event effects  | [Signing flow](/docs/architects/flows/signing-flow)                           |
| Fail-closed controls  | Unsafe continuation is blocked                        | [Failure modes](/docs/architects/operability/failure-modes)                   |
| Deployment visibility | Metrics, logs, traces, dashboards, and alerts exist   | [Observability](/docs/architects/operability/observability)                   |
| Recovery evidence     | Restore drills compare measured recovery time to RTO  | [High availability](/docs/architects/self-hosting/high-availability)          |

## Where to go next [#where-to-go-next]

* Plan monitoring and alert routing with [observability](/docs/architects/operability/observability).
* Review data storage, replication, backup strategy, and retention in [database](/docs/architects/operability/database).
* Map incident response paths with [failure modes](/docs/architects/operability/failure-modes).
* Choose deployment resilience patterns with [high availability](/docs/architects/self-hosting/high-availability).
* Review deployment prerequisites in [self-hosting](/docs/architects/self-hosting).
* Check [SettleMint status](https://status.settlemint.com/) for published availability on SettleMint-hosted environments, or read [SettleMint Trust Center](https://trust.settlemint.com/) for security and compliance documentation used in procurement reviews.