Automated product proof
These lab scenarios show the behavior exercised by LatidoFlow's automated acceptance coverage: what evidence enters the system, which incident opens, and what the public status page displays.
Last reviewed: August 1, 2026
Evidence disclosure
These are reproducible technical scenarios, not customer stories. They do not claim customer usage, production scale, time saved, or measured business impact.
Four failure paths
Each scenario begins with a specific monitoring contract, introduces one controlled failure, and checks the stored run, incident, component state, and recovery behavior. Product limits remain visible alongside the proof.
invalid_output
A numeric output rule rejects the nominal success, opens an invalid-output incident, and turns the linked status component red.
Review the scenarioqueue_wait_timeout
A delay-aware start deadline expires without erasing the queued run; a late start and completion can still recover it.
Review the scenariomissing_run
The expected run is missed and becomes an outage, while an explicit Laravel schedule skip advances the window without fabricating success.
Review the scenarioinvalid_output
A 200 response keeps the uptime component operational, but failed background output still makes the overall status page an outage.
Review the scenarioProof method
The expected schedule, start deadline, HTTP status, or numeric output threshold is explicit before the failure.
Controlled fixtures establish prerequisites; the API, lifecycle state machine, and evaluator then produce and verify the monitored outcome.
The automated check verifies the run, incident, monitor, linked component, and overall status-page outcome.
Every page states what the scenario does not prove and which product limitations still apply.
Create a workspace, choose one important job, and define the evidence that should keep it from appearing healthy when its outcome is wrong.