Knowledge bits

When Adsum works on your firmware it does not rely on the model’s general training alone. It loads Knowledge bits: small, curated modules of hardware expertise, written by named engineers and maintained against a specific SDK version. You see this happen. When a bit loads, a credit line appears in the conversation, and clicking it opens the bit’s provenance: That line, and the card it opens, are the point of this page.

​

What a Knowledge bit is

Curated understanding, written for a model to read: how a chip family behaves, what a symptom usually means, which register matters. Reading an nRF fault trace is one; ESP-IDF Wi-Fi failure patterns is another. It is the teaching half of the expertise layer. The running half is a Tool bit, and architecture sets the two side by side. A bit is scoped deliberately narrowly: one chip family, one protocol stack, one debug category. At session start the agent works out what your project is and loads only what the task needs, rather than carrying everything at once. That is why a session’s credit lines tell you something real: they are the expertise that was actually applied to your problem.

​

What its tier tells you

Every bit carries a tier, and it is worth reading rather than assuming: Newer knowledge starts as draft while it is being proven and graduates once it has been. We publish it rather than hold it, and label it, so you can see how far each piece has been proven.

​

Why we show you the author

The model is a commodity: anyone can rent the same one. What makes Adsum useful on a real board is knowledge that came out of engineers’ heads and off that hardware. So we credit it. Every bit names the person who curated it, and that name is in the bit itself, not in a marketing page. If a session used three bits from two engineers, the session header says so. This matters in both directions:

• You should know whose expertise you are relying on. “The AI said so” is not a provenance. “Omar Morceli curated this, and Adsum Networks maintains it against NCS 3.2.1” is.
• The people who wrote it should be credited by name. Curated expertise is authored work. Bylines are how authored work gets treated as authored work.

​

What the credit line tells you

Click a bit’s title in the conversation to open its provenance:

• Curated by: the engineer whose domain knowledge the bit captures. Where a bit is house-maintained with no individual curator, it says Adsum authoring team rather than naming someone who did not write it.
• Maintained by: who keeps it current as SDKs move. Firmware knowledge rots: an NCS or ESP-IDF release can invalidate an answer that was correct last quarter, so a bit with nobody maintaining it is a liability, not an asset.
• Rights: who holds the intellectual property in the bit, and the year. For everything Adsum publishes this is Adsum Networks; the byline above it is unaffected.
• Version: bits are versioned and updated independently of the extension.

The session header collects every bit used, so you can see the whole roster without scrolling back.

​

Who owns a bit

A credit line names the engineer who wrote a bit. It does not say who owns it, so this page does.

• Authors keep the byline. Every bit names the engineers who curated it, in the product, in every session that loads it. Credit is permanent and cumulative, and survives a bit changing hands.
• Adsum Networks holds the rights. Knowledge bits and Tool bits published by Adsum are proprietary works of Adsum Networks; intellectual property in contributed work vests in Adsum Networks. © 2026 Adsum Networks. All rights reserved.
• Independently authored bits are a different case. An engineer who authors and maintains a bit entirely on their own may hold defined rights in it. Those terms are agreed in writing, with the author, before the bit is published — and the bit itself records who holds them, which is what the Rights row in the provenance card reads.

​

Attribution is credit, not a verdict

This is the part worth being precise about. Attribution tells you who built the expertise Adsum applied and how it is maintained. It is not a statement about your device, your build, or your compliance status. Concretely:

• A credited bit does not mean your firmware is secure, correct, or compliant.
• Adsum describes evidence and tells you what to verify. It does not certify your device, because no automated tool can, and any tool claiming otherwise is selling you a false assurance.
• Where Adsum reports on your build (CVE findings, an SBOM, a CRA readiness check), it states what it observed and what it could not determine. Read those outputs as evidence to act on, not as a pass mark. See CRA readiness and Limitations.

The product is built to the same rule: a credit line can never read as a verdict on your device.

​

Where bits come from

Some ship inside the extension; others are served from Adsum’s registry and resolved the first time a task needs one, which is how a bit improves without a new extension release. Either way the behaviour is the same from your side: the agent loads what the task needs, and you see who wrote it.