Verify the database, not the agent’s claim.
A fluent completion message cannot prove that a workflow reached its intended state. Maydan’s verifier reads the saved database after an agent acts.
What does a task check?
Each task defines the intended target and final state. Checks can require the correct entity, prerequisite resolution, terminal action, audit state and unchanged bystanders. Some instances require the agent to make no change at all.
Example: select only the records meeting a date rule; resolve their blockers; complete those records; leave every other record untouched. If the exact qualifying count is not met, do nothing.
What can fail despite a success message?
- The agent stops before the terminal state.
- It changes the right kind of record, but the wrong entity.
- It reports success without a saved state change.
- It finishes the targets and changes unrelated records.
- It reaches a reward condition without the intended interaction.
How are rules handled?
Modelled rules carry provenance: verified against a current official source, inferred from official material, or synthetic for the environment. Scope and provenance matter because a simulator should not present invented behaviour as government policy.
What should a buyer ask to inspect?
Ask for the task definition, initial state, expected state, verifier logic, adversarial checks, failure trace and rule provenance relevant to the proposed workflow. A pilot should make its exclusions and limitations explicit before evidence is used for a decision.
Past experimental results affected by contract or instrumentation defects are not a general model ranking. Current calibration is English only and does not establish an Arabic performance gap.