Dagychu evaluation
Prove the recovery boundary on one real workflow
A bounded commercial pilot for teams that already investigate or recover a Python or Bash workflow by hand. Keep unrelated workloads where they are; test Dagychu against the failure your operators actually face.
What this page covers
The pilot does not begin with a platform-wide migration. Raideria and your team select one workflow, document its current operating procedure, run it through Dagychu, introduce a controlled failure and verify recovery against the resulting business data.
The result is a go, no-go or bounded-follow-up decision supported by execution evidence. The pilot does not manufacture throughput, MTTR, exactly-once or implementation-time claims.
Choose work that can prove or disprove the fit
A useful pilot has an existing operational burden. A clean hello-world pipeline proves installation, not value.
- The workflow is implemented in Python or Bash and can run on Linux, locally or in a Dagychu project runtime container.
- It contains more than one meaningful step or has a failure whose investigation currently crosses several systems.
- The team can define the expected business result and identify external side effects.
- Someone other than the workflow author can participate in the investigation and recovery exercise.
- Synthetic or sanitized inputs can reproduce the workflow without exposing unrelated production data.
Record the current operating model first
The comparison starts before Dagychu is installed. Otherwise a polished UI can be mistaken for an operational improvement.
| Question | What to record |
|---|---|
| Identity | How the product request, queue message, process, logs and business result are correlated today. |
| State | Where an operator determines which step is queued, running, successful, failed or unknown. |
| Input and result | Where the original input and the expected business result can be inspected. |
| Recovery | The SQL, scripts, endpoints, deploys and people required after a partial failure. |
| Side effects | Which writes can be repeated, deduplicated, compensated or reconciled. |
| Access | Who may inspect or act, and which shared tokens or elevated infrastructure permissions are involved. |
Run the operational acceptance protocol
- Define one task identity, its input, expected output, credentials and external side effects.
- Place the existing script or repository in a Dagychu project and configure its runtime and pipeline YAML. A standalone script does not need source-code changes; add JSON I/O only where jobs exchange structured data.
- Run one successful execution and verify the business result outside Dagychu.
- Introduce an agreed controlled failure after an intermediate step using synthetic or sanitized data.
- Ask an operator who did not implement the workflow to identify the failed work, inspect its evidence and explain what may happen next.
- Apply the agreed idempotency, deduplication, compensation or reconciliation rule and rerun only the selected work when that rule permits it.
- Verify the final business result for missing and duplicate effects, then compare the remaining custom status, retry and admin machinery.
A shared test with explicit responsibilities
| Raideria | Your team |
|---|---|
| Configure the bounded Dagychu workflow and its execution evidence. | Provide the workflow, sanitized test data and its current operating procedure. |
| Define and execute the controlled platform failure scenario with your approval. | Define business success and identify external side effects. |
| Guide investigation, targeted rerun and reconciliation surfaces. | Decide which effects are safe to repeat and verify the final result. |
| Document edition boundaries and the remaining infrastructure ownership. | Review security, deployment and access requirements for any next stage. |
What the pilot produces
- A configured Dagychu project and pipeline for the selected workflow.
- A written before-and-after operating procedure tied to one task identity.
- Evidence from a successful run, controlled failure, investigation and recovery.
- A side-effect and safe-rerun boundary owned by the workflow team, not inferred by Dagychu.
- A list of custom status, retry, log-search and admin components that would remain or could be retired.
- A go, no-go or follow-up recommendation, including whether Community is sufficient or Enterprise capabilities are required.
What the pilot does not promise
- A migration of every cron job, Celery task, Kubernetes Job or Airflow DAG.
- Exactly-once external effects or automatic business-level idempotency.
- A production performance, availability or recovery-time result that was not measured in the agreed environment.
- Automatic import of historical executions from another runner.
- A conclusion that Dagychu must win; retaining the current system is a valid outcome.
Frequently asked questions
Must we rewrite an existing script?
No. A standalone Python or Bash script can run without source-code changes. Configure its project runtime and pipeline YAML. Change the script or add an adapter only when it must consume Dagychu JSON input or emit structured output_json for downstream jobs and reports.
Does targeted rerun make external effects safe?
No. Dagychu selects execution work; your team defines idempotency, deduplication, compensation or reconciliation for each external effect.
Do we have to buy Enterprise before the test?
Not for a Community-scope execution and recovery evaluation. Include Enterprise when the acceptance boundary requires OIDC, advanced RBAC, the External Execution API, organization-wide monitoring, reporting or commercial support.
Is this a platform migration project?
No. The pilot is intentionally limited to one workflow and leaves unrelated workloads in their current systems.
Bring one workflow with a real recovery problem
Describe the workflow, its current runner and the last failure that required manual investigation. Raideria will use that boundary to determine whether a pilot is appropriate.