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.

​

Knowledge bits and Tool bits

Two kinds, shorthand K-bit and T-bit: 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 the bits 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.

​

Why we show you the author

The model is a commodity — anyone can rent the same one. What makes Adsum useful on a Nordic or Espressif board is knowledge that came out of engineers’ heads and off real 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.
• 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.

​

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 — 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.

We hold ourselves to this in the product: the interface is checked at build time so it cannot render language that turns provenance into a verdict.

​

Where bits come from

Some bits ship inside the extension. Others are served from Adsum’s knowledge registry and resolved on demand the first time a task needs one — which is how a bit can be updated without shipping a new extension version. Either way the behaviour is the same from your side: the agent loads what the task needs, and you see who wrote it.