xOx Orchestration Guidance
What is Orchestration?
Orchestration is where the locked Contract is turned into controlled build steps.
View the full Guidance map or return to the Method overview.
What is Orchestration?
Orchestration is where the locked Contract is turned into controlled build steps.
This is an active phase.
You remain responsible for deciding what moves forward, what should be reviewed, and what should wait.
How should I guide xOx?
Be clear about what you want to do next.
You can ask xOx to focus on:
- one feature
- one page or screen
- one workflow
- one component
- one integration
- one bug or improvement
- one release-readiness task
For example, you might say:
Prepare the next build step for the booking calendar.
Focus only on the customer management page.
Do not touch the UI yet.
Split this into smaller build steps.
Show me the next safe execution step.
Pause this part and continue with another area first.
Ask how to review the work
You do not need to be an architect or developer to stay in control.
If you are unsure how to review a proposed build step, ask xOx what you should look at.
For example, you might say:
How can I review this if I am not technical?
What should I look at before approving this step?
Which screens, files, or behavior should I review?
What could go wrong with this change?
How do I know whether this stayed within scope?
xOx can help translate technical work into practical review points so you can make informed decisions.
UI and review
The Contract does not reopen during Orchestration.
If UI is part of the locked Contract, xOx may recommend building the UI together with the related functionality so both can be reviewed together.
If UI is not part of the Contract, xOx may still recommend a preliminary browser-based interface to help review workflows, navigation, and behavior.
That does not change the Contract.
It is a review aid, not a new commitment.
Review interfaces and final design
During Orchestration, xOx may recommend browser-based interfaces to help review workflows, functionality, navigation, and user experience assumptions.
These interfaces are often intended to support review and feedback rather than represent the final visual design.
In many projects, visual design and user experience refinement are handled later by a UI/UX designer or design team.
For that reason, a review interface may:
- prioritize functionality over appearance
- use temporary styling
- use placeholder layouts
- focus on workflow review
- focus on usability feedback
A successful review interface proves that the project is moving in the right direction.
It does not necessarily represent the final visual appearance of the product.
If visual design is part of the Contract, xOx may recommend reviewing functionality and presentation together.
If visual design is not part of the Contract, the interface should be viewed as a review tool rather than a final design deliverable.
Stay in charge
Orchestration does not mean xOx takes over.
You decide:
- what should be built next
- what should be delayed
- what boundaries must be respected
- whether a proposed step is acceptable
- whether work should be split into smaller steps
- whether work should pause for review
If something feels too broad, ask xOx to narrow it.
If something feels risky, ask xOx to isolate it.
If something is not ready, ask xOx to hold it back.
Keep build steps focused
Smaller build steps are easier to review, understand, and control.
Avoid turning a large project into one oversized execution request.
Instead, move through the project in controlled slices.
Good slices include:
- one page
- one component
- one workflow
- one integration
- one improvement
- one release task
This keeps work easier to inspect and reduces the risk of unintended side effects.
Remember
Orchestration is where build work becomes ordered, reviewable, and user-directed.