A parks department is onboarding a new SaaS reservation tool, and the contract has no data-quality acceptance criteria for inbound feeds. What quality-by-design gap exists?
Select an answer to reveal the explanation.
Short Explanation
Inviting a SaaS feed with no quality acceptance criteria is like hiring a caterer with no food-safety clause. Inbound vendor data needs DQ gates written up front. Quality-by-design covers contracts, not only internal screens.
Full Explanation
Quality by design extends to inbound vendor and SaaS feeds, not only internal municipal applications built by city IT. When a parks department onboards a new SaaS reservation tool and the contract lacks data-quality acceptance criteria for inbound feeds, that gap leaves the city without leverage when bad reference, customer, or booking data arrives. Claiming SaaS vendors never supply data so criteria are irrelevant is usually false for civic platforms that sync customers, assets, schedules, or payments. Parking acceptance criteria only in disaster-recovery addenda after go-live is too late for day-one fitness of resident-facing reservations. Saying quality-by-design applies solely to batch warehouses, never to SaaS APIs, invents a false architectural boundary that weakens modern city platforms. Exam caveat: acceptance criteria should name dimensions, thresholds, remediation SLAs, rejection rights, and the civic owner who can stop a bad feed. Operational check: add DQ acceptance clauses before signature, test sample extracts against city standards in a pilot environment, and assign an integration steward to monitor post-go-live defect rates. Procurement and information-management leads should jointly refuse go-live if inbound feed quality gates are missing from the civic contract and runbook.