A municipal generator-test program can only prove monthly load-bank results with paper logs that no API can read. How should indicator collection be configured for that KRI?
Select an answer to reveal the explanation.
Short Explanation
Some proofs still live on clipboards — the platform can take a handwritten score on a schedule. Set the indicator to manual collection so owners punch in the load-bank result. Faking it from CPU metrics or shoving it into VR is the wrong swap.
Full Explanation
When a municipal generator-test program can only prove monthly load-bank results with paper logs that no API can read, the KRI should be configured for manual collection so owners enter results on the required cadence. IRM indicators support manual as well as automated collection; clipboard proofs still belong on a schedule inside the risk system. Refusing non-automated KRIs abandons real operational evidence civic plants rely on.
Refusing to track the KRI at all because only automated feeds are allowed invents a false product constraint and blinds the register. Fabricating nightly automated values from CMDB CPU metrics as a stand-in for generator tests falsifies the measure. Converting the indicator into a security vulnerability group under CIS-VR misfiles an operational readiness KRI into vulnerability management.
Exam caveat: manual indicator collection is legitimate when source systems cannot automate. Do not fake automation or relocate the KRI into VR.
Operational check: set the generator-test KRI to manual monthly collection; assign an owner; enter a load-bank result; confirm the indicator history stores the manual value and threshold evaluation runs.
Manual collection still needs validation rules: require the test date, result pass/fail or measured load, and attester identity so paper-log transcription remains examinable. Spot-audit monthly entries against physical logs quarterly to deter fabricated automation substitutes from CPU metrics.