A transit team refuses to promote AI-generated detections that lack unit tests. What quality gate is that enforcing?
Select an answer to reveal the explanation.
Short Explanation
No unit tests, no ticket to ride—AI-written detections still need a quality gate. Passing integration tests with your pipeline isn't proof you've got a working detection. Transit detection engineering trusts tests more than generative confidence.
Full Explanation
A transit team that refuses to promote AI-generated detections that lack unit tests is requiring unit tests as a quality gate before promoting AI-assisted detections. Generative models can produce plausible Sigma/KQL that fails on edge cases, mis-handles fields, or matches far too broadly on transit telemetry. Unit tests encode expected hit and non-hit fixtures so promotion depends on demonstrated behavior of the detection itself, not just integration tests; passing integration tests can still hide a detection that mis-handles fields or misses edge cases at the unit level. That gate keeps AI assistance inside the same engineering discipline transit already applies to safety-adjacent software changes.
Why the other options fail by concept: Requiring peer review as a quality gate before promoting AI-assisted detections adds a human review step; peer review is useful but it is not the automated quality gate that requires the unit tests and proves detection behavior before promotion. Requiring integration tests as a quality gate before promoting AI-assisted detections tests how components work together, not isolated detection correctness; an integration suite can pass yet the AI-assisted detection can still fail on edge cases or mis-handle fields without its own unit tests. Requiring regression tests as a quality gate before promoting AI-assisted detections checks that existing behavior has not broken, not that new AI-drafted logic is correct; every AI-drafted detection still needs its own unit tests before promotion, not just regression coverage.
Exam caveat: unit tests should include both positive abuse cases and realistic benign transit events (schedule noise, maintenance accounts) or rules will pass narrow fixtures and fail in production. Operational check: block the detection promotion pipeline unless associated unit tests exist and pass, and periodically add fixtures from recent false positive/negative transit incidents.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.