[{"data":1,"prerenderedAt":624},["ShallowReactive",2],{"docs-navigation":3,"docs-search-files":111,"home-page":520},[4,23,29,57,63,75,81,100],{"title":5,"path":6,"stem":7,"children":8,"page":-1},"Getting Started","\u002Fgetting-started","1.getting-started",[9,11,15,19],{"title":5,"path":6,"stem":10},"1.getting-started\u002Findex",{"title":12,"path":13,"stem":14},"Account and Workspaces","\u002Fgetting-started\u002Faccount-and-workspaces","1.getting-started\u002F1.account-and-workspaces",{"title":16,"path":17,"stem":18},"The Starter Library","\u002Fgetting-started\u002Fstarter-library","1.getting-started\u002F2.starter-library",{"title":20,"path":21,"stem":22},"Your First Suggestions","\u002Fgetting-started\u002Ffirst-suggestions","1.getting-started\u002F3.first-suggestions",{"title":24,"path":25,"stem":26,"children":27},"Platforms, Programs, and Assets","\u002Finventory","2.inventory\u002Findex",[28],{"title":24,"path":25,"stem":26},{"title":30,"path":31,"stem":32,"children":33,"page":-1},"Components","\u002Fcomponents","3.components",[34,37,41,45,49,53],{"title":35,"path":31,"stem":36},"Overview","3.components\u002Findex",{"title":38,"path":39,"stem":40},"Technologies","\u002Fcomponents\u002Ftechnologies","3.components\u002F1.technologies",{"title":42,"path":43,"stem":44},"Functionalities","\u002Fcomponents\u002Ffunctionalities","3.components\u002F2.functionalities",{"title":46,"path":47,"stem":48},"Gadgets","\u002Fcomponents\u002Fgadgets","3.components\u002F3.gadgets",{"title":50,"path":51,"stem":52},"Vectors","\u002Fcomponents\u002Fvectors","3.components\u002F4.vectors",{"title":54,"path":55,"stem":56},"Quirks","\u002Fcomponents\u002Fquirks","3.components\u002F5.quirks",{"title":58,"path":59,"stem":60,"children":61},"Playbooks","\u002Fplaybooks","4.playbooks\u002Findex",[62],{"title":58,"path":59,"stem":60},{"title":64,"path":65,"stem":66,"children":67,"page":-1},"Nexus Engine","\u002Fnexus-engine","5.nexus-engine",[68,71],{"title":69,"path":65,"stem":70},"The Nexus Engine","5.nexus-engine\u002Findex",{"title":72,"path":73,"stem":74},"Checklist and Probes","\u002Fnexus-engine\u002Fchecklist-and-probes","5.nexus-engine\u002F1.checklist-and-probes",{"title":76,"path":77,"stem":78,"children":79},"Notespaces and Endpoints","\u002Fnotespaces","6.notespaces\u002Findex",[80],{"title":76,"path":77,"stem":78},{"title":82,"path":83,"stem":84,"children":85,"page":-1},"Guides","\u002Fguides","7.guides",[86,88,92,96],{"title":82,"path":83,"stem":87},"7.guides\u002Findex",{"title":89,"path":90,"stem":91},"Map an Asset","\u002Fguides\u002Fmap-an-asset","7.guides\u002F1.map-an-asset",{"title":93,"path":94,"stem":95},"Work a Prompt","\u002Fguides\u002Fwork-a-prompt","7.guides\u002F2.work-a-prompt",{"title":97,"path":98,"stem":99},"Run a Playbook","\u002Fguides\u002Frun-a-playbook","7.guides\u002F3.run-a-playbook",{"title":101,"path":102,"stem":103,"children":104,"page":-1},"Reference","\u002Freference","8.reference",[105,107],{"title":101,"path":102,"stem":106},"8.reference\u002Findex",{"title":108,"path":109,"stem":110},"Glossary","\u002Freference\u002Fglossary","8.reference\u002F1.glossary",[112,116,122,127,132,137,140,145,150,155,159,162,167,170,175,180,183,188,191,196,201,206,211,215,218,223,227,231,235,239,242,247,251,255,260,264,267,272,276,281,285,289,292,297,301,306,310,314,317,322,327,332,336,339,344,349,354,358,361,366,371,376,381,385,388,393,398,403,408,412,415,420,425,430,434,437,442,446,449,454,457,462,467,471,474,479,482,487,492,497,502,505,510,515],{"id":13,"title":12,"titles":113,"content":114,"level":115},[],"Sign in, create a workspace, and bring your team into the vault.",1,{"id":117,"title":118,"titles":119,"content":120,"level":121},"\u002Fgetting-started\u002Faccount-and-workspaces#accounts","Accounts",[12],"Nimbus Vault uses your account to keep your work portable: your profile, plan, and workspace memberships follow you across devices. Sign in from the auth screen, and you land on your workspace dashboard.",2,{"id":123,"title":124,"titles":125,"content":126,"level":121},"\u002Fgetting-started\u002Faccount-and-workspaces#workspaces","Workspaces",[12],"A workspace is the container for everything — assets, components, playbooks, and notespaces. Most researchers operate in a single workspace; teams share one so that the component library and threat library compound for everyone. Creating your first workspace takes one step from the dashboard. You can create additional workspaces when you want a hard boundary between engagements.",{"id":128,"title":129,"titles":130,"content":131,"level":121},"\u002Fgetting-started\u002Faccount-and-workspaces#members-and-roles","Members and roles",[12],"Invite teammates from workspace settings. Each member has a role: Admin — can manage workspace settings, members, and everything inside the workspace.Member — full access to the workspace's assets, components, and playbooks. Pending invites are visible from the sidebar avatar, so you always know who has not joined yet. Some capabilities — like agent connections and sharing — are part of the Pro plan. Pro features are marked with the  badge throughout these docs.",{"id":133,"title":134,"titles":135,"content":136,"level":121},"\u002Fgetting-started\u002Faccount-and-workspaces#whats-next","What's next",[12],"Seed your workspace so you are not starting from an empty library: the starter library.",{"id":17,"title":16,"titles":138,"content":139,"level":115},[],"Seed your workspace with curated components and playbooks.",{"id":141,"title":142,"titles":143,"content":144,"level":121},"\u002Fgetting-started\u002Fstarter-library#why-seed-the-library","Why seed the library",[16],"The Nexus Engine can only match what exists in your vault. An empty workspace gives you an empty checklist — a seeded one gives you a working library of common technologies, functionalities, gadgets, vectors, quirks, and the playbooks that use them.",{"id":146,"title":147,"titles":148,"content":149,"level":121},"\u002Fgetting-started\u002Fstarter-library#seeding-your-workspace","Seeding your workspace",[16],"From the dashboard, use the Starter Library card to bring curated content into your workspace. Seeded content behaves exactly like content you create yourself: you can edit it, extend it, and link it to your assets. It is a head start, not a separate tier. Seed first, then prune. It is faster to delete the few entries you will never use than to author a library from nothing.",{"id":151,"title":152,"titles":153,"content":154,"level":121},"\u002Fgetting-started\u002Fstarter-library#growing-beyond-it","Growing beyond it",[16],"Every engagement adds to your library. When you observe something new on a target, you record it as a component — and from then on the engine can match it everywhere. See components for what earns a place in the library.",{"id":156,"title":134,"titles":157,"content":158,"level":121},"\u002Fgetting-started\u002Fstarter-library#whats-next",[16],"Map your first asset and watch the engine light up.",{"id":21,"title":20,"titles":160,"content":161,"level":115},[],"What the Nexus Engine shows you once an asset has components.",{"id":163,"title":164,"titles":165,"content":166,"level":121},"\u002Fgetting-started\u002Ffirst-suggestions#the-moment-it-clicks","The moment it clicks",[20],"A suggestion appears when a playbook's required components are satisfied by what you have linked to an asset. Each suggestion is ranked and explainable: open it and you will see which components matched, how specific the match is, and what part of the playbook is still unconfirmed. Suggestions are deterministic. The same asset and the same library always produce the same result — nothing is guessed, and nothing changes until you change the data. Suggestions versus the checklistAlongside suggestions, the engine produces a proactive checklist on the asset. Where suggestions say \"this playbook applies now\", the checklist asks questions that could unlock more: capabilities worth probing for on this target.Working the checklist is how coverage grows. See Work a prompt.Reading a suggestionMatch — the components that satisfied the playbook's requirements.Score and rank — specificity decides the order. More precise matches (scoped vectors and quirks, exact endpoints) score higher than generic ones.Yield — the capability the playbook grants if it succeeds. Yields become primitives on the asset.What's nextThe Nexus Engine — the model behind all of it.Map an asset — build the inventory the engine reads.",{"id":6,"title":5,"titles":168,"content":169,"level":115},[],"From an empty workspace to your first ranked suggestions in one session.",{"id":171,"title":172,"titles":173,"content":174,"level":121},"\u002Fgetting-started#the-first-loop","The first loop",[5],"Nimbus Vault rewards you at every step: the more you observe and record, the more the Nexus Engine can tell you. The fastest way to understand the product is to complete one full loop: Set up — create a workspace and (optionally) seed it with the starter library.Map one asset — create an asset and link the components you have observed.Watch suggestions appear — the engine matches your playbooks against the asset immediately.Work the checklist and run a playbook — record what you test; success earns new capabilities.",{"id":176,"title":177,"titles":178,"content":179,"level":121},"\u002Fgetting-started#in-this-section","In this section",[5],"Account and workspaces — signing in, workspaces, members.The starter library — seed your vault with curated content.Your first suggestions — what the engine shows you and why.",{"id":25,"title":24,"titles":181,"content":182,"level":115},[],"How Nimbus Vault organizes the targets you are hacking on.",{"id":184,"title":185,"titles":186,"content":187,"level":121},"\u002Finventory#the-hierarchy","The hierarchy",[24],"Platform — where the program lives: a bug bounty platform, a VDP, a private engagement. One record per source of work.Program — a scope of testing published by an organization: the rules, the rewards, the boundary.Asset — one concrete thing you are testing: admin.example.com, an API endpoint, an Android app, a source checkout. You rarely test a \"program\" directly. Work happens on assets, so that is where observations, components, and suggestions live. One asset, one focusThe model pushes you to keep assets concrete. \"The whole product\" is not an asset. api.example.com is. Concrete assets make the Nexus Engine's matching precise — and precision is what ranks a suggestion to the top.Assets can have children: an app with its API, a host with its services. Hierarchy lets a capability on a child (a vector inside an API) sharpen what the engine knows about the parent without duplicating records.Getting assets inManual — create an asset and link components as you observe them. This is the map an asset loop.CSV import — bring in a target list you already maintain and start linking components to each row.SharingIndividual assets can be shared outside the workspace with a link — useful when you want a second pair of eyes on one target without inviting someone into everything.What's nextLearn the vocabulary you will attach to every asset: components.",{"id":39,"title":38,"titles":189,"content":190,"level":115},[],"The frameworks, servers, languages, and platforms a target is built with.",{"id":192,"title":193,"titles":194,"content":195,"level":121},"\u002Fcomponents\u002Ftechnologies#what-a-technology-is","What a technology is",[38],"A technology is something a target is built with or runs on: a language runtime (Node.js, PHP), a web server or proxy (Caddy, nginx), a datastore (PostgreSQL, Redis), a framework (Laravel, Rails), a platform (Android, Cloudflare Workers).",{"id":197,"title":198,"titles":199,"content":200,"level":121},"\u002Fcomponents\u002Ftechnologies#why-they-matter","Why they matter",[38],"Technologies are the anchor for everything version-, configuration-, or runtime-specific. A quirk almost never applies \"everywhere on the asset\" — it applies to a specific technology in a specific state. Linking the technology gives those observations a place to live and gives the engine a scoping anchor.",{"id":202,"title":203,"titles":204,"content":205,"level":121},"\u002Fcomponents\u002Ftechnologies#how-they-link","How they link",[38],"Usually directly to the asset — a technology is a property of the thing you are testing. Behavior specific to it is captured as scoped children: a quirk inside the technology (Prototype pollution inside Node.js)a vector inside the part of the stack it affects A quirk scoped to a technology scores more specifically than the same quirk floating on the asset, and playbooks that require the pairing can only match when the structure is right.",{"id":207,"title":208,"titles":209,"content":210,"level":121},"\u002Fcomponents\u002Ftechnologies#library-hygiene","Library hygiene",[38],"One entry per technology, kept stable and undated. Node.js is knowledge you keep forever; prototype pollution is a quirk scoped to it; the version condition is a detail on that observation. When you are tempted to create \"Apache 2.4.49 path traversal\" as a technology, you are really looking at three separate components.",{"id":212,"title":134,"titles":213,"content":214,"level":121},"\u002Fcomponents\u002Ftechnologies#whats-next",[38],"Functionalities — what the stack does for users.",{"id":43,"title":42,"titles":216,"content":217,"level":115},[],"What a target does for its users — and where most attack surface lives.",{"id":219,"title":220,"titles":221,"content":222,"level":121},"\u002Fcomponents\u002Ffunctionalities#what-a-functionality-is","What a functionality is",[42],"A functionality is something the target does for its users: file upload, password reset, signup, search, exports, invitation flows, webhook configuration, billing management.",{"id":224,"title":198,"titles":225,"content":226,"level":121},"\u002Fcomponents\u002Ffunctionalities#why-they-matter",[42],"Most attack surface is functionality-shaped. Playbook requirements frequently start from a functionality, and the vectors you find while testing one almost always belong to it — which makes functionalities the natural parent for scoped observations.",{"id":228,"title":203,"titles":229,"content":230,"level":121},"\u002Fcomponents\u002Ffunctionalities#how-they-link",[42],"Usually directly to the asset, with vectors and quirks hanging off them as scoped children: File Upload            (functionality)\n  └─ SVG upload        (vector)\n  └─ size limit bypass (quirk) Scoping a vector inside the functionality that produces it is what makes a suggestion specific. The engine can tell \"this asset has an SVG upload vector somewhere\" apart from \"this asset has one inside its avatar uploader\" — and only one of those is usually worth acting on.",{"id":232,"title":208,"titles":233,"content":234,"level":121},"\u002Fcomponents\u002Ffunctionalities#library-hygiene",[42],"Name the capability, not the endpoint. File Upload is a component; POST \u002Fapi\u002Favatar on admin.example.com is where you recorded it — the endpoint belongs on the link, not in the name.",{"id":236,"title":134,"titles":237,"content":238,"level":121},"\u002Fcomponents\u002Ffunctionalities#whats-next",[42],"Gadgets — the capabilities that ride along.",{"id":47,"title":46,"titles":240,"content":241,"level":115},[],"Extra capabilities that ride along with a target, beyond its intended purpose.",{"id":243,"title":244,"titles":245,"content":246,"level":121},"\u002Fcomponents\u002Fgadgets#what-a-gadget-is","What a gadget is",[46],"A gadget is an extra capability that rides along with the target — not the purpose of the system, but a surface it exposes anyway: a GraphQL endpoint, an admin panel, a metrics endpoint, a debug console, auto-generated API docs, a feature-flag surface.",{"id":248,"title":198,"titles":249,"content":250,"level":121},"\u002Fcomponents\u002Fgadgets#why-they-matter",[46],"Gadgets are where \"it also does this\" turns into attack surface. They are frequently discovered while mapping something else — you are testing the API and notice the debug console — and each one seeds its own vectors and quirks. Left unrecorded, they are invisible to the engine.",{"id":252,"title":203,"titles":253,"content":254,"level":121},"\u002Fcomponents\u002Fgadgets#how-they-link",[46],"Directly on the asset, or scoped inside the technology that exposes them (GraphQL endpoint inside Apollo Server). If a gadget exists only because of a specific parent component, scope it there.",{"id":256,"title":257,"titles":258,"content":259,"level":121},"\u002Fcomponents\u002Fgadgets#functionality-vs-gadget","Functionality vs. gadget",[46],"A functionality is what the product is for — password reset. A gadget is what came along with it — the metrics endpoint the reset service happens to expose. When in doubt: if users are supposed to use it, it is a functionality; if it is a side door, it is a gadget.",{"id":261,"title":134,"titles":262,"content":263,"level":121},"\u002Fcomponents\u002Fgadgets#whats-next",[46],"Vectors — the specific ways in.",{"id":51,"title":50,"titles":265,"content":266,"level":115},[],"The specific mechanisms that turn observed behavior into a reachable attack.",{"id":268,"title":269,"titles":270,"content":271,"level":121},"\u002Fcomponents\u002Fvectors#what-a-vector-is","What a vector is",[50],"A vector is the specific way in — the mechanism that turns observed behavior into a reachable attack: SVG upload, an SSRF-prone webhook fetcher, path traversal in file handling, OAuth redirect manipulation, mass assignment. A vector is a mechanism, not a payload. SVG upload is a vector; the payload you deliver through it is an exploit, and that belongs in the playbook that uses it — not in the library.",{"id":273,"title":203,"titles":274,"content":275,"level":121},"\u002Fcomponents\u002Fvectors#how-they-link",[50],"Vectors are rarely asset-wide. They are usually scoped inside the parent that produces them — the functionality or technology where the mechanism was observed: File Upload             (functionality)\n  └─ SVG upload         (vector)\n\nWebhook Configuration   (functionality)\n  └─ SSRF-prone fetcher (vector) Scoped matches rank higher in the engine. The more precisely a vector is anchored, the more trustworthy the suggestion it appears in.",{"id":277,"title":278,"titles":279,"content":280,"level":121},"\u002Fcomponents\u002Fvectors#record-the-endpoint","Record the endpoint",[50],"When you know where a vector was observed, record the endpoint on the link. Endpoints are how the engine decides whether two capabilities actually meet — a vector without one can still match, but any playbook with a co-location requirement will not.",{"id":282,"title":208,"titles":283,"content":284,"level":121},"\u002Fcomponents\u002Fvectors#library-hygiene",[50],"One mechanism per component. Split \"SVG upload with stored XSS\" into SVG upload (vector) and stored XSS (quirk) — the playbook is where they combine.",{"id":286,"title":134,"titles":287,"content":288,"level":121},"\u002Fcomponents\u002Fvectors#whats-next",[50],"Quirks — the behaviors that change what a vector can do.",{"id":55,"title":54,"titles":290,"content":291,"level":115},[],"Behavior that tips an attack — and why scoping quirks to their parent matters most.",{"id":293,"title":294,"titles":295,"content":296,"level":121},"\u002Fcomponents\u002Fquirks#what-a-quirk-is","What a quirk is",[54],"A quirk is behavior that changes an outcome: missing CSRF protection, prototype pollution, predictable reset tokens, verbose error pages, permissive CORS, unsafe deserialization. Quirks rarely stand alone. They amplify, dampen, or gate what a vector can do — which is why the engine weighs specific vector\u002Fquirk pairings when it ranks suggestions, not just the presence of each one.",{"id":298,"title":203,"titles":299,"content":300,"level":121},"\u002Fcomponents\u002Fquirks#how-they-link",[54],"Usually scoped inside the component where the behavior was observed: Node.js          (technology)\n  └─ Prototype pollution      (quirk)\n\nPassword Reset   (functionality)\n  └─ Predictable tokens       (quirk) A quirk scoped to its parent is far more valuable than the same quirk floating on the asset. It tells the engine exactly where the behavior lives, and it unlocks playbooks that require that pairing — playbooks that a flat quirk can never satisfy.",{"id":302,"title":303,"titles":304,"content":305,"level":121},"\u002Fcomponents\u002Fquirks#stateful-quirks","Stateful quirks",[54],"Some quirks are stateful: triggering them changes how the target behaves or the state it is in. Record the behavior you actually observed, with the state details that matter, rather than the generic label — the engine accounts for how a specific quirk pairs with a specific vector when scoring.",{"id":307,"title":208,"titles":308,"content":309,"level":121},"\u002Fcomponents\u002Fquirks#library-hygiene",[54],"Name the behavior, not the exploit. Prototype pollution is a quirk; \"RCE via prototype pollution in lodash merge\" is a playbook.",{"id":311,"title":134,"titles":312,"content":313,"level":121},"\u002Fcomponents\u002Fquirks#whats-next",[54],"See the library in context: Overview or the Glossary.",{"id":31,"title":35,"titles":315,"content":316,"level":115},[],"What components are, the five types, and what earns a place in the library.",{"id":318,"title":319,"titles":320,"content":321,"level":121},"\u002Fcomponents#the-vocabulary-of-the-vault","The vocabulary of the vault",[35],"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: TypeQuestion it answersExampleTechnologyWhat is it built on or running?Node.js, Caddy, PostgreSQLFunctionalityWhat does it do for the user?File upload, password resetGadgetWhat additional capability rides along?GraphQL endpoint, admin panelVectorWhat is the specific way in?SVG upload, SSRF-prone webhookQuirkWhat 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.",{"id":323,"title":324,"titles":325,"content":326,"level":121},"\u002Fcomponents#what-earns-a-place-in-the-library","What earns a place in the library",[35],"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 \u002Ftelescope\" is three components, not one. Components that fail this test become noise that pollutes matching for every asset.",{"id":328,"title":329,"titles":330,"content":331,"level":121},"\u002Fcomponents#organizing-the-library","Organizing the library",[35],"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. At the asset level you can also mark wildcards — links that match any concrete value until you confirm one, so a known-but-not-yet-pinned capability still contributes to matching. Trendy, undated facts age badly. \"Apache 2.4.49 path traversal\" is a moment in time; \"path traversal\" as a vector, scoped to the version you observed, is knowledge you keep forever.",{"id":333,"title":134,"titles":334,"content":335,"level":121},"\u002Fcomponents#whats-next",[35],"Technologies — the most common entry point.Notespaces and endpoints — where observations live once linked.",{"id":59,"title":58,"titles":337,"content":338,"level":115},[],"Requirements in, capabilities out — the recipes of your threat library.",{"id":340,"title":341,"titles":342,"content":343,"level":121},"\u002Fplaybooks#a-playbook-is-a-recipe","A playbook is a recipe",[58],"A playbook describes how a situation is exploited: if a target has these things, this capability becomes available. Two halves: Requirements — the components that must be present for the playbook to apply. These are hard gates: miss one and the playbook is excluded.Yields — the capabilities the playbook grants when it succeeds. Requirements can be loose or strict: a plain component, a component scoped inside another, a category match, or a co-located requirement — two capabilities that must meet at the same endpoint. Strictness changes how specific a match is, which changes its rank, but never bypasses a gate.",{"id":345,"title":346,"titles":347,"content":348,"level":121},"\u002Fplaybooks#yields-become-primitives","Yields become primitives",[58],"When you run a playbook and record it as successful, its yields are granted to the asset as primitives — earned capabilities that are not part of the component library. Primitives exist only because something granted them, and they feed back into matching: a playbook that requires \"SSRF available on this endpoint\" can be satisfied by a primitive that an earlier playbook earned. This chaining is how a vault grows from observations into an attack graph. A playbook can grant all of its yields at once, or let you pick which ones actually materialized during the run. Both modes are available per playbook.",{"id":350,"title":351,"titles":352,"content":353,"level":121},"\u002Fplaybooks#outcomes-and-honesty","Outcomes and honesty",[58],"Every run gets an outcome: success, failed, or not applicable. Outcomes are evidence, not vibes: Success earns yields — and may ask which endpoint the capability was demonstrated on.A failed run is still knowledge: it prunes what the engine keeps suggesting.Retracting a success revokes the yields it granted, cascading through anything that depended on them. The history stays in the playbook's notespace, so the reasoning trail survives long after you forget the details.",{"id":355,"title":134,"titles":356,"content":357,"level":121},"\u002Fplaybooks#whats-next",[58],"See the machinery that decides which playbook applies: the Nexus Engine.",{"id":73,"title":72,"titles":359,"content":360,"level":115},[],"The proactive half of the engine — the questions that unlock more suggestions.",{"id":362,"title":363,"titles":364,"content":365,"level":121},"\u002Fnexus-engine\u002Fchecklist-and-probes#reactive-vs-proactive","Reactive vs. proactive",[72],"Matching is reactive: it answers questions about what you have already recorded. The checklist is proactive: it asks what is still unknown. For every asset, the engine generates a checklist from playbook requirements that are not yet confirmed. Each item is a prompt — a question about the target: Does this asset expose a password-reset flow?",{"id":367,"title":368,"titles":369,"content":370,"level":121},"\u002Fnexus-engine\u002Fchecklist-and-probes#prompts-and-probes","Prompts and probes",[72],"A probe is what you do to answer a prompt: following the flow, checking the surface, actually testing. The checklist is a queue of work, not a form to click through. How to resolve a prompt: Yes — link the capability to the asset. If you discovered the specific value while probing, resolve it to the concrete component rather than a placeholder.No — only after tracing the full surface. A negative is a real result, but a wrong one silently suppresses every playbook behind it. Details in Work a Prompt.Endpoint — if confirming the capability revealed where it lives, record the endpoint on the link.",{"id":372,"title":373,"titles":374,"content":375,"level":121},"\u002Fnexus-engine\u002Fchecklist-and-probes#what-happens-after-you-resolve","What happens after you resolve",[72],"The engine re-evaluates the asset immediately: new suggestions appear, others disappear, and the checklist shrinks. Every resolution either unlocks a playbook or prunes the search space — which is why working the checklist is the fastest way to make the vault smarter.",{"id":377,"title":378,"titles":379,"content":380,"level":121},"\u002Fnexus-engine\u002Fchecklist-and-probes#checklist-vs-coverage","Checklist vs. coverage",[72],"The checklist is the open work for one asset. Coverage is the measure of how much of what could apply you have actually confirmed. Both live on the asset, and both move when you resolve prompts with evidence.",{"id":382,"title":134,"titles":383,"content":384,"level":121},"\u002Fnexus-engine\u002Fchecklist-and-probes#whats-next",[72],"Work a Prompt — the practical discipline.",{"id":65,"title":69,"titles":386,"content":387,"level":115},[],"Deterministic matching, ranked suggestions, and the proactive checklist.",{"id":389,"title":390,"titles":391,"content":392,"level":121},"\u002Fnexus-engine#rules-not-guesses","Rules, not guesses",[69],"The Nexus Engine is deterministic. Given the same library and the same asset, it always produces the same suggestions in the same order. There is no model making up plausible-sounding attacks — every suggestion traces back to a playbook and the exact components that satisfied it. That property is what makes the output trustworthy: you can audit it, and you can fix it by fixing your data.",{"id":394,"title":395,"titles":396,"content":397,"level":121},"\u002Fnexus-engine#how-a-match-happens","How a match happens",[69],"Every time an asset changes, the engine re-evaluates the playbook library against it: Hard gates — playbooks are checked against the asset's components. A missing required component excludes the playbook — no exceptions, no partial credit.Structure matters — a quirk scoped inside a specific technology is not the same as the same quirk anywhere on the asset. Scoped matches are stronger and rank higher.Co-location — where a playbook demands it, requirements must be tied to intersecting endpoints.Ranking — satisfied playbooks are scored by how specific and complete the match is. The most precise, best-supported suggestion sits at the top.Coverage — the engine also measures how much of what could apply you have actually confirmed.",{"id":399,"title":400,"titles":401,"content":402,"level":121},"\u002Fnexus-engine#the-proactive-checklist","The proactive checklist",[69],"Matching is reactive: it answers questions about what you already recorded. The checklist is proactive: it asks what is still unknown. For each asset, the engine generates prompts — questions whose answers would unlock more playbooks. Resolving a prompt with evidence updates the asset and triggers a fresh round of matching. A negative answer is a real result, but it must come from checking the full surface: a wrong \"no\" silently suppresses every playbook behind it. See Checklist and Probes for the model and Work a Prompt for the practice.",{"id":404,"title":405,"titles":406,"content":407,"level":121},"\u002Fnexus-engine#why-it-compounds","Why it compounds",[69],"The engine is not a scanner. It does not know more than you tell it — it knows better than a note pile. Every confirmed component and every consumed prompt sharpens the next suggestion, and earned primitives let later playbooks stand on earlier successes.",{"id":409,"title":134,"titles":410,"content":411,"level":121},"\u002Fnexus-engine#whats-next",[69],"Put it to work: map an asset, then work a prompt.",{"id":77,"title":76,"titles":413,"content":414,"level":115},[],"Where observations live, and the data that makes matches precise.",{"id":416,"title":417,"titles":418,"content":419,"level":121},"\u002Fnotespaces#every-entity-has-a-notespace","Every entity has a notespace",[76],"Each asset, playbook, and component carries a notespace: one page where its links, notes, and history live. When you open a technology, you are seeing its notespace; when you open an asset, you are seeing the asset's. Notespaces make the model uniform. A component is not just a tag — it is a full record that assets can link to, that other components can nest inside, and that notes can accumulate against over time.",{"id":421,"title":422,"titles":423,"content":424,"level":121},"\u002Fnotespaces#links-carry-the-context","Links carry the context",[76],"A link between an asset and a component is not just \"this asset has this technology.\" Each link can carry: Endpoints — where the capability was observed.Scoped children — vectors and quirks nested inside a specific parent component.Requirements — whether a playbook needs it, or just benefits from it.Yield metadata — when a capability was earned, which playbook granted it, and the endpoint it was discovered on.",{"id":426,"title":427,"titles":428,"content":429,"level":121},"\u002Fnotespaces#why-endpoints-matter","Why endpoints matter",[76],"Endpoints are what turn a pile of components into a theory of the target. A file upload on the marketing site and an SSRF-prone fetcher on the internal API are both \"on example.com\" — but they only combine if they actually meet at the same endpoint. The engine uses endpoints for co-location: a rule can require that two capabilities occur on the same endpoint before it counts. The stricter the endpoint data you record, the more trustworthy the match. Recording endpoints is not optional busywork. A playbook whose primitives were never tied to matching endpoints will not match — and that is by design, because an exploit that assumes two things meet without evidence is a guess.",{"id":431,"title":134,"titles":432,"content":433,"level":121},"\u002Fnotespaces#whats-next",[76],"Playbooks — the recipes that consume all of this.",{"id":90,"title":89,"titles":435,"content":436,"level":115},[],"Turn a target you have observed into a structured component inventory. Mapping is the highest-leverage habit in Nimbus Vault. Everything the engine can ever tell you is bounded by what you record here. Under the program it belongs to, create an asset for one concrete thing you are testing — a host, an API, an app. Name it exactly as you think about it, then start exploring.\n  \n  \n    Every time you notice something real — a technology in the stack, a feature in the UI, a framework behavior — link it to the asset. Search the library first: most things already exist, and linking beats recreating. Only add a new component when it passes the [library test](\u002Fcomponents#what-earns-a-place-in-the-library).\n  \n  \n    A quirk inside a specific technology, a vector inside a specific functionality — link it as a scoped child of that parent, not as a flat sibling. Scoped matches rank higher because they are more specific.\n  \n  \n    When you know where a capability was observed — the specific URL or path — record it on the link. Endpoints are what let the engine decide whether two capabilities actually meet.\n  \n  \n    Open the asset's suggestions panel. Playbooks whose requirements you have satisfied appear immediately, ranked. If nothing appears yet, that is information too — check the checklist for what the engine is asking for. Map in one sitting when you can. The value of the inventory comes from completeness — a half-mapped asset produces half-trustworthy suggestions.",{"id":438,"title":439,"titles":440,"content":441,"level":121},"\u002Fguides\u002Fmap-an-asset#variations","Variations",[89],"Existing target list? Import assets via CSV, then map the ones worth pursuing.Children — model sub-parts (an API under an app, a service under a host) as child assets when they have their own components and endpoints.Not sure of the exact value? Use a wildcard link so matching still works until you confirm the concrete one.",{"id":443,"title":134,"titles":444,"content":445,"level":121},"\u002Fguides\u002Fmap-an-asset#whats-next",[89],"The engine now has something to think about: work the prompts it generates.",{"id":94,"title":93,"titles":447,"content":448,"level":115},[],"Resolve the proactive checklist accurately — positives unlock playbooks, negatives hide them.",{"id":450,"title":451,"titles":452,"content":453,"level":121},"\u002Fguides\u002Fwork-a-prompt#what-a-prompt-is","What a prompt is",[93],"A prompt is a question the engine asks about an asset: does this capability apply here? Prompts come from playbook requirements that are not yet confirmed, so every honest resolution sharpens what Nimbus Vault can tell you. The checklist is a queue, not a mandate. Work prompts you have the access and time to test — an unanswered prompt costs nothing; a wrong answer costs a lot.\n  \n  \n    If the capability exists, say so and link it. If you discovered the specific value while probing, resolve it to the concrete component rather than leaving a placeholder.\n  \n  \n    \"No\" is a real, useful answer — but only after you have traced the full flow. If the capability would require a vector nested inside a functionality, check that the parent, the child, and the flow between them are all actually absent. Incomplete negatives silently suppress every playbook behind them.\n  \n  \n    If confirming a capability revealed where it lives, attach the endpoint. It costs one field now and pays off in co-location precision later.\n  What happens after you resolveThe engine re-evaluates the asset immediately: new suggestions appear, others disappear, and the remaining checklist shrinks. Resolutions are revision-safe — if you later learn something new, update the record; the engine follows your data, not a stale decision.\nNever resolve a prompt from assumption. The checklist exists to capture evidence — treating it as a click-through form defeats the entire model.\nWhat's nextWhen a suggestion looks right, go execute: run a playbook.",{"id":98,"title":97,"titles":455,"content":456,"level":115},[],"Execute a suggestion and record the outcome — so the vault learns from every attempt.",{"id":458,"title":459,"titles":460,"content":461,"level":121},"\u002Fguides\u002Frun-a-playbook#before-you-start","Before you start",[97],"Run playbooks from the suggestions panel, not from a wish list. A suggestion means the engine has verified the requirements are present on this asset — the ground truth you said you observed. Only work suggestions the engine actually produced. Executing unrelated playbooks burns time and poisons the outcome history with noise. Read it first: which components matched, how specific the match is, and what the playbook yields if it succeeds. The reasoning is the point — if a match looks wrong, fix the data before you test.\n  \n  \n    Do the actual work outside Nimbus Vault, within program rules. The vault is where knowledge lives, not where exploitation happens.\n  \n  \n    Record the run as **success**, **failed**, or **not applicable**:\n- **Success** grants the playbook's yields — possibly asking you to pick which ones materialized, and on which endpoint.\n- **Failed** prunes this suggestion from the queue.\n- **Not applicable** marks the playbook as irrelevant to this asset without treating it as a failed attack.\n\n  \n  \n    Yields land on the asset as primitives. New playbooks that require those primitives may now appear — that cascade is the vault working as intended.",{"id":463,"title":464,"titles":465,"content":466,"level":121},"\u002Fguides\u002Frun-a-playbook#retracting","Retracting",[97],"If a success turns out to be wrong, retract it. The yields it granted are revoked, cascading through whatever depended on them. Nothing is lost from history — the outcome trail stays intact, which is exactly why recording honestly is safe.",{"id":468,"title":134,"titles":469,"content":470,"level":121},"\u002Fguides\u002Frun-a-playbook#whats-next",[97],"Keep the loop tight: back to mapping as you discover more.See the full vocabulary in the glossary.",{"id":83,"title":82,"titles":472,"content":473,"level":115},[],"Task-by-task walkthroughs for the core Nimbus Vault loop.",{"id":475,"title":476,"titles":477,"content":478,"level":121},"\u002Fguides#the-loop-step-by-step","The loop, step by step",[82],"Everything in Nimbus Vault serves one loop: map what exists, confirm what you can, run what applies, record what happened. These guides walk each stage. Map an asset — build the component inventory the engine reads.Work a prompt — answer the checklist without corrupting your data.Run a playbook — execute suggestions and record outcomes honestly.",{"id":109,"title":108,"titles":480,"content":481,"level":115},[],"Every Nimbus Vault term in one place.",{"id":483,"title":484,"titles":485,"content":486,"level":121},"\u002Freference\u002Fglossary#targets","Targets",[108],"Platform — a source of work: a bug bounty platform, a VDP, or a private engagement. Program — an organization's published scope: rules, rewards, and boundary for testing. Asset — one concrete thing you are testing: a host, an API, an app, a checkout. Assets can have children. Wildcard — a component link that matches any concrete value until you confirm the real one, so a known-but-unpinned capability still contributes to matching.",{"id":488,"title":489,"titles":490,"content":491,"level":121},"\u002Freference\u002Fglossary#library","Library",[108],"Component — a reusable building block observed on targets. Five types: technology, functionality, gadget, vector, quirk. Technology — what a target is built on or running. Functionality — what a target does for its users. Gadget — an additional capability that rides along with the target. Vector — the specific way in: an attack-relevant mechanism. Quirk — behavior that could tip an attack outcome. Category — a themed grouping of components used by the engine's structured matching. Tag — a lightweight label for slicing the library and attaching conditions in playbooks. Asset-Level Component (ALC) — a component linked directly to the asset, rather than scoped inside another component. Component-Level Vector (CLV) — a vector scoped inside a specific parent component. Component-Level Quirk (CLQ) — a quirk scoped inside a specific parent component. Starter Library — the curated set of components and playbooks you can seed a workspace with.",{"id":493,"title":494,"titles":495,"content":496,"level":121},"\u002Freference\u002Fglossary#engine","Engine",[108],"Nexus Engine — the deterministic, rule-based engine that matches playbooks against assets, ranks suggestions, and builds the proactive checklist. Requirement — a component a playbook needs before it can apply. Requirements are hard gates. Co-location — a requirement that two capabilities must meet at the same endpoint before they count as combined. Suggestion — a ranked playbook match, with the reasoning that produced it. Prompt — a question from the checklist: does a capability apply to this asset? Resolving it feeds the engine. Coverage — how much of what could apply to an asset you have actually confirmed. Yield — a capability a playbook declares as an output. Primitive — an earned capability granted by a successful playbook; not part of the component library. Outcome — the recorded result of a run: success, failed, or not applicable. CAVET — Component Analysis & Vulnerability Enumeration Technique: the methodology Nimbus Vault implements — analyze targets into components, then enumerate exploitable behavior systematically.",{"id":498,"title":499,"titles":500,"content":501,"level":121},"\u002Freference\u002Fglossary#work","Work",[108],"Workspace — the container for all assets, components, playbooks, and notespaces; shared with your team. Notespace — the single page where an entity's links, notes, and history live. Endpoint — the concrete URL or path where a capability was observed. Scope — where a link applies: directly on the asset, or inside a parent component. Agent connection — a capability-scoped token that lets an AI agent read from and write to your workspace over the Model Context Protocol (MCP).",{"id":102,"title":101,"titles":503,"content":504,"level":115},[],"Lookup material — the vocabulary, and the details behind the workflow.",{"id":506,"title":507,"titles":508,"content":509,"level":121},"\u002Freference#quick-lookups","Quick lookups",[101],"Glossary — every Nimbus Vault term, defined.",{"id":511,"title":512,"titles":513,"content":514,"level":115},"\u002F","Nimbus Vault Docs",[],"Everything you need to run Nimbus Vault — from your first asset to playbook-driven exploitation.",{"id":516,"title":517,"titles":518,"content":519,"level":121},"\u002F#what-is-nimbus-vault","What is Nimbus Vault?",[512],"Nimbus Vault is a structured workspace for ethical hackers. Instead of scattered notes, you build three things that compound: A target inventory — platforms, programs, and assets, with everything you observe attached where it belongs.A component library — the reusable building blocks of your targets: technologies, functionalities, gadgets, vectors, and quirks.A playbook library — capability recipes that describe how observed components combine into exploitable outcomes. The Nexus Engine connects the three. It is deterministic and rule-based — no AI guessing — matching your playbooks against what you have observed, surfacing ranked suggestions with the reasoning behind them, and building a proactive checklist of what to probe next. Where to startGetting started — create a workspace, seed your library, see your first suggestions.Inventory — how targets are organized.Components — the library and its five types.Playbooks and the Nexus Engine — how knowledge becomes suggestions.Guides — task-by-task walkthroughs.Glossary — every term in one place.",{"id":521,"title":512,"body":522,"description":514,"extension":616,"meta":617,"navigation":618,"path":511,"pro":618,"seo":619,"stem":620,"type":621,"updatedAt":622,"__hash__":623},"docs\u002Findex.md",{"type":523,"value":524,"toc":610},"minimark",[525,529,533,556,562],[526,527,517],"h2",{"id":528},"what-is-nimbus-vault",[530,531,532],"p",{},"Nimbus Vault is a structured workspace for ethical hackers. Instead of scattered notes, you build three things that compound:",[534,535,536,544,550],"ul",{},[537,538,539,543],"li",{},[540,541,542],"strong",{},"A target inventory"," — platforms, programs, and assets, with everything you observe attached where it belongs.",[537,545,546,549],{},[540,547,548],{},"A component library"," — the reusable building blocks of your targets: technologies, functionalities, gadgets, vectors, and quirks.",[537,551,552,555],{},[540,553,554],{},"A playbook library"," — capability recipes that describe how observed components combine into exploitable outcomes.",[530,557,558,559,561],{},"The ",[540,560,64],{}," connects the three. It is deterministic and rule-based — no AI guessing — matching your playbooks against what you have observed, surfacing ranked suggestions with the reasoning behind them, and building a proactive checklist of what to probe next.",[563,564,567,571],"visual-placeholder",{"label":565,"hint":566},"Two-minute product tour","Needs: short workflow clip or the landing tutorial video",[526,568,570],{"id":569},"where-to-start","Where to start",[534,572,573,580,586,591,600,605],{},[537,574,575,579],{},[576,577,578],"a",{"href":6},"Getting started"," — create a workspace, seed your library, see your first suggestions.",[537,581,582,585],{},[576,583,584],{"href":25},"Inventory"," — how targets are organized.",[537,587,588,590],{},[576,589,30],{"href":31}," — the library and its five types.",[537,592,593,595,596,599],{},[576,594,58],{"href":59}," and ",[576,597,598],{"href":65},"the Nexus Engine"," — how knowledge becomes suggestions.",[537,601,602,604],{},[576,603,82],{"href":83}," — task-by-task walkthroughs.",[537,606,607,609],{},[576,608,108],{"href":109}," — every term in one place.",{"title":611,"searchDepth":612,"depth":612,"links":613},"",3,[614,615],{"id":528,"depth":121,"text":517},{"id":569,"depth":121,"text":570},"md",{},false,{"title":512,"description":514},"index","overview","2026-10-06","ltQn8DTnTf8k3o1qSYb37pLyQK_zq0-L47A3FiSZN3k",1791329712954]