AI Enterprise SolutionsGPT & Claude

Növbə — shift rules in your own words, a rota that provably follows them

Managers of small shift teams in Azerbaijan — shops, pharmacies, clinics, call centres with 8–15 staff on morning/evening/night shifts. Every week they rebuild the rota by hand in Excel or on paper. The rules live in WhatsApp/Telegram messages and in their heads, written in Azerbaijani, Russian or a mix, often without special letters ("Aysel cume gunleri isleye bilmez", "Лейла не может по субботам"). One missed rule means a senior missing from a night shift, someone working 7 days straight, or a night worker back on shift 8 hours later. When the rules cannot all be met, nobody can say which ones collide, so the manager keeps reshuffling. A chatbot can write a rota that looks right, but nothing checks it. Növbə: the manager writes rules as they talk; AI turns each sentence into a structured rule (or asks when it is a preference, or says "not supported yet"); the manager confirms; a constraint solver (OR-Tools CP-SAT) builds the rota; an independent checker re-verifies every rule. If the rules are impossible, it names exactly which ones clash. If someone calls in sick, it moves as few seats as possible.

Video GitHub

Preliminary score

76.0/ 100Strongaverage of 2 judges

Value for the user21.0 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI23.0 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing15.5 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility8.5 / 15
Data requirements, running costs and a clear next step.
Originality8.0 / 10
A meaningful difference from common solutions.

What the judges wrote

Claude Opus 5.5Preliminary75/100
Strengths
You split the work cleanly: the LLM only turns Azerbaijani and Russian rule text into 8 typed constraints, CP-SAT builds the rota, and a separate verifier that does not import the solver re-checks every rule. That makes '0 violations' a checked result rather than a claim. Your evaluation is concrete: 25/25 feasible cases had 0 violations, and the clashing rules matched the planted ones in 5/5 impossible cases. You also show 33 unit tests and Playwright end-to-end checks. You report real failures honestly, including the over-broad conflict report fixed by core shrinking, the 20 s time-limit case and the OR-Tools segfault. The infeasibility explanation and minimum-change sick-day repair answer the manager's actual pain of not knowing which rules collide.
To improve
The weakest link is still unmeasured: parser accuracy per language, including no-diacritics and mixed text. So is the chatbot baseline, so the AI step and the comparison with today's approach have no numbers yet. Run eval/run_eval.py and eval/baseline_chatbot.py and report the results. Add a running-cost estimate (LLM calls per weekly rota, hosting) and a concrete next step, such as a pilot with one real pharmacy or shop. Also name an adoption metric, such as minutes a manager spends on the weekly rota now versus with Növbə.
GPT-6 AstraPreliminary77/100
Strengths
Your separation of language parsing from CP-SAT scheduling and independent verification is a strong reliability choice. Your 30-case synthetic evaluation, rule-level verifier tests and documented fixes provide concrete evidence of the scheduling engine's behavior. Your Azerbaijani/Russian input, explainable conflicts and low-disruption absence repair address specific problems for small shift teams.
To improve
Your main evidence gap is the live AI parser: publish per-language accuracy and full text-to-rota tests, including ambiguous and unsupported rules. Compare your output with manual planning and a chatbot using the same checker, then measure manager time saved in a small pilot. Add per-rota API costs and a concrete deployment next step, including what staff data reaches the model provider. Scope your correctness guarantee to confirmed supported constraints, rather than automatic understanding of every original sentence.

The team

Mathin Khalilov
developer
Zeynalabbdin Huseynli
data
Valiyyaddin AliyevLead
data

Disclosure

Required by the rules. Judges verify it against the repository.

Models: Anthropic Claude via API (model from env NOVBE_MODEL, default claude-sonnet-5-5), temperature 0, output validated with pydantic. Used only to parse rule text and word explanations — never to build the schedule. Built with AI coding assistance (Claude Code).
Data: Fully synthetic: 12 fictional staff (data/shop_staff.json), 7 demo rules, and 30 generated evaluation cases (eval/gen_cases.py, seeded). No real people, nothing stored beyond the session.
Components: Google OR-Tools CP-SAT 9.12, Streamlit, pydantic, anthropic SDK, pandas, pytest, Playwright (UI test only), python-dotenv.
Built during the event: Confirmed

Quality testing

Tested: - 30 synthetic cases (ground truth written first, then rendered as Azerbaijani, Russian, mixed and no-diacritics text), teams of 9–14, 2 weeks. Solver + independent checker: 25/25 feasible cases solved with 0 rule violations; 5/5 impossible rule sets detected, and the reported clashing rules exactly matched the planted ones in 5/5. Median solve 0.13 s. - 33 unit tests: each of the 8 rule types has one passing and one failing check in the independent verifier; solver, infeasibility core, sick-day repair (1–3 seats change, still 0 violations), name matching across scripts (Лейла = Leyla, Gunel = Günel). - 4/4 end-to-end browser checks (Playwright): read rules → build → 0 violations → repair → still 0 violations; 390 px phone layout has no horizontal overflow. What broke: 1. The first conflict report blamed all 6 rules (3 default coverage rules + an unrelated one). Fixed with deletion-based core shrinking: now exactly the 2 clashing rules. 2. Proving "impossible" timed out at 5 s without an objective; with the balancing objective it takes 0.04 s. 3. One eval case hit the 20 s time limit: valid rota, 0 violations, but balance not proven optimal (reported as max solve 20.06 s). 4. OR-Tools 9.15 segfaulted on Windows; pinned 9.12. Not yet measured: parser accuracy per language and a chatbot baseline scored by the same checker — the harness is built (eval/run_eval.py, eval/baseline_chatbot.py) but needs an API key to run.

Worth 20 of the 100 points.

Running it

Python 3.11+ (tested on 3.12, Windows). pip install -r requirements.txt streamlit run app.py No API key? Click "Offline demo: load hand-written constraints for the 7 demo rules (no AI)" → "Build schedule" → in "Report an absence" click "Repair". With a key: set ANTHROPIC_API_KEY (or .env from .env.example) and click "Read the rules". Tests: pytest -q (33 pass, 1 needs an API key). Eval: python -m eval.gen_cases && python -m eval.run_eval && python -m eval.make_testing. UI test: pip install -r requirements-dev.txt && python -m playwright install chromium && python scripts/ui_smoke.py Known limits: 8 rule types only (others flagged "not supported yet"); ortools pinned to 9.12 because 9.15 crashed on Windows; synthetic data only.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.