Startlist AI for Equipe — User Guide

Startlist AI is an extension for Equipe that turns riders' free‑text wishes into a fair, rule‑based start order — and helps you import and inspect Hippodata alongside it. You write what a rider asks in plain language, in any language, and the AI reads it, converts it into precise start‑order constraints, and helps you apply them to the class.

This guide covers day‑to‑day use for show secretaries and organizers. A short technical appendix at the end covers the AI backend.

Contents

1. Overview
2. Opening the extension
3. Screen 1 — Rider Requests
4. Writing a good request
5. What the AI understands
6. Screen 2 — Process Rider Requests
7. Status icons reference
8. Good practices
9. Technical appendix

Overview

The workflow has two halves:

Collect wishes. On the Rider Requests screen you record, one by one, what each rider (or their groom, trainer, or the secretariat) asks for. The AI reads each request the moment you save it and shows you the constraints it understood.

Build the order. On the Process Rider Requests screen you pick a class, let the tool compute a start order that respects every understood constraint, review what was applied or could not be satisfied, and push the result back to Equipe.

Two companion screens — Hippodata import and Hippodata Viewer — let you bring class, result, team and FEI‑article data in from Hippodata and inspect the raw data when you need to.

Everything runs against your own local AI server, so rider names and requests never leave your network.

Opening the extension

The extension opens from inside Equipe and shares Equipe's session, so it always works on the meeting you already have open — there is nothing to log into separately.

Because Equipe opens the extension in the same tab, every screen has a Back to Equipe button in the top‑right of the title bar. Use it to return to exactly the Equipe page you came from.

Screen 1 — Rider Requests

This is where wishes come in. The screen has two parts: a form to add a new request at the top ("New request to AI"), and the Requests received table below it.

Adding a request

1. Pick the rider. Start typing a rider's name (or a horse's name) in the search box and choose from the list. If you pick a horse, its rider is selected automatically.
2. Choose the scope. By default a request applies to the whole show — every class that rider is entered in. If the wish only concerns certain classes, untick Whole show and pick the specific classes from the grid. When the meeting spans several weeks, use the week tabs to narrow the list first.
3. Write the request. Type what the rider asks in the text box, in any language. You do not need to translate it or phrase it in any special way — write it as the rider said it.
4. Save. The request is stored immediately and sent to the AI. Within a few seconds the row updates with the constraints the AI understood.

If you are unsure how to phrase something, the help button next to Save shows worked examples of well‑understood requests.

Reading the Requests received table

Each row shows:

Two small buttons on the right let you edit (✎) or delete (🗑) a request.

When the AI needs your help

Most requests are understood outright and marked with a green check. Three things can ask for a human decision:

• Two matches — pick one. The rider named someone (e.g. "after Rozier") and more than one rider matches that name. A small dropdown appears — choose the correct person and the constraint resolves.
• guessed. The wording was unusual, so the AI proposed the closest constraint but left it inactive. Read it, and if it is right, click ✓ approve to activate it.
• not understood. The AI could not interpret the text. If it is the only thing in the request, a rephrase button lets you reword it. This is also what you see when a request contradicts itself (for example "before 10:00 and after 14:00") — the reason is shown so you can explain it to the rider.

The step badge at the top of the screen tells you at a glance how many items still need a human decision.

Writing a good request

The AI is designed to read natural, messy, real‑world requests. A few principles help it do its best work.

Write in any language. French, English, Dutch, German — mix them if you like. The AI detects the language automatically.

Say it the way the rider said it. You do not need keywords. "My horse is green, I'd rather go early", "j'arrive du CSI voisin, pas avant 14h", and "graag vroeg starten" all work.

Put several wishes in one request. One sentence can hold many constraints and the AI will extract each one. "Not right after Rozier, but with Gonin and Billot, and not before 14:30" becomes four separate constraints.

Approximation words are fine. "More or less in the middle", "if possible early", "ideally near the end" are all read as normal preferences, not as uncertainty.

Examples that work

What the AI understands

The AI maps every request onto a fixed vocabulary of constraint types. You do not need to memorise these — they are what you see on the ✨ line — but this reference explains each one.

Position in the list

Timing (clock)

The AI is careful with the difference: "before 10:00" limits the latest start, while "not before 14:00" limits the earliest.

Spacing and horse order

Relative to other riders

Grouping riders

Family / surname grouping. A request like "put all the Beks together" or "the three Beks" is understood as a group of every entered rider carrying that surname — you do not have to name each one. The AI expands the surname to all matching riders in the meeting.

The break

"Before" only means the break when followed by "the break" / "the pause"; "before Cyrius" is read as an order between horses or riders, not the break.

Negations and conflicts

The AI reads negation before the keyword: "not after the break" becomes before the break, "not too early" becomes start late. When a request contradicts itself in a way that can never be satisfied — first and after the break, before 10:00 and after 14:00 — it is flagged as not understood with the reason shown, rather than silently applied.

When the AI genuinely cannot tell what a rider wants, it returns unknown instead of guessing. A message that only describes the horse's condition or simply says thank you is left as unknown on purpose.

Screen 2 — Process Rider Requests

Once wishes are in, this screen builds the actual start order for a class.

Pick the class. Use the Week / Day tabs to navigate to the right day (the Week row is hidden automatically when the meeting is a single week), then choose a class from the list.

Compute the order. The tool works out a start order that satisfies as many constraints as possible, and shows you the proposed running order.

Review what happened. A log lists each constraint and its outcome — applied, could not be applied (with the reason), or still needing review. Riders cited in group requests are highlighted so you can see the blocks. Anything the AI never understood on the Rider Requests screen is called out here so it is not silently lost.

Watch for arena overlaps. If a computed order would make the same rider clash across arenas running in parallel, the screen warns you.

Undo if needed. A history panel lets you restore the previous order for a class if you want to step back.

Apply to Equipe. When you are happy, push the order back to Equipe.

Status icons reference

Each request row carries one status:

Within an interpreted request, individual constraints may still show:

• ✓ — resolved and ready.
• ⚠ pick one — a name matches several riders; choose which.
• guessed / ✓ approve — inferred from unusual wording; approve to activate.
• ✗ not found / ✗ incomplete — a named rider or horse could not be matched, or a group has too few resolved members.

Good practices

Record wishes as they arrive rather than in a batch — the AI reads each one in a few seconds, so the table stays current and you catch anything that needs a decision early. Prefer the rider's own words over your paraphrase; the AI is tuned for natural phrasing and paraphrasing can lose nuance. When a request concerns only some classes, set the scope precisely so it does not apply show‑wide. And before applying an order, glance at the log for any "could not apply" lines — those are the wishes worth a quick word with the rider.

Technical appendix

For the administrator running the extension.

AI backend. Requests are interpreted by a local large‑language model served through Ollama (/api/chat). The default model is Gemma 4 12B. Running locally keeps all rider data on your own network.

How interpretation works. Each request is sent with a fixed system prompt that defines the constraint vocabulary and the rules above, at temperature 0 (deterministic) with JSON‑formatted output. The server also receives the rider's own horses so it can tell a horse name from a rider name, and the rider's own name so it can spot self‑references. After the model replies, the extension resolves the named riders and horses against the meeting's entries and flags anything ambiguous or unmatched.

Speed and the timing badge. The ⚡ done in X s badge on each row is the real inference time measured around the model call. Because the large system prompt is cached by Ollama between requests (prompt/KV caching), typical interpretations run in about 3–5 seconds on modest GPU hardware. Keep the model resident (keep_alive: -1) so it never has to reload after idle periods.

Monitoring. If you point an uptime monitor (e.g. Uptime Kuma) at the Ollama server, prefer the lightweight GET /api/tags endpoint for health checks; reserve real generation checks for a longer interval so they do not occupy the GPU unnecessarily.

Data flow for the timing badge. Interpretation time is stored per request and returned to the browser with the rest of the request record, so no extra configuration is needed for the badge to appear; requests interpreted before the feature was added simply show no badge.