Overview
Overview map for operating DALP deployments: telemetry, PostgreSQL persistence, workflow durability, high availability handoffs, and failure behavior.
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 | Resilience depends on the selected deployment pattern, measured recovery targets, and restore evidence. |
| Operators | Observability | Enabled telemetry gives the team metrics, logs, traces, dashboards, and alerts for incident response. |
| Data owners | Database | PostgreSQL stores application, workflow, indexed chain, and audit data that must survive disruption. |
| Security reviewers | Failure modes | Security-sensitive operations fail closed when required checks cannot finish. |
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
DALP's operating model has four linked concerns:
- Visibility: when the observability stack is enabled, operators inspect platform health through metrics, logs, traces, and dashboards with configured alerting.
- Persistence: PostgreSQL stores application data including identity records, asset configuration, indexed chain state, workflow state, and audit records.
- 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.
- 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.
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
For production reviews, treat these pages as an evidence chain rather than isolated references:
- Observability shows what your deployment can detect.
- PostgreSQL and workflow checkpoints show which state survives restart, failover, or restore.
- High availability planning shows the recovery pattern and your measured recovery targets.
- 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
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 |
| Which state must survive restart, failover, or restore? | PostgreSQL data domains, database HA, backup layers, audit logging, and access controls | 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 |
| What happens when a dependency or component is unavailable? | Component failure modes, degraded behavior, detection path, retry or manual recovery expectation | Failure modes |
| Which transaction or signing state can resume after disruption? | Workflow checkpointing, idempotent processing, signing durability, and transaction retry paths | Signing flow |
Key reliability characteristics
| Characteristic | Operator value | Related page |
|---|---|---|
| Workflow durability | Restarts can resume from the last recorded checkpoint | Workflow Engine |
| Idempotent processing | Retries avoid duplicate transaction or event effects | Signing flow |
| Fail-closed controls | Unsafe continuation is blocked | Failure modes |
| Deployment visibility | Metrics, logs, traces, dashboards, and alerts exist | Observability |
| Recovery evidence | Restore drills compare measured recovery time to RTO | High availability |
Where to go next
- Plan monitoring and alert routing with observability.
- Review data storage, replication, backup strategy, and retention in database.
- Map incident response paths with failure modes.
- Choose deployment resilience patterns with high availability.
- Review deployment prerequisites in self-hosting.
- Check SettleMint status for published availability on SettleMint-hosted environments, or read SettleMint Trust Center for security and compliance documentation used in procurement reviews.
Ledger Index
The Ledger Index reads EVM logs, decodes DALP events, and writes queryable read models. It explains how checkpoints, finality, reorg handling, and reindexing affect the state shown by APIs and dashboards.
Observability
The observability stack provides platform visibility through metrics collection, log aggregation, distributed tracing, and a connected Grafana dashboard system with a single-glance platform health view, for deployments that enable the observability chart.