The municipal transit fare-system ART can technically deploy fare changes, but leaders refuse to release because they treat deploy and go-live as the same event. What CDP distinction should the RTE clarify?
Select an answer to reveal the explanation.
Short Explanation
Being able to roll a fare table onto the bus computers is not the same as charging riders tomorrow morning. Deploy is the technical path; Release on Demand is the business decision. Confusing the two either freezes the pipeline or surprises the city.
Full Explanation
Release on Demand separates the technical ability to deploy from the business decision of when users actually see the change. When a municipal transit fare-system ART can deploy but leaders refuse to release because they treat deploy and go-live as the same event, the RTE should clarify that distinction. Claiming that if the train can deploy it must release to every rider in the same hour removes business control. Claiming Release on Demand is identical to Continuous Integration so fear of release means CI is broken conflates integration with release strategy. Delaying deployment ability until the business is already ready to release keeps the technical path immature and makes eventual go-live riskier. Transit fare Continuous Delivery still allows business release timing for rider communication; automation should not mean surprise fare behavior in production. Exam caveat: fare changes may need legal or rider-communication windows; those windows are release decisions, not reasons to keep deployment manual. Operational check: demonstrate deploy-to-staging or dark-launch capability for a fare change without rider exposure, then schedule the business release separately. Demonstrate dark-launch or staging deploy for a fare change, then schedule the rider-visible release deliberately.