About
About me
High school student at The Lawrenceville School, working on projects in physics, computation, and energy.
Austin Amissah
The Lawrenceville School, Class of 2027
I was born in New York and grew up in Connecticut and New Jersey. I was named for my grandfather, Justice Austin Amissah (1930–2001), a Ghanaian judge and legal scholar. Not Without Help is his autobiography. In addition to English, I can hold a conversation in Chinese, French, and Spanish. Two of my projects I started on my own, one about a home battery that should charge when electricity is cheap and one about a quantum circuit that has to get the right answer on every test, while the third, a furnace that has to put its heat in the right place, came with my internship. What holds my interest in problems like these is that objective numbers decide whether the work is right.
I began by reading broadly about energy systems and narrowed, over time, to a research project on quantum computing for solar storage. When the competition at ecdsa.fail caught my interest, I did that one too. In the summer of 2026, between my junior and senior years, I was fortunate to spend six weeks at Brookhaven National Laboratory in its High School Research Program.
Beyond the lab
I have been playing soccer since I was four. These days I play varsity soccer in the fall and run varsity track in the spring at Lawrenceville (the Big Red). Practice takes a real part of my week. It is the one part of the day where the only thing that counts is what you do right then.
This summer I also got to climb in Yosemite.
Journey
How I got here
Milestones. The day-by-day is in the progress notes on each project page.
July 2025
Launched this site
Started writing down what I was reading about energy systems.
January 2026
Narrowed to one question
Can quantum computing optimize home solar and battery storage?
January to June 2026
Set up to build
Linux, git, this site, and the Python and Qiskit stack. What I learned was the workflow: run it, read what comes back, decide what happens next.
July 2026
Both projects running
Solar: real Colorado data in, and four circuits on ibm_fez for 7 seconds. ECDSA: reproduced the community circuit on all 9,024 test points and concluded it could not be improved.
July to August 2026
Brookhaven National Laboratory
Six weeks in the High School Research Program. Found where an optical oven focuses its light, mapped the beam, melted indium, tin and zinc there, and presented a poster on the last day. Both projects ran mostly on nights and weekends.
August 2026
The year, the encoding, and three hardware runs
All 365 days solved: $455.72. The same question on 52 qubits instead of 117. On ibm_fez the smaller encoding degraded less, 0.30 against 0.37, three runs out of three.
August 2026
The circuit changed underneath the ECDSA work
The competition replaced its circuit on August 23 and accepted 25 improvements to the one I had called unimprovable. Two of my published claims fell that week. Built a filter for the new circuit and posted the corrected numbers upstream.
August 2026
Depth went to hardware
Registered a dead heat between one and two circuit layers. The deeper circuit won, and won again the next day.
August 2026
Corrections, and writing it up
Reviewed both repositories, rebuilt every figure on this site, and wrote up the internship.
Method
Checking the fast version against the slow one
In both projects the obviously correct way to get an answer is too slow to use. So you write a faster one, and then you have to decide whether to believe it. My rule is that the fast version does not get used until it matches the slow one everywhere the slow one still runs.
- Brute force tries every battery schedule, so it cannot be wrong. It runs out of room at about 20 variables. The fast method and the simulator have to match it exactly below that.
- To know how much the real machine distorted an answer, I need the undistorted answer to compare it against. I compute that in NumPy, because Qiskit runs out of memory at the sizes I needed. The two agree to four parts in a quadrillion where Qiskit still works.
- In the circuit competition, changing the circuit changes the test it has to pass, so every version has a failure rate rather than a verdict, and measuring that rate means running the whole benchmark over and over. My tool for that is 9.2 times faster than the official one. Before using it I ran both on the same 199 attempts and made it match the exact count of failures, not just pass or fail. 199 of 199, every difference zero.
- Each of the three arguments I tried for proving a gate dead came with a case where the answer was known in advance, so a negative result would mean the method worked rather than that it was broken.
- My filter for the circuit the competition ships now has to reject the same candidates the real simulator rejects, and reject them at the same point. On two test candidates it named shot 223 and shot 421 as the first failure. The simulator named 223 and 421.
Two of those known-answer cases came back wrong, and both were bugs in my own code. A fourth tool, a sampler counting how often each gate fires, failed its test outright: it saw a quarter of the supposedly dead gates firing in a circuit that passes all 9,024 tests. A sampler sees a gate fire but cannot see why a gate is quiet, so it cannot answer the question it was built for.
None of this is my invention. The rule I lean on most came from another competitor's notes: a null result only counts if the output changed. That rule caught a run of mine that was measuring the same thing every time and returning what looked like clean data.
Disclosure
How this work gets made
I build with an AI assistant, Claude Code. It writes and debugs code, helps draft and revise the words on these pages, and checks the numbers I publish against the data in my repositories.
The decisions are mine. The histories of both projects and this site run to hundreds of commits on GitHub, and each one records a choice I made: a question I want answered, what to try, whether the result was good enough to keep, what to redo, what to claim, and what to leave out. The tool does not make those choices, and it does not judge its own output and then ask for a specific improvement. I do that.
The runs happened on my laptop and my own IBM Quantum account, and when something on these pages is wrong, that is on me, not the tool.
This is also how I learn. I built all three by asking questions and wanting each version to be better than the last. I ask, it explains, I push back, then I verify, because my name is on the result.
Two tables in the quantum-solar repository record how the runs went. PREDICTIONS.md lists every prediction I wrote down before a run, next to what the run returned: 26 predictions, 13 held, 8 falsified, and 5 where the plan set a rule for reading the result instead of guessing which way it would go. DECISIONS.md lists 9 points where a cheaper or better-looking option was available and I took the other one. Most of the time that was because I wanted to see what the answer would be. A test in the repository fails if a registered prediction is missing from PREDICTIONS.md, if a link in either table stops working, or if these counts stop matching the write-ups.
A personal note
What it was like
With the quantum circuits especially, there were long stretches where I did not know what I was doing. I could follow the steps and I could tell when a number came out wrong, but I could not always have told you why the thing I was trying was the right thing to try.
The harder part was that there was never one obvious next step. There were always several directions I could go, and most of the work was deciding which ones to drop. Chase this or leave it? Is it worth another week? I got a fair number of those calls wrong, and the project pages say where.
It also took much longer than I expected. There was a long stretch where I was not sure I would finish either project at all. What kept me going was usually not a good idea arriving. It was looking at a result, or a page, and not liking how it looked. I do not want to stop when something does not look right.
When I was stuck on a decision I went back to what I wanted at the start: build something useful, that I would learn from, and that I could explain to someone else in one piece. That ruled a lot of things out. If I could not explain why a result mattered, it usually meant I did not understand it yet.
I kept writing it all down for one particular reason. From the outside, quantum computing looks closed off, like something you need a lab and a doctorate to touch. It is less closed than it looks. I ran on a real quantum computer for free, from my desk, on an account anyone can sign up for. If someone reading this comes away thinking it is something they could try as well, then the writing was worth doing.
Both projects still have follow-up work I would like to do. But they are at a stopping point where I would be glad for someone to read them. I expect to come back as the machines and the algorithms improve, or when I have a new idea worth testing. A lot of what I ran into was the limit of what is available today rather than the limit of the question.