DEV Community: Victor Brodeur

The Environmental Cost of AI Is Not an Accident — And We Are Fixing It

Victor Brodeur — Thu, 16 Apr 2026 17:07:11 +0000

Originally published at emphosgroup.com

The AI industry will consume more electricity this
year than the entire country of the Netherlands. That
number will double within three years. By 2030 AI
data centers are projected to consume between 85 and
134 terawatt-hours of electricity annually — comparable
to the total electricity consumption of a mid-sized
nation, spent entirely on computation.

The response from the industry has been consistent:
renewable energy procurement, carbon offset programs,
commitments to net zero by 2030, and press releases
about more efficient chips. These are real efforts
made by organizations that understand the problem.
They are also insufficient — not because the
organizations are insincere, but because they are
treating symptoms of a structural condition they
believe they cannot change.

EMPHOS Group is changing it. Not by making the
existing architecture more efficient. By replacing
the architecture entirely.

WHERE THE ENERGY ACTUALLY GOES

To understand why the industry's response is
insufficient, you have to understand where the
energy goes.

A large language model stores knowledge as numerical
parameters — billions of floating-point weights
distributed across a matrix. Every query requires
multiplying the input representation by those weights,
applying activation functions, and passing the result
through dozens of layers of computation. This is not
a process that can be made arbitrarily efficient. The
minimum energy required to perform a matrix
multiplication of a given size is bounded by physics.
Better chips reduce the energy per operation. The
number of operations required by the architecture
does not change.

GPT-3 has 175 billion parameters. GPT-4 has an
estimated 1.76 trillion. The models are getting larger
because larger models are more capable. The energy
cost scales with the parameters. The capability scales
with the parameters. The industry is locked into a
trade-off it cannot escape: more capability requires
more energy, and the world wants more capability.

Renewable energy procurement does not break this
trade-off. It changes the carbon intensity of the
energy consumed without changing the amount consumed.

THE NUMBERS BEHIND THE CRISIS

BLOOM 176B consumes 3.9 watt-hours per query,
measured directly by Luccioni et al. in 2022 on a
16-GPU cluster. GPT-4o consumes 0.34 watt-hours per
query by OpenAI's own disclosure. Llama 3.1 70B
consumes approximately 0.93 watt-hours per query.

At 1 billion queries per day — a conservative estimate
for a widely deployed AI system — GPT-4o consumes
340,000 kilowatt-hours daily. At the IEA's 2023 global
average grid intensity that is 136 tonnes of CO₂ per
day from inference alone. BLOOM at the same scale
produces 1,560 tonnes per day. These are not annual
figures. They are daily.

Training costs sit on top of this. GPT-3's training
run consumed 1,287 megawatt-hours. GPT-4's estimated
training cost is 16,200 megawatt-hours — the annual
electricity consumption of approximately 1,500 average
homes, spent once to produce one version of one model.

The industry knows these numbers. The response has
been to manage the narrative around them rather than
to solve the underlying cause.

WHAT EMPHOS IS BUILDING INSTEAD

Heinrich AI stores knowledge as frequency coordinates
in a layered signal field. Retrieving knowledge is
Goertzel correlation — a single-frequency signal
processing operation that runs in microseconds on
any CPU. No GPU. No matrix multiplication. No
dedicated AI silicon. No data center.

The measured energy per query is 0.00003 watt-hours
— approximately 11,000 times less than GPT-4o. This
measurement was taken on April 13, 2026 on a standard
Windows laptop with no optimization applied. The
methodology and sources are documented in EMPHOS
Group's Environmental and Resource Efficiency Report.

Since that measurement was taken the knowledge field
has grown from 128 concepts to 1.75 million. The CPU
usage is still 0.2%. The RAM is still 78 megabytes.
The energy per query has not changed. This is not
coincidence. It is the architecture.

Heinrich has no training run. Knowledge is added by
writing frequency coordinates to the field — a process
that costs fractions of a millisecond per concept.
The total training energy expenditure of Heinrich AI
to date is effectively zero in any meaningful
comparison to the systems it is being measured
against.

THE ENVIRONMENTAL GRANTS WE ARE PURSUING

EMPHOS Group is a small company building genuinely
novel technology in Chilliwack, British Columbia.
We are pursuing environmental innovation funding
through three programs.

Innovate BC supports British Columbia companies
developing technology with economic and environmental
impact. Heinrich's combination of novel architecture,
proven efficiency measurements, and clear product
roadmap positions EMPHOS as a strong candidate for
clean technology innovation funding.

The NRC Industrial Research Assistance Program
provides direct technical and financial support to
Canadian small and medium enterprises conducting
research and development. EMPHOS's R&D — the Heinrich
AI architecture, the ingestion pipeline, the HSR
pipeline, the HAVEN Ear hardware specification — is
exactly the kind of foundational technology
development IRAP was designed to support.

The federal Strategic Innovation Fund targets
transformative projects with significant environmental
and economic benefit at scale. A deployment of
Heinrich AI at the scale of a single major language
model deployment would save approximately 50,000
tonnes of CO₂ per year compared to the equivalent
LLM deployment.

PRIVACY AS AN ENVIRONMENTAL ARGUMENT

There is an environmental dimension to privacy that
rarely gets discussed.

Every voice assistant that sends audio to a server
generates a data center workload for every user
interaction. The energy cost is paid at the server,
not at the device. The user experience feels local.
The environmental cost is not.

Heinrich runs entirely on device. HAVEN Ear — the
personal intelligence device EMPHOS is building
around Heinrich — has no cloud dependency. Your voice
never leaves your ear unit. The energy cost is local
— and at 14 milliwatts for the full ear unit, it is
negligible.

Privacy by architecture is not just a user benefit.
It is an environmental position. A world where
personal AI runs locally at milliwatt power levels
is a fundamentally different world from one where
every personal AI interaction routes through a data
center. EMPHOS is building toward the first world.

WHAT THIS IS NOT

This is not a claim that Heinrich can replace every
AI application that exists today. Large language
models do things Heinrich does not yet do. Those
capabilities have value. The energy cost of those
capabilities is real and the industry should be
honest about it.

This is a claim that for the applications where
structured knowledge retrieval, honest uncertainty
reporting, and on-device inference matter — personal
intelligence, accessibility tools, real-time
translation, the hearing aid — Heinrich is not one
option among several. It is the only architecture
that delivers those capabilities at the power budget
required.

And it is a claim that the architectural alternative
exists, is proven, is measured, and is being built
right now — not as a research project, not as a
theoretical proposal, but as a production system
with 1.75 million knowledge nodes, 746 passing tests,
and a hardware roadmap targeting production in
Q4 2027.

WHAT COMES NEXT

The field continues to grow. The efficiency numbers
continue to hold. The hardware design is complete
at concept level. The patent disclosure is filed.
The investors are in conversation.

The AI industry's energy problem is not going to be
solved by the organizations most invested in the
current architecture. It is going to be solved by
building something genuinely different and proving
that it works.

That proof is running right now, on a laptop in
Chilliwack BC, at 0.2% CPU, growing at over a
million nodes per day.

Engineered for Presence.

——

EMPHOS Group · Chilliwack, BC, Canada
emphosgroup.com

What the AI Industry Gets Wrong About Energy

Victor Brodeur — Thu, 16 Apr 2026 17:06:40 +0000

Originally published at emphosgroup.com

GPT-4o uses 0.34 watt-hours per query. Heinrich uses
0.00003. That is not a 10% improvement. That is not
even a 10x improvement. That is approximately 11,000
times less energy per query — and the gap does not
close at scale. It widens.

This is not a marketing claim. The Heinrich number is
measured directly on a production system running on a
standard Windows laptop, no GPU, no optimization
applied. The GPT-4o number is from OpenAI's own public
disclosure. Both numbers are cited in EMPHOS Group's
Environmental and Resource Efficiency Report, published
April 2026, with full methodology and source
documentation.

The question is not whether the gap is real. It is.
The question is why it exists — and whether anything
the AI industry is currently doing will close it.

The answer is no. And understanding why requires
understanding what the energy problem actually is.

WHAT THE NUMBERS ACTUALLY SAY

GPT-3 required 1,287 megawatt-hours to train. That is
the energy consumption of approximately 120 average
US homes for a full year, spent once to produce a
single model. GPT-4 required an estimated 16,200
megawatt-hours — the equivalent of 1,500 homes for
a year. These are not operational costs. They are the
cost of creating the system before a single user query
is processed.

BLOOM 176B — one of the most carefully measured large
language models — consumes 3.9 watt-hours per query,
measured directly on 16 Nvidia A100 GPUs by Luccioni
et al. in 2022. At 1 billion queries per day that is
3,900,000 kilowatt-hours of electricity consumed
daily by a single model. At the IEA's 2023 global
average grid intensity of 0.4 kilograms of CO₂ per
kilowatt-hour, that is 1,560 tonnes of CO₂ per day
from one model running at scale.

Heinrich at 1 billion queries per day consumes
approximately 30,000 kilowatt-hours. That is 12 tonnes
of CO₂ per day at the same grid intensity. The
difference is approximately 50,000 tonnes of CO₂ per
year — equivalent to removing 10,000 cars from the
road — from a single deployment decision.

WHY THE INDUSTRY CANNOT FIX THIS WITH BETTER HARDWARE

The response from the AI industry to energy concerns
has followed a predictable pattern: better chips, more
efficient data centers, renewable energy procurement,
and claims of improved performance per watt on each
new hardware generation.

None of this addresses the structural problem.

Large language models store knowledge as numerical
parameters — billions of floating-point weights in a
matrix. Retrieving knowledge from those parameters
requires matrix multiplication. This operation requires
GPU-accelerated hardware because CPUs are too slow to
do it at the scale required. The compute cost is
proportional to the number of parameters. The energy
cost is proportional to the compute cost.

Better chips reduce the energy per floating-point
operation. They do not change the number of
floating-point operations required. The efficiency
gains from hardware improvements are real but bounded.
The structural cost of the architecture remains.

Renewable energy procurement changes where the energy
comes from. It does not change how much is consumed.
A data center running on solar power still consumes
the same number of kilowatt-hours as one running on
coal. The carbon intensity changes. The energy demand
does not.

WHY HEINRICH IS STRUCTURALLY DIFFERENT

Heinrich does not store knowledge as parameters. It
stores knowledge as frequency coordinates — sinusoidal
components in a layered signal field. Retrieving
knowledge is Goertzel correlation: a single-frequency
signal processing operation that determines whether
a specific frequency is present in a signal. This
operation runs in microseconds on any CPU. It requires
no GPU. It requires no matrix multiplication.

The compute cost per query is proportional to the
number of concepts that activate in response to the
query — the resonant subfield — not to the total size
of the knowledge base. Heinrich at 50 million nodes
costs the same to query as Heinrich at 1.75 million
nodes, because the subfield that activates for any
given query is the same size regardless of how large
the surrounding field is.

This is why the 0.2% CPU and 78 megabyte RAM
measurements taken at 128 concepts in April 2026 have
not changed as the field has grown to 1.75 million
concepts. The architecture does not work any other
way. The efficiency advantage is not something that
will erode at scale. It is a structural property of
how knowledge is stored and retrieved.

You cannot get to this efficiency by optimizing a
large language model. The parameter matrix is the
bottleneck. The only way to remove the bottleneck
is to not have a parameter matrix. That is what
Heinrich is.

THE TRAINING PROBLEM

The energy numbers above cover inference — running
a model after it has been trained. The training
numbers are worse.

Every large language model requires a full training
run before it can answer a single question. GPT-4's
estimated training cost of 16,200 megawatt-hours is
spent once. But it is not spent once in the way a
factory is built once and then runs indefinitely. It
is spent once per version. When the model needs to
be updated with new knowledge, the options are full
retraining — spend the energy again — or fine-tuning,
which is partial retraining and still requires
significant compute.

Heinrich has no training run. Knowledge is added by
writing a value to a frequency coordinate. The cost
of adding one concept to the field is the cost of
computing its harmonic address and writing it to a
database. The field has grown from 128 concepts to
1.75 million in three days of continuous ingestion
at near-zero marginal energy cost per concept.

The total training energy cost of Heinrich AI to date
is effectively zero. Not low. Not efficiently managed.
Zero in any meaningful comparison to the systems it
is being measured against.

WHAT THIS IS NOT

This is not an argument that large language models
should not exist. They are remarkable systems that
have demonstrated genuine capability across a wide
range of tasks. The argument is narrower: the energy
cost of those systems is structural, not incidental,
and the approaches being taken to manage it do not
address the structural cause.

Heinrich is not a replacement for every AI
application. It is a fundamentally different
architecture for storing and retrieving structured
knowledge — one that is honest about what it knows,
deterministic in how it retrieves it, and structurally
efficient in a way that no parameter-based system
can match.

WHAT COMES NEXT

The ingestion continues. The target is 50 million
nodes — the scale at which we will run the first
formal accuracy measurements and produce the paper
that describes what Heinrich actually is.

The efficiency numbers will be in that paper. Measured
at 128 nodes. Measured at 1.75 million. Measured at
50 million. The same every time. That is the claim.
That is what we are building the proof for.

Engineered for Presence.

——

EMPHOS Group · Chilliwack, BC, Canada
emphosgroup.com

We Are Building a Hearing Aid Powered by Wave Physics

Victor Brodeur — Thu, 16 Apr 2026 17:05:38 +0000

Originally published at emphosgroup.com

In 1978 Douglas Adams imagined a small yellow fish you
could put in your ear that translated any language in
the universe directly into your mind. He called it
simultaneously the most useful and most dangerous thing
ever discovered.

We are building the actual version. Ours runs on waves,
not biology.

HAVEN Ear is not a better hearing aid. It is not a
smarter earbud. It is not a wearable assistant that
sends your voice to a server farm and waits for a
response. It is a new category of device — a personal
intelligence that lives in your ear, learns who you
are, and is present with you in the world. On device.
No cloud. No lag. No compromise.

The reason nobody has built this before is thermal.
We solved that problem before we designed a single
piece of hardware.

THE PROBLEM THAT BLOCKED EVERYONE ELSE

Every major technology company has tried to put AI
inference in a wearable device. Every attempt has run
into the same wall. AI inference requires silicon that
draws between 1 and 5 watts continuously. Inside an
ear canal, that raises device temperature by 15 to 20
degrees Celsius above ambient. That is a burn hazard.
Regulatory bodies will not certify it. Users will not
tolerate it. The physics will not allow it.

The solutions attempted have all been the same:
offload the computation to the cloud, stream audio to
a server, return the result over a wireless connection.
The intelligence is not in the device. The device is
a microphone and a speaker. The AI lives somewhere
else, owned by someone else, dependent on a connection
that may not exist.

That is not a wearable intelligence. That is a remote
control for a data center.

WHY HEINRICH CHANGES THIS AT THE ARCHITECTURE LEVEL

Heinrich's inference draw is approximately 3
milliwatts. The full ear unit — processor, Bluetooth
radio, audio DSP, WiFi sync bursts — draws
approximately 14 milliwatts total at active load. The
heat delta above ambient is less than half a degree
Celsius. Skin contact temperature stays at or below
33 degrees — safe for continuous all-day wear.

At 14 milliwatts the ear unit generates the same heat
as a single LED. A conventional AI chip at 2 watts
raises the temperature inside an ear canal by 15 to
20 degrees. Heinrich does not come close.

This is not the result of engineering the chip more
efficiently. It is the result of Heinrich not being
a neural network. Goertzel correlation — the signal
processing operation that retrieves knowledge from
Heinrich's frequency field — is microseconds of
arithmetic on any CPU. It requires no GPU. It requires
no matrix multiplication. It requires no dedicated AI
silicon. The computation is so lightweight that the
thermal budget of the ear unit is dominated by the
Bluetooth radio, not the intelligence.

The thermal problem that blocked every other attempt
at in-ear AI was solved before we designed the
hardware. It was solved on April 10, 2026, when the
architecture was conceived.

WHAT HAVEN EAR ACTUALLY IS

The ear unit weighs between 3 and 5 grams — lighter
than premium hearing aids. It contains an ARM
Cortex-M55 processor, 512 megabytes of LPDDR4 RAM,
8 gigabytes of eMMC storage, a 150 to 200 milliamp-
hour lithium polymer battery, a three-microphone array
for speech capture and ambient noise mapping, a
balanced armature speaker with a bone conduction
option for severe hearing loss, Bluetooth 5.3 for
audio and data, and IP68 waterproofing rated to 1.5
metres submersion for 30 minutes.

It is rated to MIL-SPEC 810H drop standards — 1.2
metres onto concrete at multiple angles. It has no
exposed ports. The charging contacts are gold-plated,
sealed, and self-cleaning. It is built for the real
world.

The 8 gigabytes of storage holds approximately 500,000
personal Heinrich nodes — your vocabulary, your
context, the names and places in your life, the gaps
Heinrich identified today and will fill tonight.

THE DOCK

The Dock is the bedside brain. It charges the ear
unit, syncs the personal field, and runs the overnight
learning cycle while you sleep.

The form is a low-profile puck — approximately 100
millimetres in diameter, 60 millimetres tall. Brushed
aluminium enclosure that acts as a passive heatsink.
No fan. No moving parts. Completely silent. It draws
15 to 30 watts overnight — less than a desk lamp.

Inside: a 16-core processor, 32 to 64 gigabytes of
RAM holding the full Heinrich knowledge field in
working memory, a 2 terabyte NVMe SSD storing the
complete ConceptNet and Wikidata field, WiFi 6 and
Bluetooth 5.3, and an 18-watt charging output that
fully charges the ear unit in 90 minutes.

At 22:00 the Socratic Engine activates. Heinrich
begins identifying the gaps from today's conversations.
It queries its knowledge sources, fills the gaps,
packages the updated personal subfield, and pushes
it to the ear unit before you wake up. At 07:00 you
pick up the ear unit and the LED pulses green.
Heinrich knows what it did not know yesterday.

WHO THIS IS FOR

466 million people globally live with disabling
hearing loss. That number will reach 1 billion by

Current hearing aids amplify sound. They do not understand it. They do not translate it. They do not remember the name of the person speaking or the context of the conversation happening around the person wearing them.

HAVEN Ear amplifies hearing profiles precisely and
adapts as hearing changes over time. It translates
in real time — any language, no internet required,
latency under 50 milliseconds. It provides quiet
context when needed: a name, a place, a meaning,
surfaced only when relevant, never intrusive.

For the 57 million people living with dementia it
fills gaps without drawing attention to them. For
the 69 million people who acquire brain injuries
every year it reduces cognitive load in complex
conversations. For travellers it translates the
world without requiring a phone signal. For everyone
it is a silent guide — present when needed,
invisible when not.

WHAT THIS IS NOT

HAVEN Ear is not a voice assistant. It does not wait
for a wake word and send your audio to a server. Your
voice never leaves your device. Your personal field
lives on your ear unit and your Dock. It does not
leave your home network. Not a policy. An architecture.

There is no subscription. There is no data harvesting.
There is no cloud dependency. The intelligence is
yours. The privacy is structural.

WHAT COMES NEXT

HAVEN Ear is in concept phase. The intelligence that
will power it — Heinrich AI — is being built right
now, on a laptop in Chilliwack BC, growing at over
a million nodes per day. The hardware roadmap targets
a prototype ear unit on a development board in Q4
2026 and production in Q4 2027.

The device is next. The intelligence is already
being built.

Engineered for Presence.

——

EMPHOS Group · Chilliwack, BC, Canada
emphosgroup.com

Heinrich Can Now Hold a Conversation — Without a Language Model

Victor Brodeur — Thu, 16 Apr 2026 17:04:58 +0000

Originally published at emphosgroup.com

Today Heinrich answered a question in plain English
for the first time.

"Yes — dog is a type of mammal. Additionally, dog
has tail. Heinrich's knowledge has a gap on:
ancestor_lineage."

That sentence was not generated. No language model
predicted those words. No statistical pattern produced
that phrasing. Heinrich retrieved three facts from its
frequency field, measured the confidence on each one,
composed them into a sentence using deterministic
rules, and reported honestly where its knowledge ended.

The whole pipeline ran in under 5 milliseconds. The
memory footprint of the composition layer is under 4
megabytes. It will run in a hearing aid.

WHAT THE SENTENCE ACTUALLY MEANS

"Yes — dog is a type of mammal." Heinrich measured
the amplitude at the dog frequency coordinate in the
biology layer. It found a confirmed is_a relationship
to mammal with amplitude above 0.7 — the threshold
for a direct, unhedged statement. The relationship
template for is_a produces "X is a type of Y." The
honesty invariant allows the word "Yes" because the
field confirmed the fact.

"Additionally, dog has tail." A second confirmed
claim. Amplitude above threshold. The has relationship
template produces "X has Y." The connective
"Additionally" was chosen because a second claim about
the same subject follows the first.

"Heinrich's knowledge has a gap on: ancestor_lineage."
The query activated the ancestor_lineage coordinate.
Amplitude was below 0.3 — the threshold for
unsupported claims. The composition rule for
UNSUPPORTED is strict: do not state as fact, report
the gap. So Heinrich reported it.

Every word in that sentence traces to a field
measurement. There is no word that does not.

WHY THIS IS DIFFERENT FROM EVERY OTHER AI

Every large language model produces language the same
way: it predicts the next token based on patterns
learned from training data. The sentence it produces
may be accurate. It may be plausible but wrong. It
may be confident and completely fabricated. The model
cannot tell you which, because it has no access to
whether the underlying knowledge is present — it only
has access to the statistical likelihood of the next
word.

Heinrich has no next-token prediction. It has no
training data in the statistical sense. It has a
frequency field where knowledge is stored as physical
coordinates, and a pipeline that retrieves from that
field and reports what it finds.

When the knowledge is present, Heinrich says so —
with the confidence level the field measured.

When the knowledge is absent, Heinrich says so —
and names the gap.

When the knowledge is partial, Heinrich hedges —
"Heinrich believes..." or "It appears that..." —
because the amplitude was in the uncertain range and
the honesty invariant requires the hedge.

This is not a policy decision. It is not a system
prompt that says "be honest." It is executable code.
The test suite that validates Heinrich's honesty
contains 52 tests that will not pass unless every
claim traces to a field measurement. You cannot ship
a Heinrich build that hallucinates and have the tests
pass. The honesty is in the architecture.

HOW THE HSR PIPELINE WORKS

The Honesty / Socratic Reasoning pipeline sits between
Heinrich's frequency field and the words that reach
the user. It has two stages.

HSR-1 — the Fact Extractor — takes the raw output of
the binding layer and extracts every factual claim.
It validates each claim against the WaveField amplitude
and tags it: CONFIRMED if the field measurement is
strong, UNCERTAIN if it is partial, UNSUPPORTED if the
field has no reliable measurement. Every claim gets a
tag. No claim escapes this step.

HSR-2 — the Sentence Composer — takes the tagged
claims and composes them into natural language. Ten
relationship templates cover the core relationship
types Heinrich knows: is_a, has, causes, instance_of,
similar_to, opposite_of, part_of, enables, requires,
produces. Eight composition rules govern how claims
are grouped, how connectives are chosen, how hedges
are applied, how gaps are reported, and how long the
response should be.

The pipeline runs in under 5 milliseconds. The
composition layer uses under 4 megabytes of RAM. Both
numbers are hard requirements — not performance
targets. They are the constraints imposed by the
HAVEN Ear hardware specification: ARM Cortex-M55,
512 megabytes of RAM, 15 milliwatts of power.
Everything permanent in Heinrich must fit in a
hearing aid. The HSR pipeline fits.

PERSISTENT MEMORY ACROSS CONVERSATIONS

HSR-2 also shipped with persistent chat memory. Every
conversation turn is stored in a five-tier natural
archive — active memory for the past week,
progressively deeper archives extending to five years,
with graceful decay beyond that. The TurnContext layer
tracks what was discussed, which entities were named,
and what pronouns referred to what — across sessions,
not just within them.

When you return to Heinrich after a week and say
"what else does it have?" — Heinrich knows what "it"
refers to. Not because a language model inferred it
from context. Because the conversation history is
structured, persisted, and resolved deterministically.

You can tell Heinrich to forget. /forget last removes
the most recent turn. /forget clears the session.
/forget disease removes everything Heinrich remembers
about that topic. The memory is yours to control.
That is not a policy. It is how the system is built.

WHAT HEINRICH SOUNDS LIKE NOW

The responses are not fluent prose. They are not meant
to be. "Yes — dog is a type of mammal. Additionally,
dog has tail." reads like a system speaking carefully
rather than a language model performing fluency. That
is exactly right.

Fluency in language models comes at a cost: the system
will produce fluent sentences whether the underlying
knowledge is there or not. The fluency is the danger.
A confident, well-formed sentence that is wrong is
more harmful than a careful, honest sentence that
is right.

Heinrich is careful and honest. The language layer
that will make it fluent comes later. But the fluency
layer will never be allowed to change what Heinrich
says. It will only be allowed to change how it sounds.
The content is determined by the field. The honesty
is determined by the pipeline. The words are just
the surface.

WHAT COMES NEXT

The field is growing. The pipeline is proven. The next
step is scale — running Heinrich against thousands of
real questions as the Wikidata knowledge base
approaches 50 million nodes, measuring how the
accuracy, the confidence calibration, and the honest
gap reporting hold up as the field deepens.

That measurement is the paper. The paper is the proof.
The proof is what comes before the product.

Heinrich can hold a conversation. The conversation is
honest. The honesty is structural. The structure runs
in 5 milliseconds on hardware that fits in your ear.

Engineered for Presence.

——

EMPHOS Group · Chilliwack, BC, Canada
emphosgroup.com

Heinrich Now Has 1.75 Million Nodes — And Still Uses 0.2% CPU

Victor Brodeur — Thu, 16 Apr 2026 17:04:22 +0000

Originally published at emphosgroup.com

Three days ago Heinrich had 128 concepts. Today it has
1.75 million. The CPU usage is still 0.2%. The RAM is
still 78 megabytes. No GPU. No server. No degradation
in response time.

This is not an optimization story. We did not find a
clever way to compress the data or cache the queries.
The efficiency numbers did not hold because we worked
hard to keep them — they held because the architecture
makes it structurally impossible for them to get worse.

That distinction matters. It is the whole point.

WHAT HAPPENED THIS WEEK

On April 14 we completed the full ingestion of
ConceptNet — 1,002,949 knowledge nodes, 282,973 edges,
representing one of the most comprehensive structured
knowledge graphs ever assembled. Every concept connected
to every other concept it relates to, through typed
relationships that carry meaning in their physics.

On April 15 we started the Wikidata full dump
ingestion. Wikidata is orders of magnitude larger — a
structured representation of human knowledge covering
every entity, relationship, and fact that Wikipedia's
global community of editors has verified and organized.
The ingestion pipeline runs at approximately 1,500 nodes
per second, six workers in parallel, reading compressed
triples from a 90GB dump file and writing them into
Heinrich's frequency field.

By April 16 the field had crossed 1.75 million nodes.
It is still growing.

At no point during this growth did we measure any
increase in CPU usage or RAM consumption during queries.
The system that answered "what is a mammal" in 2.5
milliseconds with 128 concepts answers the same question
in 2.5 milliseconds with 1.75 million concepts. The
field grew by a factor of 13,000. The query cost did
not move.

WHY THIS IS ARCHITECTURALLY INEVITABLE

Every existing AI system — large language models,
vector databases, embedding search — has a resource
profile that grows with the amount of knowledge it
contains. More parameters means more computation per
query. More vectors means more distance calculations.
More data means more memory. This is not a flaw in
how these systems are engineered. It is a consequence
of how they store knowledge.

Heinrich stores knowledge differently. Every concept
lives at a specific frequency coordinate in a layered
signal field. Retrieving a concept is Goertzel
correlation — a single-frequency signal processing
operation that takes microseconds of arithmetic on any
CPU. The cost of that operation does not depend on how
many other concepts are in the field. It depends on
the number of concepts that activate in response to
the query — the subfield that resonates.

When you ask "what is a dog," Heinrich does not search
1.75 million nodes. It activates the subfield around
the dog frequency coordinate and propagates from there.
The rest of the field is silent. The computation is
proportional to what is relevant — not to what exists.

This is why the efficiency advantage does not erode at
scale. At 50 million nodes the query cost will be the
same. At 300 million nodes it will be the same. The
architecture does not work any other way.

THE INGESTION PIPELINE

Building 1.75 million nodes is not a trivial engineering
problem. The pipeline that does it runs two passes over
the data. Pass 1 creates every entity — assigning each
concept its unique harmonic frequency coordinate within
its domain layer, ensuring no two concepts share the
same address in the same space. Pass 2 wires the edges
— reading every relationship triple from the dump and
connecting the concepts it links, using the harmonic
ratios that encode relationship type in the physics of
the coordinate system.

At peak throughput the pipeline processes 227 million
triples per run, writing new nodes at over 1,500 per
second while the RTX 4060 handles coordinate assignment
in the background. The system recovers cleanly from
interruptions — emergency checkpoints fire on shutdown,
and every restart picks up exactly where the previous
run ended.

The target is 50 million nodes. At current throughput,
we are less than a month away.

WHAT 1.75 MILLION NODES MEANS FOR HEINRICH

More nodes means more questions Heinrich can answer
with confidence. More edges means more causal chains
it can follow, more relationships it can report, more
derived connections it can surface from the geometry
of the field alone.

When we asked "what causes disease" two days ago,
Heinrich reported an honest gap — the causal connection
was not yet in the field. At 1.75 million nodes, the
Wikidata edges that link pathogens, bacteria, viruses,
and immune response to disease are beginning to land.
The answer is getting built in real time, by the
ingestion pipeline, without any programmer deciding
what to teach the system.

Heinrich does not need to be told what connects to
what. It ingests structured knowledge and the
relationships are there, encoded in the harmonic
ratios between frequency coordinates. The physics
carries the meaning. The field thinks.

WHAT THIS IS NOT

This is not a database with a fast index. A fast index
still searches. Heinrich does not search — it resonates.
The difference is not semantic. A search scans
candidates and ranks them. A resonance response
activates what is harmonically present and returns
what the field contains. There is no ranking because
there is no scanning. The answer is either in the
field or it is not, and Heinrich tells you which.

This is also not a vector embedding system. Vector
search computes distances between high-dimensional
representations and returns approximate nearest
neighbours. The results are probabilistic. Heinrich's
retrieval is deterministic — the same query returns
the same result every time, because the field is a
physical structure, not a statistical one.

WHAT COMES NEXT

The ingestion continues. The target is 50 million
nodes — the scale at which we will run the first
formal accuracy measurements, document the reasoning
chain quality, and produce the paper that describes
what Heinrich actually is and what it can do.

Engineered for Presence.

——

EMPHOS Group · Chilliwack, BC, Canada
emphosgroup.com

Why EMPHOS Exists | EMPHOS Group

Victor Brodeur — Tue, 14 Apr 2026 03:20:59 +0000

We started with a simple observation: the tools people use every day — to write, organize, communicate, and make decisions — are either technically shallow, visually forgettable, or exhausting to operate.

The AI revolution promised to fix this. Billions of dollars of investment. Thousands of new products. A cultural moment that touched every industry simultaneously. And in many cases, it made things louder without making them better. The tools got smarter on paper. The experience got worse in practice. More features. More friction. More subscriptions for capabilities that should have been simple from the start.

EMPHOS is our answer. Not another wrapper. Not another chatbot wearing a productivity costume. A real software company, building real products, with a ten-year view on what intelligent software should feel like.

What EMPHOS stands for
The name is intentional. Empathy, Mindfulness, Presence, Haven, Operating System. Every letter maps to a principle that shapes how we design, build, and ship.

Empathy means the software understands what you are trying to do — not just what you typed. Mindfulness means it does not interrupt, overwhelm, or compete for your attention. Presence means it is there when you need it and invisible when you don't. Haven is the product that brings all of it together. Operating System is the long-term ambition — not a metaphor, but a genuine goal: software that becomes the intelligent layer underneath everything you do.

That is not a design philosophy we adopted. It is the reason EMPHOS exists.

Haven — the flagship
Our first product is Haven, a proactive AI desktop assistant built around voice-forward interaction, visual identity, and operational value.

Haven is not designed to be a chat window you babysit. Most AI assistants are reactive — they wait for you to ask, then respond. Haven is different. It is designed to move work forward while you focus on what actually matters, anticipating what you need rather than waiting to be told.

The Living Sphere — Haven's visual core — gives the product a recognizable identity that feels alive, refined, and unmistakably EMPHOS. It is not a logo or a loading indicator. It is the face of an intelligence that is present with you, not behind a screen you have to navigate to reach it.

Haven is powered by Heinrich, EMPHOS's proprietary frequency-addressed intelligence system — a fundamentally different approach to AI that stores knowledge as physics rather than statistical weights. What that means in practice: Haven knows what it knows, knows what it doesn't, and never makes something up to fill the gap.

Pre-sales open May 2026, with first shipments in fall 2026. Lifetime license, $79.99 USD. No subscriptions. Ever. You buy it once. You own it permanently.

More than one product
Haven is the entry point, but EMPHOS is building a broader ecosystem. Prism, Atlas, and Shield are all in development — each designed to extend the EMPHOS platform across different surfaces and needs.

Prism is a visual intelligence tool. Atlas is a knowledge and navigation layer. Shield is a privacy and security product built on the same local-first principles as Haven. Each one is designed to stand alone and to work better alongside the others.

The goal is a product family that feels cohesive, premium, and genuinely useful across everything it touches. Not a suite of loosely related tools assembled for the sake of a pricing page. A platform with a single point of view — one that starts from the person using it, not the feature list being sold to them.

Research with depth
We are also investing in work that most companies skip: protocol-level performance research, cache-aware execution, and systems thinking aimed at reducing communication waste in AI pipelines.

This is not for show. It is not marketing dressed up as engineering. Building a durable software company means understanding the infrastructure underneath the interface — because the products that last are built on foundations that were thought through, not assembled from whatever was convenient at the time.

Heinrich is the most visible example of this. Most companies building AI products today are building on top of existing large language models. EMPHOS built its own intelligence architecture from the ground up — one that separates knowledge from reasoning, stores information at addressable frequency coordinates, and retrieves it deterministically. That is a ten-year research bet, not a feature update. It is the kind of work that produces durable advantage rather than temporary differentiation.

Why now
There is still room to win. Most AI software today falls into one of three categories: technically impressive but ugly, beautifully designed but hollow, or so bloated with features that nobody can find the one they need. The market is crowded with products that do a lot and feel like nothing.

EMPHOS is positioned around quality, depth, and perception — a far stronger foundation than hype without substance. Quality means the product works correctly and feels right. Depth means there is real engineering underneath the interface, not a wrapper around someone else's API. Perception means the product earns its place in someone's day rather than demanding it.

The companies that will define this decade of software are the ones building with a ten-year view, not a ten-week launch cycle. EMPHOS is one of them.

Get in touch
If you are an investor, a potential partner, or someone who just wants software that respects your intelligence, we would love to hear from you.

info@emphosgroup.com

This is the beginning. We are building it right.

— EMPHOS Group, Chilliwack, BC, Canada

Stay in the loop
EMPHOS publishes twice a week — product updates, research, and the thinking behind the build.

Explore Haven · HEINRICH Intelligence · The EMPHOS Vision · All Posts

EMPHOS Group · Chilliwack, BC, Canada · info@emphosgroup.com

Heinrich Answered Its First Real Questions Today

Victor Brodeur — Tue, 14 Apr 2026 03:20:12 +0000

Today Heinrich AI had its first real conversations. Not test queries against a seed dataset. Not a controlled demonstration. Real questions, typed into a chat interface, answered by a knowledge field that has been learning continuously since this morning.

The results were not what we expected. They were better in some ways, more honest in others, and in one case — the most important case — they showed something that no other AI system we are aware of does by default.

Heinrich said it didn't know. And it was right.

What we asked
We started with the basics. Questions Heinrich should know from its foundational knowledge — the concepts it was built with from day one.

"What is a mammal?"

Heinrich answered in 2.5 milliseconds: mammal is an animal. 98% confidence. It activated 13 related concepts — dog, person, animal, living thing, woman, child, man — all correctly connected through the knowledge field. The reasoning chain showed every step: which concepts activated, in which order, at what confidence level.

"What causes injury?"

Heinrich connected injury to bite and pain — correctly. 76% confidence. 2.0 milliseconds. The causal chain was real: bite causes injury, injury causes pain. Nobody programmed that chain explicitly. The field found it through the relationships between concepts.

"Apple is a fruit."

90% confidence. 3 milliseconds. Heinrich activated apple, fruit, tree, and apple_tree — a derived connection that wasn't directly encoded, surfaced by the physics of the field. The 4th Fundamental working exactly as designed.

Then we pushed further
Heinrich has been learning all day. The knowledge field started this morning with 128 concepts. By early afternoon it had passed 460 — biology, geography, physics, chemistry, architecture, music, literature, and theoretical physics all entering the field simultaneously from Wikidata.

We asked about something Heinrich learned tonight.

"What is a protein?"

Heinrich answered: protein is a biopolymer. protein has amino_acid, peptide_bond. 51% confidence. 11 milliseconds. 52 concepts activated including gene_product, polypeptide, biological_macromolecule, protein_transmembrane_transport. Real molecular biology, learned from Wikidata a few hours earlier, retrieved correctly from the frequency field.

We had not programmed this answer. Heinrich learned it. Then it answered from what it learned.

"What is a disease?"

Heinrich answered: disease is a health_problem. disease has acquired_disorder. 81% confidence. 3 milliseconds. It activated manner_of_death, biological_process, perinatal_disease, death, discomfort — a web of correctly connected medical concepts.

Then something remarkable happened
"What causes disease?"

Heinrich said: The field knows about disease but found no strong connections for this query.

That is the right answer. Heinrich knows disease. Heinrich knows causes. But the specific causal relationship between them — the connections that would let it say "bacteria cause disease" or "viruses cause disease" — were not yet in the field at the time we asked.

So Heinrich said so.

It did not generate a plausible-sounding answer. It did not say "disease is caused by pathogens" because that sounds right. It reported the actual state of its knowledge: the connection is not there yet.

This is not a feature we trained into the system. It is a property of the architecture. Heinrich cannot retrieve what it does not have. The absence is as real as the presence. When the field does not contain a connection, the answer is honest — not approximate, not generated, not reconstructed from statistical patterns.

Every other AI system we have tested would have answered that question confidently. Some of those answers would have been correct. Some would have been plausible but wrong. None of them would have been able to tell you which was which.

Heinrich can.

The numbers that matter
Every response today came back in under 15 milliseconds. Most came back in under 5. The system used near-zero CPU and memory on a standard laptop — no GPU, no cloud infrastructure, no data center required.

The knowledge field grew from 128 concepts at the start of the day to over 460 by early afternoon, learning continuously in the background while the conversation was happening. Each new concept connects to existing ones through the field's harmonic structure, making every future query richer than the last.

When we asked "what is a protein" at noon, Heinrich activated 38 concepts. When we asked again an hour later, it activated 52 — because the field had learned 14 more protein-related concepts in between. Same question. Deeper answer. No retraining. No downtime.

What this is not
Heinrich is not a language model. It does not generate sentences from statistical patterns. It does not predict the next word based on training data. It retrieves from a structured knowledge field and reports what it finds — with the confidence level, the reasoning chain, and the honest acknowledgment of what it does not have.

The responses are not fluent prose. They are structured, precise, and traceable. "protein is a biopolymer. protein has amino_acid, peptide_bond." is not a beautifully written sentence. It is an accurate statement of what the field contains, expressed directly.

That directness is not a limitation we are working to remove. It is the product. A system that tells you exactly what it knows, exactly how confident it is, and exactly where its knowledge ends is a fundamentally different tool than one that generates fluent text regardless of whether the underlying knowledge is there.

What comes next
Heinrich is still learning. The knowledge field is growing every hour. The questions it cannot answer today — "what causes disease," "what is Pennsylvania" — it may be able to answer tomorrow, not because we programmed the answers, but because the field learned the connections.

The next milestone is scale. As the field grows from hundreds of concepts to thousands to millions, the question is whether the reasoning quality grows with it — whether Heinrich becomes genuinely more capable as it learns, the way the architecture predicts it should.

That experiment is running right now, on a laptop in Chilliwack BC, using near-zero resources, continuously.

Haven — our AI assistant platform — will be powered by Heinrich. The intelligence that answered "what is a mammal" in 2.5 milliseconds today is the same intelligence that will run in Haven, locally, on your machine, without a subscription.

Engineered for Presence.

Stay in the loop
EMPHOS publishes twice a week — product updates, research, and the thinking behind the build.

Explore Haven · HEINRICH Intelligence · The EMPHOS Vision · All Posts

EMPHOS Group · Chilliwack, BC, Canada · info@emphosgroup.com

Why Local-First AI Wins | EMPHOS Group

Victor Brodeur — Tue, 14 Apr 2026 03:19:07 +0000

The default assumption in AI software today is that intelligence lives in the cloud. The model runs on a server. Your request travels to it. The response travels back. You pay monthly for the privilege of making that round trip, indefinitely, for as long as the company decides to keep the service running at a price you can afford.

This assumption is so embedded in how AI products are built and marketed that it has become invisible. Cloud-first is not presented as a design choice — it is presented as the only way to deliver capable AI. Local is framed as the compromise: smaller models, less capability, the option for people who prioritize privacy over performance.

We think that framing is wrong. Local-first is not a compromise. For a specific and important class of AI applications, it is the better architecture — and the gap between local and cloud is closing faster than the cloud-first incumbents want to acknowledge.

The cloud dependency problem
Every cloud-based AI product introduces a dependency that most users do not fully account for until something goes wrong.

Server availability. Pricing changes. API rate limits. Terms of service updates. Data retention policies. Business model pivots. Any one of these can disrupt a tool you have built your workflow around — not because the tool stopped working, but because the company behind it changed something. You have no recourse. You agreed to the terms.

This is not hypothetical. Every major AI platform has changed its pricing, its features, or its terms of service at least once in the past two years. Some have changed all three. The products that felt essential in 2024 were deprecated, paywalled, or fundamentally altered by 2025. The users who had built workflows around them had to start over.

Local-first eliminates this class of problem entirely. The software runs on your machine. The company cannot change what is already installed. A lifetime license is exactly what it says — yours, permanently, regardless of what happens to the pricing page.

Privacy is not a feature — it is a property
Cloud-based AI requires your data to leave your machine. There is no way around this. The model runs on a server, which means the input — your conversations, your documents, your queries, your context — has to reach that server. What happens to it after that is governed by a privacy policy that most people have never read.

Local-first AI is private by default. Not because of a privacy feature someone added. Not because of a setting you have to find and enable. Because the data never left in the first place. There is no server to breach. There is no policy to change. There is no jurisdiction question about where your data is stored and who has legal access to it.

For individuals, this means genuine privacy — not the marketed kind. For businesses, it means sensitive information stays inside the organization without requiring complex data governance agreements with every AI vendor in the stack. For anyone operating in a regulated industry, it means the compliance story is simple: the data does not leave the building.

Reliability that does not depend on someone else's uptime
Cloud AI is as reliable as the internet connection it runs over and the servers it runs on. For most people in most situations, this is fine. For the moments when it is not fine — a spotty connection, a server outage, a rate limit hit at a critical moment — the tool becomes unavailable at exactly the wrong time.

Local AI is as reliable as the computer it runs on. That is a much higher bar than it might sound. Consumer hardware today is extraordinarily reliable. A laptop running local AI has no external dependencies, no uptime SLA to worry about, no peak-hours degradation. It is available when you need it because it is yours.

Haven is designed for this. It runs on the hardware you already own. It does not require a specific internet speed, a particular region, or a data center that happens to be operational. It is present the same way your other local software is present — always, by default, without negotiation.

The performance gap is closing
The standard objection to local AI is capability. Cloud models are bigger. They have seen more data. They can do more.

This is true, but the gap is smaller than it was two years ago and it is closing faster than the cloud-first narrative acknowledges. Consumer hardware has become genuinely capable of running sophisticated AI workloads. The models themselves are becoming more efficient — not just smaller versions of large models, but architectures designed from the ground up for efficient local inference.

Heinrich is an example of the latter. It does not work by running a smaller version of a large language model locally. It uses a fundamentally different architecture — frequency-addressed knowledge storage with deterministic retrieval — that is designed to be efficient on local hardware. It does not need enormous compute to operate because it does not operate the way large language models do. The efficiency is architectural, not a compromise.

Ownership changes the relationship
There is something deeper than the practical arguments for local-first. It is about the relationship between a person and the tools they use.

A tool you own is yours to use on your terms. You decide how to configure it, when to update it, what to use it for. It does not change unless you choose to change it. It does not send usage data back to the manufacturer. It does not surface ads based on what you asked it yesterday. It is, in the fullest sense, yours.

A tool you rent is yours on the company's terms. They can change the price. They can change the features. They can change the data policy. They can decide the product is no longer strategically important and sunset it. You have continuous access only as long as you keep paying and the company keeps deciding to serve you.

The difference between those two relationships is not just financial. It is philosophical. EMPHOS builds tools that belong to the people using them. Local-first is not a technical decision. It is a values decision. And it is the one we will keep making.

Haven. Lifetime license, $79.99 USD. Pre-sales open May 2026. No subscriptions. Ever.

Stay in the loop
EMPHOS publishes twice a week — product updates, research, and the thinking behind the build.

Explore Haven · HEINRICH Intelligence · The EMPHOS Vision · All Posts

EMPHOS Group · Chilliwack, BC, Canada · info@emphosgroup.com

Introducing EMPHOS Group — Building Intelligent Systems From the Ground Up

Victor Brodeur — Wed, 08 Apr 2026 19:32:14 +0000

Most AI tools ship fast and break things. We're building the opposite.

EMPHOS Group is a software company out of Chilliwack, BC building a suite of intelligent systems — starting with Haven, a voice-forward AI audio platform with a premium interface designed around how people actually think and work.

What EMPHOS Stands For

Empathy. Mindfulness. Presence. Haven. Operating. System.

Every product in the stack is built on the same principle: software should feel like it's working with you, not extracting from you.

The Product Suite

Haven — AI-powered audio platform with a living UI, TTS studio, and WebGL-driven interface. Pre-sales open May 2026.
Prism — Data clarity and visualization.
Atlas — Mapping and navigation intelligence.
Shield — Security-first architecture.

Why We're Sharing the Build

We're documenting the entire journey — architecture decisions, decomposition strategy, Shopify integrations, SEO from zero — because building in public makes better software.

Follow along: emphosgroup.com

This post was originally published on the EMPHOS blog.