Knowledge Overview
Notes, invariants, and skills — the context you give Cygent once so every audit and every fix is sharper.
Overview
Out of the box, Cygent reasons about your code from the code alone. Knowledge is how you give it the context that isn't in the code: the trust assumptions, the protocol-specific properties that must always hold, and the coding conventions your team expects. You set this up once, and it carries forward into every audit and every fix.
Knowledge comes in three types, and they do different jobs at different points in the lifecycle:
Notes
Free-form context about your protocol's design and trust model. Steers how the auditor reasons. Used at audit time.
Invariants
Falsifiable properties that must always hold. The auditor actively tries to break each one and reports a verdict. Used at audit time.
Skills
Reusable instruction packs for the coding agent. Shape how Cygent Code writes and fixes code. Not used during audits.
Where to find it
Knowledge lives in its own tab on the instance dashboard, with a sub-tab for each type — Notes, Invariants, and Coding Skills — plus a Recommendations banner at the top.
The mental model
The single most important thing to understand:
| Type | Consumed by | When it takes effect |
|---|---|---|
| Notes | The auditor (CARA) | Injected at the start of each audit |
| Invariants | The auditor (CARA) | Injected at the start of each audit, verdict reported at the end |
| Skills | The coding agent (Cygent Code) | Loaded at the start of each coding session |
Notes and invariants are read at audit start. Adding them after you kick off an audit does nothing for that run — they apply to the next one. Set them up before you press Run. See best practices below.
Scoping: global vs. project
Every piece of knowledge is scoped one of two ways:
| Scope | Applies to | Use it for |
|---|---|---|
| Global | Every project in the instance | Team-wide standards: "we never use tx.origin", a house style skill, a trust assumption that holds org-wide |
| Project | One repository | Context specific to one protocol: "this vault only supports WETH and USDC", an invariant about this token |
Global and project knowledge stack. When Cygent audits owner/repo, it sees every global note and invariant plus every one scoped to owner/repo. Skills stack the same way in coding sessions — a project-scoped skill with the same name as a global one overrides it for that repo.
Recommendations
You don't have to write everything by hand. Cygent watches signals — audit findings, your chat conversations about the protocol, the build tools it detects in your repo — and proposes knowledge entries it thinks are worth adding. They show up in the Recommendations banner.
Every recommendation is a suggestion, never an automatic write:
- Accept opens the relevant form prefilled with the proposed content, so you review and edit before it's saved.
- Dismiss removes it and stops Cygent from proposing the same thing again.
There's no risk of Cygent silently adding a bad note — a human reviews every entry before it lands. See Notes for how the loop works in practice.
Best practices
Three habits separate teams who get real leverage from Knowledge from teams who set it up once and forget it.
Set notes and invariants *before* you audit
They're injected at audit start. The workflow is: add your context, then run the audit. Treat the minutes before a first audit on a new protocol as setup time — write down the trust model and the must-hold properties while they're fresh in your head.
Refine invariants between runs
An invariant that comes back Inconclusive is telling you it was ambiguous or unreachable. Tighten the wording and re-run. Invariants are a feedback loop, not a one-shot.
Set up and fine-tune skills before you rely on them
A skill is only as good as its instructions. Write it, run it against a real coding task, read the resulting PR, and edit the skill until the output is what you'd accept from a teammate. Don't add a skill and assume it works — prove it on a low-stakes task first.