Student-Centered Policy

Learning is Everything. Winning is a goal. Have fun.

This Student-Centered Policy ("Policy") sets the standard for work that belongs to the students. It is published by the Global Robotics & 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 Policy sets the rules for adults and the protections every student can count on.

Together, these three documents cover three things: whose work it is, how everyone behaves, and how students are protected.

Why Student-Centered

The work the students do is where learning and understanding come from. The educational value of robotics is what students learn by doing that work themselves.

In a single season, a team designs, builds, 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.

Student-centered does not mean there are no adults. Educators, family, and mentors all have a role to play in a student's journey, every season. That involvement carries one requirement: student learning stays the focus. When it does, the program does what it exists to do. When adults do the work instead, the students are not learning and 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.

Global Robotics is committed to keeping it that way: every part of the program exists to support the students' learning and understanding, and to keep the work in their hands.

The Student-Centered Check

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: Teaching vs. Taking Over

The table shows the clear cases, not all of them. When help is still unclear, the Help Check tests it. Professional development for mentors, coming to the Global Robotics Library, will teach the difference in depth.

The Help Check

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.

Paid help is still help. Club dues, a paid coach or camp, a class, tuition at a school with a robotics program, a mentor's own professional development: paying for teaching is normal, and the Help Check applies to it the same. The work itself is never for sale: see Purchased Work.

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.

So when assessing a student-centered question, it should not be focused on where the idea started. The question 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 Ownership Check asks whether the team did that work.

The Ownership Check

Credit lives where the work lives. Outside code is credited in the program itself. A team that keeps a notebook credits its sources there; a team that is judged gathers them in its Credit Summary. A team with no notebook still credits its sources. It names them when asked: at inspection, in a review, or by a judge. No team needs a notebook to be honest about where an idea came from. Crediting a source never counts against a team. Judges expect to see where ideas came from; a credited outside idea, made the team's own, is engineering done right.

Working with other teams

Collaboration between teams is welcome. Teams that share ideas, teach each other, and work through problems together are doing what engineers do. Collaboration does not move the team boundary: what a team brings home is an outside idea, credited and run through the Ownership Check like any other. Another team can teach you; it cannot do your work. However close the collaboration, every team answers the Student-Centered Check for itself. Its robot, its code, its notebook, its decisions: done by the team and explainable by the team. Credit makes the collaboration visible; no team is required to publish its 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 Ownership 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 and 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 Ownership 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 Ownership Check, and it is how engineering moves forward.
• Teams can work together and may arrive with robots that look alike. That is not copying when each team did its own work, credited the collaboration, and can explain its own robot: this passes the Student-Centered Check. Handing over a finished robot or finished code is different: the receiving team did not do the work, so it fails, the same as purchased work.
• 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 Ownership 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 the team's own engineering. 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 Ownership 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.

Instructions are a starting point with the decisions already made. Build steps, a type-along code tutorial, a strategy playbook, a notebook template that says what to write: whoever wrote the instructions did the deciding. Only official VEX starting points may be competed with as provided. Instructions from anyone else, whether an organization, another team, a video, or a generative AI tool, are an outside source like any other: credit them, and make what they built your own. Followed exactly, they fail the Ownership Check: nothing was adapted, and the hands that assembled the robot did not do the deciding.

Code

Code is the team's engineering work, the same as its design and build. It is also unlike the rest of that work; a robot must be built by hand, but 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 season. 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, 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 Ownership Check: adapt it, test it, understand it, and credit the source. Code the team drops in without understanding what it does is not the team's work: that is copying, and it fails the Ownership Check.
  • Libraries work differently. A library is meant to be used as built, called rather than changed, so using one is not copying and leaving it unchanged is not a failure. The team's work is choosing the library, understanding what it does, writing the code that uses it, and being able to explain why it is there. The team credits the library the same as any other outside source.

Bought code is purchased work: no price makes it the team's own (see Purchased Work). Paying for teaching is different: a paid coach or a class is help, and the Help Check applies.

The Help Check applies to code as it does everywhere, and for code it has one answer: teach, but do not do.

• Adults and generative AI tools can teach code.
• Adults do not type or write the team's code.
• Generative AI tools do not write the team's code. What a generative AI tool produces is outside code: a starting point the team builds on and runs through the Ownership Check, never a finished program the team runs as its own.

Crediting code

Outside code is credited where it appears in the code and again in the Credit Summary, so a judge reads one list instead of searching the program. What a credit contains is covered in the Notebooks 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. No adult and no generative AI tool writes it for them. 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. All three summaries are the students' own work, held to the same student-centered standard as the notebook and the code. Judging is something the team asks for; these summaries are how the team makes that judging possible.

• We recommend that teams draft 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 overview 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. A team that runs many programs still writes one page: the overview shows how the programs fit together and how the team chooses among them, not each program in turn. 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. At an event the team does all of the work, and the only reason an adult touches anything is the safety floor that always applies. Time pressure 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. Accommodations are arranged with the Event Partner before the event.

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 Ownership Check cannot rescue purchased work. The Ownership Check is how a team makes an outside idea its own, by adapting it, testing it, and understanding it in the context of 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.

Do the work. Explain it. Have fun.