The Intelligence Has to Fit on the Machine
EMPHOS Group, June 27, 2026, 6 min read
There is a simple question every AI company eventually has to answer: where does the intelligence live?
For most of the industry, the answer is somewhere else. A data center. A rented model endpoint. A cluster of accelerators behind an API. The product on your computer is an interface. The intelligence is remote, metered, and controlled by someone else's infrastructure.
Heinrich is built in the other direction.
The intelligence has to fit on the machine. Not as a toy demo. Not as a thin offline mode. As the actual product architecture.
The packaging boundary
The current Heinrich runtime is organized around packaged local artifacts. The latest runtime pack manifest records three packs: COEUS, Mercury, and CODE. COEUS is the mind pack. Mercury is the language pack. CODE is the code-intelligence pack.
Together, the latest packaged runtime is roughly 3.4 GB across 38 entries. COEUS accounts for about 2.96 GB. Mercury accounts for about 436 MB. CODE accounts for about 11.7 MB.
Those numbers matter because they describe a boundary. The system is not pretending to be local while secretly depending on a remote model to think. The runtime packs are the materials the product loads. The machine has the artifacts it needs to answer through the Heinrich path.
Just as important, the packaging report shows what is excluded. Reports are excluded. Tests are excluded. Source clusters are excluded. Unexpected sidecars are excluded.
That exclusion is not housekeeping. It is authority control.
Build time is not answer time
Heinrich can use source material when it builds its mind. That is build time. Source records can shape the field, provide concept material, influence couplings, and become part of compiled artifacts through governed processes.
Answer time is different.
When a user asks a question, the system should not rummage through source folders, proof reports, test outputs, old logs, or developer notes looking for a sentence to repeat. That would be retrieval dressed up as cognition. It would also make the product impossible to audit, because any file on disk could quietly become answer authority.
The runtime pack boundary prevents that. The product loads packaged artifacts. Those artifacts carry the prepared field and language materials. Source shaping happens before. Runtime cognition happens after. The two stages are related, but they are not allowed to collapse into each other.
This is one of the least glamorous parts of the Heinrich build, and one of the most important.
The mind pack
The COEUS pack is the largest because the mind is the largest responsibility. It carries the prepared materials for concept identity, numeric activation, sparse propagation, role states, and thought formation. It is where the system begins turning a user query into a supported internal result.
The important thing is not that the pack is large. The important thing is what it is for. COEUS is not a bag of finished answers. It is the prepared substrate for runtime reasoning. The product path must still inject the query, propagate activation, form support, identify uncertainty, and hand a thought packet forward.
A packed mind is not a lookup table. It is a local field that can be activated.
The mouth pack
The Mercury pack is the language side. The current materialized Mercury language field records 49 language segments and 49 million language concepts in the runtime materialization path.
Mercury's job is to speak from COEUS support. That means the language pack exists to make expression better, not to become factual authority. It can plan a response. It can vary wording. It can avoid canned repetition. It can turn a thought packet into readable English. But if COEUS did not support a claim, Mercury is not supposed to invent it.
This is why Heinrich separates a language pack from a mind pack. The system should be fluent without allowing fluency to masquerade as truth.
The code pack
The CODE pack is smaller today, but the boundary is still important. Code intelligence is not the same as general conversation. It needs its own materials, its own verification path, and its own relationship to local files, tests, tools, and edits.
Putting CODE beside COEUS and Mercury makes the future product direction clear. Heinrich is not only a question-answering system. It is a local intelligence body that can eventually reason, speak, build, inspect, and act through separate governed capabilities.
Those capabilities should share a product surface. They should not collapse into one unstructured model.
Why local changes the contract
Local-first intelligence changes the user's contract with the product.
It means the product is not only a conversation with a remote vendor. It means the system can be inspected as software. It has files. It has manifests. It has hashes. It has a runtime boundary. It has a machine-local service. It has a packaging story that can be tested without asking a cloud provider what happened behind the curtain.
Local does not automatically mean private, honest, or safe. Bad local software can still be bad software. But local makes a different kind of accountability possible. It lets the product own its runtime instead of renting the center of its mind.
That is the direction Heinrich is built around. The intelligence has to fit on the machine because the user should not need to send their work somewhere else for the system to exist.
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