[{"data":1,"prerenderedAt":1419},["ShallowReactive",2],{"docs-navigation":3,"docs-search-files":202,"page-\u002Fmethodology\u002Fchain-recognition":1256,"surround-\u002Fmethodology\u002Fchain-recognition":1415},[4,23,34,40,72,95,111,117,152,179],{"title":5,"path":6,"stem":7,"children":8},"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},"Complementary Features","\u002Fcomplementary-features","10.complementary-features",[28,30],{"title":24,"path":25,"stem":29},"10.complementary-features\u002Findex",{"title":31,"path":32,"stem":33},"Connect an AI Agent","\u002Fcomplementary-features\u002Fconnect-an-agent","10.complementary-features\u002F1.connect-an-agent",{"title":35,"path":36,"stem":37,"children":38},"Platforms, Programs, and Assets","\u002Finventory","2.inventory\u002Findex",[39],{"title":35,"path":36,"stem":37},{"title":41,"path":42,"stem":43,"children":44},"Components","\u002Fcomponents","3.components",[45,48,52,56,60,64,68],{"title":46,"path":42,"stem":47},"Overview","3.components\u002Findex",{"title":49,"path":50,"stem":51},"Technologies","\u002Fcomponents\u002Ftechnologies","3.components\u002F1.technologies",{"title":53,"path":54,"stem":55},"Functionalities","\u002Fcomponents\u002Ffunctionalities","3.components\u002F2.functionalities",{"title":57,"path":58,"stem":59},"Gadgets","\u002Fcomponents\u002Fgadgets","3.components\u002F3.gadgets",{"title":61,"path":62,"stem":63},"Vectors","\u002Fcomponents\u002Fvectors","3.components\u002F4.vectors",{"title":65,"path":66,"stem":67},"Quirks","\u002Fcomponents\u002Fquirks","3.components\u002F5.quirks",{"title":69,"path":70,"stem":71},"Scopes and Levels","\u002Fcomponents\u002Fscopes-and-levels","3.components\u002F6.scopes-and-levels",{"title":73,"path":74,"stem":75,"children":76},"Playbooks","\u002Fplaybooks","4.playbooks",[77,79,83,87,91],{"title":73,"path":74,"stem":78},"4.playbooks\u002Findex",{"title":80,"path":81,"stem":82},"Authoring Guide","\u002Fplaybooks\u002Fauthoring-guide","4.playbooks\u002F1.authoring-guide",{"title":84,"path":85,"stem":86},"Requirements","\u002Fplaybooks\u002Frequirements","4.playbooks\u002F2.requirements",{"title":88,"path":89,"stem":90},"Yields and Primitives","\u002Fplaybooks\u002Fyields-and-primitives","4.playbooks\u002F3.yields-and-primitives",{"title":92,"path":93,"stem":94},"Outcomes and History","\u002Fplaybooks\u002Foutcomes-and-history","4.playbooks\u002F4.outcomes-and-history",{"title":96,"path":97,"stem":98,"children":99},"Nexus Engine","\u002Fnexus-engine","5.nexus-engine",[100,103,107],{"title":101,"path":97,"stem":102},"The Nexus Engine","5.nexus-engine\u002Findex",{"title":104,"path":105,"stem":106},"Suggestions and Ranking","\u002Fnexus-engine\u002Fsuggestions-and-ranking","5.nexus-engine\u002F1.suggestions-and-ranking",{"title":108,"path":109,"stem":110},"Checklist and Probes","\u002Fnexus-engine\u002Fchecklist-and-probes","5.nexus-engine\u002F2.checklist-and-probes",{"title":112,"path":113,"stem":114,"children":115},"Notespaces and Endpoints","\u002Fnotespaces","6.notespaces\u002Findex",[116],{"title":112,"path":113,"stem":114},{"title":118,"path":119,"stem":120,"children":121},"Guides","\u002Fguides","7.guides",[122,124,128,132,136,140,144,148],{"title":118,"path":119,"stem":123},"7.guides\u002Findex",{"title":125,"path":126,"stem":127},"Map an Asset","\u002Fguides\u002Fmap-an-asset","7.guides\u002F1.map-an-asset",{"title":129,"path":130,"stem":131},"Work a Prompt","\u002Fguides\u002Fwork-a-prompt","7.guides\u002F2.work-a-prompt",{"title":133,"path":134,"stem":135},"Run a Playbook","\u002Fguides\u002Frun-a-playbook","7.guides\u002F3.run-a-playbook",{"title":137,"path":138,"stem":139},"Search the Workspace","\u002Fguides\u002Fcommand-center-and-search","7.guides\u002F4.command-center-and-search",{"title":141,"path":142,"stem":143},"Manage Your Scope","\u002Fguides\u002Fmanage-your-scope","7.guides\u002F5.manage-your-scope",{"title":145,"path":146,"stem":147},"Share and Collaborate","\u002Fguides\u002Fshare-and-collaborate","7.guides\u002F6.share-and-collaborate",{"title":149,"path":150,"stem":151},"Clone a Workspace","\u002Fguides\u002Fclone-a-workspace","7.guides\u002F7.clone-a-workspace",{"title":153,"path":154,"stem":155,"children":156},"Reference","\u002Freference","8.reference",[157,159,163,167,171,175],{"title":153,"path":154,"stem":158},"8.reference\u002Findex",{"title":160,"path":161,"stem":162},"Glossary","\u002Freference\u002Fglossary","8.reference\u002F1.glossary",{"title":164,"path":165,"stem":166},"Search Syntax","\u002Freference\u002Fsearch-syntax","8.reference\u002F2.search-syntax",{"title":168,"path":169,"stem":170},"Settings","\u002Freference\u002Fsettings","8.reference\u002F3.settings",{"title":172,"path":173,"stem":174},"Dashboard Metrics","\u002Freference\u002Fdashboard-metrics","8.reference\u002F4.dashboard-metrics",{"title":176,"path":177,"stem":178},"FAQ","\u002Freference\u002Ffaq","8.reference\u002F5.faq",{"title":180,"path":181,"stem":182,"children":183},"Methodology","\u002Fmethodology","9.methodology",[184,186,190,194,198],{"title":180,"path":181,"stem":185},"9.methodology\u002Findex",{"title":187,"path":188,"stem":189},"The CAVET Method","\u002Fmethodology\u002Fcavet","9.methodology\u002F1.cavet",{"title":191,"path":192,"stem":193},"Contextual Hacking","\u002Fmethodology\u002Fcontextual-hacking","9.methodology\u002F2.contextual-hacking",{"title":195,"path":196,"stem":197},"Chain Recognition","\u002Fmethodology\u002Fchain-recognition","9.methodology\u002F3.chain-recognition",{"title":199,"path":200,"stem":201},"Worked Chains","\u002Fmethodology\u002Fworked-chains","9.methodology\u002F4.worked-chains",[203,207,213,218,223,228,231,236,241,246,250,253,258,261,266,271,274,279,284,287,292,295,300,303,308,313,318,323,327,330,335,339,343,347,351,354,359,363,367,372,376,379,384,388,393,397,401,404,409,413,418,422,426,429,434,439,444,449,454,458,461,466,471,476,480,483,488,493,498,504,509,514,519,524,529,534,539,544,548,551,556,561,565,570,575,580,585,590,595,600,605,608,613,618,623,628,633,638,643,647,650,655,660,665,670,674,677,682,686,690,693,698,703,708,713,718,722,725,730,735,740,745,749,752,757,761,766,771,776,780,783,788,793,798,803,808,812,815,820,824,827,832,835,840,845,849,852,857,862,867,872,876,879,884,889,894,898,901,906,910,915,920,925,929,932,937,942,947,951,954,959,962,967,972,977,982,985,990,995,999,1004,1009,1014,1019,1024,1027,1032,1037,1042,1045,1050,1055,1060,1065,1070,1073,1078,1083,1088,1093,1098,1103,1108,1113,1116,1121,1124,1129,1134,1139,1144,1149,1153,1156,1161,1166,1171,1176,1180,1183,1188,1193,1198,1202,1207,1211,1214,1219,1224,1229,1234,1238,1241,1246,1251],{"id":13,"title":12,"titles":204,"content":205,"level":206},[],"Sign in, create a workspace, and bring your team into the vault.",1,{"id":208,"title":209,"titles":210,"content":211,"level":212},"\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":214,"title":215,"titles":216,"content":217,"level":212},"\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":219,"title":220,"titles":221,"content":222,"level":212},"\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 — are part of the Pro plan, and workspace ownership is limited by plan (Free accounts own one workspace; Pro accounts up to five). Pro features are marked with the  badge throughout these docs.",{"id":224,"title":225,"titles":226,"content":227,"level":212},"\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":229,"content":230,"level":206},[],"Seed your workspace with curated components and playbooks.",{"id":232,"title":233,"titles":234,"content":235,"level":212},"\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":237,"title":238,"titles":239,"content":240,"level":212},"\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":242,"title":243,"titles":244,"content":245,"level":212},"\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":247,"title":225,"titles":248,"content":249,"level":212},"\u002Fgetting-started\u002Fstarter-library#whats-next",[16],"Map your first asset and watch the engine light up.",{"id":21,"title":20,"titles":251,"content":252,"level":206},[],"What the Nexus Engine shows you once an asset has components.",{"id":254,"title":255,"titles":256,"content":257,"level":212},"\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":259,"content":260,"level":206},[],"From an empty workspace to your first ranked suggestions in one session.",{"id":262,"title":263,"titles":264,"content":265,"level":212},"\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":267,"title":268,"titles":269,"content":270,"level":212},"\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":32,"title":31,"titles":272,"content":273,"level":206},[],"Give an AI agent scoped access to your workspace over MCP.",{"id":275,"title":276,"titles":277,"content":278,"level":212},"\u002Fcomplementary-features\u002Fconnect-an-agent#what-a-connection-does","What a connection does",[31],"A connection lets an AI agent work in your workspace on your behalf, with your access level — over the Model Context Protocol (MCP). The agent can read what you can read and do what you can do, scoped to that workspace and bounded by the capabilities you leave enabled on the connection. Everything below happens in Workspace Settings → Integrations. Every member can see the workspace's connections (name, owner, status, expiry) — transparency without secrets. Owners manage their own; admins can revoke any. Agent connections are a Pro feature. Each member can hold up to 10 connections per workspace.",{"id":280,"title":281,"titles":282,"content":283,"level":212},"\u002Fcomplementary-features\u002Fconnect-an-agent#creating-a-connection","Creating a connection",[31],"Open the Integrations tab and create one. Give it a name you will recognize later — `Claude Code — laptop` beats `test` — and choose an expiry: 90 days by default, or 30 \u002F 90 \u002F 365 \u002F never.\n  \n  \n    The connection token (`nv_live_…`) is shown a single time. Copy it into your client before closing the dialog; if you lose it, rotate the connection and copy a fresh one.\n  \n  \n    Pick your client and paste the pre-filled snippet — the dialog provides one for **Claude Code**, **Claude Desktop**, **Cursor**, and a generic \"Other\" form. For Claude Code:\nclaude mcp add --transport http nimbus https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp \\\n  --header \"Authorization: Bearer nv_live_…\"\n```\n\nFor JSON-based clients (Claude Desktop, Cursor):\n\n```json\n{\n  \"mcpServers\": {\n    \"nimbus\": {\n      \"type\": \"http\",\n      \"url\": \"https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp\",\n      \"headers\": { \"Authorization\": \"Bearer nv_live_…\" }\n    }\n  }\n}\n```\n\u003C\u002FStep>\n\n\u003CStep title=\"First prompt\">\nAsk your agent: *\"Use Nimbus to show my workspace context.\"* The first exchange flips the connection from **Never** to recently used — proof the loop works.\n\u003C\u002FStep>\n\u003C\u002FSteps>\n\n## What the agent can do\n\nThe agent receives a curated tool surface — the read and write operations that map to the vault's workflows:\nRead — workspace context, search across the vault, programs and assets, an asset's component digest, ranked suggestions, the checklist, history, and change feeds.Act — link observed components, resolve prompts, record outcomes, and create library entries, following the same methodology the docs describe.Each connection has capability toggles — open a connection's row to tune exactly which of those the agent may use. Start narrow; widen deliberately.Agents also receive Nimbus's working guide as part of the connection, so they follow the same map → suggest → confirm → record loop you do.Managing connectionsStatus chips — Active, Expired, or Revoked, at a glance.Rename \u002F renew \u002F rotate — lifecycle actions for the owner. Rotate immediately if a token leaks.Revoke — owners revoke their own; admins can revoke any. Revocation takes effect at the next exchange, and live sessions end shortly after.Delete — removes revoked or expired rows permanently.Leaving or being removed from a workspace deletes your connections for it.Security modelWorkspace-scoped. A token reaches one workspace and nothing else.No secret at rest. The raw token is never stored or logged — only a hash, used to mint short-lived sessions.Expiry by default. Connections come with an end date unless you deliberately choose otherwise.Audited. Connecting, revoking, and every write the agent makes are recorded in the workspace's audit log.What's nextShare and Collaborate — the human side of working together.Search the Workspace — the same surface, driven by you.",{"id":25,"title":24,"titles":285,"content":286,"level":206},[],"Capabilities that extend the workspace beyond the web app.",{"id":288,"title":289,"titles":290,"content":291,"level":212},"\u002Fcomplementary-features#beyond-the-app","Beyond the app",[24],"A workspace is more useful when your tools can meet it halfway. This section documents the complementary features that plug into Nimbus Vault from outside the web app. Connect an AI Agent — give an agent scoped access to your workspace over MCP, with capability toggles, expiry, and revocation under your control. The section grows as more complementary features ship.",{"id":36,"title":35,"titles":293,"content":294,"level":206},[],"How Nimbus Vault organizes the targets you are hacking on.",{"id":296,"title":297,"titles":298,"content":299,"level":212},"\u002Finventory#the-hierarchy","The hierarchy",[35],"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.Asset typesWeb, API, Mobile iOS, Mobile Android, Desktop, Browser Extension, Cloud Infrastructure, Network\u002FVPN, Smart Contract, Hardware\u002FIoT, Source Code Repository — pick the closest fit, and Other for anything the list does not cover. The type is descriptive: it tells collaborators what kind of target they are looking at.One type is special: Wildcard. A wildcard asset is a grouping container, not a tracked target — its name must be a pattern like *.example.com, and concrete URLs live beneath it as Web assets. It organizes a broad scope without pretending the wildcard itself is something you test.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":50,"title":49,"titles":301,"content":302,"level":206},[],"The frameworks, servers, languages, and platforms a target is built with.",{"id":304,"title":305,"titles":306,"content":307,"level":212},"\u002Fcomponents\u002Ftechnologies#what-a-technology-is","What a technology is",[49],"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). In CAVET terms, technologies define the constraint space — the universe of what is possible on this target and what is not.",{"id":309,"title":310,"titles":311,"content":312,"level":212},"\u002Fcomponents\u002Ftechnologies#why-they-matter","Why they matter",[49],"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":314,"title":315,"titles":316,"content":317,"level":212},"\u002Fcomponents\u002Ftechnologies#how-they-link","How they link",[49],"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":319,"title":320,"titles":321,"content":322,"level":212},"\u002Fcomponents\u002Ftechnologies#library-hygiene","Library hygiene",[49],"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":324,"title":225,"titles":325,"content":326,"level":212},"\u002Fcomponents\u002Ftechnologies#whats-next",[49],"Functionalities — what the stack does for users.",{"id":54,"title":53,"titles":328,"content":329,"level":206},[],"What a target does for its users — and where most attack surface lives.",{"id":331,"title":332,"titles":333,"content":334,"level":212},"\u002Fcomponents\u002Ffunctionalities#what-a-functionality-is","What a functionality is",[53],"A functionality is something the target does for its users: file upload, password reset, signup, search, exports, invitation flows, webhook configuration, billing management. In CAVET terms, functionalities are trust boundaries: places where the application accepts outside input and makes a promise about what it will do with it. Vulnerabilities are broken promises.",{"id":336,"title":310,"titles":337,"content":338,"level":212},"\u002Fcomponents\u002Ffunctionalities#why-they-matter",[53],"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":340,"title":315,"titles":341,"content":342,"level":212},"\u002Fcomponents\u002Ffunctionalities#how-they-link",[53],"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":344,"title":320,"titles":345,"content":346,"level":212},"\u002Fcomponents\u002Ffunctionalities#library-hygiene",[53],"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":348,"title":225,"titles":349,"content":350,"level":212},"\u002Fcomponents\u002Ffunctionalities#whats-next",[53],"Gadgets — the capabilities that ride along.",{"id":58,"title":57,"titles":352,"content":353,"level":206},[],"Extra capabilities that ride along with a target, beyond its intended purpose.",{"id":355,"title":356,"titles":357,"content":358,"level":212},"\u002Fcomponents\u002Fgadgets#what-a-gadget-is","What a gadget is",[57],"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. In CAVET terms, gadgets are unintended capabilities — mechanisms built for legitimate purposes that attackers repurpose into force multipliers.",{"id":360,"title":310,"titles":361,"content":362,"level":212},"\u002Fcomponents\u002Fgadgets#why-they-matter",[57],"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":364,"title":315,"titles":365,"content":366,"level":212},"\u002Fcomponents\u002Fgadgets#how-they-link",[57],"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":368,"title":369,"titles":370,"content":371,"level":212},"\u002Fcomponents\u002Fgadgets#functionality-vs-gadget","Functionality vs. gadget",[57],"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":373,"title":225,"titles":374,"content":375,"level":212},"\u002Fcomponents\u002Fgadgets#whats-next",[57],"Vectors — the specific ways in.",{"id":62,"title":61,"titles":377,"content":378,"level":206},[],"The specific mechanisms that turn observed behavior into a reachable attack.",{"id":380,"title":381,"titles":382,"content":383,"level":212},"\u002Fcomponents\u002Fvectors#what-a-vector-is","What a vector is",[61],"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. In CAVET terms, vectors are the application's perception system — the lenses through which it sees input. The same payload behaves differently depending on which lens it arrives through. 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":385,"title":315,"titles":386,"content":387,"level":212},"\u002Fcomponents\u002Fvectors#how-they-link",[61],"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":389,"title":390,"titles":391,"content":392,"level":212},"\u002Fcomponents\u002Fvectors#record-the-endpoint","Record the endpoint",[61],"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":394,"title":320,"titles":395,"content":396,"level":212},"\u002Fcomponents\u002Fvectors#library-hygiene",[61],"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":398,"title":225,"titles":399,"content":400,"level":212},"\u002Fcomponents\u002Fvectors#whats-next",[61],"Quirks — the behaviors that change what a vector can do.",{"id":66,"title":65,"titles":402,"content":403,"level":206},[],"Behavior that tips an attack — and why scoping quirks to their parent matters most.",{"id":405,"title":406,"titles":407,"content":408,"level":212},"\u002Fcomponents\u002Fquirks#what-a-quirk-is","What a quirk is",[65],"A quirk is behavior that changes an outcome: missing CSRF protection, prototype pollution, predictable reset tokens, verbose error pages, permissive CORS, unsafe deserialization. In CAVET terms, quirks are ground truth — not what should be true of the stack in theory, but what is true of this target as observed. 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":410,"title":315,"titles":411,"content":412,"level":212},"\u002Fcomponents\u002Fquirks#how-they-link",[65],"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":414,"title":415,"titles":416,"content":417,"level":212},"\u002Fcomponents\u002Fquirks#stateful-quirks","Stateful quirks",[65],"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":419,"title":320,"titles":420,"content":421,"level":212},"\u002Fcomponents\u002Fquirks#library-hygiene",[65],"Name the behavior, not the exploit. Prototype pollution is a quirk; \"RCE via prototype pollution in lodash merge\" is a playbook.",{"id":423,"title":225,"titles":424,"content":425,"level":212},"\u002Fcomponents\u002Fquirks#whats-next",[65],"See the library in context: Overview or the Glossary.",{"id":70,"title":69,"titles":427,"content":428,"level":206},[],"How components nest — asset-level observations versus scoped children.",{"id":430,"title":431,"titles":432,"content":433,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#why-scoping-exists","Why scoping exists",[69],"\"This asset has prototype pollution\" and \"this specific Node.js service has prototype pollution\" are different claims. The second one is worth more: it tells the engine where the behavior lives, lets it satisfy scoped requirements that a flat observation never could, and produces suggestions you can act on instead of guesses. Scoping is how you make the second claim. A scoped component is a vector or quirk linked inside the parent component it was observed on, rather than floating on the asset.",{"id":435,"title":436,"titles":437,"content":438,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#the-levels","The levels",[69],"LevelWhat it meansExampleComponentObserved directly on the assetNode.js, File UploadScoped vector (CLV)A vector inside a specific parentSVG upload inside File UploadScoped quirk (CLQ)A quirk inside a specific parentPrototype pollution inside Node.jsQuirk on a vector (CLVQ)A quirk on a scoped vectorStored XSS on SVG uploadNested vector (CLVv)A vector inside another vectorVector chainingScoped gadget (CLG)A gadget nested inside a parentGraphQL endpoint inside a technology Asset-wide vectors and quirks exist too — you observed them, but not inside any particular parent. Link them flat when that is the truth. The rule of thumb: scope when you observed the relationship, not when you assume it.",{"id":440,"title":441,"titles":442,"content":443,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#the-exact-parent-rule","The exact-parent rule",[69],"Scoped matching is strict about parentage. A vector scoped inside one functionality does not satisfy a requirement for the same vector type inside a different functionality: File Upload → SVG upload      does NOT satisfy      Login Form → SVG upload This is deliberate. Scoping that ignored its parent would just be a slower way of writing a flat link. Structural claims match structural requirements — that is what makes them precise. Playbook requirements use the same levels, so what you observe and what a playbook demands speak the same language.",{"id":445,"title":446,"titles":447,"content":448,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#instances-the-same-component-multiple-places","Instances: the same component, multiple places",[69],"One asset can surface the same component more than once — three file uploads, two APIs, several endpoints running the same service. Each occurrence is an instance, and endpoints are recorded per instance rather than per component. This matters downstream: instances are what co-location reason about. \"File upload and SSRF fetcher on the same endpoint\" is a statement about instances, not about components in general — two capabilities that exist on an asset but never meet on the same endpoint are not a chain.",{"id":450,"title":451,"titles":452,"content":453,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#quirks-carry-roles","Quirks carry roles",[69],"A quirk's meaning is contextual, and the vault records it that way: Enabling or mitigating — the role is assigned per playbook, not on the component itself. The same quirk can enable one attack and mitigate another.Present or absent — stateful quirks record whether the target exhibits the behavior or explicitly does not. A confirmed absence is a result, and the right kind of absence can satisfy a requirement written as \"does not exhibit.\" Details live in Requirements.",{"id":455,"title":225,"titles":456,"content":457,"level":212},"\u002Fcomponents\u002Fscopes-and-levels#whats-next",[69],"Authoring Guide — how scoped observations become playbook triggers.Notespaces and Endpoints — where links, instances, and endpoints live.",{"id":42,"title":46,"titles":459,"content":460,"level":206},[],"What components are, the five types, and what earns a place in the library.",{"id":462,"title":463,"titles":464,"content":465,"level":212},"\u002Fcomponents#the-vocabulary-of-the-vault","The vocabulary of the vault",[46],"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":467,"title":468,"titles":469,"content":470,"level":212},"\u002Fcomponents#what-earns-a-place-in-the-library","What earns a place in the library",[46],"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":472,"title":473,"titles":474,"content":475,"level":212},"\u002Fcomponents#organizing-the-library","Organizing the library",[46],"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. 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":477,"title":225,"titles":478,"content":479,"level":212},"\u002Fcomponents#whats-next",[46],"Technologies — the most common entry point.Scopes and levels — how components nest inside their parents.The CAVET Method — why these five types exist.Notespaces and endpoints — where observations live once linked.",{"id":81,"title":80,"titles":481,"content":482,"level":206},[],"Build playbooks that fire at the right moment — the detection-path method.",{"id":484,"title":485,"titles":486,"content":487,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#a-hunting-tool-not-a-reference-document","A hunting tool, not a reference document",[80],"The instinctive way to build a playbook is to document a vulnerability: capture every component involved, every variant, every technique, and save it. The result looks thorough — and it never fires. A reference document is something you consult after you already suspect a vulnerability. A hunting tool fires before you have consciously made the connection, because the conditions you have mapped already satisfy its trigger. Those are different goals, and they produce different playbooks. A playbook's component requirements are not a description of a vulnerability. They are the minimum set of observable signals that tell the Nexus Engine \"this playbook is now relevant to this target.\"",{"id":489,"title":490,"titles":491,"content":492,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#the-detection-path-question","The detection path question",[80],"Before you assign a single component, answer this: What would I need to observe in a target for this attack to become worth testing? Not \"what are all the components involved\" — at what point in your reconnaissance does the playbook become relevant, and what observable signals mark that point? Most playbooks need only two or three component types to define a meaningful trigger. The rest belongs in the playbook body. Forcing every type into the requirements doesn't make a playbook more rigorous — it makes it harder to trigger, slower to assign, and noisier.",{"id":494,"title":495,"titles":496,"content":497,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#the-building-blocks","The building blocks",[80],"",{"id":499,"title":500,"titles":501,"content":502,"level":503},"\u002Fplaybooks\u002Fauthoring-guide#required-is-an-and-gate","Required is an AND gate",[80,495],"Required does not mean \"this field must be filled in.\" Required means \"this component must be confirmed and assigned before this playbook is considered applicable.\" All required components together form the sufficient condition: the engine stays silent until every one is satisfied. This makes the choice of required components the most consequential decision in playbook design: Too few required conditions → the playbook fires on irrelevant targets. Noise.Too many → it can never fire in black-box hunting. Silence. The goal is the minimum set that fires at the right time and not before.",3,{"id":505,"title":506,"titles":507,"content":508,"level":503},"\u002Fplaybooks\u002Fauthoring-guide#optional-components-shape-confidence","Optional components shape confidence",[80,495],"An optional component does not gate the playbook — it weights the suggestion. Present raises confidence; absent lowers it. Use it for signal that matters but cannot be a hard requirement: a Technology that is disproportionately affected, or a Gadget that varies by application. Required components define when the playbook fires; optional components define how confidently.",{"id":510,"title":511,"titles":512,"content":513,"level":503},"\u002Fplaybooks\u002Fauthoring-guide#encode-blind-spots-as-required-quirks","Encode blind spots as required quirks",[80,495],"A required component-level quirk (CLQ) is not just a gate — it is a proactive prompt. When a playbook is partially satisfied and the only missing piece is a required CLQ, the engine turns it into a proactive prompt asking you to confirm that condition. This lets you encode the things you know you would forget. If you always map a file upload that accepts archives and move on without checking whether the server extracts them, make \"server-side archive extraction\" a required CLQ — and never skip it again.",{"id":515,"title":516,"titles":517,"content":518,"level":503},"\u002Fplaybooks\u002Fauthoring-guide#categories","Categories",[80,495],"A category assignment replaces a specific component with a category-wide condition: instead of requiring \"Login Form,\" require any Functionality in the Authentication category. One assignment covers every variant, including ones that don't exist yet. The type is always locked by the slot: a category on a Functionality slot resolves against functionalities only. If any member of the category makes the playbook relevant, use a category assignment; if only a subset does, use the next tool.",{"id":520,"title":521,"titles":522,"content":523,"level":503},"\u002Fplaybooks\u002Fauthoring-guide#tags-and-category-tag","Tags and category + tag",[80,495],"Tags live on components in the library and travel with them. A category + tag assignment requires both conditions simultaneously — the component must be in the category and carry the tag. This is how you handle variance without multiplying playbooks. One playbook requiring File Types + #archive-file covers ZIP, TAR, JAR, and every future format you tag — no new playbook ever needed. If you find yourself writing near-identical playbooks that differ only by which component is involved, collapse them into one and let tags do the work.",{"id":525,"title":526,"titles":527,"content":528,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#the-seven-principles","The seven principles",[80],"Adapted from the Nimbus playbook design methodology: Map the detection path, not the vulnerability. Requirements are trigger conditions. Exploitation steps, variants, and language nuance belong in the body.Use required components as sequential filters. Each one should eliminate a meaningful subset of irrelevant targets. If removing it changes nothing, it isn't load-bearing.Encode your blind spots as required CLQs. The engine will hold the playbook partially satisfied and keep asking until you confirm or rule out the condition.Let context do its share. If a competent hunter would naturally observe and record it, don't systematize it.Keep the trigger lean, push detail downstream. The body is for what to do after the playbook fires — never for what the engine needs to decide it should.Use tags to absorb variance. One playbook tagged across all affected variants beats one playbook per variant.Ask the minimum-components question last. Challenge every requirement: can I remove it and still not fire on irrelevant targets? If yes, remove it.",{"id":530,"title":531,"titles":532,"content":533,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#case-study-zip-slip","Case study: Zip Slip",[80],"Step 1 — the research. Zip Slip is directory traversal through archive extraction: it needs an upload that accepts archives, and server-side extraction of those archives. Step 2 — the detection path question. What would I need to observe for Zip Slip to become worth testing? A file upload — no upload surface, no attack. This is the broadest gate.The upload accepts archives — an image-only upload has no exposure. Handled by a tag, not by naming every format.The server extracts what was uploaded — storing archives isn't enough. This condition is invisible from the upload interface, which is exactly why it must be encoded as a required CLQ. Java is meaningful context on top — disproportionately affected — but it is not part of the detection path, so it is optional. Step 3 — the final playbook. Required Components:\n\n  [Functionality]\n  File Upload  (Required)\n    [CLV] File Types + #archive-file — Required\n    [CLQ] server-side archive extraction — Required\n\n  [Technology]\n  Java — Optional (confidence signal)\n\nExecution Steps (in the playbook body):\n  1. Craft an archive whose filenames contain traversal sequences\n  2. Upload it through the identified functionality\n  3. Observe whether traversal paths are preserved server-side\n  4. Attempt to overwrite a known file to confirm arbitrary write\n  5. Chain to RCE by targeting files the server process will execute Notice what is not there: no gadget naming the extraction library (varies by app, unconfirmable black-box), no vector naming the filename field (implicit in confirmed extraction), no quirk for missing path validation (that is what you are testing for). All of it is real, useful knowledge — none of it belongs in the trigger.",{"id":535,"title":536,"titles":537,"content":538,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#before-you-finalize","Before you finalize",[80],"Is every required component observable during normal reconnaissance, without a dedicated investigation?Does each required component eliminate a meaningful subset of irrelevant targets?Is there any required component that can almost never be confirmed black-box?Is there a condition that is both necessary and easy to forget? Is it a required CLQ?Could two playbooks be collapsed into one with better tag usage?Is there anything in the requirements that a hunter would only need after deciding to run the playbook? If those all hold, you have built a hunting tool.",{"id":540,"title":541,"titles":542,"content":543,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#the-deeper-principle","The deeper principle",[80],"Nimbus is not a vulnerability database. It is a context engine. A database stores information and retrieves it when you query; a context engine observes the context you are building and surfaces relevant attack surface automatically. For that to work, it needs to know the right conditions under which each playbook becomes relevant. Too broad — noise. Too narrow — silence. The precise middle ground is what this guide is about.",{"id":545,"title":225,"titles":546,"content":547,"level":212},"\u002Fplaybooks\u002Fauthoring-guide#whats-next",[80],"Requirements — every assignment level and property in detail.Yields and Primitives — what playbooks produce, and how chains form.",{"id":85,"title":84,"titles":549,"content":550,"level":206},[],"Every assignment level and property a playbook requirement can carry.",{"id":552,"title":553,"titles":554,"content":555,"level":212},"\u002Fplaybooks\u002Frequirements#what-a-requirement-is","What a requirement is",[84],"A playbook requirement tells the engine what must be observed before the playbook becomes relevant. Requirements come in different levels (what they point at) and properties (how they behave when matched). This page is the full mechanics reference — for the how to think about them, read the Authoring Guide.",{"id":557,"title":558,"titles":559,"content":560,"level":212},"\u002Fplaybooks\u002Frequirements#assignment-levels","Assignment levels",[84],"A requirement can point at a single component, at a scoped child of a component, or at a category: LevelResolves againstExampleIndividual componentOne specific entry in the libraryTechnology: Node.jsScoped vector (CLV)A vector observed inside a specific parentSVG upload inside File UploadScoped quirk (CLQ)A quirk observed inside a specific parentPrototype pollution inside Node.jsQuirk on a vector (CLVQ)A quirk on a scoped vectorStored XSS on SVG uploadNested vector (CLVv)A vector inside another vectorVector chainingScoped gadget (CLG)A gadget nested inside a parent componentGraphQL endpoint inside a technologyCategoryAny component in a categoryAny Functionality in AuthenticationCategory + tagComponents in a category carrying a tagAuthentication + #oauth Scoped matching requires the exact parent. A vector scoped inside one functionality does not satisfy a requirement for the same vector type scoped inside a different functionality — SVG upload on File Upload is not SVG upload on Login Form. This is what makes scoping worth doing: it encodes where a capability lives, not just that it exists. Category mode: any or all. An \"any\" category requirement is satisfied by at least one member. An \"all\" requirement needs every member of the category — and it grows as the category does, so a new component added to a category becomes a new required condition for every playbook that requires the whole category. The type is locked by the slot. A category assignment resolves only against the component type it sits in — a category on a Technology slot never resolves against functionalities that share the label.",{"id":562,"title":563,"titles":564,"content":497,"level":212},"\u002Fplaybooks\u002Frequirements#properties","Properties",[84],{"id":566,"title":567,"titles":568,"content":569,"level":503},"\u002Fplaybooks\u002Frequirements#required-the-hard-gate","Required — the hard gate",[84,563],"All required components together form an AND gate. The playbook is excluded entirely until every required component is satisfied — later scoring never runs. A partially satisfied playbook does not sit silently; its missing required components become proactive prompts.",{"id":571,"title":572,"titles":573,"content":574,"level":503},"\u002Fplaybooks\u002Frequirements#optional-the-confidence-signal","Optional — the confidence signal",[84,563],"Optional components never gate. Once the required set is satisfied, the playbook fires whether or not they are present; their absence lowers confidence, their presence raises it. Optional components are how you encode meaningful-but-unconfirmable context (an affected framework, a risky ecosystem) without creating silence.",{"id":576,"title":577,"titles":578,"content":579,"level":503},"\u002Fplaybooks\u002Frequirements#enabling-and-mitigating-quirks","Enabling and mitigating quirks",[84,563],"A quirk requirement can act as an enabler (its presence makes the outcome more likely) or a mitigator (its presence blocks or dampens the outcome). The same quirk can be an enabler in one playbook and a mitigator in another — the role is set per assignment. Mitigating factors carry more weight when absent, because a single mitigation can block an exploit while a single enabler rarely guarantees one.",{"id":581,"title":582,"titles":583,"content":584,"level":503},"\u002Fplaybooks\u002Frequirements#present-and-absent-quirk-polarity","Present and absent — quirk polarity",[84,563],"Some quirks are stateful: what matters is whether the target currently exhibits the behavior or explicitly does not. These carry a polarity — present or absent — and the reactive checklist only offers objectives whose polarity matches what was actually observed on the asset. A required quirk written as \"does not exhibit X\" is satisfied only by a confirmed absence, not by silence.",{"id":586,"title":587,"titles":588,"content":589,"level":503},"\u002Fplaybooks\u002Frequirements#version-constraints","Version constraints",[84,563],"Technology requirements can carry a version constraint — exact versions, comparisons (>=14, \u003C19), and ranges. How the engine treats constraints is a workspace setting: Lax — unknown versions are still included, with a confidence penalty.Strict — a technology whose version cannot be verified never satisfies a versioned requirement, and unknown versions are excluded. Lax favors coverage during black-box hunting; strict favors precision when version data is reliable.",{"id":591,"title":592,"titles":593,"content":594,"level":503},"\u002Fplaybooks\u002Frequirements#co-location","Co-location",[84,563],"A playbook-only flag on an individual component link: \"the same endpoint as the required primitive.\" The flagged component only counts where its recorded endpoints intersect the endpoints of the playbook's required primitives — the union of all of them. It is available only when the playbook has at least one required primitive.It is strict both ways: no endpoints recorded on the component, or no endpoints on the primitives, means no match.A failed required co-located link excludes the playbook entirely; a failed optional one just lowers the score. This is how a playbook avoids the classic false positive where every ingredient exists on a target but never in the same place.",{"id":596,"title":597,"titles":598,"content":599,"level":503},"\u002Fplaybooks\u002Frequirements#primitive-requirements","Primitive requirements",[84,563],"A requirement can demand an earned primitive rather than a library component — a capability granted by an earlier playbook's success. Assigned components never satisfy it; it must be earned. See Yields and Primitives.",{"id":601,"title":602,"titles":603,"content":604,"level":212},"\u002Fplaybooks\u002Frequirements#how-the-engine-treats-requirements","How the engine treats requirements",[84],"Required and missing → playbook excluded; the gap becomes a prompt on the asset.Scoped and matched at the right level → a more specific match, ranked higher than a flat one.Optional → tuned into the score.Satisfied entirely → the playbook appears in the asset's suggestions, ranked against everything else that matched.",{"id":89,"title":88,"titles":606,"content":607,"level":206},[],"What playbooks produce on success, and how earned capabilities form chains.",{"id":609,"title":610,"titles":611,"content":612,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#yields-what-a-playbook-produces","Yields: what a playbook produces",[88],"Requirements describe what a playbook needs. A yield declares what it produces. When a playbook is marked successful, its yields are granted to the asset as capabilities that did not exist there before. A yield can be: A library concept — an existing reusable component like Stored XSS or SSRF, earned rather than observed.A chain token — a self-contained capability that only exists because a playbook granted it, like arbitrary-file-write or an internal foothold. These never pollute the component library: they have no library page, only purpose as a link in a chain. Not every capability a playbook demonstrates should be a yield. Declare a yield when another playbook could one day start from it — that is the test.",{"id":614,"title":615,"titles":616,"content":617,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#primitives-earned-not-observed","Primitives: earned, not observed",[88],"Granted yields land on the asset as primitives. The distinction between a primitive and a library component is the whole point: A component is something you observed: you found Node.js, you saw a file upload.A primitive is something you achieved: you turned the upload into arbitrary file write, you turned the reflection into execution. Primitives can't be \"reconned\" — you can't nmap for them or find them in a JS bundle. The asset's primitives panel is read-only: the only way in is a successful playbook, and the only way out is retracting that outcome. That immutability is a feature. A primitive means someone demonstrated something, not that someone ticked a box.",{"id":619,"title":620,"titles":621,"content":622,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#granting-yields","Granting yields",[88],"When you mark a playbook successful: Grant all — its declared yields are all attached to the asset silently.Pick — for playbooks with more than one yield, you choose which actually materialized. Real runs are messy: you got the shell but never found credentials. The vault records what happened, not what could have. If a yield's discovery happened on a specific endpoint, the vault asks for it at grant time and stores it on the earned link — the same endpoint discipline that powers co-location, now applied to capabilities you earned rather than observed.",{"id":624,"title":625,"titles":626,"content":627,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#yield-gating-the-chain-mechanic","Yield-gating: the chain mechanic",[88],"A playbook requirement can demand an earned primitive instead of a library component. This is yield-gating, and it changes what the requirement means: the engine will not accept a manually assigned gadget, no matter how similar. The capability must have been earned by a successful playbook. That is how chains form. A playbook that requires \"stored XSS on this asset\" can be satisfied in exactly one way — by earning stored-xss somewhere upstream — and the moment it is earned, every playbook gated on it becomes eligible.",{"id":629,"title":630,"titles":631,"content":632,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#meta-playbooks","Meta-playbooks",[88],"Because yield-gating consumes the capability rather than the route to it, some playbooks are deliberately written without an upstream: an escalation playbook that takes any stored XSS and raises it, regardless of where the XSS came from. Write the escalation knowledge once, and every path that lands on that primitive gets it for free.",{"id":634,"title":635,"titles":636,"content":637,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#a-worked-chain","A worked chain",[88],"Archive extraction on File Upload\n  └─ earns: arbitrary file write\n       └─ enables: overwrite a served file\n            └─ earns: stored XSS\n                 └─ enables: an escalation meta-playbook\n                      └─ earns: privileged action on the target\n                           └─ account takeover Each stage was a separate playbook with its own requirements. None of them could fire until the previous one succeeded — and none of them needed to know how the previous one was achieved. The suggestion list only grows as you work through a chain, because earned primitives stay earned.",{"id":639,"title":640,"titles":641,"content":642,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#retraction-and-the-cascade","Retraction and the cascade",[88],"Marking a success is a claim; claims can be corrected. If you retract a success: The yields it granted are revoked from the asset.Every playbook whose requirement depended on a revoked primitive is re-evaluated — downstream suggestions that were standing on that primitive are reverted with it.The history keeps the full trail; nothing about the correction is hidden. This is also why outcomes are recorded honestly in the first place: the cascade only works when the data is true. See Outcomes and History.",{"id":644,"title":225,"titles":645,"content":646,"level":212},"\u002Fplaybooks\u002Fyields-and-primitives#whats-next",[88],"Outcomes and History — recording runs the engine can trust.Chains — how chains are recognized as a methodology.",{"id":93,"title":92,"titles":648,"content":649,"level":206},[],"Recording what actually happened — the feedback loop between a run and the engine.",{"id":651,"title":652,"titles":653,"content":654,"level":212},"\u002Fplaybooks\u002Foutcomes-and-history#three-outcomes","Three outcomes",[92],"Every playbook run ends in one of three states: OutcomeMeaningEffect on the vaultSuccessThe playbook's capability was achievedGrants its yields as primitives; unlocks gated playbooksFailedIt was applicable, but did not work hereThe suggestion is retired — the engine stops surfacing itNot applicableIt is genuinely irrelevant to this assetRetired as noise, without recording a failed test Success earns. Failed and not-applicable prune. Both directions make the vault better: a failed run is still knowledge, and a not-applicable answer removes a suggestion that would otherwise keep asking for attention.",{"id":656,"title":657,"titles":658,"content":659,"level":212},"\u002Fplaybooks\u002Foutcomes-and-history#what-recording-a-run-does","What recording a run does",[92],"Recording an outcome moves the playbook out of the active suggestion list and into the asset's history. From then on: Success stands as evidence — and every playbook gated on its yields now sees them.Failed stays on record: you tested it, it did not apply, the engine reasons with that truth.Retracting a success revokes the yields it granted and cascades through anything that depended on them (see Yields and Primitives). Nothing is deleted. The reasoning trail — what fired, when, and what happened — lives in the playbook's and the asset's history long after you forget the details.",{"id":661,"title":662,"titles":663,"content":664,"level":212},"\u002Fplaybooks\u002Foutcomes-and-history#history-per-asset","History per asset",[92],"Each asset keeps a history with three sections: Playbooks — every run outcome, with its yield trail.Proactive Checklist — prompts you resolved by hand rather than by assignment.Reactive Checklist — component objectives you checked or dismissed. Items stay in history permanently unless you remove them. Removing an entry makes it eligible again — a prompt can ask once more, a dismissed objective can resurface. That is the escape hatch for mistakes, not the default: the record is meant to be trustworthy, so corrections are deliberate. The history is the engine's memory of your evidence. Recording an outcome you did not actually test — a success to unlock a chain, a failed run to quiet a suggestion — corrupts every suggestion that follows. Regressions are worse than omissions here.",{"id":666,"title":667,"titles":668,"content":669,"level":212},"\u002Fplaybooks\u002Foutcomes-and-history#the-discipline","The discipline",[92],"Record outcomes only for playbooks you actually ran.Record them with the yield endpoint when you have it.Prefer \"not applicable\" for noise and \"failed\" for tested-and-didn't-work; the difference matters in the trail.Correct mistakes by retracting — never by leaving a false success in place.",{"id":671,"title":225,"titles":672,"content":673,"level":212},"\u002Fplaybooks\u002Foutcomes-and-history#whats-next",[92],"The loop closes here and reopens at the top: map what you learned, and the engine reasons from better data.",{"id":74,"title":73,"titles":675,"content":676,"level":206},[],"Requirements in, capabilities out — the recipes of your threat library.",{"id":678,"title":679,"titles":680,"content":681,"level":212},"\u002Fplaybooks#a-playbook-is-a-recipe","A playbook is a recipe",[73],"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 observed 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 — earned primitives that feed back into matching. Requirements can be loose or strict: a plain component, a component scoped inside another, a category match, or a co-located requirement. Strictness changes how specific a match is, which changes its rank, but never bypasses a gate.",{"id":683,"title":268,"titles":684,"content":685,"level":212},"\u002Fplaybooks#in-this-section",[73],"Authoring Guide — the detection-path method for building playbooks that fire at the right moment.Requirements — every assignment level and property a requirement can carry.Yields and Primitives — what playbooks produce, and how chains form.Outcomes and History — recording runs honestly, and what each outcome does.",{"id":687,"title":225,"titles":688,"content":689,"level":212},"\u002Fplaybooks#whats-next",[73],"See the machinery that decides which playbook applies: the Nexus Engine.",{"id":105,"title":104,"titles":691,"content":692,"level":206},[],"How matches become ranked, explainable suggestions you can act on.",{"id":694,"title":695,"titles":696,"content":697,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#the-moment-a-match-happens","The moment a match happens",[104],"Every time an asset changes — a component is linked, an endpoint recorded, a prompt resolved — the engine re-evaluates the playbook library against it. A playbook appears as a suggestion only when every required component is satisfied. No partial credit, no \"close enough.\" The result is deterministic: the same library and the same asset always produce the same suggestions in the same order. Nothing is guessed, and nothing changes until the data changes.",{"id":699,"title":700,"titles":701,"content":702,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#ranked-and-explainable","Ranked and explainable",[104],"Suggestions are sorted best-first, and every suggestion can explain itself. Open one and you see the components that matched, how specific each match was, and what the playbook produces if it succeeds. The reasoning is the point — if a match looks wrong, the fix is in your data, and the suggestion list will follow.",{"id":704,"title":705,"titles":706,"content":707,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#what-ranks-a-suggestion-higher","What ranks a suggestion higher",[104],"Ranking reflects specificity and completeness, not just \"how many things matched\": Structure beats volume. A quirk scoped inside the exact technology that owns it is a stronger claim than the same quirk floating somewhere on the asset. Scoped matches outrank flat ones.Category precision. A category + tag requirement is satisfied by fewer things than a bare category — and fires only when the exact subset exists.Endpoint support. A requirement that asks for capabilities to meet on the same endpoint only ranks well when the endpoints actually line up.Quirk pressure. Enabling quirks raise confidence; mitigating quirks lower it. Mitigations weigh heavier in the other direction — one confirmed mitigation can block an exploit, so its absence is treated as more meaningful than a single enabler's presence.Version confidence. With lax version matching an unverified version slightly lowers confidence; with strict matching it removes the candidate entirely. The engine never inflates relevance. If a suggestion is at the top, it is because the evidence you recorded supports it.",{"id":709,"title":710,"titles":711,"content":712,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#partially-satisfied-playbooks","Partially satisfied playbooks",[104],"A playbook whose requirements are partially satisfied does not appear as a weak suggestion — it becomes work. Its missing required components turn into proactive prompts on the asset, ordered by how close they are to unlocking something. That split is deliberate. Suggestions are for playbooks you can act on now; prompts are for the gap between where you are and the next suggestion.",{"id":714,"title":715,"titles":716,"content":717,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#reading-a-suggestion","Reading a suggestion",[104],"The match — which of the playbook's requirements were satisfied, and at what level.The confidence — how specific and complete the evidence is.The yield — the capability the playbook grants if it succeeds, which may unlock gated playbooks (see Yields and Primitives). From here, the loop is run it and record what happened.",{"id":719,"title":225,"titles":720,"content":721,"level":212},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#whats-next",[104],"Checklist and Probes — the other half: what the engine asks you to look for.Requirements — the mechanics behind every match.",{"id":109,"title":108,"titles":723,"content":724,"level":206},[],"The proactive half of the engine — the questions that unlock more suggestions.",{"id":726,"title":727,"titles":728,"content":729,"level":212},"\u002Fnexus-engine\u002Fchecklist-and-probes#reactive-vs-proactive","Reactive vs. proactive",[108],"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":731,"title":732,"titles":733,"content":734,"level":212},"\u002Fnexus-engine\u002Fchecklist-and-probes#prompts-and-probes","Prompts and probes",[108],"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":736,"title":737,"titles":738,"content":739,"level":212},"\u002Fnexus-engine\u002Fchecklist-and-probes#what-happens-after-you-resolve","What happens after you resolve",[108],"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":741,"title":742,"titles":743,"content":744,"level":212},"\u002Fnexus-engine\u002Fchecklist-and-probes#checklist-vs-coverage","Checklist vs. coverage",[108],"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":746,"title":225,"titles":747,"content":748,"level":212},"\u002Fnexus-engine\u002Fchecklist-and-probes#whats-next",[108],"Work a Prompt — the practical discipline.",{"id":97,"title":101,"titles":750,"content":751,"level":206},[],"Deterministic matching, ranked suggestions, and the proactive checklist.",{"id":753,"title":754,"titles":755,"content":756,"level":212},"\u002Fnexus-engine#rules-not-guesses","Rules, not guesses",[101],"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":758,"title":268,"titles":759,"content":760,"level":212},"\u002Fnexus-engine#in-this-section",[101],"Suggestions and Ranking — how matches become ranked, explainable suggestions.Checklist and Probes — the proactive half: prompts and how to answer them.",{"id":762,"title":763,"titles":764,"content":765,"level":212},"\u002Fnexus-engine#how-a-match-happens","How a match happens",[101],"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":767,"title":768,"titles":769,"content":770,"level":212},"\u002Fnexus-engine#the-proactive-checklist","The proactive checklist",[101],"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":772,"title":773,"titles":774,"content":775,"level":212},"\u002Fnexus-engine#why-it-compounds","Why it compounds",[101],"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":777,"title":225,"titles":778,"content":779,"level":212},"\u002Fnexus-engine#whats-next",[101],"Put it to work: map an asset, then work a prompt.",{"id":113,"title":112,"titles":781,"content":782,"level":206},[],"Where observations live, and the data that makes matches precise.",{"id":784,"title":785,"titles":786,"content":787,"level":212},"\u002Fnotespaces#every-entity-has-a-notespace","Every entity has a notespace",[112],"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":789,"title":790,"titles":791,"content":792,"level":212},"\u002Fnotespaces#links-carry-the-context","Links carry the context",[112],"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":794,"title":795,"titles":796,"content":797,"level":212},"\u002Fnotespaces#instances","Instances",[112],"A component can occur more than once on an asset — three uploads, two APIs, several endpoints running the same service. Each occurrence is an instance, and endpoints are recorded per instance. Instances are what co-location reasons about: \"these two capabilities meet on the same endpoint\" is a statement about occurrences, not about components in general. Two capabilities that exist on an asset but never share an endpoint are not a chain.",{"id":799,"title":800,"titles":801,"content":802,"level":212},"\u002Fnotespaces#why-endpoints-matter","Why endpoints matter",[112],"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":804,"title":805,"titles":806,"content":807,"level":212},"\u002Fnotespaces#probes","Probes",[112],"Component notespaces carry probes — short, reusable notes about how to check for that component on a target. When a checklist prompt asks you to confirm a specific component, its probes are one click away, so the \"how would I even check this\" knowledge travels with the prompt instead of living in your head.",{"id":809,"title":225,"titles":810,"content":811,"level":212},"\u002Fnotespaces#whats-next",[112],"Playbooks — the recipes that consume all of this.",{"id":126,"title":125,"titles":813,"content":814,"level":206},[],"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":816,"title":817,"titles":818,"content":819,"level":212},"\u002Fguides\u002Fmap-an-asset#variations","Variations",[125],"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":821,"title":225,"titles":822,"content":823,"level":212},"\u002Fguides\u002Fmap-an-asset#whats-next",[125],"The engine now has something to think about: work the prompts it generates.",{"id":130,"title":129,"titles":825,"content":826,"level":206},[],"Resolve the proactive checklist accurately — positives unlock playbooks, negatives hide them.",{"id":828,"title":829,"titles":830,"content":831,"level":212},"\u002Fguides\u002Fwork-a-prompt#what-a-prompt-is","What a prompt is",[129],"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":134,"title":133,"titles":833,"content":834,"level":206},[],"Execute a suggestion and record the outcome — so the vault learns from every attempt.",{"id":836,"title":837,"titles":838,"content":839,"level":212},"\u002Fguides\u002Frun-a-playbook#before-you-start","Before you start",[133],"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":841,"title":842,"titles":843,"content":844,"level":212},"\u002Fguides\u002Frun-a-playbook#retracting","Retracting",[133],"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":846,"title":225,"titles":847,"content":848,"level":212},"\u002Fguides\u002Frun-a-playbook#whats-next",[133],"Keep the loop tight: back to mapping as you discover more.See the full vocabulary in the glossary.",{"id":138,"title":137,"titles":850,"content":851,"level":206},[],"Use the command center to find anything in the vault — and to hunt horizontally.",{"id":853,"title":854,"titles":855,"content":856,"level":212},"\u002Fguides\u002Fcommand-center-and-search#one-search-across-everything","One search across everything",[137],"The command center opens with Cmd K (Ctrl K on Windows\u002FLinux). It searches the entire workspace at once — platforms, programs, assets, every component type, and playbooks — and every result opens directly. Type plain text to search names, or add filters to slice the vault. Filters combine with AND: type:playbook difficulty:high means high-difficulty playbooks only. Negation works on tags and presence: !tag:wip, !has:quirk.",{"id":858,"title":859,"titles":860,"content":861,"level":212},"\u002Fguides\u002Fcommand-center-and-search#finding-the-thing-in-front-of-you","Finding the thing in front of you",[137],"has:functionality:\"File Upload\" — every entity connected to file uploads.type:asset priority:critical — the assets that matter most.version:>=14 — technology links at or above a version.created:7d \u002F updated:30d — what changed recently. Autocomplete (press Tab) completes filter names and values, and active filters appear as chips you can clear individually. The complete grammar lives in the search syntax reference.",{"id":863,"title":864,"titles":865,"content":866,"level":212},"\u002Fguides\u002Fcommand-center-and-search#hunting-horizontally","Hunting horizontally",[137],"The command center is also the fastest way to answer cross-workspace questions — the ones a single asset page can never answer: \"Where is this technology?\" — has:technology:Caddy across every program at once.\"What did we tag as needing review?\" — !tag:reviewed or a status filter, depending on what you track.\"What does the library connect to?\" — has:gadget:\"GraphQL endpoint\" to see every asset and playbook that touches it. This is the moment the vault pays you back: knowledge that was entered engagement by engagement becomes queryable across all of them.",{"id":868,"title":869,"titles":870,"content":871,"level":212},"\u002Fguides\u002Fcommand-center-and-search#practical-habits","Practical habits",[137],"Filter, then read. Text alone floods; one or two filters turn the vault into an answer.Quote multi-word values — has:func:\"File Upload\".Use the chips to iterate. Build a query in the box, then refine by clearing the one filter that is too narrow.Everything is a result. If it exists in the vault — an asset, a component, a playbook, a platform — search returns it.",{"id":873,"title":225,"titles":874,"content":875,"level":212},"\u002Fguides\u002Fcommand-center-and-search#whats-next",[137],"Search syntax reference — every filter, alias, and operator.Map an asset — keep the vault worth searching.",{"id":142,"title":141,"titles":877,"content":878,"level":206},[],"Organize platforms, programs, and assets so the rest of the vault has a place to live.",{"id":880,"title":881,"titles":882,"content":883,"level":212},"\u002Fguides\u002Fmanage-your-scope#the-shape-of-the-work","The shape of the work",[141],"Everything in the vault hangs off the scope hierarchy: platform → program → asset. You rarely revisit it once it is set up, but a sloppy hierarchy makes every later step worse. A platform is where the work comes from: a bug bounty platform, a VDP, a private client. Capture the essentials — name, description, and the program's currency — and move on. Platforms are containers, not analysis.\n  \n  \n    A program is one organization's scope. Set the **program type** (bug bounty, VDP, or pentest), its status, and the practical details — rewards range, program URL, and the asset types it covers. This is where the rules of engagement live.\n  \n  \n    An asset is one thing you test: a host, an API, an app, a repository. Choose the **asset type** (Web, API, Mobile iOS\u002FAndroid, Desktop, Cloud Infrastructure, Network\u002FVPN, Smart Contract, Hardware\u002FIoT, Source Code Repository, and more) and set a **priority** if it deserves one. Name assets the way you think about them — the engine works with whatever is concrete.\n  \n  \n    Real targets have structure: subdomains belong to a domain, an API belongs to an app. Nest assets under a parent instead of flattening everything into the program — a capability recorded on a child sharpens what the engine knows about the parent without duplicating records.\n  \n  \n    A **Wildcard** is a special asset type for grouping: its name must be a pattern like `*.example.com`, and it is a container rather than a tracked target. Concrete URLs live under it as Web assets. This keeps broad scopes organized without pretending the wildcard is something you test directly.",{"id":885,"title":886,"titles":887,"content":888,"level":212},"\u002Fguides\u002Fmanage-your-scope#getting-a-list-in","Getting a list in",[141],"If you already maintain a target list, import it rather than retyping: a CSV import brings assets in, and you can map components to them afterward. Import first, then map the ones worth pursuing.",{"id":890,"title":891,"titles":892,"content":893,"level":212},"\u002Fguides\u002Fmanage-your-scope#habits-that-pay-off","Habits that pay off",[141],"Concrete names. api.example.com beats \"the API\". The engine ranks precision, and it starts with what you called things.Priorities are triage. Nothing stops you from mapping everything, but priority focuses which assets get attention first.Tags and favorites on platforms and programs keep large scopes navigable as they grow.One workspace per context — client boundaries are worth preserving, and cloning makes the setup cheap (see Clone a Workspace).",{"id":895,"title":225,"titles":896,"content":897,"level":212},"\u002Fguides\u002Fmanage-your-scope#whats-next",[141],"With the scope in place, the real work starts: map an asset.",{"id":146,"title":145,"titles":899,"content":900,"level":206},[],"Invite teammates, share single entities, and keep a visible trail.",{"id":902,"title":903,"titles":904,"content":905,"level":212},"\u002Fguides\u002Fshare-and-collaborate#working-in-a-shared-workspace","Working in a shared workspace",[145],"A workspace is built to be shared. The value compounds when the mapping, the library, and the outcomes are everyone's — one person's observation unlocks another person's suggestion.",{"id":907,"title":220,"titles":908,"content":909,"level":503},"\u002Fguides\u002Fshare-and-collaborate#members-and-roles",[145,903],"Invite teammates from workspace settings by email — or share the workspace invite link, which lets anyone holding it join. Each invite carries a role: Admin — manages workspace settings, members, and everything inside.Member — full access to the vault's content. Invites have an expiry and a status (pending, accepted, declined, revoked, expired), and pending invites are visible from your sidebar avatar, so you always know who has not joined yet. Admins can also review activity in the workspace's audit log.",{"id":911,"title":912,"titles":913,"content":914,"level":503},"\u002Fguides\u002Fshare-and-collaborate#what-sharing-looks-like-in-practice","What sharing looks like in practice",[145,903],"The library is the team's memory. A component mapped by one hunter is available to everyone's assets.Playbooks are institutional knowledge. Outcomes and yields accumulate against a shared threat library.Suggestions are personal where it matters. Your assets and your hunt stay yours; the knowledge underneath is shared.",{"id":916,"title":917,"titles":918,"content":919,"level":212},"\u002Fguides\u002Fshare-and-collaborate#sharing-a-single-entity","Sharing a single entity",[145],"Sometimes you want a second pair of eyes without inviting someone into everything. Any entity — an asset, a playbook, a component — can be shared as a link: The link opens a read-only snapshot: notes, links, and structure as they were shared.Recipients authenticate if they are not signed in, then land back on the snapshot.Snapshots can carry an expiry, so links are not forever. This is the \"show, don't invite\" path: useful for triage opinions, client reviews, or handing off context around a single finding.",{"id":921,"title":922,"titles":923,"content":924,"level":212},"\u002Fguides\u002Fshare-and-collaborate#keeping-it-healthy","Keeping it healthy",[145],"Give roles deliberately. Admin is for the people who should change settings and membership.Share knowledge, not just assets. The compounding only works when observations land in the shared library.Use expiry on snapshot links for anything client-facing.",{"id":926,"title":225,"titles":927,"content":928,"level":212},"\u002Fguides\u002Fshare-and-collaborate#whats-next",[145],"Clone a Workspace — start the next engagement from a known-good setup.Account and Workspaces — roles and plan basics.",{"id":150,"title":149,"titles":930,"content":931,"level":206},[],"Start an engagement from your best setup instead of an empty vault.",{"id":933,"title":934,"titles":935,"content":936,"level":212},"\u002Fguides\u002Fclone-a-workspace#why-clone","Why clone",[149],"A tuned vault — the component library you trust, the playbooks that actually fire, a scope structure that matches how you work — is a head start. Cloning copies it into a fresh workspace so the next engagement begins from your best state, not from zero.",{"id":938,"title":939,"titles":940,"content":941,"level":212},"\u002Fguides\u002Fclone-a-workspace#what-you-can-take-with-you","What you can take with you",[149],"Open Workspace Settings → Clone Workspace. You choose which parts come along: Programs & Assets — platforms, programs, assets, and their notes and observations.Components — the component library.Playbooks — the threat library, with requirements and yields. All three are selected by default; deselect what you don't need. Cross-references are handled for you: if a cloned link points at something you did not select, the reference is pruned cleanly — never left dangling, never silently pulling in things you excluded. The whole clone runs as a single operation, so a half-cloned workspace cannot happen.",{"id":943,"title":944,"titles":945,"content":946,"level":212},"\u002Fguides\u002Fclone-a-workspace#when-to-clone","When to clone",[149],"New engagement, same playbook. Keep the library and the team's playbooks; bring a fresh scope.Client templates. Maintain a well-curated base workspace and branch it per client.Experiments. Duplicate before a big restructure; the original is untouched. Cloning creates a new workspace, so your plan's workspace ownership limit applies — Free accounts own one workspace, Pro accounts up to five. See [Account and Workspaces](\u002Fgetting-started\u002Faccount-and-workspaces).",{"id":948,"title":225,"titles":949,"content":950,"level":212},"\u002Fguides\u002Fclone-a-workspace#whats-next",[149],"Manage Your Scope — shape the fresh clone.Share and Collaborate — bring the team in.",{"id":119,"title":118,"titles":952,"content":953,"level":206},[],"Task-by-task walkthroughs for the core Nimbus Vault loop.",{"id":955,"title":956,"titles":957,"content":958,"level":212},"\u002Fguides#the-loop-step-by-step","The loop, step by step",[118],"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.Search the Workspace — the command center, and how to hunt horizontally.Manage Your Scope — platforms, programs, assets, and wildcard containers.Share and Collaborate — members, roles, and snapshot links.Clone a Workspace — start from your best setup, not zero.",{"id":161,"title":160,"titles":960,"content":961,"level":206},[],"Every Nimbus Vault term in one place.",{"id":963,"title":964,"titles":965,"content":966,"level":212},"\u002Freference\u002Fglossary#targets","Targets",[160],"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 container asset type: a pattern like *.example.com that groups concrete assets beneath it; not a tracked target itself.",{"id":968,"title":969,"titles":970,"content":971,"level":212},"\u002Freference\u002Fglossary#library","Library",[160],"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":973,"title":974,"titles":975,"content":976,"level":212},"\u002Freference\u002Fglossary#engine","Engine",[160],"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. Yield-gating — a requirement satisfied only by an earned primitive, never by a manually assigned component. Chain — a sequence of playbooks where each success earns a capability the next one requires. Meta-playbook — a playbook that consumes a primitive regardless of how it was earned. Engine mode — the workspace setting for version matching: Lax includes unverified versions with a confidence penalty; Strict excludes them. 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":978,"title":979,"titles":980,"content":981,"level":212},"\u002Freference\u002Fglossary#work","Work",[160],"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. Instance — one occurrence of a component on an asset, per endpoint; instances are what co-location reasons about. Probe — a reusable note on a component describing how to check for it; surfaced alongside checklist prompts. 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":165,"title":164,"titles":983,"content":984,"level":206},[],"Every filter in the command center, with examples. The command center (Cmd K) searches the whole workspace. Plain text matches names; filters slice by field. Filters combine with AND — every condition must hold.",{"id":986,"title":987,"titles":988,"content":989,"level":212},"\u002Freference\u002Fsearch-syntax#entity-types","Entity types",[164],"FilterValuesAliasestype:platform, program, asset, technology, functionality, gadget, vector, quirk, playbookplat, prog, tech, func \u002F fn, vuln for quirks type:* matches any entity type.type:playbook difficulty:high — high-difficulty playbooks.type:asset priority:critical — your most important assets.",{"id":991,"title":992,"titles":993,"content":994,"level":212},"\u002Freference\u002Fsearch-syntax#presence","Presence",[164],"FilterMeaningExamplehas:Has a specific linked componenthas:functionality:\"File Upload\"!has:Does not have it!has:quirktag:Carries a tagtag:oauth!tag:Does not carry it!tag:reviewed has: combines a type and a value: has:technology:Node.js, has:quirk:\"Prototype pollution\". Quote multi-word values. Negation is supported for has: and tag: only.",{"id":996,"title":563,"titles":997,"content":998,"level":212},"\u002Freference\u002Fsearch-syntax#properties",[164],"FilterApplies toExampleasset-type:Assetsasset-type:apipriority:Assetspriority:highseverity:Playbooksseverity:criticaldifficulty:Playbooksdifficulty:high or difficulty:7program-type:Programsprogram-type:vdpstatus:Programsstatus:activecategory:Componentscategory:authenticationvendor:Technology linksvendor:ApacheisStateful:QuirksisStateful:true",{"id":1000,"title":1001,"titles":1002,"content":1003,"level":212},"\u002Freference\u002Fsearch-syntax#version","Version",[164],"version: filters technology links by the version you recorded (not the latest available): version:14.17.0 — exactversion:>=14 \u002F version:\u003C19 — comparisonsversion:14.x — series",{"id":1005,"title":1006,"titles":1007,"content":1008,"level":212},"\u002Freference\u002Fsearch-syntax#link-modes","Link modes",[164],"Find components by how they are observed: FilterMeaning@clqComponent-level quirks (scoped quirks)@clvComponent-level vectors (scoped vectors)@clvvNested vectors@clvqQuirks on scoped vectors",{"id":1010,"title":1011,"titles":1012,"content":1013,"level":212},"\u002Freference\u002Fsearch-syntax#time","Time",[164],"FilterMeaningcreated:meCreated by youcreated:user:\u003Cname>Created by a teammatecreated:7dCreated in the last N days\u002Fweeks\u002Fmonths (d, w, m)updated:30dUpdated in the last N days\u002Fweeks\u002Fmonths",{"id":1015,"title":1016,"titles":1017,"content":1018,"level":212},"\u002Freference\u002Fsearch-syntax#interaction","Interaction",[164],"Two-character minimum for free-text search.Enter opens the top result; arrows move the selection.Tab accepts an autocomplete suggestion; filter names and values complete as you type.Active filters appear as chips — clear them individually to widen a query.Esc closes the command center.",{"id":1020,"title":1021,"titles":1022,"content":1023,"level":212},"\u002Freference\u002Fsearch-syntax#examples","Examples",[164],"type:playbook severity:critical tag:rce\nhas:functionality:\"File Upload\" version:>=14\nasset-type:web priority:critical !tag:reviewed\ncreated:user:alex updated:7d\ntype:quirk isStateful:true @clq",{"id":169,"title":168,"titles":1025,"content":1026,"level":206},[],"What lives in account settings vs. workspace settings.",{"id":1028,"title":1029,"titles":1030,"content":1031,"level":212},"\u002Freference\u002Fsettings#account-settings","Account settings",[168],"Open from your avatar. Personal to you, across every workspace: TabWhat it coversProfileYour identity — display name, photo, and account detailsPreferencesYour personal preferences for the appInvitesWorkspace invitations waiting on you — accept or declineDelete AccountAccount deletion (email-code confirmed)",{"id":1033,"title":1034,"titles":1035,"content":1036,"level":212},"\u002Freference\u002Fsettings#workspace-settings","Workspace settings",[168],"Open from the workspace menu. Shared by every member: TabWhat it coversGeneralWorkspace name, description, and identityMembersMembership and roles — invite, remove, change roles, transfer ownershipInvitationsEmail invitations and the invite link; pending invites can be resent or revokedNexus EngineThe engine mode: Lax or Strict version matchingDashboardCoverage thresholds used by Attack CoverageIntegrationsAgent connections Danger actions — leaving the workspace, transferring ownership, and deleting the workspace — live at the bottom, behind confirmation. Deleting a workspace is not a per-member action to take casually. Prefer [cloning](\u002Fguides\u002Fclone-a-workspace) or exporting when you only need a fresh start.",{"id":1038,"title":1039,"titles":1040,"content":1041,"level":212},"\u002Freference\u002Fsettings#plan-limits","Plan limits",[168],"FreeProOwned workspaces15Agent connections (per member, per workspace)—10 (expiry required by default) Membership in other people's workspaces is not limited — the cap applies to workspaces you own.",{"id":173,"title":172,"titles":1043,"content":1044,"level":206},[],"What each number on the dashboard means — and what to do about it.",{"id":1046,"title":1047,"titles":1048,"content":1049,"level":212},"\u002Freference\u002Fdashboard-metrics#attack-coverage","Attack Coverage",[172],"Which mapped components have playbook attack coverage. Every component in your library is classified by how many playbooks cover it: Mature — well covered; if this component appears on an asset, the engine has plenty to say.Developing — partially covered; a thin spot worth growing.Gap — zero playbook coverage; the library knows the component but not what to do with it. The Mature and Developing thresholds are adjustable in Workspace Settings → Dashboard — tune them to how you want the library judged.",{"id":1051,"title":1052,"titles":1053,"content":1054,"level":212},"\u002Freference\u002Fdashboard-metrics#blind-spots","Blind Spots",[172],"Mapped asset components that still have zero playbook coverage. Attack Coverage looks at the library; Blind Spots looks at your live assets: components you have already observed on real targets that no playbook can act on yet. Hover an asset to inspect which components are uncovered. A blind spot is the most actionable metric on the page: you already did the recon, the context exists, and the only missing piece is a playbook.",{"id":1056,"title":1057,"titles":1058,"content":1059,"level":212},"\u002Freference\u002Fdashboard-metrics#playbook-coverage-rate","Playbook Coverage Rate",[172],"The percentage of suggested playbooks that have been attempted — marked with success, failure, or not-applicable. Per asset, with navigation between assets. A low rate means suggestions are piling up unexamined: surface area you have mapped but not tested. It is not a score to maximize — testing everything is not the goal — but a low rate with high-priority assets is a signal.",{"id":1061,"title":1062,"titles":1063,"content":1064,"level":212},"\u002Freference\u002Fdashboard-metrics#knowledge-velocity","Knowledge Velocity",[172],"How quickly the workspace is gaining new knowledge — notes, links, checklist objectives, and notespaces created over the last 30 days. Useful as a personal rhythm check: mapping compounds, and this measures how often you are adding to the pile.",{"id":1066,"title":1067,"titles":1068,"content":1069,"level":212},"\u002Freference\u002Fdashboard-metrics#popular-components","Popular Components",[172],"The top five most-used components per type, ranked by how many assets they are mapped to. It is a quick read on what your engagements actually consist of — and a hint about which components most deserve great playbook coverage.",{"id":177,"title":176,"titles":1071,"content":1072,"level":206},[],"Quick answers to the questions that come up most.",{"id":1074,"title":1075,"titles":1076,"content":1077,"level":503},"\u002Freference\u002Ffaq#why-doesnt-a-playbook-i-know-applies-show-up-as-a-suggestion","Why doesn't a playbook I know applies show up as a suggestion?",[176],"Suggestions only exist when every required component is satisfied. The usual causes, in order: A missing required component — check the asset's checklist; partially satisfied playbooks appear there as prompts.A scoped requirement on the wrong parent — a scoped quirk or vector must be linked inside the exact parent the playbook requires (Scopes and Levels).Strict version matching — with engine mode set to Strict, technologies whose version is unverified never satisfy a versioned requirement (Requirements).Co-location without endpoints — if a requirement demands the same endpoint as a primitive, missing endpoint data means no match.",{"id":1079,"title":1080,"titles":1081,"content":1082,"level":503},"\u002Freference\u002Ffaq#why-did-a-suggestion-disappear","Why did a suggestion disappear?",[176],"Either you recorded an outcome for it — success, failed, or not applicable — which moves it to the asset's history, or the underlying data changed. Check the history first; if an outcome was wrong, retract it and the suggestion returns (Outcomes and History).",{"id":1084,"title":1085,"titles":1086,"content":1087,"level":503},"\u002Freference\u002Ffaq#why-doesnt-my-scoped-quirk-match-the-playbook","Why doesn't my scoped quirk match the playbook?",[176],"Scoped matching is strict about parentage. Prototype pollution scoped inside Node.js does not satisfy a requirement for the same quirk inside a different technology — even if the quirk name matches. Re-check where the requirement is anchored.",{"id":1089,"title":1090,"titles":1091,"content":1092,"level":503},"\u002Freference\u002Ffaq#is-the-nexus-engine-an-ai-can-it-find-bugs-for-me","Is the Nexus Engine an AI? Can it find bugs for me?",[176],"No. It is a deterministic, rule-based expert system — the same data always produces the same suggestions, with no model guessing in between. It cannot find what you have not modeled: unencoded threats are invisible by definition. It makes the knowledge you do encode impossible to forget.",{"id":1094,"title":1095,"titles":1096,"content":1097,"level":503},"\u002Freference\u002Ffaq#failed-or-not-applicable-whats-the-difference","Failed or not applicable — what's the difference?",[176],"Failed means you tested it and it did not work on this asset. Not applicable means the playbook is genuinely irrelevant here — you are not recording a failed test. Both retire the suggestion, but they say different things in the history.",{"id":1099,"title":1100,"titles":1101,"content":1102,"level":503},"\u002Freference\u002Ffaq#how-do-i-undo-a-recorded-outcome","How do I undo a recorded outcome?",[176],"Retract it from the asset's history. Retracting a success revokes the yields it granted and cascades through anything that depended on them (Yields and Primitives).",{"id":1104,"title":1105,"titles":1106,"content":1107,"level":503},"\u002Freference\u002Ffaq#why-cant-i-create-another-workspace","Why can't I create another workspace?",[176],"Workspace ownership is limited by plan: Free accounts own one workspace, Pro accounts up to five. Cloning creates a new workspace, so it counts too.",{"id":1109,"title":1110,"titles":1111,"content":1112,"level":503},"\u002Freference\u002Ffaq#how-do-ai-agents-access-my-workspace","How do AI agents access my workspace?",[176],"Through connections in Workspace Settings → Integrations — Pro feature, capped per member, scoped to the workspace, with capability toggles, expiry, revocation, and an audit trail.",{"id":154,"title":153,"titles":1114,"content":1115,"level":206},[],"Lookup material — the vocabulary, and the details behind the workflow.",{"id":1117,"title":1118,"titles":1119,"content":1120,"level":212},"\u002Freference#quick-lookups","Quick lookups",[153],"Glossary — every Nimbus Vault term, defined.Search Syntax — every command-center filter, with examples.Settings — account vs. workspace settings, and plan limits.Dashboard Metrics — what each number means.FAQ — the questions that come up most.",{"id":188,"title":187,"titles":1122,"content":1123,"level":206},[],"Component Analysis & Vulnerability Enumeration Technique — the ontology and workflow behind Nimbus Vault.",{"id":1125,"title":1126,"titles":1127,"content":1128,"level":212},"\u002Fmethodology\u002Fcavet#what-cavet-is","What CAVET is",[187],"CAVET — Component Analysis & Vulnerability Enumeration Technique — is a systematic approach to offensive security testing. It answers one central question: What components are present, what properties do they have, and which attacks do these enable? Where defensive frameworks model what could go wrong during design, CAVET models what is testable during an engagement: it is evidence-based, built from observations of the running system.",{"id":1130,"title":1131,"titles":1132,"content":1133,"level":212},"\u002Fmethodology\u002Fcavet#the-five-components","The five components",[187],"CAVET's ontology is the same one Nimbus Vault's component library is built on. Each type isn't just a category — it plays a distinct role in how vulnerabilities come to exist. Technologies — the constraint space. The frameworks, languages, platforms, and infrastructure a target runs on. More than \"what it's built with\": technologies define the universe of what is possible and impossible — the constraint space attacks must live inside. Functionalities — trust boundaries. The discrete things the app does for users: login, upload, search, payments. Each is a boundary where the application accepts external input and makes a promise about what it will do with it. Vulnerabilities are broken promises. Gadgets — unintended capabilities. Mechanisms built for legitimate purposes that can be repurposed: innerHTML, eval(), postMessage bridges, deserialization, URLs the server fetches. Gadgets are the force multipliers that escalate simple bugs into impact. Vectors — the application's perception system. How attacker-controlled input reaches the application and how responses travel back: parameters, headers, cookies, bodies, file metadata. Vectors are the lenses through which the app sees the world — the same payload behaves differently depending on which lens it arrives through. Quirks — emergent properties and ground truth. What testing reveals about how the components actually behave: reflects input without encoding, no CSRF token present, accepts __proto__, CSP blocks inline scripts. Quirks are what is — and they come in two directions: enabling and mitigating.",{"id":1135,"title":1136,"titles":1137,"content":1138,"level":212},"\u002Fmethodology\u002Fcavet#the-workflow","The workflow",[187],"The ontology is half of CAVET. The other half is the order of operations: Observe — map the technologies, functionalities, gadgets, and vectors systematically.Probe — test the observed surface to discover its quirks.Reason — match the confirmed context against known attack patterns.Test — execute against the patterns that the context supports, and only those. The order is not a suggestion. You cannot reason about which attacks apply without knowing the quirks; you cannot probe for the properties of something you haven't observed. Skipping or rearranging the stages is what produces guesswork — payloads sprayed at inputs that were never contextualized. And the cycle repeats: testing produces new observations, probing confirms new quirks, and the context gets sharper every pass.",{"id":1140,"title":1141,"titles":1142,"content":1143,"level":212},"\u002Fmethodology\u002Fcavet#from-theory-to-practice","From theory to practice",[187],"CAVET wasn't always this formal. It began as \"contextual hacking\" — a way of describing how experienced hunters actually work — and only later acquired its ontology and workflow. The formalization is what makes it teachable: Map write-ups into components. Deconstructing a public report into technologies, functionalities, gadgets, vectors, and quirks is the fastest way to internalize the ontology.A missed quirk is the tell. If a write-up's decisive detail was a behavior you hadn't considered, the gap is in your probing, not your payloads.Synthesis is the goal. The final skill is constructing a hypothetical bug from components alone — before you have seen it.",{"id":1145,"title":1146,"titles":1147,"content":1148,"level":212},"\u002Fmethodology\u002Fcavet#how-nimbus-vault-implements-it","How Nimbus Vault implements it",[187],"The Component Library is the mapping layer — observations structured by the five types.The Threat Library is the knowledge layer — playbooks that encode attack patterns in the same language.The Nexus Engine is the logic layer — deterministic matching that connects the two. That correspondence is the point: the tool is not a companion to the methodology, it is the methodology made operational.",{"id":1150,"title":225,"titles":1151,"content":1152,"level":212},"\u002Fmethodology\u002Fcavet#whats-next",[187],"Contextual Hacking — where this way of working began.Chain Recognition — the compound case.",{"id":192,"title":191,"titles":1154,"content":1155,"level":206},[],"Hunt the context that creates vulnerabilities, not the vulnerability class.",{"id":1157,"title":1158,"titles":1159,"content":1160,"level":212},"\u002Fmethodology\u002Fcontextual-hacking#the-methodology-gap","The methodology gap",[191],"Most bug bounty education teaches isolated techniques: a video on SQL injection, a write-up on IDOR, a lab on XSS. The pieces are real, but nothing connects them into a process. The result is a familiar set of symptoms — scattered notes, bookmarked techniques you never revisit, and lab skills that never quite transfer to a live target. The failure mode has a name: single-vulnerability tunnel vision. \"Pick one vulnerability class and hunt it\" is common advice, and well-intentioned — but without the missing step, it turns every input field into \"the perfect spot for XSS,\" even in an application that handles input perfectly. The missing step is context. The advice should be: stick to one vulnerability class, but learn the context that gives birth to it.",{"id":1162,"title":1163,"titles":1164,"content":1165,"level":212},"\u002Fmethodology\u002Fcontextual-hacking#vulnerabilities-depend-on-context","Vulnerabilities depend on context",[191],"Every vulnerability class has conditions it needs: An OAuth flaw only exists where OAuth exists and is misconfigured.A race condition needs asynchronous processing colliding with critical state.SSRF lives in applications that make outbound requests from user input. None of these are lurking \"everywhere.\" They are born from specific interactions between technologies, functionalities, gadgets, vectors, and quirks — the CAVET components. So the working method inverts: instead of forcing a technique onto a target, you map the application's context and let it reveal the attack paths it actually supports. Hunting for context lets the vulnerabilities find you. This is what experienced hunters do instinctively: recon first, analyze patterns, choose techniques from evidence. Contextual hacking makes the instinct explicit — and makes a failed hypothesis productive, because the context you mapped is reusable knowledge regardless of which attack it eventually supports.",{"id":1167,"title":1168,"titles":1169,"content":1170,"level":212},"\u002Fmethodology\u002Fcontextual-hacking#map-the-context-then-test","Map the context, then test",[191],"Contextual hacking has a practical loop: Map — technologies, functionalities, gadgets, vectors, quirks. The same five types used everywhere in Nimbus Vault.Probe — test the mapped surface for the properties (quirks) that decide exploitability.Reason — hold the context against your library of attack patterns.Test — apply the techniques the context supports, with probing, bypass, and exploitation techniques as your toolkit. Techniques are still essential — they are how you probe, bypass, and exploit. What contextual hacking changes is when they enter: after the context says they apply, not before. (\"Apply first, understand second\" is how you waste an engagement; the loop above is the alternative.)",{"id":1172,"title":1173,"titles":1174,"content":1175,"level":212},"\u002Fmethodology\u002Fcontextual-hacking#the-team-version","The team version",[191],"The same idea scales past one person. A shared context base — where every mapped component, confirmed quirk, and tested technique compounds — means knowledge stops being personal and starts being infrastructural: A teammate's earlier finding surfaces on your target because the components match.Nothing learned is forgotten, and nothing is relearned.The workspace gets smarter with every engagement, not just the individual. That last property — knowledge that compounds relationally instead of accumulating as notes — is the \"context engine\" idea Nimbus Vault is built on.",{"id":1177,"title":225,"titles":1178,"content":1179,"level":212},"\u002Fmethodology\u002Fcontextual-hacking#whats-next",[191],"The CAVET Method — the formal ontology and workflow.Chain Recognition — what happens when findings compose.",{"id":196,"title":195,"titles":1181,"content":1182,"level":206},[],"How earned capabilities turn isolated findings into compound attack paths.",{"id":1184,"title":1185,"titles":1186,"content":1187,"level":212},"\u002Fmethodology\u002Fchain-recognition#why-chains-are-invisible","Why chains are invisible",[195],"A single-vulnerability view of a target has a blind spot: the interesting bugs are often compounds. A low-impact write becomes a zero-click takeover when it can reach a served file; an XSS in a low-value frame becomes an admin compromise when a postMessage bridge carries it into the main app; a missing re-authentication check turns an email swap into an account takeover. Component matching alone struggles with this. It can surface each playbook that applies, but it has no language for \"these two things together are a chain\" — because the second step only becomes true after the first one succeeds.",{"id":1189,"title":1190,"titles":1191,"content":1192,"level":212},"\u002Fmethodology\u002Fchain-recognition#earned-capabilities","Earned capabilities",[195],"The insight behind chain recognition is that some things become true about a target only when you achieve them. These are primitives: fundamental capabilities like arbitrary file write, or execution in a victim's browser, that you earn by successfully weaponizing a vulnerability. So playbooks declare what they yield on success, and the engine treats those yields as new matching signals: Zip Slip playbook            → success → yields: arbitrary file write\n  └─ overwrite-a-served-file playbook\n       (requires the earned primitive)\n                             → success → yields: stored XSS\n            └─ escalation meta-playbook\n                 (requires the earned primitive)\n                             → leads to account takeover The engine doesn't need to know the whole chain upfront. It follows the primitive graph one step at a time — and each success unlocks the next suggestion automatically. See Yields and Primitives for the mechanics.",{"id":1194,"title":1195,"titles":1196,"content":1197,"level":212},"\u002Fmethodology\u002Fchain-recognition#why-gating-matters","Why gating matters",[195],"Without yield-gating, a chain playbook that requires \"stored XSS\" would fire on any asset where a hunter manually noted stored XSS — even if the delivery path the chain assumes doesn't exist. That's noise. Yield-gating fixes it: a gated requirement is satisfied only by a capability that was actually earned. The chain stays invisible until the foundation has been demonstrated on this target.",{"id":1199,"title":630,"titles":1200,"content":1201,"level":212},"\u002Fmethodology\u002Fchain-recognition#meta-playbooks",[195],"Escalation knowledge doesn't care how the primitive was acquired. A stored-XSS escalation playbook applies whether the XSS came from an archive overwrite, a vulnerable username field, or an upload — any path that earns stored-xss feeds it. This is the meta-playbook pattern: write the escalation once, and every route to that primitive inherits it. As more playbooks yield the same primitive, the escalation playbook gets more valuable without being touched.",{"id":1203,"title":1204,"titles":1205,"content":1206,"level":212},"\u002Fmethodology\u002Fchain-recognition#what-chains-look-like","What chains look like",[195],"Compound paths tend to hide in the same places — worth keeping in the back of your head while mapping: A write that reaches a served surface — archive extraction, file overwrite, template injection: the question is whether what you wrote is ever read or executed.A trust bridge between contexts — postMessage handlers, iframes, subdomain-to-subdomain flows: weak origin checks turn a low-value frame into a foothold in the main app.Identity flows without re-authentication — email change, password reset, invite flows: the pivot from \"some execution\" to \"account takeover\" is often a missing confirmation, not a missing exploit.Parser and semantic differences — duplicate parameters, normalization mismatches, type coercion: two components that disagree about what the same input means. None of these are playbooks — they are shapes that recurring chains take. Recognizing the shape is how you know which primitives are worth pursuing on a target.",{"id":1208,"title":225,"titles":1209,"content":1210,"level":212},"\u002Fmethodology\u002Fchain-recognition#whats-next",[195],"Worked Chains — the shapes above, told as full narratives.Yields and Primitives — the mechanics behind everything on this page.Authoring Guide — writing the playbooks that gate and grant capabilities.",{"id":200,"title":199,"titles":1212,"content":1213,"level":206},[],"Three real compound attacks, retold in component terms. These are real findings retold as chains: each step shows what was observed, what capability it earned, and what that unlocked next. Read them the way you would map a target — as components, capabilities, and the playbooks that connect them. Targets are anonymized; the shapes are the lesson.",{"id":1215,"title":1216,"titles":1217,"content":1218,"level":212},"\u002Fmethodology\u002Fworked-chains#the-invite-page-write","The invite-page write",[199],"Observation. An invite-acceptance page fired an API call on load, taking an invite code from the URL and placing it into the request path client-side. The write. The code was not validated before being used as a path segment — and browsers collapse ..\u002F sequences during request construction. The page's own authenticated session and CSRF token rode along with every request. Result: authenticated request forgery with an attacker-controlled path. What it earned. With the email-change endpoint accepting the same JSON body shape the page already sent, the primitive became \"change the victim's email\" — no different-origin trickery required. Escalation. With the email changed, a legitimate password reset delivered to the attacker. After login, the second-factor check used a truthy lookup on a plain object — so a prototype-chain value (like __proto__) passed the gate. Full account takeover. The shape: a client-side sink that trusts a URL parameter → an authenticated primitive the app performs for you → an identity flow without re-authentication → a semantic bug in a gate.",{"id":1220,"title":1221,"titles":1222,"content":1223,"level":212},"\u002Fmethodology\u002Fworked-chains#the-bridge","The bridge",[199],"Observation. A support widget embedded in the main app, served from a second origin. A chat renderer that built HTML before sanitizing it, with a sanitizer hook permissive enough to let a single event handler through. Step one. Self-XSS in the low-value widget frame — interesting to nobody, because who attacks themselves? What it earned. JavaScript execution in the widget's origin. On its own: worthless. The bridge. The widget communicated with the parent over postMessage, and the parent's origin check used substring matching — so an origin like support.site.attacker-domain.com passed. Worse, the parent exposed a debug channel that evaluated received code. Escalation. From the compromised widget, one message through the bridge became DOM XSS in the main application. Then the legitimately embedded widget was used to send a crafted message as the victim — landing stored XSS in a support agent's session. frame-ancestors protections were irrelevant: the parent context was fully trusted. The shape: a rare execution context in a low-value frame → a weakly checked trust bridge between contexts → execution where it counts.",{"id":1225,"title":1226,"titles":1227,"content":1228,"level":212},"\u002Fmethodology\u002Fworked-chains#the-consent-confusion","The consent confusion",[199],"Observation. An OAuth authorization endpoint validated the redirect_uri correctly — against a value stored in the session. The quirk. A separate consent route re-read redirect_uri from the request instead, so the value that was validated and the value that was used came from different sources. (The validation was itself prefix-based, so a look-alike domain would also have passed.) What it earned. The authorization code redirected to an attacker-controlled address. Escalation. The code could be exchanged without a client secret, and it did not expire — making the interception a persistent backdoor rather than a one-shot. The shape: one flow validates, a sibling flow trusts → parameter confusion → a token that outlives the moment it was stolen.",{"id":1230,"title":1231,"titles":1232,"content":1233,"level":212},"\u002Fmethodology\u002Fworked-chains#what-to-take-from-these","What to take from these",[199],"Identity flows are where \"some execution\" becomes \"account takeover.\" Email change, password reset, OAuth — check for re-authentication and validation consistency every time.Trust bridges amplify everything. postMessage handlers, iframes, subdomains: the origin check is the whole security model, and substring matching is not a check.Small quirks decide chains. A truthy lookup, a client-side path sink, a consent route re-reading a parameter — none are impressive alone, all are pivotal in sequence.Each step here could be a playbook. That is the point: map the components, write the trigger, let the engine carry you from one earned capability to the next.",{"id":1235,"title":225,"titles":1236,"content":1237,"level":212},"\u002Fmethodology\u002Fworked-chains#whats-next",[199],"Chain Recognition — the mechanics behind these narratives.Yields and Primitives — how a chain is encoded in the vault.",{"id":181,"title":180,"titles":1239,"content":1240,"level":206},[],"The thinking behind the tooling — CAVET, contextual hacking, and chains.",{"id":1242,"title":1243,"titles":1244,"content":1245,"level":212},"\u002Fmethodology#this-section-is-about-the-method","This section is about the method",[180],"Nimbus Vault implements a methodology; it is not just a feature set. The three pages here are that methodology, described on its own terms. The CAVET Method — Component Analysis & Vulnerability Enumeration Technique: the component ontology and the Observe → Probe → Reason → Test workflow.Contextual Hacking — the mindset: hunt the context that creates vulnerabilities, rather than forcing vulnerability classes onto targets.Chain Recognition — how earned capabilities turn isolated findings into compound attack paths.Worked Chains — three real compound attacks, retold in component terms. Everything the product does — the library, the playbooks, the engine, the checklist — exists to make this way of working systematic. If you want the practical version, start with the Authoring Guide; if you want to know why any of it is shaped the way it is, read on here.",{"id":1247,"title":1248,"titles":1249,"content":1250,"level":206},"\u002F","Nimbus Vault Docs",[],"Everything you need to run Nimbus Vault — from your first asset to playbook-driven exploitation.",{"id":1252,"title":1253,"titles":1254,"content":1255,"level":212},"\u002F#what-is-nimbus-vault","What is Nimbus Vault?",[1248],"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.Methodology — CAVET and contextual hacking, the thinking behind the tooling.Guides — task-by-task walkthroughs.Complementary Features — connect an AI agent to your workspace.Glossary — every term in one place.",{"id":1257,"title":195,"body":1258,"description":1182,"extension":1407,"meta":1408,"navigation":1409,"path":196,"pro":1410,"seo":1411,"stem":197,"type":1412,"updatedAt":1413,"__hash__":1414},"docs\u002F9.methodology\u002F3.chain-recognition.md",{"type":1259,"value":1260,"toc":1399},"minimark",[1261,1265,1269,1282,1285,1292,1299,1309,1316,1319,1322,1329,1332,1339,1342,1345,1348,1376,1379,1382],[1262,1263,1185],"h2",{"id":1264},"why-chains-are-invisible",[1266,1267,1268],"p",{},"A single-vulnerability view of a target has a blind spot: the interesting bugs are often compounds. A low-impact write becomes a zero-click takeover when it can reach a served file; an XSS in a low-value frame becomes an admin compromise when a postMessage bridge carries it into the main app; a missing re-authentication check turns an email swap into an account takeover.",[1266,1270,1271,1272,1276,1277,1281],{},"Component matching alone struggles with this. It can surface each playbook that applies, but it has no language for ",[1273,1274,1275],"em",{},"\"these two things together are a chain\""," — because the second step only becomes true ",[1278,1279,1280],"strong",{},"after"," the first one succeeds.",[1262,1283,1190],{"id":1284},"earned-capabilities",[1266,1286,1287,1288,1291],{},"The insight behind chain recognition is that some things become true about a target only when you achieve them. These are ",[1278,1289,1290],{},"primitives",": fundamental capabilities like arbitrary file write, or execution in a victim's browser, that you earn by successfully weaponizing a vulnerability.",[1266,1293,1294,1295,1298],{},"So playbooks declare what they ",[1278,1296,1297],{},"yield"," on success, and the engine treats those yields as new matching signals:",[1300,1301,1306],"pre",{"className":1302,"code":1304,"language":1305},[1303],"language-text","Zip Slip playbook            → success → yields: arbitrary file write\n  └─ overwrite-a-served-file playbook\n       (requires the earned primitive)\n                             → success → yields: stored XSS\n            └─ escalation meta-playbook\n                 (requires the earned primitive)\n                             → leads to account takeover\n","text",[1307,1308,1304],"code",{"__ignoreMap":497},[1266,1310,1311,1312,1315],{},"The engine doesn't need to know the whole chain upfront. It follows the primitive graph one step at a time — and each success unlocks the next suggestion automatically. See ",[1313,1314,88],"a",{"href":89}," for the mechanics.",[1262,1317,1195],{"id":1318},"why-gating-matters",[1266,1320,1321],{},"Without yield-gating, a chain playbook that requires \"stored XSS\" would fire on any asset where a hunter manually noted stored XSS — even if the delivery path the chain assumes doesn't exist. That's noise.",[1266,1323,1324,1325,1328],{},"Yield-gating fixes it: a gated requirement is satisfied ",[1278,1326,1327],{},"only"," by a capability that was actually earned. The chain stays invisible until the foundation has been demonstrated on this target.",[1262,1330,630],{"id":1331},"meta-playbooks",[1266,1333,1334,1335,1338],{},"Escalation knowledge doesn't care how the primitive was acquired. A stored-XSS escalation playbook applies whether the XSS came from an archive overwrite, a vulnerable username field, or an upload — any path that earns ",[1307,1336,1337],{},"stored-xss"," feeds it.",[1266,1340,1341],{},"This is the meta-playbook pattern: write the escalation once, and every route to that primitive inherits it. As more playbooks yield the same primitive, the escalation playbook gets more valuable without being touched.",[1262,1343,1204],{"id":1344},"what-chains-look-like",[1266,1346,1347],{},"Compound paths tend to hide in the same places — worth keeping in the back of your head while mapping:",[1349,1350,1351,1358,1364,1370],"ul",{},[1352,1353,1354,1357],"li",{},[1278,1355,1356],{},"A write that reaches a served surface"," — archive extraction, file overwrite, template injection: the question is whether what you wrote is ever read or executed.",[1352,1359,1360,1363],{},[1278,1361,1362],{},"A trust bridge between contexts"," — postMessage handlers, iframes, subdomain-to-subdomain flows: weak origin checks turn a low-value frame into a foothold in the main app.",[1352,1365,1366,1369],{},[1278,1367,1368],{},"Identity flows without re-authentication"," — email change, password reset, invite flows: the pivot from \"some execution\" to \"account takeover\" is often a missing confirmation, not a missing exploit.",[1352,1371,1372,1375],{},[1278,1373,1374],{},"Parser and semantic differences"," — duplicate parameters, normalization mismatches, type coercion: two components that disagree about what the same input means.",[1266,1377,1378],{},"None of these are playbooks — they are shapes that recurring chains take. Recognizing the shape is how you know which primitives are worth pursuing on a target.",[1262,1380,225],{"id":1381},"whats-next",[1349,1383,1384,1389,1394],{},[1352,1385,1386,1388],{},[1313,1387,199],{"href":200}," — the shapes above, told as full narratives.",[1352,1390,1391,1393],{},[1313,1392,88],{"href":89}," — the mechanics behind everything on this page.",[1352,1395,1396,1398],{},[1313,1397,80],{"href":81}," — writing the playbooks that gate and grant capabilities.",{"title":497,"searchDepth":503,"depth":503,"links":1400},[1401,1402,1403,1404,1405,1406],{"id":1264,"depth":212,"text":1185},{"id":1284,"depth":212,"text":1190},{"id":1318,"depth":212,"text":1195},{"id":1331,"depth":212,"text":630},{"id":1344,"depth":212,"text":1204},{"id":1381,"depth":212,"text":225},"md",{},true,false,{"title":195,"description":1182},"concept","2026-10-06","17Y5ZKnLj7ldMvnnozdb4Vyec1A9X9c8JTYferhjL0E",[1416,1417],{"title":191,"path":192,"stem":193,"description":1155,"children":-1},{"title":199,"path":200,"stem":201,"description":1418,"children":-1},"Three real compound attacks, retold in component terms.",1791332108013]