Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

Fri, 23 Oct 2026 17:48:48 +0000

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

I built a meaning-learning engine that works without LLMs, embeddings, or
translation tables. Everything is stored as 2-bit ternary values {-1, 0, +1}.
It learns meaning purely from word co-occurrence in plain text.

What makes it different

No hard-coded linguistic knowledge. No stoplists, POS tags, tokenizer,
fixed vocabulary, or translation tables. All linguistic structure emerges
from training data.

Language-independent. Tested with English + Turkish. Same mechanism
works for any language with letter-based writing.

Ternary representation. {-1, 0, +1} — inhibition, unknown, excitation.
0 means "I don't know" — a first-class answer, not a failure.

Single decision rule. All thresholds come from each word's own
distribution. No hyperparameter tuning. (We call it "golden ratio freeze"
— referring to structural convergence, not φ = 1.618.)

Emergent morphology. After EN+TR dictionary training: 247 suffixes and
38 prefixes discovered automatically with zero linguistic rules.

Cross-language bridge. Without being told "water = su," the brain
forms bridges between equivalent concepts across languages. After 65 books:
average Jaccard 0.47, cosine 0.61 across 10 EN-TR word pairs.

How it works

Start with an empty brain
Train with monolingual dictionaries (word → definition)
Optionally add books/articles for richer meaning
Query: /compare water su, /map fire, /senses storm

The brain builds a sparse graph of word relationships. Multi-meaning words
split into separate sense layers automatically. Meaning groups emerge from
community detection on the neighbor graph.

Architecture

Layer	What it does
Concept neurons	Each word is a neuron with sparse ternary signature
Sentence neurons	Sentences become neurons linking words
Synapse graph	PMI-weighted co-occurrence connections
Sense layers	Dynamic multi-meaning, born from data
Topic groups	Community detection on neighbor graphs

Results (65 books trained)

Metric	Value
Concepts	288,407
Sentences	1,234,706
Synapses	102.7M
RAM	~1.3 GB

Cross-Language Bridge Examples

English	Turkish	Jaccard	Cosine
water	su	0.46	0.61
fire	ateş	0.35	0.57
king	kral	0.46	0.56
sea	deniz	0.49	0.60
moon	ay	0.43	0.67

What this is NOT

Not an LLM — no attention, no transformer, no text generation
Not open source — binary-only experimental release
Not a pretrained model — you train from scratch with your own data
Not AGI — no claims of consciousness or general intelligence

Try it yourself

git clone https://github.com/arifkurnaz/ternary-semantic-brain-demo
cd ternary-semantic-brain-demo
chmod +x scripts/linux/*.sh
./scripts/linux/02_train.sh --dict

Linux binary included. Windows via WSL2.
Full paper and architecture docs in the repo.

Local-First File Organization: Why On-Device Semantics Beat Filename Search

Wed, 21 Oct 2026 09:53:43 +0000

Most file-search advice is still stuck in the 1990s mental model: name your files well, put them in the right folder, and your future self will thank you. That model quietly assumes two things that are no longer true — that you have the time to name things well, and that the volume you're dealing with is small enough for a human index to hold.

Neither assumption survives contact with a modern workstation. This post is a principles-level look at why local-first, content-aware organization is a sound architecture, what "semantic" search actually buys you over filename search, why on-device processing is a privacy and reliability win, and why the long-term maintenance cost is the number most people forget to count.

I'm not going to pitch a specific implementation. The principles hold regardless of which tool you reach for.

The scale problem is real, not rhetorical

Let's ground this in numbers, because the architecture follows from them.

IDC estimates global data reached roughly 150–180 zettabytes in 2024 and could approach 394 zettabytes by 2028. The striking part isn't the size — it's the shape: 80–90% of that volume is unstructured, meaning documents, images, audio, and email that don't fit into neat database fields. Your personal file pile is a microscopic slice of this, but it obeys the same law. The pile grows faster than any mental or manual index you can maintain, so the index eventually breaks.

The human cost shows up in survey data too. Smallpdf found knowledge workers spend about 4.5 hours per week looking for files they'd already seen; in finance that's 6.1 hours. People keep an average of 8.5 browser tabs open — a decent proxy for "I sort of remember this exists but I can't place it." And roughly 28% feel overwhelmed by digital clutter weekly; 47% delay real tasks because sorting feels like too much; among Gen Z that last figure passes 59%.

That last cluster matters for engineers specifically: we tell ourselves we're systematic, but the data says the friction is near-universal. The question isn't "am I disciplined enough." It's "what architecture survives undisciplined reality?"

Filename search vs. semantic search

The oldest search primitive is the filename match. You type a string, the system matches strings. It's fast, it's deterministic, and it fails the moment your memory of the file doesn't align with the string you gave it.

Semantic search is the alternative. Instead of matching characters, it matches meaning. You describe the content — "the email about the supplier breach" — and the system retrieves by sense, even if the filename says re_2.pdf. This isn't magic; it's the difference between a hash lookup and a vector similarity comparison over an embedding of the file's content.

A few properties follow directly:

Robustness to bad naming. Filename search punishes past-you for panicking. Semantic search doesn't care what you called it.
Query by intent, not keyword. You often remember what a file was about long after you've forgotten its title. Meaning-based retrieval exploits exactly that.
Cross-type recall. A contract, a screenshot of a chat, and a voice memo can all be "about" the same project. Content awareness can surface all three; a filename matcher sees three unrelated strings.

The trade-off is real and worth stating: semantic retrieval is heavier at index time (you have to read and represent content), and it can return plausible-but-wrong results if the model is weak. That's why the honest engineering answer is usually a hybrid — full-text plus semantic, with the user able to fall back to exact matching. Don't trust a single primitive to do everything.

It's worth being precise about why semantic search is heavier, because the cost shape matters for local-first design. To represent content by meaning you typically embed it — pass the text (or a derived representation) through a model that produces a fixed-length vector, then store and compare those vectors. That indexing pass costs CPU and disk, and on a large corpus it's not free. The engineering question becomes: when do you index, how often do you re-index, and what do you do with files whose format you can't parse? A reasonable local design indexes lazily and incrementally — only new or changed files get represented, and the index lives beside the data rather than in a remote store. That keeps the steady-state cost low even as the pile grows, which is exactly the property you want when the whole premise is "the pile always grows."

Why local-first is an architecture, not a vibe

"Local-first" gets used loosely. Concretely, it means the primary processing and storage happen on your device, and the network is optional, not load-bearing.

For file organization, local-first has three concrete payoffs:

1. Privacy by construction. If classification and search run on-device, your documents never leave your network. That's not a nice-to-have for contracts, medical records, or internal material — it's the whole point. Cloud-index approaches require shipping content (or at least representations of it) to a remote service, which expands your attack surface and your compliance surface. On-device processing shrinks both.

2. Availability and latency. A local index works offline. Change devices, lose sync, or have a service go down and a cloud index goes blind; a local one doesn't. For someone whose work pauses the moment search fails, that reliability is the feature.

3. No lock-in drift. When your organizing lives in a third-party service's schema, you're coupled to their roadmap. Local processing keeps the data in a form you control. You can export, switch tools, or audit what happened.

The counter-argument is legitimate: local-first pushes compute and storage costs onto the user's machine, and cross-device consistency has to be solved deliberately rather than handed to a server. That's a real design cost. But for file organization specifically, the data is already on the device — you're not moving it anywhere to process it locally, so the local-first path is often the lower-friction one.

The maintenance cost nobody budgets

This is the part I think gets under-discussed. People compare tools on features and forget to compare them on half-life.

A rule-based organizer locks you into the taxonomy you set at hour zero. Every new file must conform to old rules. The moment your work shifts — new client type, new document kind, new project shape — the rigid system starts fighting you, and reshaping it is rework you didn't plan for.

A content-aware organizer judges each file at the moment it's processed, using the file's actual contents. The system moves with the files rather than holding them to a frozen rulebook. For anyone whose file types vary and whose direction shifts, that's where the long-term savings live — not in the demo, but in month nine when you didn't have to rewrite your taxonomy.

This is also why "trial before buy" matters more than it sounds for tools in this category. A file organizer is a long-haul dependency. You can't judge its maintenance behavior from a screenshot. You have to run it on your actual mess for a couple of weeks and see whether the system still helps you after the novelty wears off. The local organizer I keep coming back to is MagiFiler — search the name and you'll find it, then try it on your own pile before committing.

A framework for evaluating any file organizer

If you're comparing options, resist the feature-checklist trap. Check dimensions instead:

Dimension	What to verify	Why it matters
Organizing basis	Filename, manual tags, or content understanding?	Only content understanding survives inconsistent naming.
Retrieval method	Exact match, full-text, semantic, or hybrid?	Hybrid covers both precise and fuzzy queries.
Data residency	On-device or cloud-indexed?	Sensitive docs shouldn't leave your network.
Offline behavior	Does it work without a server?	Availability when sync lapses is the real test.
Long-term maintenance	Do you redesign rules periodically?	A frozen taxonomy becomes a tax over time.
Fit for volume	Built for tens, hundreds, or tens of thousands?	Match the tool to your actual scale.
Trial clarity	Can you test before paying?	Maintenance behavior only shows up in use.

None of those rows ask "is it the most powerful." They ask "will it still be helping me in a year, or will I be maintaining the tool instead of my files?"

Where AI organizing fits — and where it doesn't

Honesty about boundaries is part of good engineering. Content-aware organization is not a universal replacement for manual tidying.

If your total file count is tiny and you already have a naming habit that works, manual organization is lighter — don't add a system to solve a problem you don't have.
The pain shows up at high volume, files scattered across locations, and no one assigned to maintain order. That's the environment where automatic, content-based organization earns its place.
Treat it as a fire crew, not a daily nanny. The goal is to collapse the search-and-reshelve cost, not to achieve aesthetically perfect folders.

A useful mental model: the tool should reduce the cost of finding, not impose a cost of organizing. If adopting it means you spend more time managing the organizer than you used to spend finding files, the architecture has failed you, and you should reconsider.

Practical adoption notes

If you decide to go local-first and content-aware, a few low-risk ways to start:

Point it at your worst folder first, not your whole drive. Prove the value on the disaster zone before scaling.
Review, don't pre-design. Let the system propose organization from content, then correct it. You'll shape the behavior faster than by writing rules up front.
Use semantic search for the fuzzy queries and exact search for the precise ones. Keep both in your toolkit.
Check the privacy posture explicitly. If a tool can't clearly tell you your files stay on-device, that's a signal, not a detail.
Give it two weeks. Maintenance behavior — the thing that actually matters — only reveals itself in sustained use.

A note on cross-device consistency

Local-first has one awkward corner: if processing is on-device, how do multiple machines stay coherent? The naive answer — sync the whole drive to a cloud — reintroduces the privacy and availability costs we were trying to avoid. The better-shaped answer keeps the index and the organization metadata as portable local artifacts that can be synced through whatever encrypted channel you already trust, while the file contents stay put on each machine. That way "I organized this at work, can't see it at home" stops being a problem without shipping your documents to a third party. It's a harder design than just centralizing everything, but it's the difference between local-first as a principle and local-first as a slogan. If you're evaluating a tool, asking how it handles the second and third device is a fast way to tell which camp it's in.

The bottom line

Filename search assumes a tidy world that doesn't exist. The volume of unstructured data is growing faster than any human index can track, and the survey data on time lost is not flattering to anyone. The sound architecture responds by moving organization onto the device, making it content-aware rather than name-dependent, and designing for low maintenance over years rather than impressive demos.

You don't need to become a more disciplined person to have a legible file system. You need a system whose premise survives your own inconsistency — one that reads what's inside, keeps your data where it belongs, and doesn't ask you to redesign it every time your work changes shape.

That's the whole argument for local-first, semantic, on-device organization. The rest is just picking which implementation respects those principles.

If you take one thing from this: stop measuring file tools by their demo. Measure them by what happens in month nine, on a machine that's gone offline, with a folder you named badly three years ago. The architecture that still helps you there is the one worth building on or buying into. Everything else is decoration.

Coder Legion - Recent posts tagged semantics

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine