Every real piece, at once

01 The whole system, in one picture

The same real diagram embedded in the case study, full size and on its own page - every real node, restored from Tourney's own in-app documentation.

Two things worth knowing for planning purposes, both already accounted for. Single database, single server, by design - the right call for a free app with a modest number of players; the natural next step if that changes is splitting MySQL onto its own managed instance (Amazon RDS) so it can scale and fail over independently. The score-checking scheduler is intentionally lightweight - a built-in timer inside the website process, not a dedicated scheduling service; the upgrade path is a standalone worker with a real job queue, so scoring survives a website deploy or restart untouched.

02 The AI path, step by step

The same routing decision is summarized in the case study; this page has the full step-by-step, including exactly how each connection proves who's calling.

1. Tourney drops a pending job in the queue - a row in its own MySQL, nothing more.
2. The FOMX.ai Spark's worker polls Tourney's API and claims it - over a connection secured by a private client certificate plus a bearer token. The app never calls the FOMX.ai Spark.
3. The worker runs gpt-oss:20b locally, on the FOMX.ai Spark - a call to Ollama that never leaves that machine.
4. The worker posts the result back to Tourney's API - the worker initiating outward again, same as step 2.
5. Tourney saves the result to the same queue row the job started in.

For an agentic run, steps 2 and 4 each still happen once. What repeats is a third kind of call sandwiched inside step 3: every time the model wants data instead of finishing, the worker posts that one ask to the app and feeds the answer back to the model - up to 20 times per job. The Claude-direct agentic arm never touches the FOMX.ai Spark at all; its tool loop runs in-process, calling the same Python functions directly.

How the connection proves who's who

Every time the worker reaches out, it presents a certificate - a private credential belonging to it and no one else - and the app only continues once that certificate checks out. A certificate only works once two things have already happened, each done once, by hand: it's created for that one worker, and it's separately registered on that environment's own approved list.

Because dev, SIT, and production each keep their own certificate and their own approved list, a credential from one can never be used against another.

Other features, and what it's built with