Overview
What components are, the five types, and what earns a place in the library.
The vocabulary of the vault
Components are the shared vocabulary of your vault. Every observation you make about a target becomes a component, and every observation the Nexus Engine reasons about is one. There are five kinds, each answering a different question:
| Type | Question it answers | Example |
|---|---|---|
| Technology | What is it built on or running? | Node.js, Caddy, PostgreSQL |
| Functionality | What does it do for the user? | File upload, password reset |
| Gadget | What additional capability rides along? | GraphQL endpoint, admin panel |
| Vector | What is the specific way in? | SVG upload, SSRF-prone webhook |
| Quirk | What behavior could tip an attack? | Prototype pollution, missing CSRF token |
Technologies and functionalities usually sit directly on an asset. Vectors and quirks are often scoped — observed inside a specific parent component. Scoping is what lets the engine reason precisely instead of broadly, and it is usually the difference between a suggestion worth acting on and one worth ignoring.
What earns a place in the library
The library is not a notes app. Before creating a component, ask: will this be useful on another asset?
- Reusable — it describes a class of things, not one-off trivia about one host.
- Observable — you confirmed it on a target. Speculation belongs in a prompt, not the library.
- Atomic — one idea per component. "Laravel with debug mode and an exposed
/telescope" is three components, not one.
Components that fail this test become noise that pollutes matching for every asset.
Organizing the library
Categories group components by theme and power the engine's structured matching. Tags are lighter labels for slicing the library and attaching conditions in playbooks — a category plus a tag is one of the most precise requirements a playbook can express. See Categories and Tags.
What's next
- Technologies — the most common entry point.
- Scopes and levels — how components nest inside their parents.
- Reactive Checklist and Probes — a component's tests, and how-to-check notes.
- Categories and tags — the library's organizing layers.
- The CAVET Method — why these five types exist.
- Notespaces and endpoints — where observations live once linked.