Understand
Business brief
Delivery
From business request to a verified, maintainable data solution.
Business context, source evidence, approved rules, implementation, and verification stay connected when requirements change. Engagement scope and responsibilities are agreed for the specific project.
- Delivery approach
- The seven stages describe how Orisdale carries a business request through to a result that can be checked and maintained.
- Product direction
Turn a business request into a verified, maintainable data solution—and preserve that understanding when the requirements change.
The Orisdale Workflow Agent for Alteryx — BigQuery Edition is in development and is intended to support workflow generation inside this journey.
- Current evidence
- In development for Alteryx and BigQuery. A person controls execution in the current scope.
The delivery journey
Each stage names a purpose, a tangible output, and the person who remains responsible. Revision returns to the stage that the change affects, then verification follows.
To Investigate
Investigate
Source evidence
- Actual sources
- Declared synthetic
To AgreeBoth paths meet at Agree
Agree
Agreed rules
To Build
Build
Workflow or pipeline
To Execute
Execute
Authorized run record
To Verify and hand over
Verify and hand over
Verified results and handover
To Revise
Revise
Return to the affected stage, then verify the change.
Business context, evidence, and approvals stay connected as the solution changes.
What each stage produces
Understand
Organize supplied notes, business requests, and relevant signals. Separate facts, hypotheses, assumptions, and open questions.
Output. A business brief.
Responsibility. People confirm what is known and what is still open.
Investigate
Inspect available schemas, relationships, and data quality. For a demonstration, define synthetic sources and scenarios explicitly.
Output. Source evidence and findings.
Responsibility. People keep actual sources distinct from a declared synthetic demonstration.
Agree
Confirm the questions, output grain, calculations, missing-data behavior, expected outputs, and acceptance checks.
Output. Agreed requirements and business rules.
Responsibility. The people accountable for the decision approve the rules before detailed construction.
Build
Translate the agreed design into a supported native workflow or pipeline.
Output. An implementation traceable to the agreed requirements.
Responsibility. An engineer reviews the implementation before anyone treats it as ready to run.
Execute
Run through an authorized platform path. Identify the inputs, the implementation version, and the run status.
Output. An authorized run record.
Responsibility. A person authorizes the run on the platform and records the inputs, implementation version, and run status.
Verify and hand over
Check results against the agreed requirements. Include documentation and an identified operating owner. When downstream AI is in scope, verify dataset correctness and agent answer correctness separately.
Output. Verified results and a handover.
Responsibility. The named owner accepts the documentation for operation.
Revise
Return to the affected stage, then verify the change. A changed purpose may require Understand, changed source evidence may require Investigate, and changed business rules may require Agree.
Output. An explainable change and renewed verification.
Responsibility. People review the affected stage and the verification that follows. Unaffected work stays in place.
Two ways to investigate
Both paths end at the same agreement about rules and acceptance checks.
Actual source evidence
Inspect the schemas, relationships, and data quality that are actually available for the project.
Declared synthetic demonstration
Define the sources and scenarios as synthetic. A synthetic schema is not the customer's schema, and it does not establish customer demand.
A synthetic rule change
This example is synthetic. It was not executed by the product, and it has no measured result.
A demonstration rule changes from “include a record when it is opened” to “include a record only when it is accepted.”
Calculation
The inclusion rule that decides which records count.
Affected output
The summary that uses that count.
Acceptance checks
The expected rows and totals for the new rule.
Downstream instructions
Any guidance that still describes the old rule.
The change returns to Agree, then to the implementation and verification that depend on the rule. Understand stays in place unless the business purpose also changed.
Architecture describes system responsibilities. This page describes delivery and change. Review the reference architecture.
Request a Strategy Session
The session is a conversation about one business request. It does not include a formal assessment or a promised deliverable.