01
Research question
Students define a focused question, identify assumptions and select evidence capable of supporting or challenging a conclusion.

High School & Sixth Form · Ages 16–18
CIRC high-school programmes are designed for students ready to move beyond guided demonstrations. Learners define requirements, work with data, integrate software and hardware, evaluate reliability and defend technical decisions. Projects can support A Level enrichment, EPQ-style research, university preparation, portfolios and international collaboration.

Ages 16–18
Research-led projects
Technical portfolios
University and industry pathways
01 / Programme model
01
Students define a focused question, identify assumptions and select evidence capable of supporting or challenging a conclusion.
02
Software, data, electronics, mechanics, interfaces and human procedures are treated as interacting parts of one system.
03
Performance is assessed through repeatable tests, baseline comparison, failure analysis and documented limitations.
04
Every project concludes with a portfolio, demonstration and viva-style defence suitable for academic or professional audiences.
02 / Autonomous systems project
Teams develop a rover that explores a controlled environment, identifies targets and produces a useful map or mission record. The project can be implemented in simulation, with educational robotics platforms or through a more advanced custom build.
Perception
Students integrate distance, inertial, vision or marker data and document the limitations of each sensing method.
Planning
Teams compare rule-based navigation, graph search or other age-appropriate planning approaches against defined mission constraints.
Reliability
Testing includes changed lighting, sensor noise, communication loss, obstacles and recovery or safe-stop behaviour.
Output
The team submits architecture diagrams, code, test results, risk controls, a live demonstration and a technical evaluation.
03 / Computer vision research
Students build and evaluate a vision pipeline for a bounded task such as recognising recyclable materials, plant conditions or safety markers. The goal is not merely high accuracy, but understanding when a model is suitable for use.
01
Teams define classes, gather or curate permitted images, document provenance and examine representation, balance and label quality.
02
Students establish a baseline, train one or more models and keep variables controlled when comparing approaches.
03
Performance is examined using suitable metrics, confusion analysis and targeted tests outside the ideal training conditions.
04
The final paper considers privacy, bias, false confidence, environmental cost, human review and the consequences of error.
04 / Robotics and human factors
Teams design a supervised task in which a person and robot share information or physical space. The project brings together engineering, interface design, psychology, ethics and safety.
Task
Students decide which steps suit automation and which require human perception, dexterity, responsibility or contextual judgement.
Interaction
Interfaces use light, sound, screen or motion cues so the operator can understand what the robot is doing and intervene.
Safety
Teams create a risk assessment, operating boundary, emergency stop, speed limits and supervised test protocol.
Study
Participants complete a defined task while students collect non-sensitive evidence about clarity, workload, error and confidence.
05 / AI product development
Students develop a web or mobile prototype that uses an AI capability to address a genuine education, community or sustainability need. The project follows a product process rather than beginning with an API.
01
Teams research users, map the current problem and write measurable product requirements and responsible-use boundaries.
02
Students plan interface, data, model or API, storage, permissions, fallback and human-review components.
03
A minimum viable product is built in short sprints and tested against representative tasks, failure cases and accessibility needs.
04
The pitch explains value, evidence, risks, operating cost, limitations and the technical and governance work required for deployment.
06 / Data science project
Students construct a simplified digital representation of a school system using real or simulated data. They explore scenarios without claiming that a model perfectly predicts the future.
01
Teams choose a tractable domain such as energy, room use, transport, water or air quality and define what the model includes and excludes.
02
Students clean, structure, visualise and document data, including gaps, uncertainty and permitted use.
03
A dashboard or simulation compares possible interventions and makes assumptions visible to decision-makers.
04
The final output separates observed evidence, modelled scenarios and value judgements so that conclusions are not overstated.
07 / Independent research pathway
Suitable for EPQ-style work or a supervised research studio, this pathway supports an individual or small team through a defined investigation with an original practical or analytical component.
Question
Students review existing work, identify a gap appropriate to available time and resources and write a question that can be answered with evidence.
Method
The plan defines variables, participants or datasets, equipment, risk, consent where relevant and an analysis method before collection.
Analysis
Students report uncertainty, anomalies, negative findings and methodological limitations alongside any positive result.
Dissemination
Outputs may include a research paper, poster, code repository, prototype and oral defence with questions from mentors.
08 / International capstone
Teams in different countries address a shared challenge locally, exchange technical evidence and review one another’s systems. Collaboration is structured around engineering milestones rather than informal communication alone.
01
Partners agree requirements, interfaces, test cases, documentation format, data rules and evaluation criteria.
02
Teams build complementary modules or contextual variants while maintaining versioned technical records.
03
A partner team attempts to reproduce a result, test an interface or challenge an assumption using the supplied documentation.
04
Students present where designs converged, where context required difference and what evidence changed their decisions.
09 / Assessment and pathways
01
Requirements, architecture, code, data documentation, model evaluation, engineering drawings and verification results.
02
Literature review, method, ethics, analysis, limitations, citations and a reasoned conclusion.
03
Role ownership, issue tracking, version control, design decisions, peer review and individual reflection.
04
Projects create discussion material for university applications, apprenticeships, competitions and interviews without guaranteeing admission or employment.
10 / Feasible delivery
6–8 weeks
One tightly bounded system or research question with guided methods and a final technical presentation.
12–16 weeks
A full research, build, integration and verification cycle suitable for enrichment or extended curriculum time.
Two terms
Partner formation, common specification, distributed development, cross-testing and a joint showcase.
Capacity
Planning, technical preparation, assessment resources and defined mentor review strengthen delivery while preserving student ownership.
Build the next programme
We can shape a class project, school pilot, international team or multi-school pathway around your learners.