PPristone AcademyLearn · Mentor · Build

Research Mentorship Track: technology applied to the field you already care about.

Most research programs hand a student a topic. This one starts with a question the student already has. You care about genetics, or basketball, or currency markets, or how a painting holds together. You build something computational inside that interest: a model, a simulation, an analysis, or a working system. I supply the technical rigor and the research process. Your field supplies the question.

The track is 36 sessions of 1.5 hours each, 54 hours total, one-to-one and remote. It runs across a 9-month academic year, one session per week, and it also works in concentrated blocks during school holidays. That flexibility matters for boarding-school students, and the structure holds either way.

start with a diagnostic session more than 250 five-star reviews

What the track is

You pick a genuine interest. We turn it into a research question that a computer can actually help answer. Then you build the thing that answers it. Over 54 hours you go from a rough idea to one substantial piece of work: a simulation you designed, a model you trained, an analysis you can defend, or a system that runs. You write it up the way researchers do, and you present it.

I'm Edward Mabonga, founder of Pristone Academy. I'm an MIT EECS graduate with 19 years as a software engineer, over 1,000 tutoring hours, and more than 250 five-star reviews. I mentor mathematics, contest math, computer science, AI and machine learning, and technical project work.

Who it's for

Students roughly 13 to 16 who already have a field they care about and enough persistence to work on one hard thing for months. You don't need to be a strong programmer yet. You do need to be willing to learn one, write real code, and think for yourself. If you want a fast certificate or a project someone else builds for you, this isn't that.

How it's different

This isn't tutoring. Tutoring helps you get through material someone else assigned. Here you produce original work that didn't exist before.

It isn't science-fair coaching. There's no template to fill and no rush to a deadline. We go deep on one question and hold a real standard.

It isn't college-application packaging. I make no claims about admissions, and I won't. Research is worth doing because it builds real capability. That's the whole claim. What you'll have at the end is a piece of work you understand completely and can explain to anyone.

The work is authentically yours. I guide the question, teach the methods, review what you build, and hold the standard. You do the thinking. That line doesn't move.

I should also be clear about what I am and what I'm not. I mentor the computational method and the research process. I'm not a domain expert in genetics, business, or medicine. Domain knowledge comes from published literature, and where a project needs it, from a domain reviewer. I won't supervise claims about the subject matter itself. I'll make sure your method is sound and your reasoning is honest.

What you produce

One substantial project, or one substantial project plus one smaller piece. That's the honest output of 54 hours. Depth beats breadth here every time. You finish with working code, a written report in the shape of real research, results you can defend, and the ability to walk someone through every decision you made and why.

The next step

Before I accept a student, we have a short conversation and I set a small task. It tells me whether you're ready, whether your interest is real, and whether the fit is right. It costs you nothing but an hour and some honest effort.

If you have a field you care about and you want to build something serious inside it, start with a diagnostic session. We'll talk through your interest, look at what a project could look like, and decide together whether the track is right for you.

I keep only what the work requires: the student's code, drafts, and our scheduling. Files are stored securely and deleted on request after the engagement ends.

Phase architecture

Five phases across 36 sessions. The architecture holds no matter which field the student picks.

  1. Phase 1: Question and Groundwork (6 sessions)

    Goal:
    Turn a broad interest into a specific research question a computer can help answer, and confirm it's feasible in the time available.
    Student output:
    A written one-page question statement, a short review of relevant published sources, and a rough plan.
    Parent-visible signal:
    You receive the written question statement. The project now has a clear, stated goal.

  2. Phase 2: Method and Tools (7 sessions)

    Goal:
    Learn the specific programming, mathematics, and technique the project needs. Build the smallest possible working version to prove the approach.
    Student output:
    A minimal working prototype and code the student can explain line by line.
    Parent-visible signal:
    A short demonstration or screenshot showing something runs, however small.

  3. Phase 3: Build (12 sessions)

    Goal:
    Build the full project. This is the longest phase and the hard middle, where the first approach often fails and gets rebuilt.
    Student output:
    A complete working model, simulation, analysis, or system.
    Parent-visible signal:
    A working version of the full project exists and can be run or shown.

  4. Phase 4: Analysis and Validation (7 sessions)

    Goal:
    Test whether the results are real and honest. Check the method, question the findings, rule out easy mistakes.
    Student output:
    A validated set of results with the limitations stated plainly.
    Parent-visible signal:
    A results summary the student walks you through, including what the project can and can't claim.

  5. Phase 5: Write-up and Presentation (4 sessions)

    Goal:
    Write the work up in the form of real research and prepare to present it.
    Student output:
    A finished written report and a short presentation of the project.
    Parent-visible signal:
    You receive the final report and can watch or hear the presentation.

Eight research pathways

Each pathway is one computational method applied to one field. I mentor all eight on the technical and research side. Domain facts come from published literature and, where needed, a domain reviewer.

1. Simulation applied to sports

Description:
Build an agent-based simulation of a sport or a team decision and test strategies inside it.
Why it's serious:
Real teams and leagues use simulation to make decisions. Modeling a system well forces the student to state their assumptions precisely and check them against real outcomes.
Prerequisites:
Basic programming, comfort with probability, patience for iteration.
Difficulty:
Moderate.
What the student builds:
A simulation with agents that follow rules, plus experiments comparing strategies under those rules.
Final deliverable:
A working simulation and a written analysis of what strategies win and why, with limits stated.
How it goes shallow, and the fix:
It becomes a toy that just replays known tactics. Prevent it by requiring a specific prediction the simulation makes and a real dataset the prediction is checked against.

2. Machine learning applied to biology and genetics

Description:
Train a model to classify or predict something from biological sequence or measurement data.
Why it's serious:
Modern biology runs on this. Done honestly, it teaches the student where models mislead and how to test whether a result is real.
Prerequisites:
Solid programming, willingness to learn the math behind one model, care with data.
Difficulty:
High.
What the student builds:
A trained model on a public dataset, with a rigorous evaluation the student designed.
Final deliverable:
The model, the evaluation, and an honest write-up of what it predicts and where it fails.
How it goes shallow, and the fix:
The student pastes data into a library and reports an accuracy number. Prevent it by requiring a proper train and test split, a baseline to beat, and an error analysis. Biological interpretation is checked against literature or a domain reviewer, not asserted by me.

3. Computational modeling applied to art

Description:
Build a generative system that creates images or music from rules, or model the structure of existing works.
Why it's serious:
It turns aesthetic intuition into explicit rules, which is hard and revealing. The student has to define what they mean before a computer can produce it.
Prerequisites:
Basic programming, a real interest in a visual or musical form.
Difficulty:
Moderate.
What the student builds:
A generative system with parameters the student can explain, or a quantitative analysis of a body of existing work.
Final deliverable:
The system plus a written account of the rules and choices, or the analysis with its findings.
How it goes shallow, and the fix:
It becomes random output that looks interesting but means nothing. Prevent it by requiring an explicit definition of the goal and a way to judge whether an output meets it.

4. Machine learning applied to business and investing

Description:
Train a model on real business or market data to predict or classify one clearly stated thing, then test honestly whether it holds up.
Why it's serious:
Business and market data is noisy, non-stationary, and full of traps that flatter a model. Telling a real signal apart from a lucky backtest is one of the hardest lessons in applied machine learning.
Prerequisites:
Solid programming, comfort with statistics and probability, skepticism.
Difficulty:
Moderate to high.
What the student builds:
A model trained on public business or market data, with an evaluation the student designed, including a baseline and out-of-sample testing.
Final deliverable:
The model, the evaluation, the code, and a plain statement of what it predicts, where it fails, and what it does and doesn't show.
How it goes shallow, and the fix:
The student overfits a backtest, leaks future information into training, or reports a return number with nothing to compare it to. Prevent it by requiring the question up front, a strict time-ordered train and test split, a naive baseline to beat, and a written limitations section. Financial interpretation is grounded in published sources, and no claim is made about real trading performance.

5. Optimization applied to education

Description:
Model a real scheduling or resource problem and solve it with an optimization method.
Why it's serious:
These problems are genuinely hard and everywhere, from timetables to assignments. A working solver that beats the manual approach is a real result.
Prerequisites:
Solid programming, comfort with logic and constraints.
Difficulty:
High.
What the student builds:
A solver that takes a real constraint set and produces a valid, improved solution.
Final deliverable:
The solver, a comparison against a manual or naive baseline, and a write-up of the method.
How it goes shallow, and the fix:
The student solves a tiny made-up case that proves nothing. Prevent it by requiring a realistic problem size and a measured comparison to a baseline.

6. Algorithms applied to biology (bioinformatics)

Description:
Implement and apply a core algorithm, such as sequence alignment, to real biological data.
Why it's serious:
These algorithms are the foundation of the field. Implementing one from the ideas up, rather than calling a library, teaches how and why it works.
Prerequisites:
Good programming, comfort with recursion and data structures.
Difficulty:
High.
What the student builds:
A working implementation of a real algorithm, applied to public data, with correctness tests.
Final deliverable:
The implementation, the tests, an application to real data, and a write-up.
How it goes shallow, and the fix:
The student calls an existing tool and reports its output. Prevent it by requiring the algorithm to be built from the ground up and checked against known correct results.

7. Game design applied to simulation and artificial intelligence

Description:
Build a game around a specific question about rules, strategy, balance, or agent behavior, then test that question through repeatable experiments.
Why it's serious:
A game is a system of interacting rules. Designing one well requires the student to turn a creative idea into precise mechanics, model how those mechanics affect behavior, and test whether the system works as intended.
Prerequisites:
Basic programming, willingness to learn a game engine or framework, patience for testing and iteration.
Difficulty:
Moderate to high.
What the student builds:
A playable game prototype with one mechanic, rule set, or artificial-intelligence system designed as the subject of an experiment.
Final deliverable:
The working prototype, the experiment results, the code, and a written analysis of what changed, what happened, and what the results do and don't show.
How it goes shallow, and the fix:
It becomes a creative game project with no research question. Prevent it by requiring a specific hypothesis, a baseline for comparison, measurements chosen in advance, and a clear separation between what the student likes and what the evidence supports.

8. Robotics and artificial intelligence

Description:
Build a robot, physical or simulated, that senses, decides, and acts, then test one specific question about how it behaves.
Why it's serious:
Real robots defeat clean theories. Sensors are noisy, actuators drift, and the world never matches the model. Closing the loop between perception, decision, and action is where artificial intelligence stops being abstract.
Prerequisites:
Solid programming, comfort with geometry and basic physics, patience for hardware or simulation debugging.
Difficulty:
High.
What the student builds:
A working robot or a faithful simulation of one, with a control or learning policy the student implemented, plus repeated trials measuring how well it performs a defined task.
Final deliverable:
The robot or simulation, the code, the trial data, and a written analysis of what worked, what failed, and why.
How it goes shallow, and the fix:
It becomes a kit built from a tutorial with one successful demo on video. Prevent it by requiring a stated question, a policy or algorithm the student wrote rather than copied, repeated trials under varied conditions, and reported failure rates rather than a single good run.

Qualification gate

Not every student is ready for this, and taking one who isn't wastes their time and mine. Here's what I look for.

Readiness criteria.

  • A real interest in a specific field, not a general wish to do research.
  • Basic programming ability, or clear evidence the student can learn it fast. Some pathways need more than others, and I'll match the project to the level.
  • The persistence to work on one hard thing for months, including the part where it stops being fun.
  • Willingness to do the thinking themselves and to be corrected.
  • Enough written and spoken English to read sources and explain their work.
  • A schedule that can actually hold a weekly cadence or holiday blocks across 9 months.

The screening conversation and task.

Before I accept a student, we have a 45 to 60 minute diagnostic conversation. I ask what they care about and why, and I listen for whether the interest is genuine. I give a small, concrete task suited to their level, such as a short piece of code to write or a dataset to poke at and describe. I'm not testing polish. I'm testing whether they engage, think, and push through a small problem without being handed the answer. After that I tell the student and parent honestly whether the track is a good fit. Sometimes the honest answer is not yet, or not this.

Package terms

What's included.

  • 36 sessions of 1.5 hours, 54 hours total, one-to-one and remote.
  • Structured across a 9-month year, weekly or in holiday blocks.
  • All project mentorship: question design, method teaching, code and draft review, and holding the standard.
  • Up to 12 hours total of between-session review across the whole track. Reading code and drafts is real work, and this cap keeps it sustainable. I'll flag when a project is approaching heavy review needs so we can plan around it.

What's excluded.

  • Unlimited messaging between sessions. Use the sessions and the review budget.
  • Rewriting or building the student's work for them. I review and guide. The student builds.
  • Admissions or college-application consulting of any kind.
  • Domain expertise outside the computational methods listed. I mentor method and process, not the underlying science. Domain review, where a project needs it, is arranged separately.

Payment structure.

For a 9-month engagement I take a deposit of $510 (equal to four sessions) to reserve the place, then stage the remaining $4,080 in monthly installments across the term. The deposit is applied to the final month. Full track price is $4,590 at $85 per hour and $127.50 per session.

Rescheduling and cancellation.

Sessions can be rescheduled with at least 24 hours' notice at no cost. A missed session with less than 24 hours' notice counts as used. Either side can end the engagement with two weeks' notice. On cancellation, you pay only for sessions delivered plus review hours used, and any unused deposit balance is returned.

Terms for working with minors

The typical student is 13 to 16 and may be outside the US. These terms are plain on purpose.

Parent visibility.

A parent or guardian receives the output at the end of each phase and can ask for a short progress note at any time. I'll raise concerns about progress or fit early and directly.

Session recording.

Sessions are recorded only with the written consent of the parent and the student, and only so the student can review the work. Recordings are shared with the family and not used for anything else. If either the parent or student prefers no recording, we don't record.

Data handling.

I keep only what the work requires: the student's code, drafts, and our scheduling. Projects use public datasets. No private personal data about the student goes into any project. Files are stored securely and deleted on request after the engagement ends.

Ownership.

The student owns their work and their code, fully. They can publish it, keep it, or build on it. I claim no ownership. I may describe the type of project I've mentored in general terms, never using the student's name, work, or identifying details without written permission.

The next step

If you have a field you care about and you want to build something serious inside it, start with a diagnostic session. We'll talk through your interest, look at what a project could look like, and decide together whether the track is right for you.

start with a diagnostic session