What a Solution Definition Sprint leaves on the table
A Solution Definition Sprint ends with a buildable scope for one workflow, mapped to an existing application foundation. Not slides.
Part of Digital Asset Operations(6)
If the output is only slides, you bought theatre.
For digital-asset operators, a Solution Definition Sprint ends with a scope a decision-maker can act on, mapped onto an existing application foundation.
What you get (typical)
- Problem definition, sponsor and RACI for one workflow
- As-is map: people, systems, tickets and evidence gaps
- To-be workflow: dual control, gates and exceptions
- Business requirements, use cases and user stories
- Domain model, bounded contexts and the integration inventory (custody, KYC/KYT, Travel Rule, ticketing, banking rails)
- Control and evidence requirements mapped to that workflow
- Target architecture and API requirements
- The closest application foundation, and the customer-specific delta
- Implementation scope and a production path
What “done” means
- The named workflow has a clear to-be.
- The CCO can point to the control and evidence model.
- The build decision is made, or explicitly deferred, with owners.
It does not mean “we aligned stakeholders,” and it does not mean “platform roadmap.”
After the sprint
- AI Production Sprint: configure and integrate the application.
- Application Family Program: extend to related workflows.
- Add-ons: Exam & Evidence Readiness, Operator Enablement Lab, Fractional Production Owner.
None of those are forced.
Next step: Bring us the workflow. If the shape above is wrong for you, we'll say so.
Fence: Application engineering. Not custody. Not legal advice.