Temporal Operations Responsibility¶
Paridity uses Temporal internally for durable orchestration. In the customer-deployed model, Temporal runs inside the customer's environment as part of the Paridity stack.
Required Positioning¶
Temporal is a bundled internal runtime dependency, not a customer-facing feature. Customer business users do not need to use Temporal directly, and customer teams do not need to write Temporal workflows for Paridity.
However, Temporal is still production infrastructure. Unless the contract explicitly includes a Paridity-managed service, the customer platform/SRE team must operate the Temporal runtime deployed in their environment.
What Temporal Does for Paridity¶
Temporal provides:
- Durable reconciliation workflow execution
- Long-running proof and diff orchestration
- Activity retries and backoff
- Worker task queues
- Cancellation and recovery behavior
- Schedule execution
- Recovery after worker restarts
Because Paridity workflows rely on these semantics, Temporal is not currently a drop-in replaceable component.
External enterprise schedulers can still trigger Paridity:
Airflow / Control-M / Step Functions / Argo
|
v
Paridity API execution request
|
v
Paridity Temporal workflow
|
v
Paridity workers
Customer-Owned Temporal Operations¶
In the Phase 1 customer-deployed model, the customer owns:
| Area | Customer responsibility |
|---|---|
| Availability | Keep Temporal services/pods running |
| Restart | Restart Temporal using the approved runbook when needed |
| Monitoring | Monitor Temporal health, task queues, persistence, and pod status |
| Logging | Collect Temporal logs into the customer's logging platform |
| Backup | Back up Temporal persistence |
| Restore | Restore Temporal persistence during DR |
| Patching | Apply security patches through Paridity-approved chart/image updates |
| Upgrades | Upgrade within Paridity's supported Temporal compatibility range |
| Network | Ensure API and workers can reach Temporal |
| Incident response | Participate in incidents involving orchestration, stuck runs, or queue backlog |
Paridity-Owned Temporal Responsibilities¶
Paridity owns:
- Supported Temporal version range
- Helm chart configuration for the supported deployment model
- Workflow and worker compatibility testing
- Product-level troubleshooting guidance
- Upgrade instructions and release notes
- Recommendations for monitoring and alerting
Paridity should not support arbitrary customer modifications to Temporal configuration unless they are reviewed and accepted for that deployment.
Deployment Options¶
| Option | Who operates it | Recommended use |
|---|---|---|
| Embedded Temporal from the Paridity chart | Customer platform/SRE | Pilot or small non-critical deployments |
| Dedicated Temporal deployed for Paridity | Customer platform/SRE | Recommended production default |
| Existing customer-managed Temporal cluster | Customer platform/SRE | Only if version, namespace, access, and support boundaries are approved |
| Paridity-managed Temporal | Paridity | Future or separately contracted managed offering |
Go-Live Requirements¶
Before production go-live:
- Temporal owner is named.
- Temporal health checks are monitored.
- API and workers can reach Temporal.
- Temporal persistence is backed up.
- Restore path is documented.
- Upgrade path is documented.
- Logs are available to operations.
- Incident escalation path is known.