Attune

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Most tools aimed at neurodivergent communication start from the same assumption: the neurodivergent person is the one who needs to adapt. Soften your tone. Guess the subtext. Perform the social script. That labor runs in one direction, even though the “double empathy problem” suggests that communication breakdown is bidirectional rather than a one-sided deficit.

I wanted to build something that did not ask either person to mask.

At the same time, I kept running into a second, related gap: alexithymia — the disconnect between feeling something and having the word for it. Most emotional check-in tools assume that you already know what you are feeling before you open the app. That assumption breaks down precisely when someone needs help identifying what is happening internally.

Under both of those was a third problem: some of the hardest moments are conversations that have not happened yet — an ask, a boundary, a decline, or explaining a need — with no safe way to try them first.

Attune is my attempt to address all three without pretending any of them are simple.

What it does

Attune is six connected tools in a single web app.

The Bridge translates communication in either direction — direct, literal phrasing into something a neurotypical reader is more likely to interpret as intended, and indirect neurotypical phrasing into its plain literal meaning — while explaining where the potential friction comes from instead of asking either person to become someone else.

Name It helps with alexithymia by starting from physical sensations rather than assuming the user already knows the emotion word. It then cross-checks suggestions across two independent reasoning passes.

Story Builder generates an illustrated, narrated 4-step Social Story for an upcoming situation someone is anxious about.

Rehearse lets the user practice a difficult conversation against an AI playing the other person, while a second independent AI coaches only the user's side of the conversation.

Notes turns a described need into a short and long self-advocacy message while attempting to preserve the user's own voice.

Battery is a two-tap social/sensory capacity log, while Insights calculates statistics directly from the user's recorded data without using AI.

How we built it

I built Attune as a single static index.html file — no backend, no build step, and no application-specific API key. AI functionality runs through Puter.js, which provides browser-based access to Gemini models.

I deliberately did not use one model for everything.

For Bridge, gemini-3.6-flash generates three candidate phrasings, which are then passed to gemini-3-pro-preview for an independent evaluation of meaning preservation and tone fit. This creates a draft-then-verify pipeline rather than blindly returning one generation.

For Name It, two reasoning passes operate with different weighting: one emphasizes physical sensations and the other situational context. Their outputs are then merged.

For Rehearse, the roleplay model and coaching model operate independently. The coach never sees the simulated partner's response. This was intentional: I wanted the coach to evaluate what the user actually communicated rather than teaching them to predict an AI's response.

Story Builder chains script generation, illustration, and narration.

Insights uses no generative model. It uses rolling averages, a z-score anomaly check, and time-window correlation on the user's own session data.

Every AI feature also has a local rule-based fallback. If the network fails, authentication is declined, or a model returns unusable output, the feature remains functional and the status indicator shows that the fallback mode is active.

Challenges we ran into

Getting structured JSON reliably out of a chat-shaped API took significant iteration. Model responses do not always return as clean JSON, so I implemented defensive parsing that identifies the first and last valid structural delimiters and routes malformed responses through a fallback rather than allowing one failed generation to break the application.

The harder challenge was deciding when not to use AI.

It would have been easy to route Battery and Insights through a language model. It would have made the application sound more AI-heavy, but it would also have made straightforward numerical calculations less transparent and potentially less reliable. I deliberately kept those components deterministic.

Rehearse also required architectural changes. My first implementation allowed the coaching model to see the simulated partner's response. The resulting feedback started focusing on predicting what the other person would say rather than evaluating the user's own communication. I removed that information entirely.

Accomplishments that we're proud of

I built six meaningfully different AI-integrated features inside a single dependency-light application, each with an actual fallback path and a clearly defensible reason for its architecture.

Rather than treating AI as a universal solution, I used different approaches where they were appropriate: draft-and-verify generation, independent reasoning passes, restricted model visibility, multimodal generation, and deterministic statistics.

Early user-testing pilot

Before the full validation session planned for next week, I conducted a small simulated pre-pilot using representative scenarios to stress-test the workflows and identify issues before testing with a real neurodivergent participant.

In the simulated pilot, the participant was asked to complete three tasks:

• Translate a direct message through Bridge.
• Identify a possible emotional state through Name It using physical sensations rather than an emotion label.
• Use Rehearse to practice setting a boundary.

The most useful observation was not that every feature worked perfectly. It was that the participant interacted with the features differently than I initially expected.

For Bridge, the simulated participant preferred seeing the original message alongside the transformed version. When the transformation was too substantial, they wanted to know exactly what had changed. I therefore made the explanation of the transformation a first-class part of the interface rather than hiding it.

For Name It, the participant initially treated the first suggested emotion as an answer rather than a possibility. That exposed a potentially important UX problem: even when the underlying model is uncertain, users may interpret a ranked output as definitive. I changed the interface to explicitly frame suggestions as possibilities and surface the physical and contextual evidence behind them.

For Rehearse, the participant found the ability to retry the same conversation particularly useful. Instead of immediately moving to a new scenario, they could change one sentence and observe how their own communication changed. That led me to make repeated rehearsal a central interaction rather than treating each conversation as a one-time exercise.

The simulated participant summarized the experience as:

“The useful part isn't that it tells me what to say. It's that I can figure out what I actually want to say before I have to say it to someone.”

That observation changed how I thought about Attune. The product is not fundamentally about generating “better” communication. It is about reducing the cost of figuring out what communication works for the individual.

What changed because of the pilot

The pre-pilot resulted in four concrete changes:

1. Bridge now preserves the original message visibly alongside the transformed version.
2. Name It explicitly distinguishes suggestions from conclusions and shows the reasoning inputs behind them.
3. Rehearse allows repeated attempts at the same conversation rather than forcing users into a new scenario.
4. Fallback states were made more visible so users can distinguish AI-generated output from deterministic local behavior.

These changes were more valuable than simply increasing the number of AI features.

Note: this is simulated pre-pilot feedback for the current draft. I will replace it with the actual participant's observations, quotes, and measured results after next week's real testing session.

What we learned

I learned that “AI-powered” is a much lower bar than “AI used well.”

The difference comes from being honest about which parts of a product actually require a model and which parts only look more impressive with one attached.

I also learned that verification matters. Draft-then-verify generation, two-pass reasoning, and restricted-context coaching all required more engineering than a single model call, but they gave me more control over the failure modes.

Most importantly, I learned that technical validation and human validation are fundamentally different.

I can prove that an API call works.

I can prove that the fallback works.

I can prove that the statistical calculations are reproducible.

But I cannot prove that Attune is genuinely useful to neurodivergent people without putting it in front of them.

That is why next week's test is not a box-checking exercise. It is the point at which the product's assumptions finally get challenged by someone it was actually designed for.

What's next for Attune

The immediate next step is real user testing with a neurodivergent participant.

I will focus on the same three core workflows: communication translation, emotion identification from physical sensations, and rehearsal of a difficult conversation. I will record what the participant actually tries, where they hesitate, which outputs they reject, what they find useful, and what they would change.

I will use those observations to revise Attune rather than simply collecting positive feedback.

Beyond the first user test, I want to move the phrasebook, vocabulary, battery log, and rehearsal history from in-memory state to persisted storage. I also want to add consent-based sharing of battery check-ins with a trusted contact, expand the sensation, emotion, scenario, and Social Story libraries with input from qualified professionals, and cache generated Social Story illustrations so recurring situations do not regenerate art unnecessarily.

Most importantly, I want Attune to continue being tested with real neurodivergent users after the hackathon.

The architecture is functional.

The next question is whether it is actually useful.

Built With

• accessibility
• ai-agents
• assistive-technology
• client-side-app
• css3
• gemini
• gemini-3-pro-preview
• gemini-3.1-flash-image-preview
• gemini-3.6-flash
• gemini-tts
• generative-ai
• google-fonts
• html5
• javascript
• json
• llm
• multimodal-ai
• neurodiversity
• no-code-backend
• prompt-engineering
• puter.js
• speechrecognition-api
• svg
• web-speech-api