DEV Community: Arif Kurnaz

Attestkeep 1.0 is out, and three readers changed it before it shipped

Arif Kurnaz — Sun, 06 Sep 2026 10:52:38 +0000

Six days ago I posted SOC 2, CRA, NIS2: they all ask your cluster the same five questions. I expected a few reactions. What I got was three people reading the mechanism instead of the claims, and two of them found a hole that mattered.

Today the tool behind that post reached 1.0. Most of what changed between the post and the release came out of that thread, and it would be strange to write a release post that pretends otherwise.

What it is, in one paragraph

Attestkeep is a validating admission webhook for Kubernetes with a scanner behind it. Every pod CREATE and UPDATE outside a short list of bypass namespaces is reviewed against a policy: the :latest tag, a registry allow-list, digest pinning, vulnerability thresholds from the last scan, cosign signatures and attestations, and fifteen workload hardening checks (privileged containers, hostPath mounts and their relatives). Every decision, allowed or refused, is written to a ledger under the content hash of the policy that made it. When a period has gone by, you pick a framework and the ledger becomes a signed evidence package with citations, statuses and named gaps. That last part is what the previous post was about. This one is about what shipped.

What the comments changed

Vinh Nguyen pointed out that a ledger of admission decisions is evidence about boundary crossings, not about the population. Whatever entered while the webhook was down, or before it was installed, is still running and has no row. So the control grew a second half. An hourly sweep reads every running container's observed imageID, not the spec's image reference, which under a mutable tag still matches its original admission event while the bytes underneath have changed, and reconciles the digest against the ledger. A digest with no admission behind it lands in the evidence package as its own population section. The policy decides what a finding does: recorded, announced, or the pod is stopped so its controller recreates it through the webhook, onto the ledger this time.

Then he read the mechanism again and found the destructive case. A pod applied by hand has no controller, so stopping it closes the finding by deleting its subject: no denial, no admission, an absence where an unverified workload used to be. Static pods fail from the other end, because the kubelet rebuilds the mirror without going near admission, so enforcement loops without ever producing an event. Both are now reported and left running, in the same bucket as side-loaded images, marked unmanaged, with one line per sweep saying the sweep found something only a person can decide. That was 0.3.3 and it is in 1.0.

Tobias asked whether ran-and-found-nothing is recorded as evidence, or only findings. Admission is the easy half: every review writes a row, including "allowed, nothing wrong". The quiet week is the hard half, and the answer is that the operator keeps re-verifying its own webhook endpoint against the CA bundle it published to the API server, records any window in which that check fails, and prints those windows in the evidence package as outages against the period. What I conceded then still holds today: the absence alert, an absent() over the attestkeep_* series, is a few lines in your Prometheus and not a toggle in ours.

Kane Lim listed what a decision record should reference. The row today carries the namespace, the pod, the image reference and its digest, the verdict and its reason, whether the scan result was cached, the policy name and the policy's content hash, and whether break-glass was active. The workload's service account is still not on it. That is a fair gap and it is still open.

What 1.0 means

1.0.0 is the 0.3.6 line declared stable. Nothing about an installed policy, licence or evidence document changes on upgrade.

Since the first post the ledger became tamper-evident. Every decision is content-hashed when it is written, and the operator periodically seals the ledger with signed checkpoints: each carries the Merkle root of the records in its range and chains to the previous checkpoint's hash. The signing key is generated into a Kubernetes Secret and never stored in PostgreSQL, so rewriting ledger rows and re-signing the seals require two different accesses. The evidence package states whether the record set verifies and names the exact records and seals that do not. Where the guarantees end is written down on the evidence trust model page, including the part where generated_at is still an assertion by the signer and not a trusted clock.

Two decisions in 1.0 itself are about posture rather than features, so they get a paragraph each.

admissionTiming. A digest nobody has scanned has no result yet. Scanning takes minutes and the API server waits seconds, so the gate never scans inline; the scanner fills a cache in the background and admission reads the cache. The policy chooses what happens to the unknown: AllowAndScan, the default, admits it, queues the scan and decides on every later admission of that digest; DenyUntilScanned refuses it with "a scan has been queued, retry shortly" until the report exists. In 0.3.x a Community policy that set the second one was silently treated as the first. From 1.0 it is honoured in every edition, because the rule is now written down: policy behaviour is never gated by licence, only capacity is.

failurePolicy. The webhook ships with Ignore. While it is unreachable, pods are admitted unreviewed. The console used to paint that amber, which nagged everyone towards a fail-closed posture they had not chosen. Now it explains the trade: the window is recorded for your evidence, the hourly sweep reviews what came in, and webhook.failurePolicy: Fail is one Helm value away if you want a gate that holds while the operator is down. Neither value is universally right. The point is that the choice is yours and the consequence is on the record either way.

And one thing that was plainly a bug. Every operator replica used to run the daily licence check two minutes after its own start, so a rolling restart or two spent the day's allowance and the pods logged a refusal they could not act on. It is now one call a day per cluster, however many pods run and however often they restart; the check time is kept in the operator's database and shared by all replicas. Enforcement never depended on it: the certificate a cluster holds keeps working for its thirty-day term.

What a key buys, and what it does not

Every security feature is in the free Community edition: scanning, signature and attestation verification, admission enforcement, the sweep, the sealed ledger, evidence packages, deny-until-scanned, fail-closed. A community edition with the security removed would deserve to lose to the free tools. What a paid key buys is capacity, and single sign-on.

	Community	Team	Business	Enterprise
Clusters per key	1	1	3	5
Compliance frameworks	1	1	3	all eight
Image names a month	15	100	200	sized to your estate
Single sign-on (OIDC)	no	yes	yes	yes
Price	free, forever	$480 a month, or $4,800 a year	$1,440 a month, or $14,400 a year	$3,000 a month, or $30,000 a year

Prices exclude VAT. Checkout runs on Polar as merchant of record, so the card never reaches our servers. There is no time-limited trial because there is no need for one: Community never expires, and the question a trial usually answers, does this work on my cluster, is one you can answer on your own cluster for as long as you like. Any charge can be refunded within 14 days, for any reason.

For the launch, the code LAUNCH20 takes 20% off the first invoice until 6 October 2026: a month if you pay monthly, the whole first year if you pay yearly.

What leaves your cluster: once a day, a licence identifier, a hash of the kube-system namespace UID, and the operator version. Nothing about your images. The scanner reads your registry, the operator writes to your PostgreSQL, and no agent registers with us.

Try it, then watch it refuse something

One Helm command. The chart pulls from the registry, there is no repository to add.

helm install attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --create-namespace \
  --set clusterName=trial \
  --wait

kubectl -n attestkeep port-forward svc/attestkeep 8080:8080

The console asks for a licence key on first run; the free one comes from an account at attestkeep.com and never expires. Then create the owner account and you land on the overview.

An admission webhook that is silently not running looks exactly like a compliant cluster, so the first thing to do after installing any gate is to watch it refuse something. With the default policy the smallest violation is the :latest tag:

$ kubectl run enforcement-check --image=nginx:latest
Error from server: admission webhook "image-security.attestkeep.com" denied the request:
image security policy: nginx:latest: the :latest tag is blocked by policy

$ kubectl get pod enforcement-check
Error from server (NotFound): pods "enforcement-check" not found

The error comes from Error from server, meaning the deny happened inside the API server's admission chain and not in an agent that might have been asleep. If the pod was created instead, check in order: a bypassed namespace, a policy in audit mode, a webhook that is failing open, an installation that was never activated.

Kubernetes 1.27 or later, amd64 and arm64. Every release image is signed twice on the same digest: keyless through GitHub's OIDC, which proves the digest was built by the release workflow on that tag, and keyed against cosign.pub at docs.attestkeep.com/cosign.pub, which verifies with nothing beyond your registry and exists for air-gapped clusters. Verify the digest, not the tag. It is the same argument the product makes to your own cluster.

What it still does not do

Being straight about the limits, again, since the whole pitch is honest gaps.

The compliance mappings have not been through legal or audit review. They are a careful reading of the published texts, with citations included so a professional can check the work rather than trust it.
Nothing binds a report to a trusted clock.
It answers admission time and rescan time. It does not watch behaviour at runtime, and it does not do eBPF. If a container starts doing something odd at three in the morning, that is somebody else's product.
One installation is one cluster's view. Five clusters on Enterprise are five consoles. A fleet view is on the roadmap without a date attached, because I would rather say that than name a release I might miss.
It is self-hosted and closed source. Every claim above is checkable from inside your cluster, and the issue tracker is public, but you cannot read the code.

If you read the last post and left a comment, some of this is yours. If you install it and it refuses something it should not have, or admits something it should not have, that is the comment I want.

I build Attestkeep, a Kubernetes admission controller with compliance evidence built in. The release notes for 1.0.0 and 1.0.1 are on the releases page.

SOC 2, CRA, NIS2: they all ask your cluster the same five questions

Arif Kurnaz — Mon, 31 Aug 2026 12:52:22 +0000

In eleven days, on 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying to anyone who puts a product with digital elements on the European market. Not the full regulation. Just the part where, if you find out an actively exploited vulnerability is in your product, you have 24 hours to tell ENISA about it.

I have watched a lot of engineering teams meet this class of deadline for the first time. It usually goes the same way. Somebody in sales gets a security questionnaire. Somebody in engineering gets forwarded the questionnaire. Three weeks later there is a shared folder called evidence-final-v3 with 200 screenshots in it, and nobody can tell you which screenshot answers which question.

I have spent the last several months building a tool whose entire job is that folder, so I read the instruments properly. This is what I found out. It is written for engineers, not for a compliance team, and I try to be specific about what the text says rather than what a vendor blog says it says.

Where SOC 2 came from, and why that still shapes it

SOC 2 exists because of a misuse.

In 1992 the AICPA published SAS 70, an auditing standard for service organisations. Its purpose was narrow: if you outsourced your payroll, your auditor needed some assurance that your payroll provider's internal controls did not corrupt your financial statements. It was an accounting instrument, for accountants, about financial reporting.

Then the industry outsourced everything else. By the mid-2000s companies were sending their customer data to service providers, and they wanted assurance about that, not about financial reporting. There was nothing designed for it, so they asked for the thing that existed. Vendors started waving SAS 70 reports around as proof they were secure. They were not proof of that. SAS 70 had no defined control set at all: the service organisation wrote its own control objectives, and the auditor tested against whatever had been written. Two SAS 70 reports could have nothing in common.

In 2010 the AICPA split the thing in half. Financial reporting controls stayed, renamed SOC 1 under SSAE 16 (SSAE 18 since 2017). The security question got its own report: SOC 2, with an actual defined set of criteria behind it.

That history is worth carrying, because SOC 2 still has SAS 70's shape in one important respect. It defines criteria, not controls. It tells you what has to be true. It does not tell you how. More on that in a moment, because it is the single most common misunderstanding.

Type I and Type II

Two report types, and the difference is most of the value.

Type I is a point in time. An auditor looks at your controls on one date and gives an opinion on whether they are suitably designed. It answers: do you have the right things in place?

Type II covers a period, typically 3 to 12 months, with 6 being the usual choice for a first report. The auditor gives an opinion on whether the controls were suitably designed and operated effectively throughout that period.

A Type I says you built the fence. A Type II says the fence was standing every day for six months.

Almost every buyer who asks for SOC 2 means Type II, or will mean it at renewal. And it matters enormously to how you should think about evidence, because "operated effectively throughout the period" is not a thing you can produce at the end. The auditor samples across the whole window. If your quarterly access review was supposed to run four times and it ran once, in the week before fieldwork, that is an exception in your report and everybody reading it can see it.

That property, that the evidence must have existed continuously rather than being assembled afterwards, is the one I would burn into a wall. It is what makes screenshot folders a bad answer.

The five criteria, and the four you probably do not need

SOC 2 is built on the Trust Services Criteria (AICPA TSP section 100, 2017, revised 2022). Five categories:

Security — the Common Criteria, CC1 to CC9. Mandatory. Every SOC 2 includes it.
Availability — is the system up when you said it would be
Confidentiality — is information designated confidential protected
Processing Integrity — is processing complete, valid, accurate, timely, authorised
Privacy — personal information handled per your notice

Only Security is required. You choose the rest, and you should choose as few as you can defend, because each one is more scope, more testing, more cost. Most infrastructure and SaaS companies do Security, or Security plus Availability. Add Confidentiality if your contracts talk about it. Processing Integrity is genuinely rare and mostly belongs to payments and payroll.

Inside the Common Criteria, the ones an engineer actually touches:

Criterion	Roughly
CC1–CC3	Governance, communication, risk assessment. Mostly organisational.
CC4	Monitoring: do you check your own controls are present and functioning?
CC5	Control activities.
CC6	Logical and physical access. Who can reach what, and how you keep the outside out.
CC7	System operations. Detecting vulnerabilities and configuration drift, spotting anomalies, handling incidents.
CC8	Change management. Nothing untested or unauthorised reaches production.
CC9	Risk mitigation, including vendor and third-party risk.

If you run containers on Kubernetes, most of your technical evidence lands in CC6, CC7 and CC8. CC6.8 is the one people miss: "the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software." That is your image supply chain, stated in 2017 language.

SOC 2 does not tell you what to do

This is the part that catches teams out.

There is no SOC 2 control list. There is no "you must scan images" clause. The criteria are outcome statements, and you define the controls that meet them, and then the auditor tests the controls you defined. You write a control saying "all container images are scanned before deployment and images with critical vulnerabilities are blocked", and now you are on the hook to prove that happened every day of the period.

This cuts both ways. The freedom is real: you are not forced into somebody else's architecture. The trap is also real, and it is that a weak control, written vaguely, passes the audit while protecting nothing. "We use industry standard scanning tools" is a sentence that can be true while your cluster runs whatever anybody pushes.

The auditor is not there to tell you the control is weak. They are there to test whether it operated as described.

The other instruments, and their clocks

SOC 2 is voluntary and market-driven; you do it because a customer asked. Most of what arrived after it is not voluntary. Here is the landscape as it stands at the end of August 2026.

EU Cyber Resilience Act — Regulation (EU) 2024/2847. Applies to products with digital elements sold in the EU, which for most of us means the software itself. Three dates: conformity assessment bodies from 11 June 2026 (passed), vulnerability and incident reporting from 11 September 2026 (eleven days away), and the substantive obligations, including technical documentation and the SBOM requirement, from 11 December 2027. Annex I Part II point 1 is the SBOM clause: components documented in a commonly used machine-readable format, covering at least the top-level dependencies. You do not have to publish it. You do have to have it and hand it over when a market surveillance authority asks.

NIS2 — Directive (EU) 2022/2555. Applies to entities in essential and important sectors, and reaches software vendors indirectly, forcefully, through Article 21(2), which names supply chain security and requires covered entities to consider the security practices of their direct suppliers. That is why NIS2-derived questionnaires arrive at companies that are not themselves in scope. Being a supplier to somebody in scope is enough.

DORA — Regulation (EU) 2022/2554, in force since 17 January 2025 for EU financial entities and the ICT providers serving them. Chapter V Article 28 is the third-party risk chapter, and it has teeth in a way NIS2 does not, including audit rights written into contracts.

ISO/IEC 27001:2022 — certification rather than a report. Buyers outside the US often prefer it. Annex A control 8.8 (technical vulnerabilities), 8.25 through 8.31 (secure development, separation of environments) are the ones your pipeline touches.

NIST — SP 800-190 for container security specifically, SP 800-218 (SSDF) for secure development, SP 800-53 Rev. 5 for the full federal control catalogue. Not law unless you sell to the US government, but the language is precise and much of the rest of the world quotes it.

GDPR Article 32 — security of processing. Short, general, and still the clause that turns a container escape into a regulatory event if personal data was on the other side of it.

They are all asking the same five questions

Here is the thing I did not expect when I started reading these side by side. The instruments are written by different bodies, in different decades, for different legal systems, and underneath they converge hard.

CRA Annex I Part I (3)(g), on availability and resilience of essential functions, and SOC 2 A1.2 both turn on outages and what the system does when a component fails. CRA (3)(c) on access control and CC6.1 both turn on hardening and federated access. CRA (3)(k) on recording and monitoring activity and CC7.2 both turn on the audit trail. DORA Article 9's protection and prevention requirements land in the same place as CC6.8.

For a workload running in a cluster, strip away the citations and every one of them is asking:

What is running? An inventory. Not "what did we deploy", what is actually admitted right now.
Where did it come from? Provenance. A signature, an identifiable registry, a build you can point at.
What is wrong with it? Known vulnerabilities, against a database that was current at the time of the check.
Who allowed the exceptions? Because there are always exceptions. An unrecorded exception is indistinguishable from a control failure.
Can you prove all of the above for a period you did not choose in advance?

Question 5 is the one tools get wrong.

What good evidence looks like

Most compliance tooling is built to produce a dashboard. A dashboard tells you the state now. An auditor is not asking about now, they are asking about February.

Working backwards from what a Type II sampling exercise actually needs, evidence has to carry five properties:

A period, stated on the document. Not "generated today", but "covers 1 February to 31 July, and here is what happened in that window."

Provenance of the evidence itself. Who generated it, from which system, at what version. A compliance mapping is an interpretation, and interpretations change as you read a framework more carefully. Evidence that does not record which reading it used cannot be re-examined later.

Integrity. A PDF is a suggestion. Anybody can edit a PDF. If the document that goes to the auditor is not cryptographically bound to the bytes that were generated, then the strongest statement you can make about it is "someone in our company typed this."

Citation, not paraphrase. Every claim should name the clause it answers, quoted close to the instrument's own words. Auditors read the criterion, not your marketing vocabulary. If your report says "we are compliant with CC7.1" without restating what CC7.1 asks, you have made the reader do a lookup, and made yourself impossible to check.

Honest gaps. This is the one I care most about. A container security tool can evidence maybe a third of NIS2 Article 21. The rest is staff training, disclosure policies, reporting to a national CSIRT, business continuity. A report that quietly maps a feature list onto the other two thirds is worse than no report at all, because it tells an organisation a duty is discharged when nobody has done it. Anything that comes back all green is lying to you, and the lie is expensive precisely when it matters.

Why the admission controller is the right place to stand

For the Kubernetes-specific part of this: scanning in CI is necessary and insufficient.

CI scanning proves you scanned an image. It does not prove that only scanned images ran. Those are different claims and the second is the one CC6.8 asks for. Between the pipeline and the cluster there is a gap wide enough to drive a kubectl apply through: a manually applied manifest, a Helm chart from a vendor, a sidecar injected by a mesh, a latest tag that resolved to something different this morning than it did last week.

The admission webhook is the last point where the answer to "may this run" is still no. It is also the only point where a record of the decision is a record of what actually entered the cluster, rather than a record of intent. Every admission review is a dated, attributable event: this digest, this policy, admitted or refused, at this moment. That is the raw material a Type II sample is made of, and it accumulates whether or not anybody remembers to collect it.

That property, evidence that exists because the control ran and not because somebody prepared for an audit, is the whole point.

How we built this into Attestkeep

Attestkeep is a Kubernetes admission controller that scans images, verifies signatures and attestations, and enforces policy at admission. That part is not novel and I would not write a post about it. The part I want to describe is what happens after six months of it running.

You pick a period and a framework. It generates a report against eight of them: SOC 2, EU CRA + NIS2, DORA, NIST SP 800-190, SSDF, SP 800-53 Rev. 5, ISO 27001, and GDPR Article 32. Every requirement in the report carries its citation, the obligation restated close to the instrument's own words, a status, and a note written in the period's own numbers.

There are four statuses, and the fourth is the reason I am writing this section:

met — the control operates and the records show it operating
partial — it operates but something narrows what it proves: a permissive failure policy, audit-only mode, an exemption
gap — squarely within what this thing can enforce, and the records say it is not being enforced
outside_scope — a duty of the organisation, not a property of a cluster. Named rather than omitted, so the reader can see where the document's coverage ends.

Here is an unedited fragment from a real 30-day report generated against a demo cluster:

{
  "id": "CC4.1",
  "citation": "CC4.1",
  "title": "Evaluations to ascertain that controls are present and functioning",
  "asks": "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.",
  "status": "met",
  "note": "the control's operation is measured continuously rather than sampled: 293 reviews, 31 admitted, 262 refused, and 3 windows in which it was not operating",
  "evidence": ["admission", "availability"]
}

and, from the same report, one that did not pass:

{
  "id": "CC6.6",
  "citation": "CC6.6",
  "status": "gap",
  "note": "no registry allow-list is in force, so an image may be pulled from any registry the node can reach",
  "evidence": ["control_statement.allowed_registries"]
}

The summary for that period was 3 met, 6 partial, 2 gap, 2 outside scope. That is a demo cluster with a loose policy, and the report says so. I would rather ship a tool that tells you that in August than one that tells you everything is fine and lets an auditor find it in February.

The evidence field is a pointer into the sections of the same document that carry the underlying numbers, so a reader can check the claim rather than accept the note.

Integrity. The report is signed with Ed25519 into a DSSE envelope carrying an in-toto Statement v1. The signature covers report.json and nothing else. The subject is the report's SHA-256, so the signature binds to the exact bytes, and any copy of those bytes can be checked against it.

What the auditor receives is a zip:

README.txt          what is signed, and three ways to check it
report.json         the evidence. these exact bytes are what is signed
attestation.json    DSSE envelope, in-toto Statement v1
certificate.jwt     the public half of the signing key, signed by us
<id>.pdf            a readable rendering. convenience only, carries no signature
<id>.attestkeep.json  all of the above in one file, for single-file verifiers

The README is always in English, whatever language the console is set to, because an auditor's file gets read in places you cannot predict. It states plainly that if the PDF and report.json ever disagree, report.json is the record and the PDF is wrong. Verification works three ways: a browser page that runs entirely client-side and uploads nothing, a Python script with no dependencies, or cosign if you already have it. The archive is byte-for-byte reproducible: the zip entry timestamps come from the report's own generation time rather than the clock, so two people downloading the same package get the same file.

And the scope statement, which is printed at the top of every SOC 2 report we produce:

It is evidence for an audit, not an audit: only a service auditor issues an opinion, and only the entity defines its own system boundary.

I put that there because I have seen what the alternative does to people. A tool cannot make you compliant. It can make the day the auditor asks a boring one.

What this does not do

Being straight about the limits, since I just spent 400 words demanding honest gaps from everybody else.

The compliance mappings have not been through legal or audit review. They are my careful reading of published texts, with citations included specifically so a professional can check my work rather than trust it. The NIST SP 800-190 citations were corrected once already, when I went back and compared them against the published guidance instead of my notes.

Nothing here binds a report to a trusted clock. generated_at is an assertion by the signer, not proof. If you need trusted timestamping, you need it from somewhere else, and the predicate says so in a comment rather than hiding it.

And the honest scope line applies to me too: one cluster's admission control answers part of SOC 2 and a smaller part of NIS2. It does not answer your access reviews, your onboarding, your incident response drills, or your vendor register.

If you take one thing

Whatever you use, and it does not have to be mine, make the evidence a byproduct of the control operating rather than a project you run before an audit. The frameworks converge on this even where their words differ. SOC 2 Type II wants the whole period. CRA wants technical documentation that was maintained, not assembled. DORA wants an audit right that is meaningful when exercised without notice.

Update (September 2026). Vinh Nguyen pointed out in the comments that questions 1 and 5 come apart exactly where this article admits they might: the admission ledger records honestly when the control was not operating, but nothing in it says what crossed during those windows — or what predates the install, or what walked in under failurePolicy: Ignore. Whatever did is still running long after the window closed, and a ledger of boundary crossings has no row for it.

He was right, so the control grew a second half. A periodic sweep now reads every running container's observed imageID — not the spec's image reference, which under a mutable tag still matches its original admission event while the bytes underneath have changed — and reconciles each digest against the admission ledger. A running digest with no allowed admission event behind it lands in the evidence package as its own population section, right next to the availability section it completes: the document that admitted the two questions come apart now stitches them back together. Policy decides what a finding does — recorded, announced, or the pod is stopped so its controller recreates it through the webhook, onto the ledger this time. The details, including the honest edges (out-of-scope namespaces, side-loaded images with no registry digest, truncated lists that say so), are in the comment thread below.

Evidence you can only produce by preparing for the question is not evidence that the control was working. It is evidence that you can prepare.

I build Attestkeep, a Kubernetes admission controller with compliance evidence built in. It is early. If you have been through a Type II with containers in scope and something above is wrong, I would genuinely like to hear it.

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

Arif Kurnaz — Tue, 07 Jul 2026 17:29:01 +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.