Under the Hood
AI Integration
Gemini is used in a handful of narrow places where the alternative is asking a human to read something. It is never used to write the content players read, and every call site has a working fallback.
What it is not used for
Weekly missions are not generated by a model. They are drawn from a hand written template pool, and the descriptions in them are authored. The model’s only role there is classifying a mission that already exists.
Nothing a player reads is model-written except one field: the reason attached to a submission review. Contract text is written by the issuer who is paying for it, mission text is written by hand, and the interface strings are translated rather than generated.
Where it is called
Screenshot analysis
Reads a KSP screenshot a member posts and returns the craft, the location and a difficulty rating as structured data, which the reward is then calculated from.
Without it: Disabled. Screenshots are not analysed and no reward is paid.
Reviewing a submission
Given the mission text and the submitted screenshots, judges whether the work matches what was asked for. The in-game path additionally sends the vessel telemetry.
Without it: The submission is auto-accepted rather than blocked.
Classifying one contract
Turns a mission text into a type (build a craft or fly a vessel), a situation, a target body, and the constraints its wording implies.
Without it: Keyword heuristics produce the same shape of answer.
Classifying a week of missions
The same thing for a whole week's board in one call, rather than twenty.
Without it: Keyword heuristics, per mission.
Resolving a loosely named part
Pins a part a mission text refers to by an informal name onto an actual installed part.
Without it: Keyword heuristics.
Submission review is called from two places, the Discord path and the in-game path, which is why the count of call sites is six rather than five.
One gate in front of all of them
Every call site asks the same helper for a client, and that helper returns nothing in two cases: no API key is configured, or the monthly AI budget is spent. So a blown budget degrades exactly like a missing key, and there is no separate code path to get wrong.
Failing towards the player
Notice which way each fallback leans. A submission that cannot be reviewed is accepted rather than refused, because a model being unavailable is not the contractor’s fault. A screenshot that cannot be analysed pays nothing rather than paying a guess.
Caching
Classification results are stored in Firestore, so a set of missions is classified once and reused rather than re-sent every time somebody opens the board. That keeps both cost and latency predictable, and it is what makes the weekly board free to look at.
Screenshot analysis is separately rate limited per player, three calls a minute, because each one is a paid request drawn from a budget everybody shares.
Language
Anything the model reads is language-agnostic: a mission written in any language is classified the same way. Two things are not. The keyword fallbacks match English and Turkish tables, and screenshot analysis pins its output fields to English on purpose so the same screenshot produces the same record whoever posted it.
The Turkish tables are not dead code. The crew and profession heuristic runs on every classification to fill in bounds the model left unset, not only when the model is unavailable.
For the budget mechanism behind the gate, see Architecture.