Launch freezes a set of assumptions
Every workflow starts with assumptions: where the input arrives, which fields exist, what a normal request looks like, who approves the exception, and which system holds the final status.
Reality moves. A form changes. A team renames a field. A new service creates a new kind of request. Staff start using a status differently. Access expires. None of those changes need to look dramatic to break the workflow.
The system can keep running while the result gets less useful. That is what makes drift dangerous.
Watch the seams, not just the uptime
A green “running” light does not prove the work is right. The important questions live where automation meets the business:
- Are the inputs complete and coming from the expected source?
- Are normal cases still following the intended path?
- Are exceptions reaching the right person?
- Are customer-facing drafts still accurate and in bounds?
- Did the final record land in the real source of truth?
These checks are easier when the first workflow has clear rules. That is why Ridgeway recommends starting with boring, visible office work.
Operating ownership covers the boundary
Ongoing operations do not require manual inspection of every step. They require responsibility for health checks, exception queues, failed integrations, sampled outputs, business-rule changes, and pause decisions when the workflow leaves its approved boundary.
That responsibility can sit with a defined Ridgeway team and client-side business owner, with escalation and backup coverage documented before launch.
This is the core of managed AI contracting: maintenance remains part of the service after the build. The companion guide explains how risk-based human oversight focuses attention on exceptions and high-consequence actions.
Maintenance should improve the system
Good operation does more than restore yesterday’s behavior. It shows which inputs keep causing trouble, which exceptions deserve a new rule, and which steps should stay human.
Over time, the normal path gets cleaner and the exception boundary gets sharper. The next workflow is easier to choose because the team has evidence from real use instead of another guess.
Ask these questions before you buy
- Who owns the workflow after launch?
- What gets reviewed, and what happens when the review fails?
- Which actions pause for a person?
- How are changes to tools or business rules handled?
- What record proves the job finished correctly?
If the proposal answers the build questions but not the operating questions, it is only half a system. Use the consulting-versus-contracting guide to decide whether your team can own the second half or needs an operator.
Keep a change register beside the workflow
A useful change register is small: date, business change, system affected, person who approved it, test performed, and the result. Record a renamed CRM stage, a new invoice type, a changed approval limit, a new mailbox, or a revised customer message when the business makes the decision. The operator can then connect a later exception to a known change instead of treating every failure as a fresh mystery.
The register also separates maintenance from expansion. Repairing a connector after a vendor changes authentication preserves the agreed workflow. Adding a new destination, audience, or authority boundary changes what the workflow owns and deserves a new scope decision. The distinction is easier to make when the original boundary is written down.
Test recovery, not only alerts
An alert proves the system noticed a problem. It does not prove the business can recover cleanly. For a representative failure, verify that the workflow pauses safely, preserves the original item, avoids a duplicate on retry, and gives the responsible person enough context to resolve it. Then confirm that the final record reaches the source of truth.
Run that exercise after meaningful tool, policy, or ownership changes. The same discipline used in shadow mode applies after launch: compare the system’s behavior with the intended process, inspect disagreements, and widen authority only when the evidence supports it.