Student-Centered Policy

This Student-Centered Policy ("Policy") sets the standard for work that belongs to the students. It is published by the Global Robotics and Science Foundation ("Global Robotics"), and it works alongside other policies that set the rules for the VEX Competitions.

• The Code of Conduct says how everyone is expected to behave.

• The Youth Protection and Safety Policy

   sets the rules for adults and the protections every student can count on.

Together, these three documents put the VEX Philosophy into practice.

Why Student-Centered

The work belongs to the students. The educational value of robotics comes from what students learn by doing that work themselves, so every part of a Global Robotics program is built to keep the work in their hands.

In a single season a team designs, codes, tests, and operates a complete robot, decides its strategy, and competes with it. Few professional engineers ever work across a whole system this way: most spend a career on one narrow part of it. A student sees the entire system every season, from finding the problem to running the robot on the field.

Educational robotics succeeds when the students are the ones doing the work. When they are, the program does what it exists to do. When an adult does the work instead, the program is being misused: the engineering disappears, and the students are left with a result they cannot explain, however impressive it looks.

Student-centered work rests on two principles. Students do the work: the robot, code, notebook, strategy, and the decisions behind them are the team's, and deciding is the most important work a team does. Students can explain the work: someone on the team can speak to every part, though no one student has to explain all of it.

Two more checks, described below, cover outside help and outside design inspiration.

Help and Its Limits

Help is doing it with you, not for you.

Teaching leaves the work in the student's hands. The mentor adds understanding, skill, or judgment that stays with the student. The student still does the work.

Taking over puts the work in the adult's hands. It is the main way student-centered work breaks down. The student is left with work they did not do and cannot fully explain. Its clearest form is producing the team's work outright: the robot, the code, the notebook, the strategy.

Mentors make a team better when they teach rather than do the team's work. Table 1 shows the clear cases. When help is still unclear, the Help Check below tests it.

Table 1: Teaching and Taking Over

Passing the Help Check is not the whole test. We can be helped well on one thing and still not have done the work overall. The Help Check asks about a single piece of help; the Student-Centered Check asks whether the work, taken as a whole, is ours.

How to Help Without Taking Over

A good mentor asks more than answers. "What have you tried?" beats "Here is what you should do." Teaching means letting students engage in productive struggle. A student who works through a hard problem has learned something. A student who gets the answer quickly may have learned nothing.

Sometimes an adult does need to step in: for safety, to prevent damage, or because a student does not yet know enough to go on. When that happens, the help stays brief, the mentor names it out loud, and the work goes back to the student. A mentor who says, "Let me show you this part because it could be dangerous, then we go back to you doing it," is teaching. An adult who quietly does the work without saying so has taken over.

Professional development for mentors is coming to the Global Robotics Library.

Help from Generative AI

Asking a generative AI tool to explain or teach something is a form of help. Apply the Help Check, the same as for any other help.

Design Inspiration and Outside Ideas

No team works alone. A good idea can come from anywhere: a mechanism on another robot, a trick from a reveal video, a mentor's suggestion, a piece of public code. Building on the work of others is not a shortcut. It is how real-world engineering moves forward.

A student-centered question should not focus on where the idea started. It should look at whether the team did the work of making it their own. That is where understanding matters: a team that has learned the basics can take an outside idea and build on it, while a team that has not can only copy it. The Design Check asks whether the team did that work.

Ideas from Generative AI

Ideas a team keeps from a generative AI tool are an outside source, like an idea from a video or another team. Apply the Design Check, the same as for any other outside idea.

Engineering and Design

Engineering and design decide what a robot does and how. This is the team's work in every competition program, whether the team builds its own robot or competes with a pre-built one such as VEX AIM or VEX AIR. This section applies the three checks to engineering and design.

Strategy Is Student Work

A team's strategy, deciding what the robot should do, what to prioritize, and what to trade off, is an engineering decision, and it belongs to the students. An outside strategy is held to the same standard as any other outside idea. A team that takes an approach from another team or a video runs it through the Design Check. How a team uses its strategy to compete on the field is covered in Events and Matches.

The Engineering Design Process

Student-centered engineering follows the Engineering Design Process: the team defines a problem, finds possible solutions, and improves them by prototyping, testing, and refining. The process repeats: it is not a straight line. A team changes direction as it learns. The process is drawn many ways, with different steps and names, and any of them works. What matters is that the work is iterative, and the engineering notebook is where the team shows it happened.

When Designs Look Alike

Robots built for the same game often look alike, and resemblance is not copying. When one design resembles another, what matters is how it got there.

• Two teams can reach the same solution on their own because the challenge rewards it. When only a few designs score well, the same ones show up everywhere, and no one copied. This passes the Student-Centered Check.
• A team can find an idea outside, on another robot or in a reveal video, and make it their own: understood, adapted, tested, and credited. This passes the Design Check, and it is how engineering moves forward.
• Or a team can copy a design without understanding it, without adapting it, and without doing the engineering. The team's hands may have assembled it, but the work is not theirs, because this fails the Student-Centered Check and the Design Check.

Starting Points: Hero Bot and Beyond

Some competitions provide a Hero Bot: a robot a team can build from official instructions to start the season with something that works. A team can also start from its own past robots, a sample build in the VEX curriculum, a design in a reveal video, or another team's published notebook. Building from a starting point is not, by itself, the team's own engineering. What the team does with it is. A starting point is treated like any other outside source: the team credits it, and the engineering notebook shows where the team went from there to make it their own.

A team may compete with a Hero Bot for the current season. Using the official VEX starting point is not copying, so it does not fail the Design Check, whether the team competes with it as built or changes it along the way. The rest of the standard still holds: the students build the robot, drive it, write their own code, and keep their own notebook, and they can explain how it works and why. A Hero Bot the team built and understands is the team's own work. Changing and improving it makes more of the robot theirs, but a team that competes with it as provided has still done its own work.

Code

Code is the team's engineering work, the same as its design and build. Code is also unlike the rest of a team's work: a robot must be built by hand. Code can be had in seconds, copied from a website, sent from another team, or written by a generative AI tool. What matters is not that outside code exists, but where it came from and whether the team made it its own.

Where Code Comes From

Wherever code comes from, it is one of three kinds.

• The team wrote it – This is the team's own work. There is nothing to credit and nothing to check.
• An official VEX starting point – The programming languages, the built-in example projects, the sample code, and the firmware VEX provides are the shared starting point every team has. Using them is not copying, and they need no credit, the same as using VEX components or building from a Hero Bot. This only applies to the code VEX itself provides. Code someone posts on a forum or shares from another team is an outside source, covered below.
• Outside code the team built on – Outside code can be templates, another team's code, code from a past season, a library, or code from a generative AI tool. The team brings it into its own program and makes its robot do what the team wants. To make outside code work on their robot, the team applies the Design Check: understand it, adapt it, test it, and credit the source. Code that is pasted in and left to run untouched is not the team's work: that is copying, and it fails the Design Check.

Outside code must also be available to every team, not private or paid. Competition is fair when every team could have used the same resources, and code only some teams can get is not fair to the teams that cannot.

Crediting Code

Outside code is credited where it appears in the code and again in the notebook's list of outside sources, so a judge reads one list instead of searching the program. What a credit contains is covered in the Notebooks and Judged Documents section.

Notebooks and Judged Documents

Engineering Notebook

A team's engineering notebook is its own record of the season: what the team tried, what it decided, what it changed, and what it learned. It is part of the competition like the robot and the code, and it is held to the same standard. The students keep it, in their own words, and the student who wrote any part can explain it. When the team builds on an outside source, the notebook credits it. How to keep a strong notebook, the rubric judges use, and the choice of paper or digital are covered in the Global Robotics Library.

• Event Pages in the Judging section will list when Engineering Notebooks are required, and for which awards.

The Summaries

When a team is judged at an event, it also submits short summaries of its season's work. These summaries are how a team presents its season to judges who were not there to see it. A judge has only a short time with each team, and the summaries let the team show what it did, how its code works, and what it built on, so the judging begins with the team's own account of its work. Judging is something the team asks for; these summaries are how the team makes that judging possible.

• We recommend that teams document the summaries in their notebook.
• Summaries must be submitted as a separate document at the event.
• Event Pages in the Judging section will list which summaries are required, and for which awards.

Season Summary

The Season Summary is the team's one-page overview of its season: what the team learned, the skills its members built, and what its robot can do. It points to the notebook entries behind each highlight. Judges read it first, and it sets the agenda for the interview. This is the students' own account of their season, and it can also serve as the team's handout to others.

Code Summary

The Code Summary is a one-page explanation of how the team's code works: what it does, in what order, and how it decides between paths. Its job is to let someone who does not read code, including a judge, follow the logic without reading the code line by line.

The team chooses how to show it. Pseudocode, a diagram, a labeled field map, or a plain list of steps all work, as long as a reader can follow what the code does and why. What matters is not the form but that the logic is clear to someone outside the team. The Code Summary covers the code the team runs, whether autonomous, driver, or a Coding Skills program. Teams that use no code do not submit one.

Credit Summary

When the team uses an outside source, a design, a mechanism, or code it built on, the credit names where it came from: enough to identify the source, not a record of what the team did with it. List what is known: a video title, an event and date, a team name and number, a website. Those credits are listed where they occur in the Engineering Notebook and within the code.

The Credit Summary gathers these credits in one place, like the Works Cited page of a research paper: the outside ideas currently used on the robot, and the outside code currently used. A judge reads one list instead of searching the notebook and the code.

Events and Matches

The student-centered standard applies at events and in matches, the same as during the season. Coaches and mentors teach and advise. No adult does the team's work, decides for the team, or speaks for the team.

• Pits – Students work on the robot.
• Inspection – Students present the robot and answer the inspector.
• Judging – Students answer every question about the team's work.
• The field – Students drive and make the calls.
• Alliance selection – Students choose.

Adults stay present and supportive throughout: they transport, feed, organize the pit, work with the Event Partner, console, and celebrate. They do not step into the work where the team is being watched or judged, including under time pressure, which is part of the test, not an exception to it.

Judging

Judging takes place in an open, public space, and the conversation is between the judges and the students. Students need not memorize answers: they may consult their notebook, the way engineers reference their own documentation.

Accommodations

Accommodations for students who communicate differently are welcomed and protected. An interpreter, communication support, additional processing time, or a written response is not an adult taking over. It is how the student takes part. The Accessibility Accommodations covers how accommodations are requested and arranged.

Purchased Work

Everything that goes into a team's robot must be the team's own work or made the team's own. Paying for it, trading for it, or taking it as a favor does not make it the team's. A design, a mechanism, an assembled robot, or code the team did not do is not the team's work. Entering it as the team's own is not student-centered.

This is why the Design Check cannot rescue purchased work. The Design Check is how a team makes an outside idea its own, by understanding it, adapting it, and testing it on its robot. That works because an idea is only a starting point: the team still does the engineering. Purchased work is not a starting point. It is the finished result, the engineering already done by someone else. There is nothing left for the team to make its own.

Two things are not "work" in this sense, and both are expected: buying parts from the VEX catalog, and trading or sharing parts with other teams. Parts are the shared source that makes fair competition possible. Everything built from them is the team's to earn.

Modifying parts is a team's own work. But a modified part carries that work in it, so a team may not hand its fabricated parts to another team as if they were raw stock. Sharing raw parts is expected. Passing along the work done to them is not.