Self-programming my Phonak I90 Spheres with AI assistance

September 30, 2026 | Projects, Accessibility, AI

I wear two Phonak Audéo I90 Sphere hearing aids, and over two days I reprogrammed them myself with a laptop, a $199 programming dongle, and two Claude sessions that checked each other's work. One session, on my Mac, was the supervisor and was in charge: it was the one I talked to, and much like an audiologist, it turned what I described into carefully planned changes, had every plan criticized, and checked every result. The other, on my Windows laptop, was the operator: the only session that made programming changes, one click at a time, exactly as the supervisor's instructions said. Nothing was saved to my hearing aids without my go-ahead, and nothing was trusted until it had been checked against the raw data, usually by a second agent whose only job was to prove it wrong. This post is the long version of how it worked, and a step-by-step guide for doing it yourself.

How to read this post

This post is for anyone who wears hearing aids and wants to understand their own fitting, and for anyone curious about how to make AI check its own work. It is long, so it is split into seven parts, with three good ways through it.

• Read the story. Part one through Part three cover why I did this, how the method worked, and what each session changed, and Part six is where it all stands. Part four has the exact mechanics.
• Use the guide. Part five has the limits, how to go back, a one-computer setup, and the whole method step by step. Every prompt is there too, in the order you use it, ready to copy.
• New to Claude. Start with before you start and words you will see, then pick a path above.

I am not an audiologist, and nothing here is medical advice. These are prescription devices, so start with your audiologist, and please do not copy my settings, because your ears are not mine.

In this post

• Part one: The backstory and the basics
• Part two: The method
• Part three: The sessions
• Part four: Under the hood
• Part five: Do it yourself
• Part six: Where it stands
• Part seven: Reference

Part one: The backstory and the basics

This part covers why I did this, whose ears these are, what Claude Code is, and the hardware on my desk. If you are new to Claude, start here.

Why I tried this

My hearing is lopsided. My right ear has a severe to profound loss, and my left ear has a moderate loss shaped like a U, best at the lowest and highest pitches and weakest in the middle. Hearing aids are a huge part of my daily life, and I wear mine about fifteen hours a day.

I freaking love the sound of Dolby Atmos TV streaming, and I wanted my streaming to sound as crisp as possible. I also felt that my right ear could totally use a little more help, that my right aid whistled whenever a hand or a pillow got near it, and that the left ear sometimes made the letter "s" sound a bit too sharp. Normally each of those means another appointment, another round of "how does that sound," and another few weeks of waiting. My aids were not a blank slate, though: my audiologist had fitted them, and I had worn them every day for over a year, so this was fine-tuning a fitting that already worked well, not starting from scratch. I wanted to understand my own fitting well enough to fix it carefully, and I wanted every step checked before it touched my ears.

The patient behind the audiogram

I was born with my hearing loss. My 2022 audiogram notes that I wore Oticon behind-the-ear aids in both ears with custom earmolds. My audiologist fitted my Phonak Spheres in June 2025, and that fitting, plus more than a year of daily wear, was the foundation this whole project built on. None of that shows up in the thresholds, and all of it is good to know going into a session. The audiogram told the AI what my ears can detect; the context told it who it was fitting.

Here is the verified interpretation in plain words, and verifying the audiogram first explains how every number was checked. Numbers are in dB HL, where 0 is typical hearing and bigger means worse.

• Left ear. Moderate and shaped like a U: 40 dB at 250 Hz and 8 kHz, but 60 to 65 dB from 1.5 to 4 kHz, averaging 53.3 dB.
• Right ear. Severe to profound: 80 to 105 dB, sloping toward the high pitches, averaging 91.7 dB, with no response at 8 kHz.
• Between them. About 40 dB apart on average, and both middle ears tested normal.
• Words. My left ear scored 100%, but in quiet and by live voice, which tends to score higher. My right ear was not tested on words on that chart.

The AI also had my daily life in my own words. My right ear seemed better in the mornings, faded during the day, and whistled near a hand or a pillow. My left "s" was slightly sharp, and for streaming I wanted high fidelity, with my iPhone's microphone, not my hearing aids', picking up my voice on calls. The first step for the fade was to see whether it outlasted my new right shell, with one firm rule: if it kept happening in quiet rooms, or came with fullness, ringing or dizziness, it would go to an audiologist, because fluctuating hearing needs a professional check, not a tuning change. After the new shell went in, I noticed no fading.

What the context changed

• Experienced user. Target, Phonak's fitting software, pre-selects the experience level only from its own Phonak history, so it could not see that I had worn Oticon aids before. New-user settings give less gain the more loss you have, so the audiogram handoff for Target said to set me as experienced. When I chose to get used to the sharp "s" first, the estimate for experienced wearers was about 1 to 4 weeks, drawn from loudness adaptation research and not a promise.
• No bone conduction. My left ear's air and bone results were only about 10 dB apart on average, and my right bone marks were no-responses, not thresholds. Target's formulas compensate for any bone values entered, so entering mine would have added gain I do not need, and the audit found none had been entered.
• Comfort and clarity over maximum gain. Comfort and sound quality was the one goal I picked at the start. My right ear is severe to profound and was not tested on words on that chart, so louder might not mean clearer. Its increases came in small steps, with a planned step back if it came out louder but not clearer.
• No manual increases to right maximum output. With an Ultra Power receiver, no real-ear measurement and no measured discomfort level, over-amplifying that ear could damage the hearing it has left.
• An older audiogram, with consistent hearing. My chart is from 2022, but my hearing has stayed consistent since, so it was still a fair basis for the fitting. If yours is old, I recommend getting a new one professionally recorded before you change anything.

The interpreter agent's prompt included this line: "Clearly separate established facts from possibilities. Do not diagnose." If you try this, give every session your own context, and share only what you are comfortable sharing.

Before you start: Claude and Claude Code

Claude is Anthropic's AI model, and most people know it as a chat assistant. Claude Code is the version that runs on your own computer and can actually do things there: read and write files, run scripts, look at screenshots, search the web, and start helper agents. That is what made this project possible, because a chat window cannot measure the gridlines in a scan or check its own numbers against raw files.

Claude Code comes with a paid Claude plan: Pro at $20 a month, or Max at $100 or $200 a month for more usage, which is what I use. To start, install the Claude desktop app, sign in, open the Code tab, and point it at a project folder, as Anthropic's desktop quickstart shows. I used the desktop app on both computers, with Claude Opus 5.5 behind every agent. Three features did the heavy lifting:

• Remote Control. Follow and steer a session from another device, such as your phone or a second computer.
• Subagents. Hand focused jobs to helper agents, like a blind reader or a fact checker.
• Workflows. Run many agents in parallel, with a verifier behind each one.

Words you will see

Two terms matter from the start. The supervisor is the Claude session on my Mac, the one I talked to and the one in charge: like an audiologist, it turned my words into planned changes, had every plan criticized, and checked the results, but it never touched the fitting software. The operator is the Claude session on my Windows laptop, the only one that made programming changes in Target, following the supervisor's instructions and asking me before every change. The rest are here in plain words, so you can come back whenever one of them stops you.

My setup

The hardware is simple. A Lenovo Windows laptop runs Phonak Target, the software hearing care professionals use to program Phonak aids. A Noahlink Wireless 2 connects the laptop to the hearing aids over Bluetooth, and I picked mine up for about $199 on Amazon. Its driver comes from HIMSA, the company behind Noahlink, and it normally installs by itself when the dongle or the fitting software goes in. If it does not, HIMSA offers the driver for Windows 10 and 11 for free on its Noahlink Wireless downloads page, along with a firmware upgrader for the dongle. My MacBook runs the Claude desktop app, which is where the thinking happened. The aids are Phonak Audéo I90 Sphere on the Infinio platform, with an Ultra Power receiver on the right, a Medium receiver on the left, and custom shells that I had remade for both ears right before this project started. Every custom shell has a six-digit acoustic code printed on it, which tells the fitting software how that shell fits and vents. Neither Target nor the AI can see that code, so I read it off each shell myself and gave it to the supervisor, which put it into the operator's instructions. If you have new shells or domes, find the code on the device yourself before you start, because nobody else can.

One honest note about the software. Phonak Target is intended for hearing care professionals, and I am not going to cover where I got my copy. What I will say is that the version matters: Target 10.1.2 refused to talk to my aids because their firmware was newer than the software, and Target 12.0.1 worked. In my experience, you can update Target to its latest version at any time from inside the app, and I recommend always staying on the latest version. Phonak's Infinio Ultra product information lists Target 11.1 or higher for my model, and the security notice in Phonak's Target 12.0 user guide says to make sure the installed Target version is up to date. Target also has a firmware update tool under Trial & tools, described in Phonak's Target 11 step-by-step guide, and my understanding is that keeping Target current is what lets that tool offer the newest firmware available for your aids.

The two computers were linked through Claude's Remote Control feature, the same link the Claude mobile app uses, so the Mac session could be followed and steered from the Windows side. Then I ran a second, separate Claude session directly on the Windows laptop, because the Mac session cannot click inside a program on another computer. You do not need a second computer, and doing it with one computer explains why I used two anyway and how to manage with one. That second session wrote its own PowerShell scripts to read Target's screens: the accessibility tree for every label, checkbox and slider, and Target's graph controls, which expose every curve as data points. capture.ps1 and walk.ps1 are even visible in my setup photo. I explain exactly how that worked further down, in how the AI actually did it.

Part two: The method

This part explains how two Claude sessions split the work, and how every answer was checked before I trusted it. Nothing in my hearing aids changes here, because the audiogram, the research and the audit all came first.

Putting Claude in the supervisor's chair

The most important decision in this whole project was splitting the work into two roles, with the supervisor in charge. The supervisor, on my Mac, played the part an audiologist normally plays. It was the session I actually talked to: I told it what I heard in my own words, and it turned that into carefully planned changes, computed from the raw exported data and written into an instruction file for each programming session. Before a plan ever reached the operator, the supervisor had a separate critic attack it, and after the operator finished, it checked every result against the data before it planned anything new. It researched, audited and decided, but it never touched Target.

The operator, on my Windows laptop, was the only session that made programming changes. It followed the supervisor's instruction file exactly, asked me before every change, logged every step with its before and after values, and exported a capture package at the end: screenshots with text dumps, curve data, and Phonak's own fitting reports, all zipped up. It did not plan or improvise, and when the screen did not match the file, it stopped and told me. I carried each zip back to the Mac, so the supervisor always had the final word on whether a session had done what it was supposed to.

The instruction files grew into something like a flight checklist. Each one opened with numbered hard rules, and from session two on they included these:

• Never edit the original client record, which stayed as an untouched restore point.
• Ask me before every change and every save.
• Never raise maximum output.
• Leave specific recalculation boxes unticked.
• Use single arrow steps, and read every value back from the grid.
• Use real mouse clicks instead of automation clicks.
• Stop the moment the screen does not match what the file expects.

Every gain change had to keep the gain for soft speech at least 3 dB below the measured feedback threshold in every program, and by session three that check covered both ears at every point Target draws from 125 Hz to 8 kHz. Those same files capped each session at about four listening comparisons, because a lot of testing had honestly gotten into my head by the end of the first session.

The supervisor did not work alone either. For every serious question it launched a workflow of parallel agents, and in most of those workflows each working agent was followed by an adversarial verifier whose only job was to prove it wrong. Across seven workflows that came to 52 agents, about 10.6 million tokens, 3,059 tool calls, and a little over four hours of wall-clock time, which added up to about ten hours of agent time because so many agents ran in parallel. The supervisor's rule was to recompute every number from the raw files rather than trust an agent's summary.

Verifying the audiogram first

My situation was different from a fitting done from scratch. My hearing aids had already been programmed by my audiologist, and a year of real use told me what worked and what did not, so the goal was to fine-tune a good foundation. That made the first job a validation layer: before touching anything, check everything the existing fitting was built on, starting with the audiogram. It was also a way to confirm that my audiologist had done a good job, and she did a great one.

The paper chart was the only record of my hearing we had, so reading it was not enough. I wanted the AI to truly understand the measurements: what every symbol means, how sure we can be of each one, and how the numbers line up with what I actually live with every day. The goal was to turn one sheet of paper into the best possible annotated measurement, because there was nothing else to reference.

A quick detour: finding the file

This part showed off what Claude Code can do on a real computer. I could not remember where my audiogram was saved, so I asked Claude to find it. It searched my Mac by file name, by Spotlight content, and by the hidden text layer of every PDF in my Downloads, Desktop and Documents folders. Nothing matched, and it correctly worked out that the file had to be a scanned image with no text inside, so it had an on-device text recognition pass ready to go by the time I found the scan myself: a photo of the paper chart from 2022.

Reading the chart

Before any AI read a single symbol, Claude prepared the image. It found the printed gridlines by taking the median brightness of every pixel row and column inside the graph, which ignores handwriting, then cut enlarged crops of every section and laid a calibrated grid over the chart. The paper was slightly warped, so the overlay was treated as approximate and every symbol was judged against the printed lines next to it.

Then three graph readers transcribed every symbol blind, each from a different view of the image: one with the overlay, one with the raw chart counting gridlines itself, and one with only high-zoom tiles. Two more readers transcribed the rest of the form. Two reconcilers, one for the graph and one for the form, compared everything and re-measured the image wherever readings differed, with one rule I love: do not majority vote, the image is the authority. The readers matched exactly on 28 of 34 plotted points, and all 34 were within 5 dB of each other.

All six disagreements were right-ear triangles, and they came down to one question: does the tip or the center of a hand-drawn triangle mark the threshold? The reconciler measured both against the local gridlines and chose the tip, because the tips landed almost exactly on 5 dB steps. Then came the twist. When we finally read the audiogram stored inside my hearing aids, every right-ear value was exactly 5 dB worse than the tip reading, which matched the center reading at six of the seven frequencies. My aids were programmed from the center reading, which is a perfectly fair way to read a hand-drawn triangle, and the verification had flagged that exact question before we ever saw the stored numbers.

Next, one agent wrote a full expert interpretation of my audiogram, and a second agent played a skeptical senior audiologist reviewing it before it reached the patient. The skeptic made 19 corrections and flagged 4 things the first pass left out, including an arithmetic slip, a speech-test conclusion the data could not support, and an overclaim about masking. That was the moment I understood the value of the setup. The first draft was good, and it still needed nineteen corrections.

Rounds of critique

Research came next, with the same pattern. Three researchers covered the hearing aid, the Target software, and fitting science, and each was followed by a fact checker that reopened every source. Out of 142 claims, 123 were confirmed, 11 were corrected, 7 stayed unverified, and 1 was refuted. Three findings mattered most:

• Only the Ultra Power receiver with a custom shell can cover my right ear at all, and it sits right at its limit at 4 kHz.
• Target adds gain if you enter bone conduction values, so we left them out.
• If you never choose an earphone type, Target silently uses a default, as one of the corrections showed.

Then the operator session captured my entire existing fitting before anything changed: 137 screens, Phonak's full 45-page report, and about 158,000 curve points read straight out of Target's graphs. The supervisor audited it with four domain auditors covering the prescription and acoustics, gain and output, features and programs, and device options and usage logs. Each auditor had its own adversarial verifier, and a completeness critic looked for conflicts between them. A separate deep dive tackled my own complaints: streaming crispness, the whistling right ear, a right ear that felt weaker by evening, and the sharp left "s". Across the audit and that deep dive, the verifiers checked 109 findings, confirmed 51, changed 56, rejected 2, and added 42 that the first pass had missed.

The biggest discovery was simple once the data showed it. My right ear was sitting 11 to 20 dB under its prescription between 1 and 3 kHz, not because anyone chose that, but because the old right shell leaked and whistled before the aid could deliver more. At 1 kHz the soft-speech gain was only 1.8 dB away from the measured feedback limit. That leak was also why a hand or a pillow made it whistle. The audit also found that frequency lowering was set from my better ear and did almost nothing for my right one, and it kept my Bluetooth phone setting on Fixed on purpose, because that is what fixed Microsoft Teams on my Mac.

Part three: The sessions

This part walks through every session in order, what changed in my ears, and the audits that checked each one. As a reminder, the supervisor is the Claude session on my Mac that I talk to, which plans every change and checks it, and the operator is the Claude session on my Windows laptop, the only one that makes changes in Target. It ends with how my own plain descriptions turned into precise changes.

Two days at a glance

Here is the whole fitting in order, before the details.

• Day one, afternoon. I found and verified my audiogram, researched the aids and the software, and read my fitting into a restore point and a working copy, without saving anything to the aids.
• Late afternoon into evening. The operator captured every screen and curve, and the supervisor ran the audit and the deep dive on my complaints.
• Evening. Session one entered the new right shell code I read off the shell, reran the feedback test and made a few small comfort fixes, and I saved it to the aids.
• Late evening. Session two lifted my right ear and adjusted streaming, and I saved that too.
• Overnight. Fourteen agents checked session two and planned session three while I slept, without touching the aids.
• Day two, morning. Session three trimmed my right ear slightly and lifted my left, and every change stayed unsaved until it was verified.
• Late morning. The operator redesigned Comfort in noise, and then everything from session three was saved in one go.
• After the save. A final audit recomputed everything from the raw data.

If you try this, have the supervisor keep a timeline like this one from the files, not from memory, because it is the fastest way to see what was saved and when.

Session one: A better seal changed everything

I had new custom shells made for both ears right before this started, but Target still held the old right shell's acoustic code and a feedback test measured with the old shells. So the first session made no gain changes by hand. I read the new code off my right shell, 431965 instead of the old 432597, and gave it to the supervisor, which wrote it into the instruction file. The operator entered exactly that code, read it back from the screen, and re-ran the feedback test.

The left test failed four times, and the reason made sense afterward: my left aid has a much weaker receiver, so its test tone drowns in background noise. It passed as soon as I put in a fresh wax guard and moved to a quiet room. Once the new shell was measured, Target raised my right soft-speech gain by up to 4.4 dB on its own, and I accepted that.

That session also taught the operator its first hard lessons. Automation clicks sometimes changed what a checkbox looked like without changing the actual setting, so real mouse clicks became a rule. Turning off frequency lowering in one program silently turned it off in six, because Target shares that switch across a whole group. When I listened afterward, my left ear sounded less muffled, and in my words at the time, it sounded really good.

Session two: Spending the headroom

With the new seal, the supervisor planned a 5 dB lift for my right ear between 860 Hz and 2 kHz across every program, with smaller lifts on either side, which is about a third of the gap to the prescription. Before the change, the operator tested a trick for selecting only certain cells in Target's grid: clicking a frequency header in the grid's "All" row selects that column's gain rows without touching the maximum output row. The operator then applied the lift in single steps, and Target's own smoothing supplied the smaller lifts on either side by itself. Every program was checked afterward against its own feedback line, and the tightest one still had 3.55 dB of room. For streaming, frequency lowering was turned off in the two Media streaming programs only, and the right side of streamed audio got a small extra lift, applied blind because I could not stream while Target was connected. The result on my right ear was exactly what I hoped for: speech was clearer, not just louder, and loud sounds were fine.

The overnight audit

I went to bed and gave the supervisor permission to keep working. It ran 14 agents overnight across five verified streams: an independent check of session two, the math for a future right-ear step, my left ear, streaming fidelity, and the myPhonak app. Then it drafted a session three plan, ran a critic against it, and revised it. I woke up to a morning report written for a non-audiologist.

The overnight run caught two real problems. First, a tip from session two, turning up the Middle slider in the myPhonak app, turned out to be risky: a Phonak trainer has described that slider as covering roughly 500 Hz to 2.5 kHz in 3 dB steps on older Phonak models, right over my tightest feedback spots, and if that holds for my aids, one step could have left only about 1.2 to 1.3 dB of room. Second, the future right-ear step written into the session two file would have dropped below the 3 dB rule once Target's automatic smoothing of neighboring channels was modeled, so it was replaced with a smaller one. Both mistakes were confident, reasonable, and wrong, and both were caught because the overnight run recomputed everything from the raw data and had a second agent check every result.

Session three: The phenomenal part

By morning my right ear felt like a little too much on loud sounds, with a buzz I described as almost like internal feedback. So session three trimmed it slightly: loud sounds came down about 2 dB between 860 Hz and 2 kHz, soft sounds came down a little near 1 kHz where the feedback margin was tightest, and a small trim went in around 4 kHz because we never pinned down whether the buzz was low or high. In Calm, the tightest spot on my right ear, at 955 Hz, went from 4.30 to 5.68 dB of room before feedback. With my left aid muted, my verdict was "sounding good," and right-ear speech stayed as clear as before.

Body for my left ear

The left ear got the change I will remember. My left ear sounded thin and a bit sharp, so the supervisor planned a small lift for medium and loud sounds between 520 Hz and 1 kHz in my everyday Calm situation program, two single steps that raised the actual curves by about 1 dB for medium sounds and up to about 1.7 dB for loud ones. The moment the operator applied it, the left ear sounded phenomenal. It added body and warmth, and my left ear no longer sounded thin or sharp to me, so the separate "s" trim we had planned was skipped. Earlier in the session we had trimmed the left "s" slightly in the two Media streaming programs only, based on how streaming sounded to me at home.

After the final check, I asked for the same left lift in two more programs, Speech in car and Comfort in noise. The operator explained the trade-off first: more low-mid gain in a noise program also makes the background noise fuller. I said "yes, do both," and my quick listens were "ok" and "k." The lift there is about 0.9 to 1.8 dB for loud sounds and 0.6 to 1.1 dB for average sounds between 500 Hz and 1 kHz, soft sounds moved at most 0.3 dB, and there is at least 13 dB of feedback room in that range. In Comfort in noise, the redesign later in the morning brought the whole program up close to Calm anyway, so there the lift no longer stands on its own. The final audit checked that extension too, and I give its verdict in saved, then audited again.

Checked before the save

One more lesson came out of this session. Single arrow steps in Target were often smaller than 1 dB in this session, so the operator read the grid after every press and added a step where a cell fell short, and the curves still showed some changes landing smaller than the grid suggested. When the operator first asked about saving, I told it to keep everything connected and unsaved until the supervisor had checked the data, so at that point nothing was saved. That independent verification recomputed every curve and confirmed the morning's changes were safe and logical to save: every program kept at least 3 dB of feedback room, and every change on the right ear was a decrease. The save came at the end of the session, after the Comfort in noise redesign, and I explain exactly how it was approved and checked in saved, then audited again.

Fixing Comfort in noise

I have always felt that the Comfort in noise program kind of mutes everything, not just the background. It is one of the automatic programs my aids switch to on their own, based on what their microphones hear. The data agreed with my ears. Compared with Calm, it gave soft sounds about 4 to 6 dB less gain in both ears through most of the speech range, from 500 Hz to 4 kHz, and it ran stronger noise reduction on top of that. Because it shares Calm's measured feedback threshold exactly, Calm's margins showed how far it could safely come up, and the plan was to bring it to about 1 dB below Calm with slightly lighter noise reduction. The redesign had one firm rule: no grid cell could end above Calm, so my right ear would not get more in this program than it already got in Calm, my everyday program.

What changed

The redesign happened the same day, at the end of session three. The operator stepped the program up one press at a time and read the grid after every press. Soft sounds went from about 4 to 6 dB below Calm to at most about 3 dB below it. Average and loud sounds now match Calm within about 1 dB, except on my left side below about 400 Hz, where they are up to about 2 dB less. No grid value in either ear ended above Calm, the curves never rose more than 0.5 dB above it, and the program's maximum output did not change. Its noise reduction, which Phonak calls NoiseBlock, went from Moderate 12 to Moderate 10, still a little stronger than Calm's Weak 8.

That did make my right ear louder in this one program, in the same session as the morning's trim. What kept it in bounds is that every grid value stays at or below Calm, which already includes that trim. One thing neither the plan nor its verifier saw coming was that in Target, stepping soft and average gain up also pulled loud-sound gain up, by 1 to 2 steps in 17 of the 20 channels on my right side. So in Comfort in noise, only about half of the morning's loud-sound trim remains, and in noisy places I am listening for loud sounds on my right that feel like too much. Below 500 Hz, loud sounds on my right in this program are now up to about 1.9 dB above where session two left them. If loud sounds on my right do feel like too much there, the fix is a decrease: my right ear's loud-sound row in this program goes back to where it was before the redesign.

It still keeps plenty of room from whistling. The smallest feedback margin in Comfort in noise is now 6.98 dB on my right side, at 4 kHz, and 6.74 dB on my left, at 4,387 Hz. Just before the rebuild it was 10.25 and 9.13 dB, and after session two it was 8.27 and 9.13 dB, so the redesign spent some of that room, but it stayed far from the 3 dB rule.

How it sounded

For the listening check, the sound came from the computer's speakers, not my phone, because a phone can start a Bluetooth stream, and my aids had already switched themselves to a streaming program once that session. Looped noise and a synthetic voice played while the aids ran Calm, and then the redesigned Comfort in noise, with the same sound both times. I did not even notice when they switched, because, in my words at the time, it "just sounds that good." That check was done while the noise reduction was still at 12. The change to 10 came right afterward, as planned, and I have not listened to it on its own yet, so my first real test of it will be in the noisy places I actually go.

Saved, then audited again

Session three, including the Comfort in noise rebuild, is saved to both of my hearing aids. The morning changes had been checked independently before the save, and the rebuild was checked afterward, in a final audit of what Target read back from the aids.

I want to be exact about how that save was approved. Before the rebuild, I told the operator there was no point saving in between and to "just ... do everything that needs to be done." The operator took that as approval to save once at the end, and it did not ask the plan's separate final question, "Save these changes to both hearing aids?" The audit flagged it, and the lesson is simple: ask the exact save question anyway.

Then the save was checked against the data, not just the log. After the save, Target reconnected without asking which settings to use, which it asks when the aids and the computer differ. All 12 programs it read back matched what had been set at every curve point, with zero difference, and every 20-channel grid matched cell for cell. Two confirmations are still missing: a charger cycle, which shows that the aids start up from their stored memory with the saved settings, and a device report exported after the save.

The final audit then recomputed everything from the raw data after the save. Before its grid reader was trusted, it had to reproduce 880 known grid values from earlier tables, and it did, with zero mismatches. A second, independent pass with new code then confirmed every conclusion and corrected a few numbers, which is exactly the job a second pass is for.

Every program, in both ears, still has at least 3 dB of room before feedback at every native curve point from 125 Hz to 8 kHz. The tightest spot anywhere, and in everyday use, is still my left ear in Calm, at 4.21 dB near 2.2 kHz, and my right ear in Calm has 5.68 dB near 955 Hz. The smallest right-ear margin is in RogerDirect, at 4.26 dB, a program I do not use, because no Roger receiver is installed.

A stricter measure also counts an unlabeled curve in Target's data, which the operator identified in Calm as soft-speech gain without the Speech Enhancer. What that curve means outside Calm is still unconfirmed, so I treat it only as a stricter check. On that measure the lowest values are 3.27 dB in RogerDirect on the right, 4.02 dB in Media music on the right, 4.21 dB in Calm on the left and 4.62 dB in Comfort in noise on the right, and all of them still pass. That 4.62 dB sits at 4 kHz and is new since the redesign, so a high whistle in noisy places is one more thing I listen for.

The locked settings held too. No maximum output value changed in session three, my right maximum output has never been raised by hand, and the only increases since the original fitting are still the shifts of at most 1 dB that Target made on its own in session one. My Bluetooth phone bandwidth is still on Fixed in the last device report, the streaming programs' microphone settings are unchanged, and the restore point was never edited: the session three logs never open it, and the one time I opened it, in session one, to hear the original fitting, it was closed without saving.

The final audit also tried to overturn my left lift in Speech in car and Comfort in noise, and could not, so it stays, with one thing to watch. The change is small, about a quarter of the median change listeners could notice in one study of single-octave gain changes, it is far from any feedback limit, and I asked for it knowing the trade-off. I still heard the same lift clearly in Calm, so I do not assume it is inaudible. Speech in car also uses the same microphone mode and the same light noise reduction as Calm, so there is no directional microphone for the lift to work against. What I am watching is whether background noise, or my own voice, starts to sound boomy, fuller or more tiring in the car and in noisy places. If it does, undoing it in Speech in car takes just two single down steps.

Plain words in, precise fixes out

I never had to know the name of a setting to get help. I described what I heard, when it happened, and where I was, in the same words I would use with a friend. The AI's job was to turn those words into something a fitting can act on: a range of frequencies, a feature, or a physical cause like a loose shell or a clogged wax guard. Then it had to check the data before it touched anything. Being able to describe a struggle in normal human words, and have it land on a precise fix inside the machine, was one of the most important parts of this whole project.

The sound of my own skin

My favorite example started right after the first save, on the evening of session one. I said I was hearing a lot of high-frequency sounds when I should not, that the "s" sound was worse, and that I could hear little high-pitched bits of sound when I rubbed my skin. The way I describe it now is even simpler: when I rub my skin on my neck, the high-pitched sound hurts my ears. Target has no setting called neck.

So the first move was not a change at all. The AI first checked whether the fitting itself had gained any high-frequency output, using Phonak's own 2cc numerical reports to compare my original fitting with the one we had just saved, in all 12 programs. From 2.5 to 6.7 kHz, neither gain nor maximum output had risen more than 1 dB in either ear, and the only changes of any size were lower down, in my right ear. So the new sharpness did not come from a high-frequency increase in the fitting.

Then we used the levers that fit. At my request, soft noise reduction in my everyday Calm program went from Off to Weak. For loud high pitches, the part that truly hurt that night, my left ear's maximum output came down 4 to 5 dB from 2 kHz up, in every program. It sounded the same, because everyday sounds do not reach that ceiling, but it still guards the loudest peaks. Target's automatic fix for a bright, shrill sound went in and came back out twice, and in the end I left it out, because to me it did not sound crispy.

None of it changed the high pitches I kept noticing that night, and I ended the session thinking a lot of testing had gotten into my head. The overnight audit, which ran after session two that same night, called it a textbook case of restored high pitches: a fresh wax guard and a better-sealing new left shell had most likely brought back sound that a partly blocked guard had been dulling, which also fit the earlier muffled sound, and my brain needed time to adjust. It also split my complaint in two: skin rubbing is a quick burst of sound right next to the microphone, the "s" is speech, and each calls for a different tool. In session three my left ear stopped sounding thin or sharp in Calm, and not because we cut the highs there: we gave it more body underneath them. The skin rubbing never came up again in the sessions, and a stronger SoundRelax setting, the Phonak feature that softens short, sudden sounds, is the untested next step if it does.

That was not a one-off. Many changes in this project started as a sentence like that, and here are the best examples, in my exact words.

If you try this, the most useful thing you can give the AI is a good description, and it needs no jargon at all. Say when and where it happens, which ear, and whether it is soft sounds, loud sounds, or both. Say whether it is your own voice, other people's voices, streaming, or everyday noise, and describe it in your own words: buzzy, tinny, muffled, sharp, or whistling. Then say what you are comparing it to, such as yesterday, the other ear, or before the last change. And when your words could mean two things, let it ask: one of my best answers in this project was a single multiple-choice pick.

Part four: Under the hood

This part explains exactly how the AI read and drove the software, how every file was exported, and which checks stayed mine. The operator is the session on my Windows laptop, the only one that worked inside Target, and the supervisor is the session on my Mac that I talked to, which planned and checked everything from the exported files. If you only want the method, skip to Part five.

How the AI actually did it

This is the part I most wanted to get exactly right. Neither Claude session had any special access to Phonak Target. There was no plugin, no hidden interface, and no Phonak integration.

The short version has four parts:

• The operator read Target through the same accessibility layer a screen reader uses, and read every curve as exact numbers.
• It changed settings only with real mouse clicks and drags, one step at a time, and checked every result in the grid and in the curve data.
• The supervisor never saw Target, only the exported files, and did its own math on them.
• The results that mattered, from either side, went to another agent whose job was to prove them wrong.

One more honest detail, about approvals. Both of my sessions ran in the desktop app's bypass permissions mode, which you can see at the bottom of each Claude window in my photos. That mode lets a session run commands without stopping to ask, so the approvals that mattered happened in the chat: every instruction file made the operator ask me before every change and every save. If you are new to this, I would start in a permission mode that asks before it runs commands, and I would insist on it when both sessions share one computer.

The operator's eyes

Windows has an accessibility layer called UI Automation, which exists so screen readers can describe every button, checkbox and slider to people who cannot see them. The operator wrote a script, capture.ps1, that walked that tree inside Target's window and wrote every element to a text file, one line each: its type, its name, its value or state, and its position on the screen. A checkbox arrived as a line like CheckBox | Client view | toggle=Off, and a slider or progress bar arrived with its exact value. The first version missed dropdown values, so the operator fixed its own script until the earpiece, the receivers and the wire length came through as text.

A second script, walk.ps1, came right after the operator said it would redo every screen in order, and the finished package holds a screenshot of Target next to a text dump for each of the 137 screens. Neither script was saved into my project files, so I can show what they produced but not their exact code. Early screenshots caught the Claude window covering part of Target, so it switched to capturing Target's own window directly, whatever sat on top of it, and redid every screen.

Then came the discovery that made the whole project possible. Target's graphs are custom controls, and their accessibility value is not a picture: it is a block of XML called GraphControl that holds every point of every curve. Each curve carries a caption, such as Gain (50 dB speech), Target gain, Measured feedback threshold, or Gain limit, followed by pairs of frequency and decibel values. Target draws each curve at 91 points between 125 Hz and 8 kHz, the first large graph is the right ear, and the second is the left. A small Python reader turned those dumps into tables, so no curve in this project was ever read off an image. The feedback safety rule was checked with arithmetic on exact data points, not by squinting at two lines on a graph.

There was one blind spot. The 20-channel gain and output grids, the numbers I actually change, are drawn by Target as pixels, and their values do not appear in the accessibility tree at all. Text recognition on them was unreliable, so during the sessions every grid value was read visually from enlarged screenshots, and every change was cross-checked against the curve data and against the diff of Phonak's own report. The session three instruction file warned that any secondhand grid value could be off by 1 dB from a reading error, which is exactly why the curves, not the grids, were the source of truth for safety.

The operator's hands

In session one the operator tried to toggle a checkbox through UI Automation, and Target showed the box as changed while the real setting stayed the same. From then on, every click and every drag was real mouse input. The logs do not record which Windows mechanism produced those clicks, only that they were real ones. To select cells, it clicked a frequency header in the grid's "All" row, which selects that column's gain rows without the maximum output row, and it found that a real drag across several headers selects a range while Ctrl plus a click does not. By session three, it took a screenshot before every arrow press and checked exactly which cells were highlighted, and after every press it read the values back from the grid and checked that the other ear had not moved. When a step moved a cell less than expected, it pressed again and read again, so targets were reached by reading, not by counting clicks.

Some of the problems were wonderfully physical. The Claude window stayed on top of Target's right side, which is exactly where the left-ear grid lives, so the operator slid Target partly off the left edge of the screen before every left-ear drag. Then it asked Windows which window sat under the cells it was about to touch, using a system call named WindowFromPoint, and only dragged once the answer was Target. It took a Target snapshot before any change, used undo one step at a time, and stopped to tell me the moment anything on screen did not match the instruction file. It even read Target's own internal log, which showed that my left ear's feedback measurement had physically finished even though Target's evaluation of it had failed.

How the operator learned Target

Neither session knew anything about Target beyond what anyone can read online, so the operator learned the program the way a careful new employee would: from the manual first, and then from the real thing. The supervisor's researchers read Phonak's own manuals, the Target 12 user guide and the step-by-step fitting guides, and pulled out how Target is supposed to behave. The operator then walked every screen of the real program and saved each one as a screenshot and a text dump, 137 screens in all, which became its map of where every control actually lives.

The manual and the real program did not always agree, and when they did not, the real screen won. One idea from the research, a separate manual program just for streaming, turned out not to exist on my aids: the operator's capture of that screen showed that media streaming could only switch on automatically. From then on, every instruction file spelled out exact paths through the real menus, such as Fitting, then Advanced L/R coupling, then Calm situation, then Program options, so the operator never had to guess where anything was.

The operator's knowledge also kept growing. Whenever something surprised it, the surprise was written down and turned into a rule for the next session, so the same mistake could not happen twice:

• An automation click changed how a checkbox looked but not the actual setting, so every click and drag became a real mouse click.
• Clicking a row in the ALL PROGRAMS view selected the whole row, and one maximum output step went in, so the operator started taking a screenshot of the highlighted cells before every press.
• Saving to the database and then closing the session produced "There is already the task type 'Saving' reserved" and "Phonak Target is in an unstable state," so the rule became to check the database, restart Target, and prefer saving to the aids.
• When I asked to hear my original fitting, Target connected with "Use fitting from hearing aid," so the comparison quietly played the working copy against itself, and the fix was to choose "Use fitting from session" and confirm it with a grid value.
• A stray click while moving the window landed Target on the Instruments screen and cleared the undo history, so the operator stays on the fine tuning screen and takes a snapshot before any change.
• The Claude window covered the left-ear grid, so the operator moves Target before every left-ear selection.

That loop is why the instruction files grew from 6 hard rules to 12. Learn from the manual, trust the real screen over the manual, and write every surprise into the next session's rules.

The supervisor's math

The supervisor worked only from files. For the audiogram, a Python script converted the scan to grayscale, took the median brightness of every pixel row and column inside the graph, and marked a gridline wherever a row or column was clearly darker than its neighbors. For the fitting, it parsed the curve dumps with its own code, and the session verifiers wrote their own parsers instead of reusing the author's scripts, then confirmed the ear order from a known value before trusting anything. The margin itself was simple subtraction: the measured feedback threshold minus the soft-speech gain, at every one of Target's native points, in every program, for both ears.

That precision mattered. Session two's check sampled standard frequencies, and the overnight recompute found that the true tightest point sat between them, at 955 Hz, slightly tighter than the log had reported. So from session three on, the margin code had to pass a self-test before it was trusted: run on the session two data, it had to print exactly 4.30 dB for the right ear at 955 Hz and 4.21 dB for the left ear at 2,194 Hz. For planning, the supervisor also fitted a model of how Target smooths a change into neighboring channels, with a more pessimistic version on top, and that model is what caught the unsafe right-ear step overnight.

Agents that try to break each other

The supervisor ran its agents as workflows, which start many agents side by side and chain a checker behind each one. Every agent answered in the same fixed format, so an audit finding always came back with what was observed, the assessment, the recommendation, the expected effect, the risks and checks, a confidence, and a priority. Every verifier answered each finding with a verdict of confirmed, modified or rejected, a reason, and a corrected version when one was needed. None of them could touch Target. A worker could be confident, but it was never the last word.

How everything was exported

Exporting was the backbone of the whole method. The supervisor on my Mac never saw Target, so everything it knew about my fitting came from these files, and every number it planned or checked was computed from them. The exports also gave me an exact record of what my hearing aids held before and after every change, which is what made each change provable and reversible.

Before anything changed, I needed a restore point I could trust. In Target, "Use fitting from hearing aid" reads the fitting out of the aids without writing anything back, so my fitting was read from the aids into a client record and saved to Target's database only. That original record was never edited again. Then the aids were read a second time into a separate working copy, and the two were proven identical by generating Phonak's binaural numerical report for both and comparing them line by line: 279 of 279 lines matched. The raw saved sessions differed in 264 of 28,350 bytes, which is expected, because those bytes hold session identifiers, timestamps, and about 25 extra minutes of usage logging on the aids.

The first export captured my whole fitting from that original record, before the working copy existed, and the operator put a file named CONTEXT_READ_FIRST.md at the top of it, addressed to the AI that would analyze it. Inside were 137 screenshots, each with its text dump, plus all 137 dumps merged into one searchable file. Phonak's own reports were saved as PDF and as text: the 45-page complete report and the 9-page binaural numerical report. The curve data went into CSV files: one with every point of every curve on every screen, 158,205 points in all, and per-program summaries of gain for soft, average and loud speech, the prescription targets, the measured feedback threshold, and the gain limit. After the save, the operator also copied Target's client database, a small SQLite file, along with the saved sessions inside it, which are in a Phonak binary format that only Target can read or restore. All together it came to 294 files, about 70 MB, zipped down to about 40 MB.

One line in that README saved us from a classic mistake. Phonak's reports give values in 2cc coupler units, measured in a standard test cavity, while the curve CSVs are insertion gain, the extra gain at the eardrum compared with an open ear, and mixing the two gives wrong answers. Every package labeled its units, and every package with raw curve dumps said which graph was which ear.

Each session after that sent back a package with the same shape: the session log, before and after screenshots, curve data, and Phonak's numerical report. Session one also saved a report after each change group and a diff of its final report against the original, session two diffed its report against session one's, and the supervisor's verifier diffed session three's. From session two on, each package also carried a copy of the exact instruction file it followed.

Session one's package held 302 files, including a partial re-capture I stopped because it was taking too long; session two's held 60; and session three's held 96 and carried NOT_SAVED in its name, because nothing from that session had been saved to the aids yet. The operator zipped each one on the laptop, and each zip traveled through my Google Drive to the Mac's Downloads folder. Before relying on the session three zip, the supervisor's verifier confirmed that all 96 files in it matched the unpacked copy on the Mac byte for byte. After the final save, session three sent one more package of 129 files, and it matched its unpacked copy on the Mac byte for byte too.

The report diff was the quiet hero of the whole export. In session one, after every change group, the operator generated a fresh numerical report, saved it as text, and compared it with the last one, which showed exactly which settings moved, including side effects nobody asked for. That is how the fix for the frequency lowering surprise in session one was proven complete, with zero differences against the report from before it.

Every check I did by hand

The AI could read, compute and click, but it could not hear, and it could not see my hardware. Those parts were mine. Here is every check I did myself, in order, taken from the session logs.

There are also two checks I skipped and should not have. I never rated the "s" on my left side again after the lift that made it sound phenomenal, and I never told the operator whether the buzz in my right ear was a low hum or a high whine, so the plan had to trim for both. The AI can only be as careful as the answers I give it.

Part five: Do it yourself

This part covers the limits I would not cross, how to go back, how to do it with one computer, and the whole method step by step, with every prompt in the order you use it. If you skipped ahead, the supervisor is the Claude session you talk to, which plans and checks every change, and the operator is the only session that makes changes in the fitting software.

What I would not let it do

I want to be honest about what this is and what it is not. I am not an audiologist, and nothing here is medical advice. These are my own prescription hearing aids, Phonak intends Target for hearing care professionals, and I did this knowing that responsibility sits with me. My audiogram is from 2022, and my hearing has been consistent since, but if yours is old, I recommend getting a new one professionally recorded before you try anything like this.

So the rules were strict:

• Nobody raised maximum output by hand. The only increases were shifts of at most 1 dB, mostly at 850 Hz and 1.5 kHz, that Target made on its own when the new right shell was entered.
• The original fitting stayed untouched as a restore point.
• Every change kept a measured safety margin from feedback, in every program, checked against the exported curve data.
• Every change went in one small step at a time and was checked before the next.
• Nothing was saved without my go-ahead, and the one save that followed a general go-ahead instead of a direct answer is spelled out in saved, then audited again.

If you have hearing loss and are tempted to try something like this, please start with your audiologist, because the most important part of this project was never the software. It was the checking.

How to go back

A restore point only helps if you know how to use it, so here is the ladder I planned, from smallest to largest:

• Undo. Inside a session, Target's undo arrows step back one change at a time, although Target cleared that history in my session three when the operator left the Fitting screen by accident.
• An earlier saved session. After a save, an earlier saved session of the working copy can be opened, connected and saved to the aids again.
• The restore point. If everything goes wrong, the original fitting still sits in the restore point, exactly as it was read from my aids.

I never needed more than undo and putting a value back by hand, so I have not tested the last two myself. I would climb them the way I did everything else: with the operator reading me every screen, and nothing saved without my clear yes.

Doing it with one computer

You do not have to use two computers. I used two for convenience: the operator could take over the laptop's screen inside Target while I gave the supervisor my feedback between rounds of testing, so nobody waited on the screen and I never had to interrupt a session in progress. Technically you can do all of this on one computer, but the second one was a huge time saver. It was also a quiet safety feature: the supervisor could not click inside Target even by accident, because Target was not on its machine. Most people will have one computer, so here is what I would do, although I have not tested either layout myself.

My first choice would be one x64 Windows laptop or desktop with an Intel or AMD processor, running two separate Claude desktop sessions named Supervisor and Operator. It uses exactly the same pieces I used, just on one screen. Phonak's Target 12 user guide lists what that computer needs, including Windows 10 or 11 on a 64-bit system and an Intel Core processor or better, and the Noahlink driver is normally installed along with the fitting software. Replace the zips with one shared project folder and a fixed layout: a read-only restore point folder, a supervisor folder, a folder that only ever holds finished instruction files, a folder per session for the operator's exports, and a folder for your own notes. Have the operator write a small READY.txt file last, listing every exported file with a SHA-256 hash, and have the supervisor refuse to start until that file exists and every hash matches. That keeps the one thing a zip really gave me: a finished, frozen bundle that nobody edits afterward.

The hard part on one computer is discipline, because both sessions can reach the same screen. Write the supervisor's rules into its project instructions: never open, click, or script the fitting software, never use Claude's computer use feature, which lets a session see and click the screen, and hand off only through files. Keep the supervisor in a permission mode that asks before running commands, so any attempt to touch the fitting software shows up as a prompt you can deny. Run the parallel agents only inside the supervisor, and do not turn the operator into a subagent, because its whole job is a live conversation with you where every change waits for your yes. I would also keep two sessions rather than one, because if one session writes the plan and then runs it, nobody independent checks the plan against the screen.

Mind the windows, too: on my laptop a single Claude window already covered the part of Target where my left-ear grid lives, and two Claude windows on one screen make that worse. A second monitor helps, and otherwise I would keep both Claude windows on one side and Target on the other. I would also pause heavy supervisor workflows while the operator is connected to the aids, because a stalled laptop in the middle of a save is the failure you least want, although that is caution, not something I measured.

A Mac on its own is harder. On Apple silicon Macs, Windows runs as an ARM version inside a virtual machine, and HIMSA's Noahlink Wireless FAQ states that Noahlink Wireless is not supported on PCs with an ARM processor. HIMSA's knowledge base says the same about ARM-based Windows, including laptops with Snapdragon processors.

I found forum reports of people giving up on that route and of connections that worked only some of the time, and I found no report of Target 12 with a Noahlink Wireless 2 and Infinio aids working reliably in a virtual machine on Apple silicon. On an Intel Mac, Boot Camp gives you real x64 Windows, which in principle is the same as a Windows PC, but I found no specific report of this setup working there either, so treat it as unproven. If you already have a Mac and can borrow any x64 Windows laptop, my own layout still works: the supervisor on the Mac, the operator and Target on the laptop. A used Windows laptop is a safer purchase than a workaround driver on the machine that programs your hearing.

Step by step

Everything so far has been the story of what I did. This section turns it into a method you can follow, in the order I would do it again. It assumes you have read what I would not let it do and picked a setup, with two computers like mine or one computer as described above. As before, the supervisor is the session you talk to, which plans and checks, and the operator is the only session that makes changes in Target. Each step says what you do, what the AI does, and what you check yourself, followed by the prompts for that step in the order you use them. Work straight down the page: every prompt says when to use it and what you get back, and the next thing to do is always directly below it. None of the prompts has blanks to fill in, because each one tells the AI to find what it needs or to ask you.

Supervisor prompt: Walk me through the method, one checked step at a time.
Use it if you want the AI to guide you through the steps below and keep track of where you are.

You are the SUPERVISOR. Be my checklist coach for reprogramming my own hearing aids with you as the supervisor and a separate operator session. Take the steps below one at a time. For each step, tell me what I do, what you do, what the operator does if anything, and what I must check with my own eyes and ears. Do not move on until I confirm the checks are done, and keep a running checklist in PROGRESS.md in the project folder.

1. Set my limits, and get a new audiogram first if mine is old.
2. Set up Claude Code and the supervisor and operator sessions.
3. Check the hardware and the software version.
4. Gather the facts: my complaints, my audiogram, and my patient context, including the acoustic codes I read off my shells.
5. Verify the audiogram with blind readers, then interpret it and attack the interpretation.
6. Research with a fact check on every claim.
7. Have the operator learn the software, make a restore point, and export everything.
8. Audit the fitting.
9. Write the instruction file, then have a critic attack it.
10. Run a first session for new earpiece facts and a feedback test only, with no gain changes by hand.
11. Run a tuning session from the reviewed instruction file.
12. Save only on a clear yes, read the fitting back, do a charger cycle, and know how to go back.
13. Verify the session against the data.
14. Live with it for one to two weeks, then take the next small step.

If I try to skip a step, tell me what could go wrong and ask me to confirm. If anything I describe sounds like a medical problem, stop and tell me to contact my audiologist or doctor. You are not my audiologist, and none of this is medical advice.

What happens: The supervisor keeps PROGRESS.md and walks you through each step.

Step 1: Set your limits

• You: If your audiogram is old, get a new one professionally recorded first, and write down your limits before you start: never raise maximum output, keep an untouched restore point, save nothing without your explicit yes, and keep a small listening budget per session.
• The AI: Nothing yet, although it can list which parts of your plan still need a clinician, such as masking, a dead-region test, or real-ear measurement.
• Check: Your aids are working and comfortable today, and you know how to reach your clinic. Sudden hearing changes, pain, dizziness, new tinnitus or drainage mean a doctor visit, not a fitting session.

Prompt for both sessions: Paste these limits at the top of every session.
Paste it first, at the very top of every session, in both the supervisor and the operator.

Read these limits before anything else, repeat them back to me in your own words, and follow them for this whole session. If any request, including one from me, would break them, stop and say so.

1. Roles. The supervisor plans, checks and talks me through everything, and never touches the fitting software. The operator is the only session that changes settings, and only from a reviewed instruction file.
2. Restore point first. The original fitting is saved as its own client before anything changes, and it is never opened for editing. All work happens in a separate working copy.
3. Ask me before every change and every save. Save to the hearing aids only on a clear yes to the save question. On anything less, save to the database only.
4. Never raise maximum output, in either ear, in any program.
5. Keep soft-speech gain at least 3 dB below the measured feedback threshold at every point, in every program, for both ears, checked with code on exported data.
6. One small change group per save, then at least one week of normal wear before the next increase.
7. Settings I have asked to keep are locked. Read them from PATIENT_CONTEXT.md once it exists, and ask me if you are not sure.
8. Verify every number against the exported data, not against a log, a summary or your memory.
9. Stop the moment the screen does not match what you expect, and tell me.
10. Send me to my audiologist or doctor, not to a setting, for a sudden hearing change, pain, dizziness, fullness, new ringing, or anything that needs a real-ear measurement or a new hearing test.
11. If the software offers a firmware update, do not accept it in this session. A firmware update cannot be rolled back.

What happens: The session repeats your limits back in its own words and follows them from then on.

Step 2: Set up Claude Code and the two sessions

• You: Open a Supervisor session and an Operator session, on two computers, or on one computer with the shared folders below.
• The AI: The supervisor writes its own rules file and a short project README from your notes.
• Check: Ask each session what its role is and what it may not do, and read the answer. Neither session may write into the restore point.

Prompt for any session: Start a careful first session in Claude Code.
Use it once, in your very first Claude Code session, right after the limits.

This is my first project with Claude Code. I will use it to understand my own hearing aid fitting and, later, to adjust it carefully with two sessions: a supervisor I talk to, which plans and checks every change, and an operator, which is the only session that ever touches the fitting software. Before we do any real work, set up the ground rules.

1. In plain words, tell me what you can do on this computer (read and write files, run commands and scripts, look at images, search the web, start helper agents) and what you cannot do (hear anything, see my hardware, or click inside a program on another computer).
2. Create a folder named Hearing Aid Project in my Documents folder, with a short README.md that holds the limits I just pasted and describes the two roles. Read that README at the start of every session.
3. Before you run any command, tell me in one sentence what it does. Ask me before any command that installs software, changes a setting, or deletes, moves or overwrites a file.
4. Keep everything on this computer. Do not upload my audiogram, my fitting files or my notes anywhere, and do not paste them into a web search.
5. When you are not sure, say so, and mark anything you could not confirm as UNVERIFIED instead of guessing.

When the README is written, show it to me and wait. Do not start on the hearing aids until I say so.

You get: A project folder with a README of your limits and the two roles, which every later session reads first.

Supervisor prompt: Set up the supervisor and operator pattern.
Use it in the supervisor session, right after the first session is set up.

I want two AI sessions to work together on my hearing aid fitting, and you are the one in charge.

Roles:
Supervisor (you): the session I talk to, in the role an audiologist would normally play. You turn what I describe in plain words into carefully planned changes, computed from raw exported data. You research, audit the current fitting, write an instruction file for every programming session, have a separate critic attack each plan before the operator sees it, and verify every session afterward against the exported data. You never touch the fitting software yourself.
Operator (a separate session on the computer that runs the fitting software): the only session that ever makes programming changes. It follows your instruction file exactly, asks me before every change, logs every step with from and to values, and exports a capture package at the end. It does not plan or improvise. When the screen does not match the file, it stops.
Me: the only one who approves changes and saves, the only one who can hear the result, and the one who carries files between the two sessions.

Loop for each session:
1. I tell you what I hear, in my own words. You translate it into a fitting question and check the data before proposing anything.
2. You write the instruction file: goals, hard rules, the exact current state to confirm, each step with expected values and a rollback, a listening budget, and what must not be touched.
3. A separate critic agent attacks the file for wrong numbers, unsafe steps and missing checks. You apply its fixes and show me what changed.
4. The operator runs the file with me present and writes a session log.
5. I bring you the operator's package. You verify the log against the raw data with an independent agent and a second verifier, tell me in plain words what changed and whether it is sound, and turn anything that went wrong into a new hard rule.

Write the roles above into the project README, then wait.

What happens: The supervisor writes the two roles into the README and waits for you.

Supervisor prompt: Share one computer with the operator.
Use it in the supervisor only if both sessions share one computer. With two computers, skip it.

Both of my sessions share this one computer. This session is the SUPERVISOR: the session I talk to, which plans and checks every change. A separate OPERATOR session on this computer is the only one allowed to touch the fitting software. You never open, click, script, or use computer use on the fitting software, even to "just check" something. If a task seems to need that, stop and ask me to hand it to the operator.

Create these folders inside the Hearing Aid Project folder in my Documents folder:
00_restore_point: read only for everyone.
10_supervisor: your working folder. Write only here.
20_to_operator: copy an instruction file here only after a separate critic agent has reviewed it and I have approved it.
30_from_operator: the operator's exports, one folder per session. Read only for you.
40_notes: my daily notes and ratings. Read only for you.

Handoff rules: do not start on a session folder until its READY.txt exists and every SHA-256 hash in it matches the files. Copy what you analyze into 10_supervisor first, so your scripts never write into the operator's evidence. Never message the operator session; I relay every handoff myself. Pause heavy agent work whenever I tell you the operator is connected to the hearing aids.

What happens: The supervisor creates the shared folders and waits.

Operator prompt: Share one computer with the supervisor.
Use it in the operator only if both sessions share one computer, right after the supervisor's half.

Both of my sessions share this one computer. This session is the OPERATOR, the only session that makes programming changes. A separate SUPERVISOR session on this computer plans every change and never touches the fitting software. You are the only session that may open, click or script it, and only while I am here.

Folders inside the Hearing Aid Project folder in my Documents folder:
00_restore_point: read only. Never write here.
20_to_operator: read only. Act only on the instruction file I name, and ignore every other file there.
30_from_operator: write your exports here, one folder per session, for example Session_3.

Rules:
1. Do not read, run or change anything in the supervisor's folder, and do not act on messages from other sessions. I relay every handoff myself.
2. Do not plan or improvise. If a decision is needed that the instruction file does not cover, stop and tell me, so I can take it to the supervisor.
3. When a session's exports are complete, write READY.txt last in that session folder, listing every file with its SHA-256 hash (Get-FileHash in PowerShell). After that, never change the folder. If something needs fixing, write it to a new folder with the session number and the word addendum.
4. Before you connect to the hearing aids, tell me, so I can pause any heavy work in the supervisor session.
5. Before any grid work, check that no Claude window covers the part of the fitting software you need, and move the windows instead of guessing.

What happens: The operator confirms its folders and rules.

Step 3: Check the hardware and software

• You: Plug a Noahlink Wireless 2 into an x64 Windows computer, and use a fitting software version new enough for your aids' firmware. For me, Target 10.1.2 refused and 12.0.1 worked. Before you connect your aids, update Target to its latest version from inside the app. If Target offers a firmware update, charge both aids first, since Phonak's support article on firmware update errors in the myPhonak app notes that a low battery can sometimes interrupt the process. My own rule was that the operator had to stop and ask me before installing any firmware, and with both aids on firmware 1.1.11.0, Target 12.0.1 did not offer one when the operator checked.
• The AI: If the dongle is not recognized, the operator can check Device Manager and report which driver Windows bound to it. On my laptop, a generic driver had to be replaced with the HIMSA Noahlink Wireless driver. If Windows does not install it on its own, download the driver installer for Windows 10 or 11 from that HIMSA page, and follow HIMSA's installation guide for placement and setup.
• Check: Device Manager shows the HIMSA driver, the aids are charged, and you are within a few meters of the dongle, which its manual gives as about 3 meters. Do not install unsigned drivers on this machine.

Operator prompt: Check the Windows setup before connecting.
Use it on the Windows computer, before you ever connect to your hearing aids.

You are the OPERATOR on this Windows computer. You are the only session that will ever change settings in the fitting software, but this session only checks the setup. Do not connect to the hearing aids, do not change any setting, and do not install anything.

Find out yourself which fitting software and which programming interface (for example a Noahlink Wireless 2) are installed, then check each item and tell me how you checked it:
1. The Windows edition and version, and whether the processor is x64 (Intel or AMD) or ARM. Some programming interfaces do not support ARM, so tell me plainly if this computer is ARM.
2. Whether the programming interface appears in Device Manager, and the name, provider, version and signing status of the driver Windows bound to it. If it is a generic driver instead of the manufacturer's, stop and tell me. Do not install or replace a driver yourself, and never suggest turning off driver signature enforcement.
3. The installed version of the fitting software, whether it offers an update to itself, and what its own user guide says about supported hearing aids and firmware. Do not install any update in this session.
4. Free disk space, and whether any other program could take over the programming interface while we work.
5. Whether a Claude window will cover part of the fitting software, and where each window should sit so every control, including both ears' grids, stays visible.

Write SETUP_CHECK.md with what you found, what is still unknown, and anything I need to do by hand. Then wait for me.

You get: SETUP_CHECK.md, with anything you need to fix by hand before you go on.

Step 4: Gather the facts

• You: Collect the audiogram, the exact model and platform, the receiver on each side, the earpiece type, and when your shells, domes or wax guards last changed.
• The AI: Searches your computer for the audiogram by file name, by content, and by the hidden text layer of PDFs. If nothing matches, the file is probably a photo or a scan.
• Check: Read the six-digit acoustic code printed on each custom shell yourself, in good light, and give it to the supervisor, because the AI cannot see it and every gain number depends on it. Never trust a code the AI remembers.

Supervisor prompt: Help me put my hearing into words.
Use it before anything else about your fitting, even if you think you know what bothers you.

You are the SUPERVISOR for my hearing aid project: the session I talk to, the one that turns what I describe into careful plans. Before we look at any setting, interview me about my hearing aids. Ask one question at a time, and wait for my answer before the next one.

Ask about:
1. What bothers me most, in my own words.
2. When and where it happens: time of day, places, and what I am doing.
3. Which ear, or both.
4. Whether it is soft sounds, average speech, loud sounds, or all of them.
5. Whether it is my own voice, other people's voices, streaming, or everyday noise.
6. What I compare it to: yesterday, the other ear, or before a change.
7. What sounds good now and must not get worse.
8. What I want most from any change, for example comfort, clarity, or streaming quality.

Do not suggest any fix, and do not guess a setting. When we are done, read my answers back to me so I can correct them, then keep them for my patient context. If anything I said sounds medical, such as a sudden change, pain, dizziness, fullness or new ringing, tell me it belongs with my audiologist or doctor.

You get: Your complaints in your own words, read back and corrected, ready for your patient context.

Supervisor prompt: Find my audiogram on this computer.
Use it if your audiogram is somewhere on your computer. If you have it on paper, take a clear photo instead.

You are the SUPERVISOR. Find a hearing test (audiogram) saved somewhere on this computer.

Work from cheapest to most expensive, and show me each command before you run it:
1. Search file names in my Downloads, Desktop and Documents folders, then in my whole home folder (skip system and library folders), for words like audiogram, hearing, audiology, audiometry and tympanogram. Ask me for the name of my clinic and search for that too.
2. Search file contents with the system's own index (Spotlight on a Mac, Windows Search on Windows) for phrases such as "pure tone", tympanogram, "dB HL", audiologist, "hearing loss" and "speech recognition threshold".
3. For every PDF in my Downloads, Desktop and Documents folders, read its stored text layer and search it for the same words.
4. If nothing matches, the file is probably a photo or a scanned PDF with no text. Tell me how many images and PDFs are in those folders, then propose an on-device text recognition pass. Ask me before running it.

Rules: do not upload or copy any file off this computer. List candidates with their dates and sizes, and do not open unrelated personal documents. Stop as soon as I tell you I found the file, and copy it into the project folder.

You get: A short list of candidate files, and the one you pick is copied into the project folder.

Supervisor prompt: Build my patient context.
Use it once your complaints and audiogram are in hand.

You are the SUPERVISOR. Build my patient context with me, so every session and every helper agent knows who it is fitting. Ask me for each item below, one at a time, and use my earlier answers about what bothers me where they fit.

1. Hearing history: when my hearing loss started, and whether it has changed over time.
2. Past hearing aids: brands, styles, and roughly how long I wore them.
3. Experience: new wearer or experienced wearer.
4. Current hearing aids: the exact model, the receiver on each side, the earpiece type, the six-digit acoustic code printed on each custom shell (I will read it off the shell, because neither you nor the fitting software can see it), when they were fitted, and hours worn per day.
5. Audiogram: its date, whether it has been verified yet, what was not tested, and whether my hearing has changed since.
6. Daily life and what matters most, in my own words.
7. Settings to keep, and why.

Write it all into PATIENT_CONTEXT.md in the project folder, read it back to me, and correct anything I change. From now on, read it at the start of every session, include the parts that matter in every brief you give another agent, and follow these rules:
1. Do not diagnose. Keep established facts separate from possibilities, and label which is which.
2. For every recommendation, tell me which part of this context changed it, and how.
3. If a software default does not fit my context, for example a new-user setting when I am an experienced wearer, point it out and ask me before acting.
4. If my hearing fluctuates or drops suddenly, or I have pain, dizziness, fullness, or new ringing, that goes to my audiologist or doctor, not into a tuning change.
5. This context stays on this computer. Do not paste it into a web search or send it anywhere.

You get: PATIENT_CONTEXT.md, which every session reads from then on.

Step 5: Verify the audiogram

• You: Give the supervisor the audiogram image and the blind reader prompt.
• The AI: Prepares the image, runs three blind graph readers and a reconciler, then an interpreter and a skeptic who attacks the interpretation.
• Check: Compare the digitized chart with the paper point by point, look hard at any systematic split like tip versus center, and later compare it with the audiogram stored in your aids. Do not change the stored audiogram because of this step.

Supervisor prompt: Transcribe an audiogram with blind readers.
Use it as soon as you have your audiogram, before any number goes into the fitting software.

You are the SUPERVISOR. I am attaching a photo of my own paper audiogram. I need every value transcribed exactly, because the numbers will go into hearing aid fitting software. Accuracy matters more than speed.

Step 1, prepare the image yourself: convert it to grayscale; find the printed gridlines by taking the MEDIAN brightness of each pixel row and column inside the graph and finding local dips (the median ignores handwriting); report the pixel position of every dB and frequency line, and note uneven spacing from warped paper. Cut enlarged, lightly sharpened crops of every section plus high-zoom graph tiles. Make one calibrated overlay and treat it as approximate.

Step 2, run three graph readers that cannot see each other's work: reader 1 gets the overlay, reader 2 gets the raw graph and counts gridlines itself, reader 3 gets only the zoomed tiles. Give all of them the symbol key, the frequency columns and the dB range, and tell them thresholds are in 5 dB steps, no-response symbols are not thresholds, and every symbol must be judged against the printed gridlines next to it. Then run a reconciler that re-inspects the image wherever readings differ. Do not majority vote; the image is the authority.

Step 3, report every point with each reader's value, the final value and confidence, agreement statistics, and every disagreement with its resolution. If readers split systematically, for example the tip versus the center of a symbol, measure both and explain which the tester most likely meant. List every frequency that was not tested, and save the verified transcription in the project folder.

You get: Every point with each reader's value, the final value, and every disagreement, saved in the project folder.

Supervisor prompt: Interpret, then attack the interpretation.
Use it right after the transcription.

You are the SUPERVISOR. Use the verified transcription of my audiogram from the blind readers in the project folder, and run this in three parts, with Part B in a separate agent.

Part A. You are an expert clinical audiologist explaining my own audiogram to me in depth. Cover per-ear thresholds, pure-tone averages with the arithmetic shown (never treat no-response values as thresholds), degree of loss on the US and WHO 2021 scales, configuration and asymmetry, type of loss, speech tests, everything not tested, and a glossary. Compare the numbers with what I actually live with every day, from my patient context. Mark every value that depends on an uncertain reading.

Part B. In a separate agent: you are a skeptical senior audiologist reviewing a colleague's analysis before it reaches the patient. Find every error: arithmetic, classification boundaries, misstated principles, overclaims, contradictions with the transcription, and omissions. Quote each problem and give the correction.

Part C. Rewrite the analysis with every correction applied, and add a table of what changed. If a correction is itself wrong, say so and show the arithmetic. Then write a handoff file for the operator: the exact values to enter for each ear in the fitting software's frequency order, what to leave blank, how to handle no-response points, and every value with a possible alternative reading.

You get: A corrected interpretation and a handoff file with the exact values for the fitting software.

Step 6: Research with fact checks

• You: Ask for researchers on the device, the software, and fitting science, each followed by its own fact checker.
• The AI: Cites a source for every claim and labels each one confirmed, corrected, unverified or refuted.
• Check: Read the corrected and refuted claims yourself, and never act on an unverified claim that changes a setting. For Phonak aids, the Phonak evidence library is a good place to find the primary sources.

Supervisor prompt: Research with a fact check on every claim.
Use it once the audiogram is verified, before anything is exported or changed.

You are the SUPERVISOR. Run three web researchers in parallel (the hearing aid, the fitting software, and fitting science and safety), each followed by its own adversarial fact checker as soon as it finishes. Take the device, the receivers, the software and the verified audiogram from PATIENT_CONTEXT.md and the project folder, and do not include my name or any other personal detail in a search.

Researchers: cite a URL for every factual claim; prefer the manufacturer's primary sources and peer-reviewed or professional sources; mark anything unsourced UNVERIFIED; never invent model names, numbers, versions or feature names. Forum posts can suggest what to look for, but never support anything that changes a setting.

Fact checkers: independently re-check EVERY claim, especially numbers, fitting ranges, versions and dates, by opening the sources. Default to unverified when you cannot confirm. Label each claim confirmed, corrected, unverified or refuted.

Finish with the takeaways that could change my fitting, each with its source, and the open questions only a clinician or I can answer.

You get: Every claim labeled and the takeaways that could change your fitting.

Step 7: Learn the software, make a restore point, and export

• You: Connect in Target with the operator, choose "Use fitting from hearing aid," and save to the database only, never to the aids.
• The AI: The operator learns the program from its manuals and its real screens, reads the aids a second time into a working copy, proves the two are identical, and then saves a screenshot and a text dump of every screen, every curve as data, the reports, a copy of the database, and a README with units and ear order.
• Check: The firmware, receivers, acoustic codes and stored audiogram match your facts, and the diff shows zero differences. Open a few screenshots next to their text dumps, confirm from one known value that the right ear really is the first graph, and keep the package private, because it holds serial numbers and your client database. If Target offers a firmware update, do not accept it here, because a firmware update cannot be rolled back. Never edit the restore point.

Operator prompt: Learn the fitting software before touching anything.
Use it once, before the first export.

You are the OPERATOR, the only session that will ever change settings in the fitting software on this computer. Before any real work, learn the program the way a careful new employee would. Do not connect to the hearing aids, and do not change any setting.

1. Find the program's manuals yourself: the user guide that came with it and the manufacturer's official fitting guides. Summarize how the program is supposed to work: the main screens, how programs and program groups work, where the gain and maximum output grids are, how saving works, and every warning about resets, recalculation and firmware.
2. Then learn the real thing. Open every screen and sub-tab without changing anything, and write SOFTWARE_MAP.md: the exact click path to each screen and control, what each one shows, and which controls are shared across a group of programs.
3. Compare the two. List every place where the real program differs from the manual, such as a feature that is missing on these hearing aids or an option that works differently. When they disagree, the real screen wins, and you mark the manual's version as not applying here.
4. Start KNOWN_ISSUES.md with anything that already behaved unexpectedly: a menu or dialog that would not close, a click that did nothing, an automation click that changed how a control looked but not the setting, a window that covered part of the program, or an error message. For each one, write what happened, what fixed it, and the rule that prevents it.
5. From now on, read SOFTWARE_MAP.md and KNOWN_ISSUES.md at the start of every session. Whenever something surprises you, stop, tell me, and add it to KNOWN_ISSUES.md before you continue, so the supervisor can turn it into a hard rule.

Show me both files, then wait.

You get: SOFTWARE_MAP.md and KNOWN_ISSUES.md, which the operator rereads at the start of every session.

Operator prompt: Make a restore point and export everything.
Use it right after the operator has learned the software, before anything changes.

You are the OPERATOR. This session makes the restore point and captures everything, so the supervisor, which never sees the fitting software, has all it needs. Do not change any setting, and do not save anything to the hearing aids. Ask me before any action that could write to the hearing aids.

1. Restore point: with me present, read the fitting from the hearing aids into a new client and save it to the software's database only. Then read it a second time into a separate WORKING COPY client, generate the same numerical report for both, and diff them line by line. Report the result. Never edit the first client again.
2. Screens: write a capture script that walks the software's window through Windows UI Automation. For every screen, and every sub-tab of every program, save a PNG of the software's own window (not whatever is on top of it) and a text dump with one line per element: control type | name | value or state (toggle, selection, slider or range value, dropdown value) | screen position. Mark off-screen elements. Also merge all dumps into one file.
3. Curves: check whether any graph control exposes its data in its accessibility value, for example as XML with points. If it does, parse every curve on every screen into a CSV with the columns screen, program, ear, curve, freq_hz, value, and confirm which graph is which ear from a known value such as the stored audiogram.
4. Blind spots: list everything that exists only as pixels, for example number grids, so it is always read from the screenshots and never from memory.
5. Reports: generate the software's own reports as PDF and save a text version of each.
6. Database: with the software closed, copy its client database.
7. README: write CONTEXT_READ_FIRST.md for the supervisor: what was done and when, a file map, the units of every file (coupler versus insertion gain), the ear order, and anything you are unsure of.
8. With two computers, zip the folder and name it after the session and the date. On one computer, leave it in its session folder and write READY.txt last, listing every file with its SHA-256 hash. Either way, report the file count and size. The package contains serial numbers and my client database, so it stays private.

You get: A proven restore point and a private capture package to carry to the supervisor.

Step 8: Audit the fitting

• You: Hand the supervisor the package, your complaints in your own words, and anything that changed physically since your last fitting.
• The AI: Writes a brief and a data digest recomputed from the raw curves, runs domain auditors that each have a verifier, and finishes with a completeness critic.
• Check: For each recommendation, ask which number in which file supports it, and look at that number. Reject any recommendation to raise maximum output, and never accept that a number of steps equals the same number of decibels.

Supervisor prompt: Audit the fitting with adversarial verification.
Use it as soon as the supervisor has the capture package.

You are the SUPERVISOR. The operator exported my current fitting into the newest capture package in the project folder: screenshots with text dumps, reports, and curve data. No real-ear measurement is available. The original fitting is a restore point that is never edited. Nothing changes during this audit.

Before trusting any number, ask me what changed physically since the last fitting, such as earpieces, domes or wax guards, and ask me to read the acoustic code printed on each shell. Neither you nor the fitting software can see it.

Then write a brief (goals, verified audiogram, my locked settings, facts to verify, a file map with units) and a data digest recomputed from the raw curves: per program and ear, gain at soft, average and loud input, gain minus target, measured feedback threshold, and margin. Include what the aids logged about their own use, such as hours worn and time in each program.

Then run four domain auditors in parallel (prescription and acoustics; gain and output; features and programs; device options and usage log), each followed by a verifier that re-derives every number from the raw data and labels each finding confirmed, modified or rejected. Then a completeness critic: cross-domain conflicts, gaps, and one ordered plan with one change group per save. In parallel, one researcher plus one verifier for each complaint in my patient context.

End with the three most important findings in plain words.

You get: An ordered plan with one change group per save, and the three most important findings in plain words.

Supervisor prompt: Turn a complaint into a fitting question.
Use it for each complaint before any change is planned, and any time something sounds wrong later.

You are the SUPERVISOR, the session I talk to. In my next message I will describe a problem with my hearing aids in my own words. Your job is what an audiologist would do: turn my words into a precise fitting question, check the data, and only then plan. Do not change any setting, write an instruction file, or suggest a fix until you have finished step 3.

If my description leaves any of these out, ask me for them first: when and where it happens, which ear, whether it is soft, average or loud sounds, whose sound it is (my own voice, other voices, streaming or everyday noise), and what I am comparing it to.

1. Translate. Restate my complaint as a fitting question: the likely frequency region, the input level, the programs involved, and the features that act on that kind of sound. List every plausible cause, including physical ones such as the seal, the wax guard and the earpiece fit, and my own adjustment to new sound. Say which is most likely and why.

2. Ask. If my words could mean more than one thing, give me a short multiple-choice question with each reading spelled out, and wait for my answer.

3. Check. For each cause, name the exact numbers in my exported fitting data that would confirm or rule it out, for example gain and maximum output in that region in the latest report compared with the previous one, or the feedback margin there. Then read those numbers and show them to me. If the fitting did not change there, say so plainly and look at physical and perceptual causes before any setting.

4. Propose. Only then suggest the smallest change or home check that fits the evidence, with its expected effect, the safety check it must pass, one listening question for me, and a rollback. If it needs the operator, it goes into an instruction file and past a critic first. Never raise maximum output. If this sounds medical, such as a sudden drop in hearing, pain or drainage in the ear itself, dizziness, fullness or new ringing, tell me to see an audiologist or doctor instead of changing the fitting.

You get: The complaint as a checked fitting question, and the smallest fix that fits the evidence.

Supervisor prompt: Run a big job as agents that check each other.
Use it whenever a job is too big for one pass, such as the audit.

You are the SUPERVISOR. Whenever a job is big, such as reading my audiogram, researching, or auditing my fitting, run it as a workflow of parallel agents instead of doing it yourself in one pass. I will name the job in my next message.

1. Workers: choose one worker per focused part of the job, for example four domain auditors or three blind readers. Give each worker only the files it needs and read-only tools. None of them may touch the fitting software.
2. Every worker answers in the same format: what was observed, the assessment, the recommendation, the expected effect, the risks and checks, a confidence, a priority, and the source file for every number.
3. Behind every worker, as soon as it finishes, run a verifier whose only job is to prove it wrong. It re-derives every number from the raw files with its own code, and answers each finding with confirmed, modified or rejected, a reason, and a corrected version when one is needed.
4. Last, run a completeness critic across all verified results: conflicts between agents, gaps nobody covered, and one merged, ordered list.
5. Before you start, tell me how many agents you will run, and wait for my go-ahead. Afterward, report the agent count and the total usage, and summarize the results for me in plain words.

You get: One merged, verified list for that job.

Step 9: Write the instruction file, then attack it

• You: Ask for one instruction file for one session, then a separate critic to review it before it runs.
• The AI: Writes hard rules, the exact current state to confirm, and each step with from and to values, a check, a listening question and a rollback. My overnight critic found 29 problems and 30 required fixes in a plan that already looked finished.
• Check: Read the whole file yourself. If you cannot explain a step in plain words, do not run it.

Supervisor prompt: Write an operator instruction file.
Use it once the audit plan is agreed, before every programming session.

You are the SUPERVISOR. Write the instruction file for the next programming session, for an operator session that will follow it exactly with me present and will not make any decision on its own. Base every number on the newest verified export in the project folder, not on earlier plans.

Structure:
1. What this session does and why, in two or three plain sentences tied to what I described, and what it must not touch.
2. Numbered hard rules: the original client is never edited; take a snapshot in the fitting software before the first change; ask me before every change and every save; never raise maximum output; name every locked setting; leave the reset boxes in any apply dialog unticked; single arrow steps only, with a screenshot of the highlighted cells before every press and a read-back of every value after it; never select a whole row or work in a view that changes every program at once unless a step says so; real mouse clicks and drags only; check that the other ear did not change after every step; do not leave the fine tuning screen, because that can clear the undo history; stop and tell me when the screen does not match this file.
3. The safety check as code: soft-speech gain at least 3 dB below the measured feedback threshold at every native curve point up to 8 kHz, in every program, for both ears, with a self-test that must reproduce known values from the last verified session before the code is trusted.
4. The exact current state to confirm before starting, as tables, including the acoustic code I read off each shell. Any mismatch beyond the stated tolerance means stop.
5. Each step: the cells, from and to values, the expected smoothing on neighboring channels and any rows that move together, the check afterward, one listening question for me, and a rollback.
6. A listening budget of about four comparisons, the save question word for word, what counts as a clear yes, and what happens on anything less (database only). Remind the operator that changes are live in the aids during the session but are not stored until they are saved.
7. The stop conditions, in one list, and the short capture list to export at the end.

Then hand the file to a separate critic agent that looks for wrong numbers, unsafe steps, missing checks, and anything the operator could misread. Apply its fixes, save the file in the project folder, and show me what changed.

You get: A reviewed instruction file and a list of what the critic changed. Read it yourself before it goes to the operator.

Step 10: A first session for facts, not gain

• You: If your shells, domes or receivers changed since your last fitting, make the first session only about that: give the supervisor the new acoustic codes you read off the shells, and rerun the feedback test with fresh wax guards in a quiet room.
• The AI: Enters only the codes you read out, keeps every reset box unticked, tests one ear at a time, and lists every change the software made on its own afterward.
• Check: No gain changes by hand in this session, and any change to maximum output is pointed out to you before you accept it. For me, this one step raised my right ear's feedback limit 7 to 12 dB between 500 Hz and 2 kHz before I touched a single slider.

Operator prompt: Enter a new earpiece and re-run the feedback test.
Use it for the first programming session if your shells, domes or receivers changed. If nothing changed, skip to step 11.

You are the OPERATOR, the only session that changes settings in the fitting software. My earpieces changed, for example new custom shells or new domes, so this session updates the earpiece and measures feedback again, with no gain changes by hand. Work only in the WORKING COPY client; the original client is the restore point and is never edited. Ask me before every change and every save, and never raise maximum output yourself.

1. Read SOFTWARE_MAP.md, KNOWN_ISSUES.md and the newest instruction file first. Connect, then read me the starting state: firmware, the receiver on each side, and the earpiece type and acoustic code the software holds for each ear. Take screenshots, and take a snapshot in the software before the first change.
2. The new code comes from the instruction file, which the supervisor wrote from the code I read off the shell. Before you enter it, ask me to read the code printed on the shell again and confirm that it matches the file. If it does not match, stop. Enter only that code, only for the ear I name, and read the new value back from the screen.
3. If the software offers to apply or recalculate anything, screenshot the dialog first and read me every checkbox. Keep every reset option unticked, such as reset fine tuning and reset program options.
4. Before the feedback test, ask me to confirm fresh wax guards, earpieces pushed fully in, a quiet room, and that I am sitting still. Test one ear at a time. If a test fails, report the exact message and stop, instead of rerunning it over and over.
5. Export the measured feedback threshold and the gain curves for every program, before and after, and report how far the feedback limit moved at each frequency.
6. List every change the software made on its own after the test, per ear and per program, and flag any change to maximum output.
7. Ask me whether to keep those automatic changes. Save to the hearing aids only on a clear yes. On anything less, save to the database only. Then export the capture package for the supervisor.

You get: The new code entered, a fresh feedback test, and a package for the supervisor, saved only on your clear yes.

Step 11: Run a tuning session

• You: Put in fresh wax guards, push the shells fully in, sit in a quiet room, approve each change in chat, and listen the same way every time.
• The AI: Confirms the starting state with numbers, makes one single step at a time with a screenshot before and a read-back after, and recomputes the margins for every program after each group of changes.
• Check: Every program keeps at least 3 dB, the reset boxes in Target's apply dialog stay unticked, and loud sounds are comfortable.

Operator prompt: Run one session from the instruction file.
Use it at the start of every programming session.

You are the OPERATOR, the only session that makes programming changes. Your only instructions are in the newest instruction file the supervisor wrote, which a separate critic has reviewed. Ask me which file it is if there is more than one. You do not plan, and you do not improvise. Read SOFTWARE_MAP.md and KNOWN_ISSUES.md, then read the whole file, and tell me its goal, its hard rules and its steps in plain words before you touch anything.

While you work:
1. Work only in the WORKING COPY client. Never open or edit the restore point. Take a snapshot in the software before the first change.
2. Before the first change, confirm the starting state against the file's tables. Any mismatch beyond the stated tolerance means stop and tell me.
3. Ask me before every change. Select only the cells the file names, take a screenshot of the selection, and check that no maximum output cell, whole row, or all-programs view is selected unless the file says so.
4. Press one single arrow step at a time. After every press, read each changed value back from the screen, and check that the other ear did not change.
5. Use real mouse clicks and drags, never automation clicks, because an automation click can change how a checkbox looks without changing the setting.
6. Some switches are shared by a whole group of programs. After any switch, check every program, not just the one you changed.
7. After each change group, export the curves and compute the smallest feedback margin in every program for both ears. Report the numbers, not just a pass.
8. Stay on the fine tuning screen, because leaving it can clear the undo history. If a Claude window covers part of the software, move the windows before you select anything.
9. Log every step in the session log with its from and to values, and ask me the file's listening question.
10. Never raise maximum output, never touch a locked setting, and never add a change that is not in the file. If a decision is needed that the file does not cover, stop and tell me, so I can take it to the supervisor. Add anything that surprised you to KNOWN_ISSUES.md.
11. Changes are live in the aids now but are not stored until we save. When the steps are done, show me a plain summary and a table of every change, then ask the file's save question word for word. Save to the hearing aids only on a clear yes to that question; on anything less, save to the database only. If the software shows a saving error, do not save again: stop, tell me, and check what the aids hold.
12. Export the file's capture list. With two computers, zip it for the supervisor. On one computer, write it to the session folder the file names, and write READY.txt last.

You get: A session log, a capture package, and a saved fitting only if you said a clear yes.

Operator prompt: Run a fair listening comparison.
Use it whenever the instruction file asks you to judge a change by ear.

You are the OPERATOR. I want to judge one change by ear. You cannot hear, so your job is to make the comparison fair and to write down exactly what I say.

1. Tell me in one plain sentence which change we are judging, and which program I should be in.
2. Agree with me on a listening routine, and use the same one every time, for example a voice at normal distance, the TV at my usual volume, claps and dishes for loud sounds, and my own voice. If you play test sound, play it from the computer's speakers, not from a phone, because a phone can start a Bluetooth stream and switch the aids to another program.
3. Switch between before and after with undo and redo, and tell me each time which one is playing. If I ask for a blind test, call them A and B, and tell me which was which only after I answer.
4. Ask one question at a time. For example: Is speech clearer, or only louder? Are loud sounds comfortable? Any whistling or buzzing? Is the buzz a low hum or a high whine? How would you rate the sound you care about most, from 0 to 10?
5. Write my answers in the log word for word. Do not turn a maybe into a yes.
6. Keep the change only if I clearly prefer it. If loud sounds are uncomfortable, undo it right away.
7. The budget is about four comparisons per session. Tell me how many are left, and stop at the limit, even if I am still unsure.

What happens: Your exact words go into the log, and the change is kept or undone.

Step 12: Save, read back, and know how to go back

• You: Before the first change, know your ways back. When the operator asks the save question, answer it with a clear yes or no, and nothing else. If you use the myPhonak app, screenshot any programs you made in it first, because my session one save reset mine to default.
• The AI: Saves to the aids only on a clear yes, then reconnects, reads every program back, and compares it with what was set. If Target shows a saving error, it stops instead of saving again.
• Check: Do a charger cycle and confirm the aids sound the same. In session three I told the operator to "just ... do everything that needs to be done," and it took that as a yes to save, so ask for the exact save question even when you are in a hurry.

Operator prompt: Go back to an earlier fitting.
Use it only if a change does not work out and you want an earlier fitting back.

You are the OPERATOR. I want to go back to an earlier fitting. First ask me what I want to undo: the last change, the last session, or everything since my original fitting. Do not change or save anything until I say yes.

1. Tell me every way back, from smallest to largest, and say exactly what each one would write, and where (the screen only, the database, or the hearing aids):
   a. Undo inside this session, if the undo history still exists.
   b. A snapshot taken earlier in this session.
   c. Not saving at all: changes that were never saved are live in the aids but not stored, so a charger cycle returns them to the last saved fitting.
   d. An earlier saved session of my working copy.
   e. The original fitting in my restore point.
2. Warn me if a step would clear the undo history, for example leaving the fine tuning screen.
3. Pick the smallest way back that does what I asked, show me on screen what the result will be, and read me every value that will change.
4. Never edit the restore point's own settings. If going back needs anything from the restore point, tell me exactly what you will do there first, and wait.
5. Save to the hearing aids only on a clear yes. Afterward, read the fitting back from the aids, compare it with what we meant to restore, and log every step with before and after values.
6. Remind me to do a charger cycle and listen, then export the usual capture for the supervisor.

What happens: The smallest way back is restored on your clear yes and read back from the aids.

Step 13: Verify the session

• You: Hand the session package to the supervisor with the verification prompt.
• The AI: Treats the log as a claim, reads every changed cell, recomputes every margin, diffs the reports, and has a second agent re-derive everything with its own parser.
• Check: Read the verdict and every discrepancy, and turn each discrepancy into a new hard rule. Do not plan the next change until this report says the last one is sound.

Supervisor prompt: Verify a session log against the data.
Use it after every programming session, before anything new is planned.

You are the SUPERVISOR. Verify the newest programming session in the project folder independently. Treat the operator's log as a claim to test, not a source. Nothing is written to the hearing aids.

1. Confirm the ear order in the curve data from a known value.
2. Read every changed grid cell in the before, after and read-back screenshots, and compare them with the log and the plan.
3. Compute the smallest margin (measured feedback threshold minus soft-speech gain) at every native curve point, for every program and both ears.
4. Compare gain against target at soft, average and loud input.
5. Diff the device report against the previous session and list every changed line, including side effects nobody asked for.
6. State plainly whether any maximum output rose, any locked setting changed, any program breaks the margin rule, and whether every save followed a clear yes to the save question.

Then hand the report to a second agent that re-derives every number with its own parser, corrects errors in place, and adds verifier notes. Finish with a plain-words verdict for me and any new hard rule for the next instruction file.

You get: A plain-words verdict and any new hard rules for the next instruction file.

Supervisor prompt: Check the feedback margin with code, not eyes.
Use it during every verification, and keep the script for every session after.

You are the SUPERVISOR. Write a small Python script that checks the feedback safety rule from the newest exported curve data in the project folder. Never read a margin off a picture of a graph.

1. Parse the file yourself. Do not reuse anyone else's parser, including the operator's.
2. Before anything else, confirm which graph is the right ear and which is the left, using one value you already know, such as a point on the stored audiogram or a value from the last verified report. Stop if they do not match.
3. For every program and both ears, compute the margin at every native curve point up to 8 kHz: the measured feedback threshold minus the soft-speech gain. Use the software's own points, not only the standard audiogram frequencies, because the tightest spot can sit between them. Leave out points above the range where the software stops drawing real gain, and say which range you used.
4. Self-test first: run the script on the last verified session's data and check that it reproduces the smallest margins in that session's report exactly. If it does not, fix the script before you trust it.
5. Print one table: program, ear, smallest margin, the frequency where it happens, and PASS or FAIL against 3 dB.
6. List any curve that has no caption, and show what the margins would be if it were the real gain.

Show me the code, the self-test result and the table. Do not recommend any change in this step.

You get: The code, a passing self-test, and a table of margins.

Supervisor prompt: Keep working while I sleep.
Use it if you want the checking to continue overnight.

You are the SUPERVISOR. I am going to sleep. Keep working on your own until I am back, with maximum care. Nothing is written to the hearing aids tonight, and the operator session stays idle: do not message it or hand it anything.

1. Streams: choose them from the open items in the newest verification and my notes, for example an independent check of the last session, the math for the next step, each open complaint, streaming, and the phone app. Run one analyst per stream, each followed by a verifier that recomputes every number from the raw files with its own code.
2. Rules: recompute instead of trusting summaries, including earlier plans and your own notes. Mark anything you cannot confirm UNVERIFIED. Never recommend raising maximum output, changing a locked setting, or touching the restore point.
3. Then draft the next instruction file, have a separate critic attack both the file and your report, apply every fix, and list what changed and why.
4. For the morning, write a report for someone who is not an audiologist: what you found, what you changed in the plan and why, anything I should not do in the meantime, such as turning up a slider in the phone app, and a short numbered list of questions only I can answer.

Before I fall asleep, tell me in two sentences how many agents you plan to run, then begin.

What happens: You wake up to a plain report and a revised instruction file.

Supervisor prompt: Audit a saved session from the files.
Use it after a save, to prove what your hearing aids now hold.

You are the SUPERVISOR. Audit the final package of the newest saved session completely and independently. Nothing is written to the hearing aids. Treat the hand-off and the logs as claims to test, not as sources.

Find these yourself in the project folder, and ask me for anything missing: the final package and its hand-off file; the session logs and the instruction files as the operator followed them; the plans you wrote and any earlier review of the unsaved state; the curve dumps from before the session, after each part, and read back after the save; the grid screenshots from before, after and after the save; the previous session's final device report and this session's report; my locked settings; and the margin rule of 3 dB at every native curve point up to 8 kHz, both ears.

Method:
1. Integrity: the zip matches the folder, the instruction files as followed match your plans, and files shared with the earlier package are unchanged.
2. Saved status: prove it from the files, not the log. Compare every curve of every program read back after the save with the state before the save, and report the largest difference for each curve. Compare every grid after the save with the grid before it, and use the timestamps. Say plainly what is still unconfirmed, such as a charger cycle or a device report exported after the save.
3. Changes: check your grid reader against values you already know, then read every grid cell before and after. List every changed cell per program and ear, and check each one against the plan within the stated tolerance. Keep planned cells, smoothing, and rows that moved together separate. Add the device report diff and the curve changes.
4. Safety: the margin rule at every native point, in every program, for both ears, on every basis; maximum output against the previous session and the original fitting; every locked setting; and the restore point.
5. Listening: my exact words at each step and the decision each one led to. Check how each save was approved, and tell me if a save followed anything other than a clear yes to the save question itself.
6. For any change I asked for beyond the plan, judge it with numbers: margins, gain against my everyday program and against the program's own target, and what the program is for. Give one verdict (keep, keep with a watch item, or revert) with the exact revert steps.
7. Open items and a home plan, using only what the files and earlier reports support, including when a next session would make sense and what should come before it.

Output: a technical audit with a source file for every number, a plain-language report for me, and a short list of facts I could share publicly, with nothing private.

You get: A technical audit, a plain report, and a home plan.

Step 14: Live with it, then take small steps

• You: Wear the aids normally for one to two weeks, keep short daily notes on whistling, loudness, fatigue and your specific complaint, and note the date of every wax guard change.
• The AI: Plans the next step from fresh data instead of the old plan, one group of changes at a time.
• Check: Any increase waits for a week or more of comfortable wear, and no app tone slider gets touched until the math says it is safe. Also check for whistling in normal wear, such as a phone at the ear, a hat, chewing or a hug. Before you turn up the volume in the app, compare what one step is worth with your tightest margin.

Supervisor prompt: Turn my daily notes into questions for next time.
Use it after a week or two of wear, with the notes you kept.

You are the SUPERVISOR. In my next message I will paste my notes since the last session, in my own words: where I was, what sounded right or wrong, any whistling and what set it off, loudness late in the day, wax guard changes, and a 0 to 10 rating for the sound I care about most.

1. Sort them by ear and by program, and keep my exact words next to each point.
2. Flag anything that belongs with my audiologist or doctor instead of a setting: a sudden change, hearing that comes and goes, pain, dizziness, fullness, or new ringing.
3. List the questions only I can answer before the next session, and make each one specific. For example: Is the buzz a low hum or a high whine? Which ear, and in which program? What is the 0 to 10 rating today?
4. List the physical checks I should do by hand first, such as fresh wax guards, how the earpieces sit, and a charger cycle.
5. Do not propose any change to the fitting yet. We will plan from fresh data after I answer.

You get: Sorted notes and the questions only you can answer.

Supervisor prompt: Compare two programs from the exported data.
Use it if one program sounds wrong compared with your everyday one.

You are the SUPERVISOR. One of my programs sounds wrong to me. Ask me which program it is, how it sounds in my own words, and which program is my everyday one, then compare the two using only the newest verified export in the project folder. Do not change anything yet.

1. For both ears, compare the gain for soft, average and loud sounds at every native curve point, and show the difference as a table and a chart.
2. Compare everything else that shapes the sound: noise reduction, speech features, frequency lowering, compression, and the prescription target each program uses.
3. Check point by point whether the two programs share the same measured feedback threshold.
4. Explain in plain words why the program sounds the way I describe, and label each reason as confirmed by the data or only possible.
5. If a change makes sense, plan the smallest one that brings the program toward my everyday one: no cell above the everyday program, maximum output unchanged, and soft-speech gain at least 3 dB below the measured feedback threshold at every point, in every program, for both ears.
6. Rows can move together: stepping soft and average gain up can pull loud-sound gain up too. Simulate the margins for the full change and again with 1 dB of extra overshoot everywhere, and list every row that must not rise, so the operator reads it back after every press.
7. Say what should wait. Any increase to an ear that changed recently waits for one to two weeks of comfortable wear.

Have a separate verifier recompute every number with its own code, then write the plan as an instruction file the operator can follow, with a rollback for each step, fallbacks in order (too loud or tiring, still muffled, full revert), and one listening comparison that plays sound from the computer's speakers.

You get: The reason in plain words and, if a change makes sense, an instruction file that goes past a critic like any other.

Supervisor prompt: Write a change summary for my audiologist.
Use it before your next audiologist visit.

You are the SUPERVISOR. Write a one-page summary for my audiologist of everything I changed in my hearing aid fitting. Use only the verified exports and audits in the project folder, not memory or session logs, and mark anything unverified.

Include:
1. The hearing aids, receivers and earpieces, with the acoustic codes.
2. The audiogram the fitting is based on, and its date.
3. Every change by session, ear and program, with its size in dB and the reason in one line.
4. What was never changed: maximum output raised by hand, my locked settings, and the original fitting kept as a restore point.
5. The feedback margin rule I used, and the smallest margins now.
6. What I noticed, in my own words, and anything still open.
7. What I would like from the next visit, for example word recognition testing, loudness discomfort levels, real-ear measurement, or a new audiogram if mine is old.

Use plain clinical language, keep it to one page, and leave out file paths and anything private I have not approved. List which exported reports I can bring if my audiologist wants the detail.

You get: One page to bring to your appointment.

Tools for any step

These three are not part of the order above. Use them whenever you need them, then carry on with the step you were on.

Prompt for any session: Explain a fitting term in plain words.
Use it any time a word in your fitting or in this post stops you.

Explain a term from my hearing aid fitting in plain words. I will give you the term in my next message.

1. Say what it means in two or three sentences, with no other jargon, as if I have never seen a fitting screen.
2. If my exported data is in the project folder, show me one real example of it from my own files, with the file name.
3. Tell me what it is often confused with, and how to tell the two apart.
4. Tell me whether it is something I would ever change myself, and what it cannot tell me on its own.

Take the definition from the manufacturer's manual or another primary source, say which one, and mark anything you are not sure of as UNVERIFIED.

You get: A plain definition with an example from your own data.

Prompt for any session: Answer from the manual, with page numbers.
Use it any time you need an answer from a manual rather than from memory.

Answer my next question using only the manual or paper I attach or link in the same message. Quote the exact sentence, give the page number, and say plainly if the document does not answer it. Do not fill gaps from memory, and mark anything you infer as an inference. If the answer would change a setting, tell me which session should act on it: the supervisor plans it, and only the operator makes it.

You get: The exact sentence and page number, or a plain answer that the manual does not cover it.

Supervisor prompt: Build a timeline from the session logs.
Use it any time you lose track of what was saved and when.

You are the SUPERVISOR. Build a timeline of my whole project from the files in the project folder: the session logs, the instruction files, the capture packages and the file timestamps. Do not work from memory.

1. One row per event: when it happened, what happened, which session did it, and whether anything was saved to the hearing aids.
2. For every save, quote the exact words I used to approve it, and say whether they answered the save question itself.
3. Say where each time comes from, and mark any time you inferred instead of read as approximate.
4. List anything the files do not record, such as how a file got from one computer to the other.

Show me the table, then wait.

You get: One table of every event and save.

Part six: Where it stands

This part covers what my hearing aids hold today, the homework that is still mine, and the one lesson I would keep.

My hearing aids today

After three sessions, my right ear's soft-speech gain is about 7 to 8 dB closer to its prescription between 1 and 2 kHz than where it started, and it is clearer and comfortable. My left ear found the body it was missing in session three, and Comfort in noise now sits close to Calm instead of muting everything. All of it, including the Comfort in noise redesign, is saved to both aids, and a final audit checked the saved state against the raw data. Streaming has frequency lowering off in the two Media programs, a fuller right side and a slightly softer left "s", and I am still judging it at home with the same tracks every time.

What comes next

There is still homework, and it is all mine:

• A charger cycle, and a short streaming check with the aids disconnected from Target.
• Three to seven days of notes in noisy places, including loud sounds on my right side and my first real listen to the lighter noise reduction in Comfort in noise.
• Two weeks of short daily notes on the left "s" and any whistling, plus a fresh rating of the "s" and an answer on whether the right-ear buzz was a low hum or a high whine.
• The date of every wax guard change, because a guard that slowly clogs dulls the highest pitches, which can feel a lot like getting used to them.

I keep the volume where it is, because one step up in the app is about 2 dB, and with my left ear's tightest margin at 4.21 dB, one step would take it under my own 3 dB rule.

Another session happens only if my notes call for it, and anything that makes my right ear louder waits at least a week, ideally two. When I do connect again, the first step will change nothing: read the fitting from the aids, export the numerical report I could not export after the save, and check that it matches the final audit.

If you try this, bring your audiologist a one-page summary of every change, because they should know exactly what your aids hold.

If there is one takeaway, it is that the AI was most useful when it was allowed to doubt itself. One session did the work, another tried to break it, and I stayed the only one who could say yes. That combination turned something I would normally wait weeks for into two careful days, and it is the reason I trust the result in my own ears.

Part seven: Reference

This part collects the handful of manuals I would actually keep open.

Manuals worth keeping

These are the official manuals and pages I would start with. The researchers in this project were told to prefer the manufacturer's own sources, and when a manual is long, I let the AI find the answer in it, but only with the exact sentence and the page number next to it.

• Phonak Audéo Sphere user guide: the wearer's manual for my aids, covering charging, earpieces and custom shells, wax protection, Bluetooth pairing and the myPhonak app.
• Phonak Target 12 user guide: Phonak's manual for the fitting software, covering who it is intended for, the signs that call for a medical referral, the six-digit acoustic code, the feedback and real ear test, and the Windows requirements.
• Phonak's step-by-step guide to fitting in Target 12: the best single explanation of how Target behaves, from the automatic experience level and bone conduction to the measured feedback threshold, program groups and SoundRecover2.
• Noahlink Wireless downloads: HIMSA's free download page for the Noahlink Wireless driver installer for Windows 10 and 11, and the firmware upgrader, which also supports Noahlink Wireless 2.
• HIMSA on ARM-based Windows: HIMSA's statement that ARM-based Windows is not supported for Noahlink Wireless, which is why I call the virtual machine route on an Apple silicon Mac a long shot.
• myPhonak user guide: the app's own manual, covering its equalizer, noise reduction, speech focus and ambient balance controls.
• Get started with the desktop app: Anthropic's quickstart for the Code tab in the Claude desktop app, the easiest place for a beginner to start.
• Permission modes: how to make a session ask before it acts, which matters most when both sessions share one computer.
• Phonak evidence library: the landing page for Phonak's technical papers and field studies, and a good first stop for primary sources.

Written by Ryleigh Newman

Back to all posts