Technology and AI Transparency

Robolyst is a single SvelteKit application written in TypeScript, using Svelte 5 and Tailwind for the interface. It runs on Node. Most pages are built per request, against your team and your role.

Data sits in PostgreSQL. We use Drizzle for the schema and migrations, so any change to how your data is stored exists as a file in the repo that one person wrote and another approved. We don't alter the database structure by hand or reach into it through a web panel.

The notebook and documentation editors are built on TipTap. Maps are MapLibre. Icons are Lucide. We host our own fonts rather than loading them from Google, so opening a page doesn't send a request to a third party.

The application and the database run in Docker containers on a VPS we rent and administer. Cloudflare sits in front for bot detection. Uploads go to Cloudflare R2 object storage.

Last verified against production on 15 August 2026. Every name below is somewhere your data can go.

Event, team, match, ranking and award data comes from the FIRST Tech Challenge Events API. We sync it into our own database so pages load faster.

Work is tracked in GitHub issues and reaches the site through pull requests that a maintainer reads before merging. Our repository is write protected, so another person has to approve a change before it can be merged. Some of what we build is published for other teams to use.

We're a 501(c)(3) staffed exclusively by volunteers, so the constraint is time rather than money.

AI coding assistants take on a lot of the visual work while people keep the features. All it can modify is the frontend layer.

Screens are designed before they're built. The team management portal was laid out in Figma first, and so is most of what you see inside the toolkit. Someone decides what belongs on a screen, what sits next to what, and what a student should do first.

AI comes in after that, turning an agreed design into components that behave on a phone. Marketing and landing pages use it most, because they're mostly layout and they get rewritten often. Inside the toolkit it does less: we draft components and layouts with minimal styling, then use AI to polish them.

Every change gets the same review whether or not a model helped write it, and nothing deploys straight from a model's output. Code that appears to work isn't sufficient on its own. In the areas marked no in the table above, the review is slower.

There are two AI features and you have to switch each one on yourself. AI Access, under Team Management, gives your team a server URL you can connect to Claude, ChatGPT or Gemini. Once it's connected you can ask an assistant about your own roster, tasks, schedule, documentation and budget.

It signs in as you, so the assistant sees exactly what your role allows and nothing belonging to another team. It is not a way around permissions. Most of what it can do is read. The rest writes the same things you would: a task, a meeting, a checklist run, a notebook entry, an expense, an order request, a scouting note, an announcement left as a draft. Every tool is listed on the settings page, marked read or write, before you connect anything, and every write it makes is logged there with your name on it. Any owner or admin can disconnect it later.

Smart tagging is the second. With it on, a task title, a documentation entry, a link or an arriving email is sent to Google's Gemini API, which answers with a short list of your team's own tags. It picks from the list of tags you have made and cannot write anything else: the model is given your tag ids and can only reply with those. On tasks, entries and links it proposes, and a person clicks to accept. Inbox mail it files directly, the same way your own filing rules already do, and any tag it applies comes off in one click.

The same switch lets search go by meaning as well as by matching words. Once a task, a notebook entry or a wiki page has sat unedited for a couple of minutes, its text is sent to the Gemini API and comes back as a list of numbers, stored next to the record and deleted with it. What you type into search is converted the same way, so a search for "intake keeps jamming" can find an entry called "roller slippage fix". A wiki page nobody gave an icon gets one, picked from the same fixed set the icon picker shows.

What it never touches: money, cards, donations, reimbursements, member records, attendance, and anything on your public site.

The bolts board is the one thing that doesn't wait for a switch. When a documentation entry, a task or an outreach note is about to earn bolts, its text goes to the same Gemini API with one closed question: does this look like real work, yes or no. What goes out is the entry text, the task's title and description, or the outreach note. This runs for every verified team, with the AI module on or off, because the board pays money and a team that turned AI off must not thereby earn unchecked bolts. A no means the record earns no bolts. Nothing is generated, nothing is written back to your record, and the record itself is untouched.

We don't use your content to train machine learning models, and we don't pass your data to companies that would. This is in our Privacy Policy as well.

Connecting your own assistant is the exception, and it's one you make deliberately. Your questions and any data the assistant retrieves go to whichever provider you chose, under their terms rather than ours. We have no control over what they keep or for how long.

Smart tagging goes to Google on our account, not yours, and it runs on the paid tier of the Gemini API. That distinction is the whole point: on Google's free tier the terms let them train on what is sent and let human reviewers read it, and on the paid tier both are prohibited and prompts are kept only briefly for abuse detection. We will not run this feature on a free key.

We keep our own copy of each request for 30 days, the bolts check included: the text that went out, the tags or the yes or no that came back, what it cost. That is how a tag that makes no sense gets traced to the text that produced it, and it's the only record of what the feature spends. Nobody but a platform administrator can open it, and it deletes itself on a timer.

We will not publish model output under a real student's or volunteer's name. We will not let a model decide moderation, account access or whether someone is removed from a team. We will not use one team's private data to build or tune a feature for anyone else; all of our testing runs on a development instance with no real data in it.

OPR, ranking trends, luck, leaderboards and the rest are calculated from match results. No model estimates any of these numbers and no model writes scouting opinions. If a figure looks wrong, either the source data is wrong or our formula is. Both are fixable and you can report either one.