10
Assertions maximum
Each monitor can define no more than ten output rules.
Output validation
LatidoFlow evaluates strict numeric output against a monitor-level contract. If a required metric is missing or fails its comparison, the reported success becomes failed evidence and opens an invalid-output incident.
A billing export can finish cleanly while producing zero rows. A synchronization can return HTTP 200 after writing fewer records than required. Output assertions let the workload report a bounded numeric map and make every configured rule part of the success decision.
The supported operators are gte, lte, and equals. Every assertion must pass. A missing metric or failed comparison is retained as invalid-output evidence and fails the run. A malformed output payload is rejected without terminalizing the run.
POST /api/v1/runs/{run_uuid}/success
Content-Type: application/json
{
"output": {
"records_processed": 42,
"amount_exported": 1804.75
}
}
A POST heartbeat can carry the same typed output for a completion-only integration. Direct GET success and GET heartbeat requests cannot supply typed output.
10
Each monitor can define no more than ten output rules.
20
Each completion accepts no more than twenty output metrics.
Flat
Nested values are rejected; metrics must be finite JSON numbers.
All
The contract does not average away a failed condition.
Numeric strings such as "42", nested JSON, non-finite numbers, and arbitrary text values are not accepted output metrics. Assertions currently apply to heartbeat monitors. This mechanism validates the fields your workload reports; it does not independently query the source database to confirm them.
Start with a metric whose zero or missing value would make a technically successful run useless.