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: a home battery that should charge when electricity is cheap, and a quantum circuit that has to get the right answer on every test. The furnace, which has to put its heat in the right place, came with my internship. Problems like these hold my interest because objective numbers decide whether the work is right.
I began by reading broadly about energy systems, then narrowed to a research project on quantum computing for solar storage. Then the competition at ecdsa.fail caught my interest, so 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
Dates are milestones, not when the work happened. In between was reading, attempts that went nowhere, and from July 6, the internship. The day-by-day is in the progress notes on each project page.
July 2025
Launched this site
Started documenting 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
Got a working setup in place with Claude Code: Linux, git and GitHub, this site, and the Python and Qiskit stack the projects run on. The assistant wrote much of the code from the start. What I learned was the workflow: run everything on my own machine, read what comes back, and decide what happens next.
July 2026
Both projects running
Solar: a sample day solved three ways, then NREL sunlight, Xcel rates and real household usage, then four circuits on ibm_fez for 7 seconds of quantum time. ECDSA: reproduced the community circuit on all 9,024 test points, profiled where its cost lives, 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 around that point, and presented it as a poster on the last day. The lab had the working day, so both projects ran on nights and weekends. While I was there the competition accepted 25 improvements to the circuit I had just called unimprovable, eight of them in one day.
August 2026
The year, the encoding, and three hardware runs
All 365 days solved exactly: $455.72. Found an encoding that keeps the full amount on 52 qubits instead of 117. Sent both encodings to ibm_fez with my prediction written down first, and the smaller one degraded less, 0.30 against 0.37. Ran the comparison again with a control, then a third time to measure the machine against itself, which showed my published error bars were too narrow. Then swept battery sizes and found the saving stops rising once the battery holds more than it can push out during the expensive hours.
August 2026
Corrections, and writing it up
Chased a limit in my optimizer that looked like it had knocked down a published conclusion; 120 more runs said it survived. Re-measured the ECDSA search cost on the current circuit and found it unchanged. Then reviewed both repositories and rebuilt every figure on this site. After the poster session, wrote the internship up here.
August 2026
The circuit changed underneath the ECDSA work
The competition replaced its circuit on August 23. Built a filter for the new one that spots most failing candidates in milliseconds instead of the official checker’s twenty seconds. The filter’s first measurements caught one of my own claims: a search cost I had estimated from just eight samples and an exponential formula. Another claim fell the same week, when a submission improved a component twenty minutes after I had said it could not be improved. I corrected both in my own write-ups, and posted notes to the competition repository so other competitors had the corrected numbers.
August 2026
Depth went to hardware
Asked whether a deeper circuit helps once real noise is on it, with the prediction, a dead heat, registered first. The prediction was falsified: the deeper circuit won, and the identical circuits won again the next day in a fresh calibration window. The first run’s explanation for the win did not survive the second run, and the write-up withdraws it in place.
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 wrote and debugged much of the code in both projects and on this site, including the interactive demos, helped draft and revise the words on these pages, and checked 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.
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.