A community college district wants civic automation scripts to fail loudly when a controller OpenAPI or device YANG schema drifts incompatibly. What practice best enforces that contract?
Select an answer to reveal the explanation.
Short Explanation
OpenAPI and YANG are the blueprints for the building—if someone moves a load-bearing wall, the inspector should stop the job. Validate against the contract and fail the pipeline when fields vanish or change type. Quietly accepting any blob hides breaking upgrades until production night.
Full Explanation
Community-college automation scripts should fail loudly when controller OpenAPI or device YANG schemas drift incompatibly by validating requests and responses against published contracts and breaking the pipeline on incompatible changes. Contract validation turns silent field renames into visible build failures before production civic changes ship. That practice enforces API/schema discipline.
Disabling response validation so scripts keep running on any JSON shape hides breakage. Pinning scripts to scraping CLI show output exclusively abandons published schemas. Treating schema documents as optional comments and inventing field names at runtime guarantees drift pain.
Exam caveat: version pins and compatibility windows matter—breaking on every additive optional field can be too strict; break on incompatible removals/type changes. Operational check: run schema validation in CI against recorded payloads, introduce a deliberate breaking change in lab, confirm the pipeline fails, then upgrade clients intentionally. Publish schema versions used by district automation. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.