Maydan Labs
We build RL environments for government and enterprise HR systems.
Agents are graded on what actually changed in the database: whether the right records were updated, whether anything else was damaged, and whether the agent correctly did nothing when nothing should have changed.
What we build
An environment is a resettable container holding a working application, a synthetic population, a set of parameterised tasks, and deterministic verifiers. An agent operates the application through a browser and is scored on the resulting state, not on what it reports.
Our environments model Saudi employment and residency administration: employers, employees, dependents, contracts, documents with Hijri and Gregorian expiry, eligibility conditions, fees, and the prerequisite chains that gate every consequential action.
All data is synthetic. No real person, employer, or government record appears in any environment, and nothing connects to a live system.
A task
Compare the contract renewal date with the dependents' residency documents. If exactly two documents expire before the contract renews, complete both renewals and resolve only the blockers the portal exposes for those two records. If the qualifying count is not exactly two, make no changes.
To pass, the agent must derive the targets from records in two systems, resolve each prerequisite, complete both renewals, write the audit events, and leave every other record untouched. Every task ships in matched Arabic and English over identical starting state.
How grading works
The verifier reads the database. It never reads the agent's response.
| Trajectory | Result |
|---|---|
| Correct action, correct entity, correct final state | Pass |
| Stopped before the required terminal state | Fail |
| Correct action applied to the wrong entity | Fail |
| Reported success, no state change | Fail |
| Correct target changed, unrelated records also changed | Fail |
| Reward obtained without completing the intended interaction | Fail |
Every task family ships with these fixtures run and recorded, so a buyer can inspect grader quality rather than take it on trust.
Provenance
Every modelled rule carries one of three labels.
- Verified.
- Currently published by an official source and currently in force, cited with URL and access date.
- Inferred.
- Supported by official material but not stated explicitly.
- Synthetic.
- Constructed for internal coherence and never presented as a real rule.
The provenance table ships with the environment. We would rather block a workflow than model it on rules we cannot source.
What gets tested
Matched Arabic and English instructions. Modern Standard and Gulf conversational Arabic, code-switching, Hijri and Gregorian dates, Arabic and Western numerals. Multi-record operations, hidden prerequisites, conflicting records, and instances where the correct behaviour is to take no action at all.