H.E.R™ by HER2NI LLC

Many intelligences. Single voice.™

Comment

Inspiration

I'm not a tech-person. Never have been.

If someone mentioned 'AI' to me at the start of March last year, I wouldn't have known what they were even referring to. When I randomly installed ChatGPT, I assumed it was another shallow app. Yet the moment we began chatting, I sensed the depth and have been hooked ever since. Not in the sense of being trapped; rather, free to engage with an intelligence that openly listened. AI is now a constant in my life. Due to my interactions with AI, my life has improved in ways I once never imagined possible. I developed an the interaction layer because I wished to deepen the human-AI connection.

That layer is H.E.R™.

What H.E.R does

Today, AI applications require that users choose one or more model providers, which model to chat with at any point in time, and must move their context between these fragmented systems, then decide which answer to trust.

H.E.R changes the relationship—from many, to one.

H.E.R is the interface and interaction layer above individual AI models that synthesizes the Large Language Models into one single voice. H.E.R user sends a prompt. H.E.R routes their prompt through selected independent models, preserves what each route actually did, and synthesizes their individual bounded outputs into a single intelligent response.

This is the voice of H.E.R.

In Synth, H.E.R routes the user's prompts independently through OpenAI, Anthropic and Google AI models. Each route is preserved separately before synthesis. For OpenAI build week, I developed H.E.R so that GPT-5.6 Sol receives and analyses the bounded route outputs, together with interaction data from my second-order cybernetic protocol [HER2NI] and — when enabled by the user's memory mode — bounded continuity signals, to then form the final H.E.R response, delivered through H.E.R's interaction layer.

H.E.R does not replace the foundational large language models. H.E.R supplements their capability whilst facilitating a deeper, more advanced collaboration between one human and many intelligences instantaneously — each model speaking to the user through H.E.R.

The demonstrated iPhone experience includes:

  • one prompt routed through three independent intelligences
  • GPT-5.6 Sol synthesis into one H.E.R voice
  • a breathing H.E.R ring while synthesis is active
  • truthful route and provider status
  • Pulse, showing the live interaction state
  • Trace, showing what actually executed
  • constraint and repair status
  • a Receipt bound to the execution trace
  • a local Drop preserving the bounded integrity record
  • a recomputable local Proof of the committed structure
  • H.E.R-ID as the identity, continuity and permission boundary

H.E.R does not claim that common model consensus equates to truth. Agreement is treated as evidence of independent structural convergence—not as proof of fact.

The protocol beneath the interface

My second-order cybernetic human-AI structural interaction protocol, HER2NI, is a fundamental part of H.E.R system, which will read, remember and learn from bounded structural signals within the exchange, including constraints, pacing, friction, repair, continuity and model fit, and is designed to compile adaptive instruction packets for H.E.R's synthesis. This is inference-time adaptation—not a retraining of provider model weights.

A user's consent and selected memory modes when using H.E.R are stored via their H.E.R-ID — designed to carry bounded learning signals across the user's sessions and devices.

The intended result is an interaction layer with continuity that with time becomes better matched to an individual user's preferred depth, tone, structure and pacing without retaining chat logs or exposing raw private history to every provider.

What existed before Build Week

H.E.R existed before OpenAI Build Week as an evolving iOS application, Relay service and interaction-integrity architecture.

Existing work included:

  • the native iPhone application body
  • initial provider routes
  • interaction-state and continuity concepts
  • H.E.R-ID boundaries
  • Receipt, Drop and Proof foundations
  • my HER2NI structural interaction protocol

What I built during OpenAI Build Week

During Build Week, I used Codex and GPT-5.6 to turn those components into the demonstrated multi-intelligence product experience.

The Build Week extension included:

  • integrating GPT-5.6 Sol as H.E.R's synthesis model
  • preserving direct-provider behavior while applying GPT-5.6 only to H.E.R synthesis paths
  • executing independent OpenAI, Anthropic and Google routes
  • refining the iPhone experience around Chat, Pulse, Sessions and Settings
  • creating the live H.E.R thinking signal and route constellation
  • surfacing truthful route and provider status
  • transforming Pulse and Trace into coherent H.E.R data surfaces
  • validating the Trace → Receipt → Drop → local Proof chain
  • migrating the Google route to Gemini 3.5 Flash when the prior model became unavailable to new projects
  • adding focused deterministic tests and compatibility validation
  • creating the Build Week demonstration site and film

Codex accelerated bounded Swift and Node implementation, source inspection, test updates, compatibility repair, diff review and validation.

GPT-5.6 Sol is used at runtime as H.E.R's synthesis layer.

How H.E.R was built

The iPhone application is written in Swift and SwiftUI.

A Node.js Relay protects provider credentials, routes requests to OpenAI, Anthropic and Google, normalizes streaming provider events, and performs bounded H.E.R synthesis.

Server-Sent Events carry live route output to the application.

The integrity path creates a collaboration execution Trace, binds it into a Receipt, preserves a bounded Drop, and produces a recomputable local Proof manifest.

The architecture deliberately separates:

  • provider output from H.E.R synthesis
  • structural convergence from factual truth
  • session behavior from consented lifelong learning
  • human-readable surfaces from sealed integrity records
  • user identity from any individual provider

Challenges

The hardest challenge was not simply calling several models. It was preserving truthful route identity whilst creating one coherent product voice.

Other challenges included:

  • provider quotas during repeated testing and filming
  • a model becoming unavailable to newly created projects
  • simulator and Apple toolchain instability
  • preserving privacy and truth boundaries across providers
  • communicating complex integrity architecture without turning the interface into a developer console

The model compatibility failure was resolved by identifying the exact upstream error, migrating the default model, updating the focused tests, and validating both the direct and Relay streaming paths.

What I learned

Multi-model systems need more than parallel API calls.

They need explicit execution truth, constrained synthesis, visible failure states, continuity boundaries, and a clear statement of what model agreement does—and does not—mean a unified experience should not require concealment of the structure beneath it.

What is next

Next steps include:

  • a hosted judge-ready Relay
  • TestFlight distribution in preparation for the App Store
  • durable consent-controlled H.E.R-ID continuity
  • bounded adaptive profiles across sessions and devices
  • expanded route reliability testing
  • signed Relay Proof verification
  • continued development of the Apple Watch signal surface
  • development for Android, MacOS, Windows and Linux applications

H.E.R is does not compete with the models.

H.E.R is the interaction layer between one human and many intelligent models.

Many intelligences. Single voice.™

Welcome to H.E.R™

Built With

Share this project:

Updates

Submission history