[{"data":1,"prerenderedAt":2303},["ShallowReactive",2],{"docs-navigation":3,"docs-search-files":261,"page-\u002Ftools\u002Fai-agent-connections":1880,"surround-\u002Ftools\u002Fai-agent-connections":2300},[4,38,117,144,176,215,230],{"title":5,"path":6,"stem":7,"children":8},"Getting Started","\u002Fgetting-started","1.getting-started",[9,12,26,30,34],{"title":10,"path":6,"stem":11},"Overview","1.getting-started\u002Findex",{"title":13,"path":14,"stem":15,"children":16,"page":25},"Quick Start","\u002Fgetting-started\u002Fquick-start","1.getting-started\u002F1.quick-start",[17,21],{"title":18,"path":19,"stem":20},"Solo Hunter","\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter","1.getting-started\u002F1.quick-start\u002F1.solo-hunter",{"title":22,"path":23,"stem":24},"Teams","\u002Fgetting-started\u002Fquick-start\u002Fteams","1.getting-started\u002F1.quick-start\u002F2.teams",false,{"title":27,"path":28,"stem":29},"Account and Workspaces","\u002Fgetting-started\u002Faccount-and-workspaces","1.getting-started\u002F2.account-and-workspaces",{"title":31,"path":32,"stem":33},"The Starter Library","\u002Fgetting-started\u002Fstarter-library","1.getting-started\u002F3.starter-library",{"title":35,"path":36,"stem":37},"Your First Suggestions","\u002Fgetting-started\u002Ffirst-suggestions","1.getting-started\u002F4.first-suggestions",{"title":39,"path":40,"stem":41,"children":42},"The Model","\u002Fthe-model","2.the-model",[43,45,69,105],{"title":10,"path":40,"stem":44},"2.the-model\u002Findex",{"title":46,"path":47,"stem":48,"children":49,"page":25},"Methodology","\u002Fthe-model\u002Fmethodology","2.the-model\u002F1.methodology",[50,53,57,61,65],{"title":10,"path":51,"stem":52},"\u002Fthe-model\u002Fmethodology\u002Foverview","2.the-model\u002F1.methodology\u002F0.overview",{"title":54,"path":55,"stem":56},"The CAVET Method","\u002Fthe-model\u002Fmethodology\u002Fcavet","2.the-model\u002F1.methodology\u002F1.cavet",{"title":58,"path":59,"stem":60},"Contextual Hacking","\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking","2.the-model\u002F1.methodology\u002F2.contextual-hacking",{"title":62,"path":63,"stem":64},"Chain Recognition","\u002Fthe-model\u002Fmethodology\u002Fchain-recognition","2.the-model\u002F1.methodology\u002F3.chain-recognition",{"title":66,"path":67,"stem":68},"Worked Chains","\u002Fthe-model\u002Fmethodology\u002Fworked-chains","2.the-model\u002F1.methodology\u002F4.worked-chains",{"title":70,"path":71,"stem":72,"children":73,"page":25},"Components","\u002Fthe-model\u002Fcomponents","2.the-model\u002F2.components",[74,77,81,85,89,93,97,101],{"title":10,"path":75,"stem":76},"\u002Fthe-model\u002Fcomponents\u002Foverview","2.the-model\u002F2.components\u002F0.overview",{"title":78,"path":79,"stem":80},"Technologies","\u002Fthe-model\u002Fcomponents\u002Ftechnologies","2.the-model\u002F2.components\u002F1.technologies",{"title":82,"path":83,"stem":84},"Functionalities","\u002Fthe-model\u002Fcomponents\u002Ffunctionalities","2.the-model\u002F2.components\u002F2.functionalities",{"title":86,"path":87,"stem":88},"Gadgets","\u002Fthe-model\u002Fcomponents\u002Fgadgets","2.the-model\u002F2.components\u002F3.gadgets",{"title":90,"path":91,"stem":92},"Vectors","\u002Fthe-model\u002Fcomponents\u002Fvectors","2.the-model\u002F2.components\u002F4.vectors",{"title":94,"path":95,"stem":96},"Quirks","\u002Fthe-model\u002Fcomponents\u002Fquirks","2.the-model\u002F2.components\u002F5.quirks",{"title":98,"path":99,"stem":100},"Scopes and Levels","\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels","2.the-model\u002F2.components\u002F6.scopes-and-levels",{"title":102,"path":103,"stem":104},"Categories and Tags","\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags","2.the-model\u002F2.components\u002F7.categories-and-tags",{"title":106,"path":107,"stem":108,"children":109,"page":25},"Notespaces","\u002Fthe-model\u002Fnotespaces","2.the-model\u002F3.notespaces",[110,113],{"title":10,"path":111,"stem":112},"\u002Fthe-model\u002Fnotespaces\u002Foverview","2.the-model\u002F3.notespaces\u002F0.overview",{"title":114,"path":115,"stem":116},"Link Metadata","\u002Fthe-model\u002Fnotespaces\u002Flink-metadata","2.the-model\u002F3.notespaces\u002F1.link-metadata",{"title":118,"path":119,"stem":120,"children":121},"Workspace","\u002Fworkspace","3.workspace",[122,124,128,132,136,140],{"title":10,"path":119,"stem":123},"3.workspace\u002Findex",{"title":125,"path":126,"stem":127},"Platforms, Programs, and Assets","\u002Fworkspace\u002Fplatforms-programs-assets","3.workspace\u002F1.platforms-programs-assets",{"title":129,"path":130,"stem":131},"Map an Asset","\u002Fworkspace\u002Fmap-an-asset","3.workspace\u002F2.map-an-asset",{"title":133,"path":134,"stem":135},"Manage Your Scope","\u002Fworkspace\u002Fmanage-your-scope","3.workspace\u002F3.manage-your-scope",{"title":137,"path":138,"stem":139},"Share and Collaborate","\u002Fworkspace\u002Fshare-and-collaborate","3.workspace\u002F4.share-and-collaborate",{"title":141,"path":142,"stem":143},"Clone a Workspace","\u002Fworkspace\u002Fclone-a-workspace","3.workspace\u002F5.clone-a-workspace",{"title":145,"path":146,"stem":147,"children":148},"Nexus Engine","\u002Fnexus-engine","4.nexus-engine",[149,151,155,168,172],{"title":10,"path":146,"stem":150},"4.nexus-engine\u002Findex",{"title":152,"path":153,"stem":154},"Suggestions and Ranking","\u002Fnexus-engine\u002Fsuggestions-and-ranking","4.nexus-engine\u002F1.suggestions-and-ranking",{"title":156,"path":157,"stem":158,"children":159,"page":25},"Checklists","\u002Fnexus-engine\u002Fchecklists","4.nexus-engine\u002F2.checklists",[160,164],{"title":161,"path":162,"stem":163},"Proactive Checklist","\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist","4.nexus-engine\u002F2.checklists\u002F1.proactive-checklist",{"title":165,"path":166,"stem":167},"Reactive Checklist","\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist","4.nexus-engine\u002F2.checklists\u002F2.reactive-checklist",{"title":169,"path":170,"stem":171},"Probes","\u002Fnexus-engine\u002Fprobes","4.nexus-engine\u002F3.probes",{"title":173,"path":174,"stem":175},"Work a Prompt","\u002Fnexus-engine\u002Fwork-a-prompt","4.nexus-engine\u002F4.work-a-prompt",{"title":177,"path":178,"stem":179,"children":180},"Playbooks","\u002Fplaybooks","5.playbooks",[181,183,187,191,195,199,203,207,211],{"title":10,"path":178,"stem":182},"5.playbooks\u002Findex",{"title":184,"path":185,"stem":186},"Create a Playbook","\u002Fplaybooks\u002Fcreate-a-playbook","5.playbooks\u002F1.create-a-playbook",{"title":188,"path":189,"stem":190},"Link Components to a Playbook","\u002Fplaybooks\u002Flink-components-to-a-playbook","5.playbooks\u002F2.link-components-to-a-playbook",{"title":192,"path":193,"stem":194},"Declare Yields","\u002Fplaybooks\u002Fdeclare-yields","5.playbooks\u002F3.declare-yields",{"title":196,"path":197,"stem":198},"Run a Playbook","\u002Fplaybooks\u002Frun-a-playbook","5.playbooks\u002F4.run-a-playbook",{"title":200,"path":201,"stem":202},"Authoring Guide","\u002Fplaybooks\u002Fauthoring-guide","5.playbooks\u002F5.authoring-guide",{"title":204,"path":205,"stem":206},"Requirements","\u002Fplaybooks\u002Frequirements","5.playbooks\u002F6.requirements",{"title":208,"path":209,"stem":210},"Yields and Primitives","\u002Fplaybooks\u002Fyields-and-primitives","5.playbooks\u002F7.yields-and-primitives",{"title":212,"path":213,"stem":214},"Outcomes and History","\u002Fplaybooks\u002Foutcomes-and-history","5.playbooks\u002F8.outcomes-and-history",{"title":216,"path":217,"stem":218,"children":219},"Tools","\u002Ftools","6.tools",[220,222,226],{"title":10,"path":217,"stem":221},"6.tools\u002Findex",{"title":223,"path":224,"stem":225},"AI Agent Connections","\u002Ftools\u002Fai-agent-connections","6.tools\u002F1.ai-agent-connections",{"title":227,"path":228,"stem":229},"Browser Extension","\u002Ftools\u002Fbrowser-extension","6.tools\u002F2.browser-extension",{"title":231,"path":232,"stem":233,"children":234},"Reference","\u002Freference","7.reference",[235,237,241,245,249,253,257],{"title":10,"path":232,"stem":236},"7.reference\u002Findex",{"title":238,"path":239,"stem":240},"Glossary","\u002Freference\u002Fglossary","7.reference\u002F1.glossary",{"title":242,"path":243,"stem":244},"Search the Workspace","\u002Freference\u002Fsearch-the-workspace","7.reference\u002F2.search-the-workspace",{"title":246,"path":247,"stem":248},"Search Syntax","\u002Freference\u002Fsearch-syntax","7.reference\u002F3.search-syntax",{"title":250,"path":251,"stem":252},"Settings","\u002Freference\u002Fsettings","7.reference\u002F4.settings",{"title":254,"path":255,"stem":256},"Dashboard Metrics","\u002Freference\u002Fdashboard-metrics","7.reference\u002F5.dashboard-metrics",{"title":258,"path":259,"stem":260},"FAQ","\u002Freference\u002Ffaq","7.reference\u002F6.faq",[262,266,272,277,282,287,292,297,302,305,310,315,320,325,330,335,340,343,348,353,358,362,365,370,375,380,384,387,392,397,402,407,412,416,419,424,429,434,440,445,450,455,460,465,470,473,478,481,486,491,496,501,506,510,513,518,523,528,533,537,540,545,550,555,560,565,569,572,577,582,587,592,596,599,604,609,614,618,621,626,631,636,641,646,650,653,658,662,666,670,674,678,681,686,690,694,699,703,707,710,715,719,724,728,732,736,739,744,748,753,757,761,765,768,773,778,783,788,793,797,800,805,810,815,820,825,830,834,837,842,847,852,857,861,865,868,873,878,883,888,892,897,901,904,909,913,916,921,926,931,936,941,945,948,953,958,963,968,973,977,980,985,990,995,1000,1005,1010,1014,1017,1022,1026,1031,1036,1041,1045,1048,1053,1058,1063,1067,1070,1075,1080,1083,1088,1093,1098,1103,1107,1111,1114,1119,1124,1129,1134,1139,1143,1146,1151,1156,1161,1166,1170,1173,1178,1183,1188,1192,1195,1200,1205,1210,1215,1219,1223,1226,1231,1236,1241,1246,1251,1255,1258,1263,1268,1273,1278,1282,1285,1290,1295,1300,1305,1310,1315,1320,1325,1329,1332,1337,1342,1347,1352,1357,1362,1367,1371,1374,1379,1384,1389,1394,1399,1404,1408,1411,1416,1421,1425,1430,1435,1440,1445,1450,1455,1460,1465,1470,1474,1477,1482,1487,1491,1496,1501,1506,1511,1516,1521,1526,1531,1534,1539,1544,1549,1554,1558,1563,1568,1572,1575,1580,1585,1590,1595,1599,1602,1607,1611,1615,1618,1623,1628,1633,1638,1643,1647,1650,1655,1660,1665,1669,1672,1677,1680,1685,1690,1695,1700,1703,1708,1713,1718,1723,1727,1730,1735,1740,1744,1749,1754,1759,1764,1769,1772,1777,1782,1787,1790,1795,1800,1805,1810,1815,1818,1823,1828,1833,1838,1843,1848,1853,1858,1861,1866,1871,1876],{"id":19,"title":18,"titles":263,"content":264,"level":265},[],"The fastest path from an empty workspace to your first playbook run. The sequence below is a starting path — follow it once end to end and you will have used every part of the core loop.",1,{"id":267,"title":268,"titles":269,"content":270,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_1-create-your-workspace","1. Create your workspace",[18],"Sign in and create a workspace. It is the container for everything: assets, components, playbooks, notespaces. If you're working alone, one workspace is all you need. Details: Account and Workspaces.",2,{"id":273,"title":274,"titles":275,"content":276,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_2-seed-the-starter-library","2. Seed the starter library",[18],"Open the dashboard and use the Starter Library card. This gives you a working set of technologies, functionalities, gadgets, vectors, quirks, and playbooks — so the engine has something to match with. Details: The Starter Library.",{"id":278,"title":279,"titles":280,"content":281,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_3-add-your-first-scope","3. Add your first scope",[18],"Create a platform (where the work comes from), a program (the scope of testing), and one asset (the concrete thing you are testing). Details: Workspace and Manage Your Scope.",{"id":283,"title":284,"titles":285,"content":286,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_4-map-the-asset","4. Map the asset",[18],"Open the asset's Components panel and link what you actually observe — the stack, the features, a behavior you noticed. Record endpoints when you know them, and scope vectors and quirks inside the component they belong to. Details: Map an Asset.",{"id":288,"title":289,"titles":290,"content":291,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_5-work-the-checklist","5. Work the checklist",[18],"Open the asset's Suggestions → Checklists panel. The proactive side asks what is missing; resolve prompts with evidence — link what exists, and only answer \"no\" after checking the full surface. The reactive side lists the objectives your components brought with them. Details: Work a Prompt, Proactive Checklist, Reactive Checklist.",{"id":293,"title":294,"titles":295,"content":296,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_6-run-a-playbook","6. Run a playbook",[18],"Back in Suggestions → Playbooks, open the top-ranked suggestion, execute it against the target, and record the outcome — success, failure, or not applicable. A success earns the playbook's yields as primitives, which can unlock the next playbook in a chain. Details: Run a Playbook, Yields and Primitives.",{"id":298,"title":299,"titles":300,"content":301,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fsolo-hunter#_7-grow-the-vault","7. Grow the vault",[18],"Every engagement adds to the library. When you observe something new, record it as a component; when you learn an escalation, write it as a playbook. The Authoring Guide is the reference for making playbooks that actually fire. New here? Do steps 1–6 in a single sitting on one asset. The loop clicks the first time you watch a suggestion appear because of something you mapped.",{"id":23,"title":22,"titles":303,"content":304,"level":265},[],"Set up a shared workspace where everyone's mapping compounds. This path covers the team-specific setup on top of the Solo Hunter loop. Everything in the core loop still applies — teams just share it.",{"id":306,"title":307,"titles":308,"content":309,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_1-create-the-shared-workspace","1. Create the shared workspace",[22],"One person creates the workspace and owns it. A workspace is the unit of sharing: the component library, playbooks, and outcomes inside it belong to everyone in it. Details: Account and Workspaces.",{"id":311,"title":312,"titles":313,"content":314,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_2-invite-your-members","2. Invite your members",[22],"From workspace settings, invite teammates by email — or share the invite link. Each invite carries a role: Admin — manages workspace settings, members, and everything inside.Member — full access to the vault's content. Details: Share and Collaborate. Granular access controls — per-asset or per-playbook permissions beyond the Admin\u002FMember roles — are not in the product yet. This page will be expanded when they arrive.",{"id":316,"title":317,"titles":318,"content":319,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_3-seed-and-shape-the-library-together","3. Seed and shape the library together",[22],"Seed the Starter Library, then treat the library as an institutional asset: anyone can add components, and every addition makes everyone's suggestions smarter. Encourage the library discipline — reusable, observable, atomic.",{"id":321,"title":322,"titles":323,"content":324,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_4-keep-engagements-separate-reuse-the-setup","4. Keep engagements separate, reuse the setup",[22],"Give each client or engagement its own workspace, and use Clone Workspace to carry over the parts worth reusing — programs & assets, components, playbooks. Details: Clone a Workspace.",{"id":326,"title":327,"titles":328,"content":329,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_5-share-single-things-when-thats-enough","5. Share single things when that's enough",[22],"Not every collaboration needs an invite. Any asset, playbook, or component can be shared as a read-only snapshot link — useful for a second opinion or a client review. Details: Share and Collaborate.",{"id":331,"title":332,"titles":333,"content":334,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#_6-connect-your-agents","6. Connect your agents",[22],"If your team works with AI agents, each member can create their own agent connection — scoped to the workspace, capped per member, revocable, and audited.",{"id":336,"title":337,"titles":338,"content":339,"level":271},"\u002Fgetting-started\u002Fquick-start\u002Fteams#whats-next","What's next",[22],"Manage Your Scope — keep large team scopes navigable.The CAVET Method — a shared vocabulary is what makes team knowledge compound.",{"id":28,"title":27,"titles":341,"content":342,"level":265},[],"Sign in, create a workspace, and bring your team into the vault.",{"id":344,"title":345,"titles":346,"content":347,"level":271},"\u002Fgetting-started\u002Faccount-and-workspaces#accounts","Accounts",[27],"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.",{"id":349,"title":350,"titles":351,"content":352,"level":271},"\u002Fgetting-started\u002Faccount-and-workspaces#workspaces","Workspaces",[27],"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":354,"title":355,"titles":356,"content":357,"level":271},"\u002Fgetting-started\u002Faccount-and-workspaces#members-and-roles","Members and roles",[27],"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":359,"title":337,"titles":360,"content":361,"level":271},"\u002Fgetting-started\u002Faccount-and-workspaces#whats-next",[27],"Seed your workspace so you are not starting from an empty library: the starter library.",{"id":32,"title":31,"titles":363,"content":364,"level":265},[],"Seed your workspace with curated components and playbooks.",{"id":366,"title":367,"titles":368,"content":369,"level":271},"\u002Fgetting-started\u002Fstarter-library#why-seed-the-library","Why seed the library",[31],"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":371,"title":372,"titles":373,"content":374,"level":271},"\u002Fgetting-started\u002Fstarter-library#seeding-your-workspace","Seeding your workspace",[31],"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":376,"title":377,"titles":378,"content":379,"level":271},"\u002Fgetting-started\u002Fstarter-library#growing-beyond-it","Growing beyond it",[31],"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":381,"title":337,"titles":382,"content":383,"level":271},"\u002Fgetting-started\u002Fstarter-library#whats-next",[31],"Map your first asset and watch the engine light up.",{"id":36,"title":35,"titles":385,"content":386,"level":265},[],"The moment mapping pays off — where suggestions appear and what you can do with them.",{"id":388,"title":389,"titles":390,"content":391,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#the-moment-it-clicks","The moment it clicks",[35],"Link a couple of components to an asset and the engine has something to say. Open the asset and switch to Suggestions — you'll find two views: Checklists — what's missing: near-miss prompts and the objectives carried by your linked components.Playbooks — what applies now: ranked suggestion cards.",{"id":393,"title":394,"titles":395,"content":396,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#reading-a-suggestion","Reading a suggestion",[35],"Each card is ranked and explainable. It shows a score with a Base and Final value — the base reflects the matched requirements, and the final folds in quirk pressure: enabling quirks present on the asset raise it, mitigating quirks lower it. Sort the list by Score, Name, or Level with the sort control. Click a card to open the playbook in a read-only view — requirements, body, and yields — with a back button. The card's menu jumps to the playbook's own notespace when you need to edit it. If a match looks wrong, fix the data: the suggestion list follows your records, not the other way around.",{"id":398,"title":399,"titles":400,"content":401,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#acting-on-one","Acting on one",[35],"Every card carries three actions, with exact meanings: ActionWhat it records✓ Mark playbook as successfulGrants the playbook's yields as primitives✗ Mark playbook as failedTested, didn't work — the suggestion retires− Mark playbook as not applicableIrrelevant to this asset — retires without a failed test The full run loop — including yield prompts and retraction — is Run a Playbook.",{"id":403,"title":404,"titles":405,"content":406,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#the-checklist-beside-it","The checklist beside it",[35],"Suggestions are the reactive half. The Checklists view is the proactive half: prompts for the required components of near-matches, plus the objectives your components bring with them. Working them is how coverage grows — start with Work a Prompt.",{"id":408,"title":409,"titles":410,"content":411,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#why-its-trustworthy","Why it's trustworthy",[35],"The engine is deterministic: the same asset and the same library always produce the same suggestions in the same order. Nothing is guessed, and nothing changes until you change the data — which makes every result auditable and every fix permanent. See The Nexus Engine.",{"id":413,"title":337,"titles":414,"content":415,"level":271},"\u002Fgetting-started\u002Ffirst-suggestions#whats-next",[35],"Map an asset — feed it more context.Work a prompt — resolve what's missing.Run a playbook — execute and record.",{"id":6,"title":10,"titles":417,"content":418,"level":265},[],"What Nimbus Vault is, how its architecture works, and why it compounds.",{"id":420,"title":421,"titles":422,"content":423,"level":271},"\u002Fgetting-started#what-nimbus-vault-is","What Nimbus Vault is",[10],"Nimbus Vault is a context engine for ethical hackers — a structured workspace where everything you observe about a target is captured as machine-readable context, and every piece of attack knowledge you accumulate is applied back to you as ranked, explainable suggestions. It exists because of a specific bottleneck. The hard part of hunting is rarely the testing itself — it's that nothing connects what you observe on a target to what you know about attacking it. Write-ups get bookmarked and forgotten, techniques stay siloed by vulnerability class, and the moment you're staring at a live target, the knowledge you need is scattered across notes, tabs, and memory. Information transfers between hunters; capability does not. Nimbus closes that gap: you map what you see, the engine applies what you know.",{"id":425,"title":426,"titles":427,"content":428,"level":271},"\u002Fgetting-started#the-loop","The loop",[10],"Everything in the product runs on one cycle: Map — observe a target and record its components in the vault. (Map an Asset)Match — the engine correlates your playbooks against what you mapped, ranking what applies. (The Nexus Engine)Confirm — proactive and reactive checklists turn gaps into concrete next questions. (Checklists)Execute — run the playbooks the engine surfaced, on the target, within program rules. (Run a Playbook)Earn — record outcomes; successful playbooks yield primitives that unlock the next playbook in a chain. (Yields and Primitives) Then the loop repeats, sharper every time. Think of it as a SIEM — for the offense. A SIEM ingests logs, normalizes them into a schema, correlates them against detection rules, and alerts on what matters. Nimbus runs the same pipeline over your reconnaissance: mapping is ingestion, the component model is the schema, playbooks are the detection rules, and suggestions and prompts are the alerts. The difference is the analyst — it's still you, deciding, testing, and executing on a live target.",{"id":430,"title":431,"titles":432,"content":433,"level":271},"\u002Fgetting-started#architecture","Architecture",[10],"The platform is three layers — the Component Library, the Threat Library, and the Nexus Engine — connected by one primitive: the link. A link ties an asset to a component, a playbook to a requirement, or a primitive to what earned it, and it carries the metadata the engine reads (Link Metadata).",{"id":435,"title":436,"titles":437,"content":438,"level":439},"\u002Fgetting-started#the-component-library-observation","The Component Library — observation",[10,431],"Assets catalog the context of a target. Five component types describe it: Technologies (what it's built with), Functionalities (what it does), Gadgets (chainable exploit primitives), Vectors (how input reaches the application), and Quirks (observable behaviors that enable or block attacks). Precision is a first-class concern. A behavior can be recorded at asset level — applying to the whole application — or scoped to the exact component where it was observed. Component-level evidence is stronger, and the engine weighs it accordingly (Scopes and Levels). Technologies carry default quirks, vectors, and gadgets that inherit onto assets, so a stack's usual suspects populate themselves.",3,{"id":441,"title":442,"titles":443,"content":444,"level":439},"\u002Fgetting-started#the-threat-library-knowledge","The Threat Library — knowledge",[10,431],"The other half is what you know. A playbook defines a testing recipe through its requirements: Required components act as hard gates — the playbook is invisible until every one is satisfied.Optional components don't gate; they shape the confidence score.Enabling quirks raise a playbook's viability; mitigating quirks block it. A single confirmed mitigation — a robust sanitizer, a strict CSP — can outweigh several enablers, and the engine is built to reflect that asymmetry. The Authoring Guide covers how to write playbooks that fire precisely.",{"id":446,"title":447,"titles":448,"content":449,"level":439},"\u002Fgetting-started#the-nexus-engine-reasoning","The Nexus Engine — reasoning",[10,431],"Matching is a deterministic, multi-stage pipeline: Hard gates — every required component is checked against the asset. One missing requirement excludes the playbook, regardless of everything else it has going for it.Overlap and structure — satisfied playbooks are scored by how completely the asset matches the playbook's full component profile, including technology version constraints, and by how precise each match is.Quirk weighting — quirk evidence is graded by precision (component-scoped beats asset-wide) and directed by role: enabling quirks push confidence up, mitigating quirks push it down harder.Confidence and ranking — the signals consolidate into a final ranked list, with deliberate ceilings: without direct behavioral evidence, a match can never claim absolute certainty. Every stage is auditable, and every result is reproducible — the same data always produces the same suggestions (Suggestions and Ranking).",{"id":451,"title":452,"titles":453,"content":454,"level":271},"\u002Fgetting-started#benefits","Benefits",[10],"Tunnel vision breaks. You stop scanning targets for one pet vulnerability class. You map context, and the engine surfaces every technique that fits — including ones you learned six months ago and forgot you knew.Your memory becomes external. There's no pressure to \"use it or lose it\" — study several techniques in one sitting, encode them, and trust the system to surface each one when its context appears on a real target. Learning in bulk becomes safe.Every mapped asset becomes queryable. When a new technique or advisory drops, you don't re-scan targets by hand — you search the vault for assets matching its conditions and get a ranked list in seconds (Search the Workspace).Knowledge compounds relationally, not just linearly. A new playbook activates against every matching asset, past and future. A new observation changes which playbooks fire. Each addition makes the whole system sharper — not just bigger — and retroactively so.Decisions stop being arbitrary. Instead of \"where do I start?\", the engine tells you what applies and what it's worth, with the reasoning shown. Consistency replaces energy-dependent coverage.Teams share capability, not just notes. A teammate's playbook isn't something you have to read and internalize — it fires against your assets automatically. You don't need to know a technique exists to benefit from it being in the workspace; the engine brings the knowledge to you at the exact moment it's relevant. Knowledge stays with the team rather than with individuals.The vault is agent-ready. The structured component → requirement → playbook graph is machine-readable by design, so AI agent connections reason against your actual playbooks and targets, not generic training data.",{"id":456,"title":457,"titles":458,"content":459,"level":271},"\u002Fgetting-started#no-guessing-no-autopilot","No guessing, no autopilot",[10],"Two expectations worth setting plainly: The engine does not guess. It is not a stochastic AI generating plausible-sounding attacks. It's a deterministic expert system — more like a chess engine than a chatbot. Every recommendation is a logical conclusion drawn from evidence you provided, traceable back to specific components and behaviors you observed. Nimbus does not find bugs for you. It doesn't replace understanding your target, and it doesn't guarantee findings. The hacker still comes from you — your curiosity, your intuition, your willingness to go down a rabbit hole at 2am. What Nimbus does is make sure nothing you've learned, mapped, or confirmed goes to waste. It's a co-pilot, not an autopilot.",{"id":461,"title":462,"titles":463,"content":464,"level":271},"\u002Fgetting-started#key-features","Key features",[10],"Playbooks — encode attack knowledge once; the engine applies it everywhere it fits.The Nexus Engine — ranked suggestions with the reasoning, plus the proactive checklist.Checklists — proactive prompts and reactive objectives, with probes showing you how to check.Yields and Primitives — successful playbooks grant capabilities; chains write themselves.Search the Workspace — query across every asset and component at once, including version-aware technology lookups.Tools — AI agent connections over MCP, and the browser extension for tagging without leaving the target.The CAVET model — components, scopes, notespaces, and the methodology underneath.",{"id":466,"title":467,"titles":468,"content":469,"level":271},"\u002Fgetting-started#where-to-start","Where to start",[10],"Just want to use it? Follow Quick Start: Solo Hunter.Setting up a team? Follow Quick Start: Teams.Want the ideas first? Read The CAVET Method, then come back.",{"id":51,"title":10,"titles":471,"content":472,"level":265},[],"The thinking behind the tooling — CAVET, contextual hacking, and chains.",{"id":474,"title":475,"titles":476,"content":477,"level":271},"\u002Fthe-model\u002Fmethodology\u002Foverview#this-section-is-about-the-method","This section is about the method",[10],"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":55,"title":54,"titles":479,"content":480,"level":265},[],"Component Analysis & Vulnerability Enumeration Technique — the ontology and workflow behind Nimbus Vault.",{"id":482,"title":483,"titles":484,"content":485,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#what-cavet-is","What CAVET is",[54],"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":487,"title":488,"titles":489,"content":490,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#the-five-components","The five components",[54],"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":492,"title":493,"titles":494,"content":495,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#the-workflow","The workflow",[54],"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":497,"title":498,"titles":499,"content":500,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#from-theory-to-practice","From theory to practice",[54],"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":502,"title":503,"titles":504,"content":505,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#how-nimbus-vault-implements-it","How Nimbus Vault implements it",[54],"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":507,"title":337,"titles":508,"content":509,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcavet#whats-next",[54],"Contextual Hacking — where this way of working began.Chain Recognition — the compound case.",{"id":59,"title":58,"titles":511,"content":512,"level":265},[],"Hunt the context that creates vulnerabilities, not the vulnerability class.",{"id":514,"title":515,"titles":516,"content":517,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#the-methodology-gap","The methodology gap",[58],"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":519,"title":520,"titles":521,"content":522,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#vulnerabilities-depend-on-context","Vulnerabilities depend on context",[58],"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":524,"title":525,"titles":526,"content":527,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#map-the-context-then-test","Map the context, then test",[58],"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":529,"title":530,"titles":531,"content":532,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#the-team-version","The team version",[58],"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":534,"title":337,"titles":535,"content":536,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fcontextual-hacking#whats-next",[58],"The CAVET Method — the formal ontology and workflow.Chain Recognition — what happens when findings compose.",{"id":63,"title":62,"titles":538,"content":539,"level":265},[],"How earned capabilities turn isolated findings into compound attack paths.",{"id":541,"title":542,"titles":543,"content":544,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#why-chains-are-invisible","Why chains are invisible",[62],"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":546,"title":547,"titles":548,"content":549,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#earned-capabilities","Earned capabilities",[62],"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":551,"title":552,"titles":553,"content":554,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#why-gating-matters","Why gating matters",[62],"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":556,"title":557,"titles":558,"content":559,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#meta-playbooks","Meta-playbooks",[62],"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":561,"title":562,"titles":563,"content":564,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#what-chains-look-like","What chains look like",[62],"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":566,"title":337,"titles":567,"content":568,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fchain-recognition#whats-next",[62],"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":67,"title":66,"titles":570,"content":571,"level":265},[],"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":573,"title":574,"titles":575,"content":576,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-invite-page-write","The invite-page write",[66],"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":578,"title":579,"titles":580,"content":581,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-bridge","The bridge",[66],"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":583,"title":584,"titles":585,"content":586,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#the-consent-confusion","The consent confusion",[66],"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":588,"title":589,"titles":590,"content":591,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#what-to-take-from-these","What to take from these",[66],"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":593,"title":337,"titles":594,"content":595,"level":271},"\u002Fthe-model\u002Fmethodology\u002Fworked-chains#whats-next",[66],"Chain Recognition — the mechanics behind these narratives.Yields and Primitives — how a chain is encoded in the vault.",{"id":75,"title":10,"titles":597,"content":598,"level":265},[],"What components are, the five types, and what earns a place in the library.",{"id":600,"title":601,"titles":602,"content":603,"level":271},"\u002Fthe-model\u002Fcomponents\u002Foverview#the-vocabulary-of-the-vault","The vocabulary of the vault",[10],"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":605,"title":606,"titles":607,"content":608,"level":271},"\u002Fthe-model\u002Fcomponents\u002Foverview#what-earns-a-place-in-the-library","What earns a place in the library",[10],"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":610,"title":611,"titles":612,"content":613,"level":271},"\u002Fthe-model\u002Fcomponents\u002Foverview#organizing-the-library","Organizing the library",[10],"Categories group components by theme and power the engine's structured matching. Tags are lighter labels for slicing the library and attaching conditions in playbooks — a category plus a tag is one of the most precise requirements a playbook can express. See Categories and Tags. 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":615,"title":337,"titles":616,"content":617,"level":271},"\u002Fthe-model\u002Fcomponents\u002Foverview#whats-next",[10],"Technologies — the most common entry point.Scopes and levels — how components nest inside their parents.Reactive Checklist and Probes — a component's tests, and how-to-check notes.Categories and tags — the library's organizing layers.The CAVET Method — why these five types exist.Notespaces and endpoints — where observations live once linked.",{"id":79,"title":78,"titles":619,"content":620,"level":265},[],"The frameworks, servers, languages, and platforms a target is built with.",{"id":622,"title":623,"titles":624,"content":625,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#what-a-technology-is","What a technology is",[78],"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":627,"title":628,"titles":629,"content":630,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#why-they-matter","Why they matter",[78],"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":632,"title":633,"titles":634,"content":635,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#how-they-link","How they link",[78],"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":637,"title":638,"titles":639,"content":640,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#library-hygiene","Library hygiene",[78],"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":642,"title":643,"titles":644,"content":645,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#in-the-app","In the app",[78],"Create one from Technologies in the sidebar with Add Technology: FieldRequiredNotesNameYesAutocompletes from the technology catalogue — picking a match fills category, description, and logoCategoryYese.g. Backend Framework; suggestions come from categories already in useDescriptionNoWhat the technology doesVendorNoWho makes or maintains itLogo URLNoOptional branding for tables and cardsTagsNoComma-separated (backend, node, wip) The technology notespace carries a Components tab no other type has: default quirks, common vectors, and common gadgets that assets inherit when they link this technology. Each default carries an Inheritance Level (Asset or Component), an Inheritance Mode (Auto or Manual), and — for quirks — a Default Polarity (Present \u002F Absent). \"This stack usually exhibits prototype pollution\" becomes one link instead of dozens. When you link a technology to an asset and know the version, record it in the link's Version field — it feeds version-constrained playbook requirements.",{"id":647,"title":337,"titles":648,"content":649,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ftechnologies#whats-next",[78],"Functionalities — what the stack does for users.",{"id":83,"title":82,"titles":651,"content":652,"level":265},[],"What a target does for its users — and where most attack surface lives.",{"id":654,"title":655,"titles":656,"content":657,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#what-a-functionality-is","What a functionality is",[82],"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":659,"title":628,"titles":660,"content":661,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#why-they-matter",[82],"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":663,"title":633,"titles":664,"content":665,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#how-they-link",[82],"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":667,"title":638,"titles":668,"content":669,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#library-hygiene",[82],"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":671,"title":643,"titles":672,"content":673,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#in-the-app",[82],"Create one from Functionalities with Add Functionality: Name (required), Category (required), Aliases (alternate names like Upload or File Transfer, so the same thing is findable under different wording), Description, and Tags. Functionalities link directly to assets, and they're usually the first type you map — the bones of the target's attack surface. They're also where scoped children accumulate: vectors live inside the functionality that produces them, quirks where the behavior was observed. Playbook requirements for those children demand the exact parent (exact-parent rule), so linking a child to the right functionality matters twice.",{"id":675,"title":337,"titles":676,"content":677,"level":271},"\u002Fthe-model\u002Fcomponents\u002Ffunctionalities#whats-next",[82],"Gadgets — the capabilities that ride along.",{"id":87,"title":86,"titles":679,"content":680,"level":265},[],"Extra capabilities that ride along with a target, beyond its intended purpose.",{"id":682,"title":683,"titles":684,"content":685,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#what-a-gadget-is","What a gadget is",[86],"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":687,"title":628,"titles":688,"content":689,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#why-they-matter",[86],"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":691,"title":633,"titles":692,"content":693,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#how-they-link",[86],"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":695,"title":696,"titles":697,"content":698,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#functionality-vs-gadget","Functionality vs. gadget",[86],"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":700,"title":643,"titles":701,"content":702,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#in-the-app",[86],"Create one from Gadgets with Add Gadget: Name (required), Category (required), Description, and Tags. Link gadgets directly to an asset, or scoped inside the technology that exposes them. In playbooks they play three roles: requirements (often optional — gadgets vary by implementation and resist black-box confirmation), nested children (Add CLGV \u002F Add CLGQ on a gadget link), and yields (toggle Yields on success to mark a gadget as a playbook output — see Declare Yields).",{"id":704,"title":337,"titles":705,"content":706,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fgadgets#whats-next",[86],"Vectors — the specific ways in.",{"id":91,"title":90,"titles":708,"content":709,"level":265},[],"The specific mechanisms that turn observed behavior into a reachable attack.",{"id":711,"title":712,"titles":713,"content":714,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#what-a-vector-is","What a vector is",[90],"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":716,"title":633,"titles":717,"content":718,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#how-they-link",[90],"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":720,"title":721,"titles":722,"content":723,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#record-the-endpoint","Record the endpoint",[90],"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":725,"title":638,"titles":726,"content":727,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#library-hygiene",[90],"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":729,"title":643,"titles":730,"content":731,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#in-the-app",[90],"Create one from Vectors with Add Vector: Name (required), Category (required), Description, and Tags. Vectors are usually observed rather than invented — you find an SVG upload while mapping an uploader, then link it as a scoped child (CLV) of the component that produces it. Nest deeper with Nested Vectors, attach a quirk to a vector with Add CLVQ, and express variance with a playbook Category + Tag combination instead of naming every format (the File Types + #archive-file pattern).",{"id":733,"title":337,"titles":734,"content":735,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fvectors#whats-next",[90],"Quirks — the behaviors that change what a vector can do.",{"id":95,"title":94,"titles":737,"content":738,"level":265},[],"Behavior that tips an attack — and why scoping quirks to their parent matters most.",{"id":740,"title":741,"titles":742,"content":743,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#what-a-quirk-is","What a quirk is",[94],"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":745,"title":633,"titles":746,"content":747,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#how-they-link",[94],"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":749,"title":750,"titles":751,"content":752,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#stateful-quirks","Stateful quirks",[94],"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":754,"title":638,"titles":755,"content":756,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#library-hygiene",[94],"Name the behavior, not the exploit. Prototype pollution is a quirk; \"RCE via prototype pollution in lodash merge\" is a playbook.",{"id":758,"title":643,"titles":759,"content":760,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#in-the-app",[94],"Create one from Quirks with Add Quirk: Name (required), Category (required), a Stateful toggle (\"This quirk is stateful\" — or stateless), Description, and Tags. Statefulness is set here, at creation: stateful quirks carry a Present \u002F Absent state wherever they're linked, and their objectives carry the same state. Whether a quirk enables or mitigates is not set here — it's chosen per playbook link, because the same quirk can enable one attack and mitigate another. Link quirks scoped inside the component where they were observed (a CLQ on the technology): the scoping is what lets scoped playbook requirements be satisfied at all.",{"id":762,"title":337,"titles":763,"content":764,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fquirks#whats-next",[94],"See the library in context: Overview or the Glossary.",{"id":99,"title":98,"titles":766,"content":767,"level":265},[],"How components nest — asset-level observations versus scoped children.",{"id":769,"title":770,"titles":771,"content":772,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#why-scoping-exists","Why scoping exists",[98],"\"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":774,"title":775,"titles":776,"content":777,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#the-levels","The levels",[98],"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":779,"title":780,"titles":781,"content":782,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#the-exact-parent-rule","The exact-parent rule",[98],"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":784,"title":785,"titles":786,"content":787,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#instances-the-same-component-multiple-places","Instances: the same component, multiple places",[98],"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":789,"title":790,"titles":791,"content":792,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#quirks-carry-roles","Quirks carry roles",[98],"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":794,"title":337,"titles":795,"content":796,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fscopes-and-levels#whats-next",[98],"Authoring Guide — how scoped observations become playbook triggers.Notespaces and Endpoints — where links, instances, and endpoints live.",{"id":103,"title":102,"titles":798,"content":799,"level":265},[],"The two organizing layers — curated structure and flexible labels.",{"id":801,"title":802,"titles":803,"content":804,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#categories-structural-groupings","Categories: structural groupings",[102],"A category is a themed grouping of components — Authentication, File Types, Backend Framework, DOM Sink. Categories are per component type: the Authentication category on a functionality has nothing to do with the same name on a technology. They are free text with suggestions: when you create or edit a component, the Category field (required) suggests values already used in that workspace, so the shared vocabulary settles naturally instead of fragmenting into near-duplicates.",{"id":806,"title":807,"titles":808,"content":809,"level":439},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#why-categories-matter","Why categories matter",[102,802],"Categories are what make broad playbook requirements possible. A playbook can require any functionality in the Authentication category instead of naming Login Form, SSO, and OAuth flow separately — and every component you categorize later is covered automatically. That is one of the highest-leverage tools in trigger design (see the Authoring Guide). When the engine matches a category assignment on an asset, it reports both the category that satisfied it and the specific component behind it.",{"id":811,"title":812,"titles":813,"content":814,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#tags-flexible-labels","Tags: flexible labels",[102],"Tags are lighter than categories. Any component type can carry them: they're entered as a comma-separated list in the create\u002Fedit drawer (archive-file, legacy, needs-review). Normalized and displayed uniformly — stored lowercase, shown as #tag.Searchable — tag:archive-file in the command center.Combinable with categories in playbooks — the Tag Combo field on a Category assignment narrows it: File Types + #archive-file means in the category and tagged.",{"id":816,"title":817,"titles":818,"content":819,"level":439},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#why-tags-matter","Why tags matter",[102,812],"Tags absorb variance without multiplying playbooks. One #archive-file tag turns a single Vector requirement into coverage for ZIP, TAR, JAR, and every future archive format you tag. If two playbooks differ only by which specific component they name, that's the signal to collapse them into one and use a category + tag.",{"id":821,"title":822,"titles":823,"content":824,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#good-habits","Good habits",[102],"Reuse before inventing. Pick the suggested category; a vocabulary of twenty categories beats two hundred one-offs.Categories are nouns of structure; tags are modifiers. File Types is a category; archive-file, legacy, wip are tags.Tag once, benefit everywhere. Tags travel with the component to every playbook assignment and every search.Don't tag what a category already says. #authentication on an Authentication functionality adds nothing.",{"id":826,"title":827,"titles":828,"content":829,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#where-they-surface","Where they surface",[102],"SurfaceCategoriesTagsComponent create\u002Fedit drawerCategory * fieldTags fieldPlaybook component linkingCategory \u002F Tag modes, Tag ComboTag mode, Tag Combo, tag childrenSearchcategory:tag:, !tag:Tables and notespace headersCategory chipsTag chips",{"id":831,"title":337,"titles":832,"content":833,"level":271},"\u002Fthe-model\u002Fcomponents\u002Fcategories-and-tags#whats-next",[102],"Link Components to a Playbook — category and combo assignments in practice.Reactive Checklist and Probes — the other half of a component's notespace.",{"id":111,"title":10,"titles":835,"content":836,"level":265},[],"Where observations live, and the data that makes matches precise.",{"id":838,"title":839,"titles":840,"content":841,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#every-entity-has-a-notespace","Every entity has a notespace",[10],"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":843,"title":844,"titles":845,"content":846,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#links-carry-the-context","Links carry the context",[10],"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":848,"title":849,"titles":850,"content":851,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#instances","Instances",[10],"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":853,"title":854,"titles":855,"content":856,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#why-endpoints-matter","Why endpoints matter",[10],"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":858,"title":169,"titles":859,"content":860,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#probes",[10],"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":862,"title":337,"titles":863,"content":864,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Foverview#whats-next",[10],"Playbooks — the recipes that consume all of this.",{"id":115,"title":114,"titles":866,"content":867,"level":265},[],"The field dictionary — everything a link between the vault's entities can carry.",{"id":869,"title":870,"titles":871,"content":872,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#what-a-link-carries","What a link carries",[114],"The link is the primitive the whole vault is built on: an asset linked to a component, a playbook linked to a requirement, a primitive linked to what earned it. Every link can carry the metadata below. This page is the dictionary; for how each field behaves during matching, see Requirements.",{"id":874,"title":875,"titles":876,"content":877,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#scope","Scope",[114],"FieldValuesMeaningLevelasset-level or component-levelWhether the link sits directly on the asset or nested inside a parent component. See Scopes and Levels.Parenta componentFor scoped links: the exact parent the child was observed in. Scoped matching requires the exact parent.",{"id":879,"title":880,"titles":881,"content":882,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#assignment","Assignment",[114],"FieldValuesMeaningModeindividual, category, category + tagWhat the link points at. Categories and combos resolve live as the library grows.Tag comboa #tagFor category links: the tag members must also carry.EvaluationAny, AllFor category links: one member is enough, or every member is required (and grows with the category).RequirementRequired, OptionalPlaybook links only. Required is a hard gate; optional tunes confidence.",{"id":884,"title":885,"titles":886,"content":887,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#observation-data","Observation data",[114],"FieldApplies toMeaningEndpointsasset linksWhere the capability was observed. Each endpoint is a separate instance; Global means no endpoint was recorded.Versiontechnology linksThe version observed, e.g. 18.2.0. Playbook constraints check it; how strictly depends on the engine mode.State polaritystateful quirksPresent or Absent — what was actually observed about the behavior.Quirk impactplaybook quirk linksEnabling or Mitigating — the role this quirk plays in this playbook.",{"id":889,"title":547,"titles":890,"content":891,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#earned-capabilities",[114],"FieldMeansSourcemanual (you recorded it) or yield (a playbook granted it on success)Yielded byFor earned links: the playbook whose success granted the capabilityYield on successPlaybook links: mark this capability as an output of the playbookPrompt for endpointYield configuration: ask which endpoint the capability was demonstrated on when it's grantedCo-locationPlaybook links: count this requirement only where its endpoints meet the required primitive's endpoints",{"id":893,"title":894,"titles":895,"content":896,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#why-the-dictionary-matters","Why the dictionary matters",[114],"Two reasons the same fields keep showing up across the docs: Every observation is structured the same way. A component on an asset, a requirement on a playbook, a primitive earned through a chain — same primitive, same metadata. Learn the fields once.The engine reads only these fields. If you can't express it as metadata, the engine can't act on it — which is why the authoring discipline matters more than prose in a playbook body.",{"id":898,"title":337,"titles":899,"content":900,"level":271},"\u002Fthe-model\u002Fnotespaces\u002Flink-metadata#whats-next",[114],"Requirements — how each field behaves during matching.Notespaces and Links — where links live.",{"id":40,"title":10,"titles":902,"content":903,"level":265},[],"How the method, the component taxonomy, and the vault's storage model fit together.",{"id":905,"title":906,"titles":907,"content":908,"level":271},"\u002Fthe-model#three-layers-one-model","Three layers, one model",[10],"Everything Nimbus Vault does is built on a single model, expressed in three layers: Methodology — how to think about a target: CAVET's Observe → Probe → Reason → Test workflow, the contextual-hacking mindset, and chain recognition as a way of seeing compound attacks.Components — the vocabulary: the five component types, their categories and tags, and the scopes that let observations nest inside their parents.Notespaces — storage: where observations live, what a link can carry (endpoints, instances, polarity, impact, versions), and how earned primitives extend an asset beyond what recon can find. The Nexus Engine reads this model; playbooks are written against it. Learn the model once and every other page — mapping, prompts, suggestions, chains — is a view of the same structure.",{"id":910,"title":467,"titles":911,"content":912,"level":271},"\u002Fthe-model#where-to-start",[10],"New to the ideas? Read The CAVET Method first.Ready to work? Start with Map an Asset and come back when a field name stops making sense.",{"id":126,"title":125,"titles":914,"content":915,"level":265},[],"How Nimbus Vault organizes the targets you are hacking on.",{"id":917,"title":918,"titles":919,"content":920,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#the-hierarchy","The hierarchy",[125],"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.",{"id":922,"title":923,"titles":924,"content":925,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#one-asset-one-focus","One asset, one focus",[125],"The 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.",{"id":927,"title":928,"titles":929,"content":930,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#getting-assets-in","Getting assets in",[125],"Manual — 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.",{"id":932,"title":933,"titles":934,"content":935,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#asset-types","Asset types",[125],"Web, 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.",{"id":937,"title":938,"titles":939,"content":940,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#sharing","Sharing",[125],"Individual 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.",{"id":942,"title":337,"titles":943,"content":944,"level":271},"\u002Fworkspace\u002Fplatforms-programs-assets#whats-next",[125],"Learn the vocabulary you will attach to every asset: components.",{"id":130,"title":129,"titles":946,"content":947,"level":265},[],"Turn a target into a structured component inventory — click by click. Mapping is the highest-leverage habit in Nimbus Vault. Everything the engine can ever tell you is bounded by what you record. This page is the operational loop; Scopes and Levels explains the model behind it.",{"id":949,"title":950,"titles":951,"content":952,"level":271},"\u002Fworkspace\u002Fmap-an-asset#where-mapping-happens","Where mapping happens",[129],"Open the asset (via its program, or Programs → Assets), and switch the right-hand sidebar to the Components panel. That panel is the inventory: one section per component type, each holding the things you have observed.",{"id":954,"title":955,"titles":956,"content":957,"level":271},"\u002Fworkspace\u002Fmap-an-asset#the-linking-flow","The linking flow",[129],"Hover a section header and click + (e.g. Link Technologies), or use the empty-state button for a type (Link Technology).\n  In the modal, search the section's list. Components already linked to this asset are excluded, so what you see is what's missing. Tick entries — they collect in the Selected (N) rail.\n  Each selected entry expands its metadata:Endpoints (Optional) — the concrete paths where you observed it. Type a path, press Add endpoint; a leading \u002F is added for you, duplicates are ignored. Each endpoint becomes its own instance.Version (Optional) — technologies only, e.g. 18.2.0.State Polarity — stateful quirks only: Present or Absent.CLQs \u002F CLGs \u002F CLVs (Optional) — attach scoped children right here (Add a CLQ...), including nested CLVVs and CLVQs.\n  Confirm with Link \u002F Link N. The engine re-evaluates immediately — suggestions and prompts update on the spot.",{"id":959,"title":960,"titles":961,"content":962,"level":271},"\u002Fworkspace\u002Fmap-an-asset#scope-it-correctly","Scope it correctly",[129],"The level you link at changes what the engine can do with it: Direct on the asset — for observations that belong to the whole target.Scoped inside a parent — a vector inside the file upload that produces it, a quirk inside the technology where you saw the behavior. Scoped requirements demand the exact parent (why).Nested deeper — vector inside vector, quirk on a vector: each scoped level has its own link modal (Link CLQs, Link CLVs, ...) with an Assign to choice: Global — or a specific endpoint, tying the child to one instance.",{"id":964,"title":965,"titles":966,"content":967,"level":271},"\u002Fworkspace\u002Fmap-an-asset#technology-defaults","Technology defaults",[129],"If a technology carries defaults — common quirks, vectors, or gadgets defined in its notespace — they surface when you link it, governed by the default's Inheritance Level (Asset or Component) and Inheritance Mode (Auto or Manual). Confirm what applies instead of retyping the stack's usual suspects.",{"id":969,"title":970,"titles":971,"content":972,"level":271},"\u002Fworkspace\u002Fmap-an-asset#habits-that-pay","Habits that pay",[129],"Technologies and functionalities first. They define the possibility space; vectors, quirks, and gadgets get linked onto the things that produce them.Endpoints are half the value. A capability without an endpoint can still match — but co-location requirements, the ones that keep chains honest, need them.One sitting beats five. The value is in completeness; a half-mapped asset yields half-trustworthy suggestions.Not sure of the exact value? Link what you can confirm now; resolve the specifics when a prompt asks. If a submit stays disabled, the rail shows why — State polarity required, CLVQ targets a vector that is not linked, and similar messages name the missing field.",{"id":974,"title":337,"titles":975,"content":976,"level":271},"\u002Fworkspace\u002Fmap-an-asset#whats-next",[129],"The engine now has something to work with: work the prompts it generates.",{"id":134,"title":133,"titles":978,"content":979,"level":265},[],"Platforms, programs, and assets — the exact forms, in order. Everything in the vault hangs off one hierarchy: platform → program → asset. Set it up once, properly, and every later step inherits the structure.",{"id":981,"title":982,"titles":983,"content":984,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#_1-create-a-platform","1. Create a platform",[133],"A platform is where the work comes from: a bug bounty platform, a VDP, a private client. Open Platforms in the sidebar.Click Add Platform.Fill in the drawer: FieldRequiredNotesNameYese.g. HackerOne, Private clientsDescriptionNoShort descriptionTagsNoComma-separated, e.g. bug bounty, privateCurrencyNoe.g. USD — shown alongside rewardsWebsiteNoe.g. example.comLogo URLNoOptional branding Click Create Platform. Platforms in the list can be favorited — the star on each row (Favorite platform \u002F Unfavorite platform) keeps active sources at hand.",{"id":986,"title":987,"titles":988,"content":989,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#_2-create-a-program","2. Create a program",[133],"A program is one organization's scope — where the rules of engagement live. Open the platform (or go to Programs and click Add Program).Fill in the drawer: FieldRequiredNotesNameYesThe organization's program namePlatformNoPre-filled when launched from inside a platformProgram TypeNoBug Bounty, VDP, or PentestStatusNoActive, Paused, or Ended — defaults to ActiveLaunch DateNoWhen the program startedProgram URLNoLink to the official briefRewards RangeNoFree text, e.g. $100 - $10,000Logo URLNoOptional branding Click Create Program. The program's page carries its own guidelines editor — paste the scope, excluded assets, and program rules there; save from that page. It is the one place to re-read the rules without leaving the vault.",{"id":991,"title":992,"titles":993,"content":994,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#_3-create-assets","3. Create assets",[133],"Assets are the concrete things you test. There's a global Assets page, and asset lists inside programs. Click Add Asset.Fill in the drawer: FieldRequiredNotesNameYese.g. api.example.com; the placeholder follows the chosen typeAsset TypeYesPick from the type list (Web, API, Mobile iOS\u002FAndroid, Desktop, Cloud Infrastructure, Network\u002FVPN, Smart Contract, Hardware\u002FIoT, Source Code Repository, and more)PriorityNoDefaults to None; also Low, Medium, High, CriticalTagsNoComma-separated, e.g. prod, internal, mobileURLNoA direct link to the target Click Create Asset.",{"id":996,"title":997,"titles":998,"content":999,"level":439},"\u002Fworkspace\u002Fmanage-your-scope#wildcards-are-containers-not-targets","Wildcards are containers, not targets",[133,992],"Choose the Wildcard type when you want to organize a broad scope. Two rules apply: The name must contain * — e.g. *.example.com or target.*.staging.com. Otherwise the drawer refuses it: \"Wildcard names must contain *.\"Concrete URLs live under the wildcard as Web assets — a URL whose parent wildcard does not exist is rejected. A wildcard groups; it is never the thing you map.",{"id":1001,"title":1002,"titles":1003,"content":1004,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#bring-in-a-list-you-already-have","Bring in a list you already have",[133],"If you maintain targets elsewhere, skip the retyping: Open the Assets page and click Import.The Import Assets modal parses your list; review and select the rows to bring in.Click Import N assets — progress streams as they land, and the import can be cancelled mid-run. Import first, then map the ones worth pursuing.",{"id":1006,"title":1007,"titles":1008,"content":1009,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#habits-that-pay-off","Habits that pay off",[133],"Concrete names. api.example.com beats \"the API\" — precision starts with what you called things.Priorities are triage. Map everything if you like; priority decides what gets attention first.Nest what belongs together. Subdomains under their domain, an API under its app — a capability on a child sharpens what the engine knows about the parent.One workspace per context — client boundaries are worth preserving, and cloning makes the setup cheap.",{"id":1011,"title":337,"titles":1012,"content":1013,"level":271},"\u002Fworkspace\u002Fmanage-your-scope#whats-next",[133],"With the scope in place, the real work starts: map an asset.",{"id":138,"title":137,"titles":1015,"content":1016,"level":265},[],"Invite teammates, share single entities, and keep a visible trail.",{"id":1018,"title":1019,"titles":1020,"content":1021,"level":271},"\u002Fworkspace\u002Fshare-and-collaborate#working-in-a-shared-workspace","Working in a shared workspace",[137],"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":1023,"title":355,"titles":1024,"content":1025,"level":439},"\u002Fworkspace\u002Fshare-and-collaborate#members-and-roles",[137,1019],"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":1027,"title":1028,"titles":1029,"content":1030,"level":439},"\u002Fworkspace\u002Fshare-and-collaborate#what-sharing-looks-like-in-practice","What sharing looks like in practice",[137,1019],"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":1032,"title":1033,"titles":1034,"content":1035,"level":271},"\u002Fworkspace\u002Fshare-and-collaborate#sharing-a-single-entity","Sharing a single entity",[137],"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":1037,"title":1038,"titles":1039,"content":1040,"level":271},"\u002Fworkspace\u002Fshare-and-collaborate#keeping-it-healthy","Keeping it healthy",[137],"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":1042,"title":337,"titles":1043,"content":1044,"level":271},"\u002Fworkspace\u002Fshare-and-collaborate#whats-next",[137],"Clone a Workspace — start the next engagement from a known-good setup.Account and Workspaces — roles and plan basics.",{"id":142,"title":141,"titles":1046,"content":1047,"level":265},[],"Start an engagement from your best setup instead of an empty vault.",{"id":1049,"title":1050,"titles":1051,"content":1052,"level":271},"\u002Fworkspace\u002Fclone-a-workspace#why-clone","Why clone",[141],"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":1054,"title":1055,"titles":1056,"content":1057,"level":271},"\u002Fworkspace\u002Fclone-a-workspace#what-you-can-take-with-you","What you can take with you",[141],"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":1059,"title":1060,"titles":1061,"content":1062,"level":271},"\u002Fworkspace\u002Fclone-a-workspace#when-to-clone","When to clone",[141],"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.",{"id":1064,"title":337,"titles":1065,"content":1066,"level":271},"\u002Fworkspace\u002Fclone-a-workspace#whats-next",[141],"Manage Your Scope — shape the fresh clone.Share and Collaborate — bring the team in.",{"id":119,"title":10,"titles":1068,"content":1069,"level":265},[],"Your scope, your team, and how work is organized.",{"id":1071,"title":1072,"titles":1073,"content":1074,"level":271},"\u002Fworkspace#the-container-for-everything","The container for everything",[10],"A workspace holds your target inventory, component library, playbooks, and notespaces — and it's what you share with a team. This section covers everything around the hunt itself: Platforms, Programs, and Assets — the scope hierarchy everything hangs off.Map an Asset — turn a target into a structured component inventory (the core operating loop).Manage Your Scope — create platforms, programs, and assets; wildcard containers; imports.Share and Collaborate — members, roles, invite links, and snapshot sharing.Clone a Workspace — start the next engagement from your best setup.",{"id":1076,"title":1077,"titles":1078,"content":1079,"level":271},"\u002Fworkspace#where-work-starts","Where work starts",[10],"If you're new: create your scope first (Manage Your Scope), then map an asset and let the engine take it from there.",{"id":153,"title":152,"titles":1081,"content":1082,"level":265},[],"How matches become ranked, explainable suggestions you can act on.",{"id":1084,"title":1085,"titles":1086,"content":1087,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#the-moment-a-match-happens","The moment a match happens",[152],"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":1089,"title":1090,"titles":1091,"content":1092,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#ranked-and-explainable","Ranked and explainable",[152],"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":1094,"title":1095,"titles":1096,"content":1097,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#what-ranks-a-suggestion-higher","What ranks a suggestion higher",[152],"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":1099,"title":1100,"titles":1101,"content":1102,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#partially-satisfied-playbooks","Partially satisfied playbooks",[152],"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":1104,"title":394,"titles":1105,"content":1106,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#reading-a-suggestion",[152],"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":1108,"title":337,"titles":1109,"content":1110,"level":271},"\u002Fnexus-engine\u002Fsuggestions-and-ranking#whats-next",[152],"Checklist and Probes — the other half: what the engine asks you to look for.Requirements — the mechanics behind every match.",{"id":162,"title":161,"titles":1112,"content":1113,"level":265},[],"Prompts for what is still unknown — how the engine turns near-misses into questions.",{"id":1115,"title":1116,"titles":1117,"content":1118,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#reactive-vs-proactive","Reactive vs. proactive",[161],"Matching is reactive: it answers questions about what you have already recorded. The proactive checklist is the other half: it asks what is still unknown. For every asset, the engine generates prompts from playbook requirements that are not yet confirmed. Each item is a question about the target: Does this asset expose a password-reset flow?",{"id":1120,"title":1121,"titles":1122,"content":1123,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#where-prompts-come-from","Where prompts come from",[161],"A prompt exists because a playbook is a near-miss: some of its required components are present on the asset, but not all. The engine is telling you \"this playbook is one confirmation away\" — the missing required components become the prompts, ordered by how close they are to unlocking something. Required CLQs are the most common source: a condition that is necessary for an attack to be applicable, and easy to forget to check — \"does the server extract uploaded archives?\" — is exactly the sort of thing worth a standing question.",{"id":1125,"title":1126,"titles":1127,"content":1128,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#resolving-a-prompt","Resolving a prompt",[161],"Three honest answers, three different mechanics: Yes — link the missing component to the asset. The prompt disappears on its own — satisfied requirements don't linger — and the playbook fires immediately if nothing else is missing. No history entry is created for a prompt that resolved itself.No — only after tracing the full surface. Record the answer as a manual check; the prompt moves to the asset's history and won't be suggested again unless you remove it there. A wrong negative silently suppresses every playbook behind it.Endpoint — if confirming the capability revealed where it lives, record the endpoint on the link. Prompts that ask about a component with probes carry a probe-count badge — the context menu's View probes shows exactly how to check for it without leaving the asset.",{"id":1130,"title":1131,"titles":1132,"content":1133,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#what-happens-after-you-resolve","What happens after you resolve",[161],"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. Resolutions land in the asset's History → Checklists → Proactive Checks, alongside the reactive checks.",{"id":1135,"title":1136,"titles":1137,"content":1138,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#checklist-vs-coverage","Checklist vs. coverage",[161],"The checklist is the open work for one asset; coverage measures how much of what could apply you have confirmed. Both live on the asset, and both move when you resolve prompts with evidence. See Dashboard Metrics.",{"id":1140,"title":337,"titles":1141,"content":1142,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Fproactive-checklist#whats-next",[161],"Work a Prompt — the practical discipline.Reactive Checklist — the objectives side of the same panel.",{"id":166,"title":165,"titles":1144,"content":1145,"level":265},[],"The objectives your components carry — authored once, checked on every target.",{"id":1147,"title":1148,"titles":1149,"content":1150,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#objectives-a-components-test-list","Objectives: a component's test list",[165],"The reactive checklist is built from objectives — the concrete things worth checking whenever a component shows up on a target. For a file upload, an objective might be \"Test for unrestricted file type acceptance\". Objectives are authored on the component, in its Checklists tab: Open the component and switch to Checklists.Click Add Objective.Fill in the Objective title and an optional Description (supports lists, inline code, and headings for context, links, or examples). For bulk entry, switch to Paste multiple — one objective per line becomes one objective each. Objectives can be drag-reordered, and the order is shared across every asset the component appears on. For stateful quirks, each objective also carries a State: Present or Absent — and the panel filters by the same values, so a quirk's test list stays coherent with how the quirk actually behaves.",{"id":1152,"title":1153,"titles":1154,"content":1155,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#where-objectives-surface","Where objectives surface",[165],"They travel with the component. When it's linked to an asset, its objectives appear in that asset's Suggestions → Checklists → Reactive section — the checklist for what you can check, as opposed to the proactive side, which asks for what's missing.",{"id":1157,"title":1158,"titles":1159,"content":1160,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#checking-them-off","Checking them off",[165],"Check an objective once you have verified it on the asset. The check is recorded in the asset's History → Checklists → Reactive Checks — the durable record of what was verified, on this asset, by hand. Entries stay in history until you remove them. Removing one makes it eligible to surface again. That's the escape hatch for mistakes, not the default — the record is meant to be trustworthy.",{"id":1162,"title":1163,"titles":1164,"content":1165,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#why-objectives-matter","Why objectives matter",[165],"They make component knowledge actionable. An objective is what a colleague — or future you — actually does with the component on a new target.They compound. Write the test once on the component, and every asset it ever appears on inherits it.They discipline review. A checklist beats trying to remember what mattered last time.",{"id":1167,"title":337,"titles":1168,"content":1169,"level":271},"\u002Fnexus-engine\u002Fchecklists\u002Freactive-checklist#whats-next",[165],"Work a Prompt — working both checklist sides in practice.Probes — the how-to notes that make each check concrete.",{"id":170,"title":169,"titles":1171,"content":1172,"level":265},[],"Reusable how-to-check notes that surface at the moment a prompt asks.",{"id":1174,"title":1175,"titles":1176,"content":1177,"level":271},"\u002Fnexus-engine\u002Fprobes#what-a-probe-is","What a probe is",[169],"If objectives say what to check, probes answer how. A probe is a short, reusable note attached to a component: the query to send, the UI path to follow, the thing that took you an hour to figure out the first time. Probes live on the component, in its Probes tab: Open the component and switch to Probes.Click Add Probe.Fill in the title and an optional description. They support drag-reordering, editing, and deletion — the same conventions as objectives.",{"id":1179,"title":1180,"titles":1181,"content":1182,"level":271},"\u002Fnexus-engine\u002Fprobes#where-probes-surface","Where probes surface",[169],"At the moment of need. When a proactive prompt asks you to confirm a component on an asset, the prompt carries a probe-count badge — and its context menu offers View probes, opening that component's probes as a numbered list, right there in the asset view. If the component has no probes yet, the panel says so: \"This component has no probes defined in its notespace yet.\"",{"id":1184,"title":1185,"titles":1186,"content":1187,"level":271},"\u002Fnexus-engine\u002Fprobes#why-probes-matter","Why probes matter",[169],"They close the distance between noticing and checking. A checklist only accelerates you if the how is one click away.They capture hard-won knowledge. The bypass that worked, the header that mattered — written once, surfaced forever.They compound like everything else. A good probe serves every asset the component ever appears on, and every teammate who ever works it.",{"id":1189,"title":337,"titles":1190,"content":1191,"level":271},"\u002Fnexus-engine\u002Fprobes#whats-next",[169],"Proactive Checklist — where probes surface.Work a Prompt — the practice of resolving prompts with evidence.",{"id":174,"title":173,"titles":1193,"content":1194,"level":265},[],"Resolve the checklist accurately — where it lives, and what each action does.",{"id":1196,"title":1197,"titles":1198,"content":1199,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#where-prompts-live","Where prompts live",[173],"Open an asset and switch to Suggestions → Checklists. The panel has two sections: Proactive — near-miss prompts. A playbook is partially satisfied and the engine is asking about a missing required component. Empty state: \"No near-miss prompts right now.\"Reactive — the objectives carried by components linked to this asset (what objectives are).",{"id":1201,"title":1202,"titles":1203,"content":1204,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#resolving-a-proactive-prompt","Resolving a proactive prompt",[173],"A prompt is a question: does this capability apply here? Three honest answers, three different mechanics: Assign the missing component to the asset (the linking flow). The prompt disappears on its own — satisfied requirements don't linger — and the playbook fires immediately if nothing else is missing. No history entry is created for a prompt that resolved itself.\n  A negative is a real result, but only after you have traced the whole flow: the parent, the child, and the interaction between them. Incomplete negatives silently suppress every playbook behind them. Record the answer as a manual check — the prompt moves to the asset's history and won't be suggested again unless you remove it there.\n  Prompts that ask about a component with probes carry a probe-count badge. Open the prompt's context menu → View probes to see exactly how to check for it, without leaving the asset.",{"id":1206,"title":1207,"titles":1208,"content":1209,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#working-the-reactive-objectives","Working the reactive objectives",[173],"Objectives arrive with the components you link, so they are always relevant to what you mapped. Check them off as you verify them in the app — each check is recorded in the asset's history under Reactive Checks. This list is what the Playbook Coverage Rate measures.",{"id":1211,"title":1212,"titles":1213,"content":1214,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#where-the-record-goes","Where the record goes",[173],"Open the asset's History panel: Playbooks — outcome history for playbook runs.Checklists — Proactive Checks (manual prompt resolutions) and Reactive Checks (objective check-offs). Entries stay until you remove them. Removing an entry makes it eligible again — a prompt can ask once more, an objective can resurface. That is the escape hatch for mistakes, not the default: the record is meant to be trustworthy. Never resolve a prompt from assumption. The checklist exists to capture evidence — treating it as a click-through form defeats the entire model, because everything downstream (suggestions, scores, chains) reasons from what it says.",{"id":1216,"title":1131,"titles":1217,"content":1218,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#what-happens-after-you-resolve",[173],"The engine re-evaluates the asset immediately: new suggestions appear, others disappear, the remaining checklist shrinks. Resolutions are revision-safe — update the record whenever you learn something new; the engine follows your data, not a stale decision.",{"id":1220,"title":337,"titles":1221,"content":1222,"level":271},"\u002Fnexus-engine\u002Fwork-a-prompt#whats-next",[173],"When a suggestion looks right, go execute: run a playbook.",{"id":146,"title":10,"titles":1224,"content":1225,"level":265},[],"Deterministic matching, ranked suggestions, and the proactive checklist.",{"id":1227,"title":1228,"titles":1229,"content":1230,"level":271},"\u002Fnexus-engine#rules-not-guesses","Rules, not guesses",[10],"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":1232,"title":1233,"titles":1234,"content":1235,"level":271},"\u002Fnexus-engine#in-this-section","In this section",[10],"Suggestions and Ranking — how matches become ranked, explainable suggestions.Proactive Checklist — prompts for what is still unknown.Reactive Checklist — the objectives your components carry.Probes — reusable how-to-check notes that surface with prompts.Work a Prompt — the practical discipline for both checklist sides.",{"id":1237,"title":1238,"titles":1239,"content":1240,"level":271},"\u002Fnexus-engine#how-a-match-happens","How a match happens",[10],"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":1242,"title":1243,"titles":1244,"content":1245,"level":271},"\u002Fnexus-engine#the-proactive-checklist","The proactive checklist",[10],"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 Proactive Checklist for the model and Work a Prompt for the practice.",{"id":1247,"title":1248,"titles":1249,"content":1250,"level":271},"\u002Fnexus-engine#why-it-compounds","Why it compounds",[10],"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":1252,"title":337,"titles":1253,"content":1254,"level":271},"\u002Fnexus-engine#whats-next",[10],"Put it to work: map an asset, then work a prompt.",{"id":185,"title":184,"titles":1256,"content":1257,"level":265},[],"From the Add Playbook drawer to a saved recipe — the exact steps.",{"id":1259,"title":1260,"titles":1261,"content":1262,"level":271},"\u002Fplaybooks\u002Fcreate-a-playbook#create-it","Create it",[184],"Open Playbooks in the sidebar.Click Add Playbook — in the toolbar, or the button in the empty state.Fill in the drawer: FieldRequiredNotesNameYesThe playbook's title, e.g. Zip Slip — Arbitrary File Write via Archive Extraction. Must be unique in the workspace.DifficultyNoN\u002FA or 1–10 — how hard it is to execute.SeverityNoN\u002FA, Low, Medium, High, or Critical — the impact if it lands.TagsNoComma-separated, e.g. archive, file-upload, rce.ReferencesNoComma-separated links — the research this playbook came from. Click Create Playbook. The playbook appears in the list (a toast confirms it); open it by clicking its card. Name collisions are rejected — you will get \"A playbook with that name already exists in this workspace.\" Rename one of them, or merge them (near-duplicates are usually a tagging problem — see the Authoring Guide).",{"id":1264,"title":1265,"titles":1266,"content":1267,"level":271},"\u002Fplaybooks\u002Fcreate-a-playbook#write-the-body","Write the body",[184],"Open the playbook to land in its notespace. The left side is the notes editor with a Rich editor \u002F Raw markdown toggle, a save-state indicator (Unsaved, Draft, Saved), and Save (⌘S). This is where everything that isn't a trigger condition belongs. The Authoring Guide makes the split explicit: requirements define when the playbook fires; the body tells the hunter what to do once it does. A body that works well in practice usually covers: What this achieves — one line, so a hunter in a hurry gets it instantly.Preconditions as observed — what the mapped context means, in plain words.Execution steps — numbered, with the payloads and variant techniques that would bloat the requirements.Bypass notes — WAF tricks, encoding variants, language-specific gotchas.References — deeper reading for the unlucky-run case.",{"id":1269,"title":1270,"titles":1271,"content":1272,"level":271},"\u002Fplaybooks\u002Fcreate-a-playbook#the-rest-of-the-notespace","The rest of the notespace",[184],"The sidebar holds the panels that make the playbook executable: Components — the requirements. Built on the next page: Link Components to a Playbook.Yields — what the playbook produces on success: Declare Yields.Folder — supplementary notes attached to the playbook.Info — severity, difficulty, tags, references, and creation\u002Fupdate history.",{"id":1274,"title":1275,"titles":1276,"content":1277,"level":271},"\u002Fplaybooks\u002Fcreate-a-playbook#managing-a-playbook","Managing a playbook",[184],"Edit fields — the pencil on the playbook card reopens the drawer as Edit Playbook (Save Playbook).Delete — Delete playbook on the card.Share — Share this playbook in the notespace header copies a read-only snapshot link (see Share and Collaborate).",{"id":1279,"title":337,"titles":1280,"content":1281,"level":271},"\u002Fplaybooks\u002Fcreate-a-playbook#whats-next",[184],"Link Components to a Playbook — turn the body into a firing trigger.Declare Yields — let the playbook unlock others when it succeeds.",{"id":189,"title":188,"titles":1283,"content":1284,"level":265},[],"Build the trigger — modes, required\u002Foptional, scoping, and every field on the way.",{"id":1286,"title":1287,"titles":1288,"content":1289,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#the-flow","The flow",[188],"Open the playbook and go to its Components panel.Click Link Component (panel header), the hover Add Component on a section, or Link a Component in the empty state.In the Link Components modal, pick an assignment mode: Individual, Category, or Tag. (Category and Tag hide the Quirks type.)Pick a component type chip — Technologies, Functionalities, Gadgets, Primitives, Vectors, Quirks — and search the list.Tick rows; the Selected (N) rail collects them. Confirm with Link \u002F Link N. Every selected entry then expands its metadata, under Assignment & Details (Individual) or Assignment (Category\u002FTag). This is where the trigger is really designed.",{"id":1291,"title":1292,"titles":1293,"content":1294,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#requirement-required-or-optional","Requirement: Required or Optional",[188],"This single toggle is the most consequential field on the page: Required — a hard gate. The engine excludes the playbook until this is satisfied. Missing required pieces become proactive prompts on the asset.Optional — a confidence signal. The playbook fires without it; presence raises the score, absence lowers it. If a component matters but can't reliably be confirmed in black-box testing, make it Optional — a required condition that can never be confirmed produces silence, not precision. See the Authoring Guide.",{"id":1296,"title":1297,"titles":1298,"content":1299,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#category-and-tag-modes","Category and Tag modes",[188],"Instead of naming one component, a Category assignment covers any member of a category — and a Tag narrows within it: Evaluation Mode: Any \u002F All — Any needs at least one member; All needs every member (and grows as the category does). All is only available when the link is Required — an optional link can never require everything.Tag Combo (Optional) — e.g. #archive-file. Both conditions must hold simultaneously: the component is in the category and carries the tag. Leave blank for a plain category assignment. If you get a warning that no current components satisfy the combo, saving is still allowed — the requirement resolves live, so future components that qualify will satisfy it.",{"id":1301,"title":1302,"titles":1303,"content":1304,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#individual-link-fields","Individual-link fields",[188],"When you're linking a specific component, extra fields appear, each valid in its own context: Version Constraint (Optional) — technology links only. Accepted formats: FormatExampleExact14.17.0Comparisons>=14.0.0, \u003C19Wildcards14.x, 1.*Tilde \u002F caret~14.2, ^14.0.0Hyphen range14.0.0 - 19.0.0OR`14 An unparseable constraint counts as unverified: penalized under lax engine mode and a no-match under strict. Endpoints (Optional) — the endpoints this requirement is expected at (\u002Fapi\u002Fv1\u002Fpath). Meaningful mainly with co-location. Co-location — a checkbox, \"Same endpoint as the required primitive.\" It only appears when the playbook declares at least one required primitive (and never on primitive or category\u002Ftag links). When set, the link only counts where its endpoints intersect the endpoints of the playbook's required primitives — a strict, both-ways check. It is the field that kills false positives where every ingredient exists but never in the same place. (Full semantics: Requirements.) Quirk Impact — Enabling or Mitigating. The same quirk can play either role in different playbooks; mitigations weigh heavier in scoring. State Polarity — Present or Absent, for stateful quirks. A requirement written as absent is satisfied only by a confirmed absence — not by silence. Yield — on gadget links, the Yields on success toggle marks the gadget as a playbook output. See Declare Yields. Boundary Refinement — \"Refine this component within its boundary.\" For individual links that sit inside an Any-mode category\u002Ftag boundary and need their own conditions (a version, extra quirks) on top of the boundary match. Yield links are never treated as boundary refinements.",{"id":1306,"title":1307,"titles":1308,"content":1309,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#scoped-children","Scoped children",[188],"Precision comes from structure, so assignments accept scoped children. On an assigned component row you'll find Add Quirks, Add Vectors, Add Gadgets, Add Categories, and Add Tags — each child with its own Required \u002F Optional and, where relevant, polarity and impact. On a vector, Add CLVQ attaches a quirk to that vector, and Nested Vectors goes one level deeper; on gadgets, Add CLGV and Add CLGQ do the same. The payoff is exact-parent matching: a quirk required inside Node.js is not satisfied by the same quirk anywhere on the asset. Structural requirements buy precision that flat links can never express.",{"id":1311,"title":1312,"titles":1313,"content":1314,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#managing-links","Managing links",[188],"Each row offers Edit details and Remove. Sections can be wiped with Clear Components — with one exception: \"Yielded links are kept. This cannot be undone.\"",{"id":1316,"title":1317,"titles":1318,"content":1319,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#if-submit-is-disabled","If submit is disabled",[188],"The rail shows the reason. The common ones: All mode requires Required (or Optional + All is not allowed) — flip the link to Required or use Any.Quirk impact required — pick Enabling or Mitigating.State polarity required \u002F Polarity required for stateful quirks — stateful quirks need Present or Absent.CLVQ targets a vector that is not linked — add the vector before the quirk that hangs off it.Vector category links cannot use Optional + All — category mode on vectors forbids optional-all.",{"id":1321,"title":1322,"titles":1323,"content":1324,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#worked-example-the-zip-slip-trigger","Worked example: the Zip Slip trigger",[188],"The Authoring Guide designs this playbook; here is the same design expressed in the UI: Link Component → Individual → Technologies → Java — Requirement: Optional. Disproportionately affected, but not part of the detection path.Link Component → Individual → Functionalities → File Upload — Requirement: Required. The broadest gate: no upload surface, no attack.On the File Upload row, Add Vectors → Category — category File Types, Tag Combo #archive-file, Mode Any, Required. One assignment covers ZIP, TAR, JAR, and every archive format you tag in the future.On the File Upload row, Add Quirks → server-side archive extraction — Required, Impact Enabling. This is the condition that's invisible from the upload UI — the reason it's a required CLQ is that the engine will hold the playbook and keep prompting until a hunter confirms or rules it out. Confirm with Link. The trigger is now exactly three conditions plus one optional signal — lean, precise, and impossible to fire on a target without server-side extraction.",{"id":1326,"title":337,"titles":1327,"content":1328,"level":271},"\u002Fplaybooks\u002Flink-components-to-a-playbook#whats-next",[188],"Declare Yields — what this playbook produces when it succeeds.Requirements — the full mechanics reference behind every field above.",{"id":193,"title":192,"titles":1330,"content":1331,"level":265},[],"Give a playbook outputs — capabilities other playbooks can require.",{"id":1333,"title":1334,"titles":1335,"content":1336,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#what-a-yield-is","What a yield is",[192],"A yield is what the playbook produces when it succeeds — a capability that lands on the asset as a primitive. Yields are how chains form: a later playbook can require a primitive, and the suggestion only appears once this playbook has actually succeeded.",{"id":1338,"title":1339,"titles":1340,"content":1341,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#two-ways-to-declare-one","Two ways to declare one",[192],"",{"id":1343,"title":1344,"titles":1345,"content":1346,"level":439},"\u002Fplaybooks\u002Fdeclare-yields#self-contained-yield-a-new-capability","Self-contained yield (a new capability)",[192,1339],"For chain-specific capabilities with no library identity — things like arbitrary-file-write or internal-foothold: Open the playbook's Yields panel.Click Create Yield.Type the name in the New yield name... field and press Create (Esc cancels). The name becomes a self-contained primitive: it lives only as a link in the chain, never as a library component. Names must be unique — creating an existing one is rejected.",{"id":1348,"title":1349,"titles":1350,"content":1351,"level":439},"\u002Fplaybooks\u002Fdeclare-yields#gadget-yield-an-existing-capability","Gadget yield (an existing capability)",[192,1339],"When the capability the playbook earns is a real concept in your library — Stored XSS, SSRF — don't create a parallel one: In the playbook's Components panel, find the gadget link (or link it first).Toggle Yields on success on that link. The gadget shows up in the Yields panel with a Gadget-marked badge. The distinction matters only for bookkeeping — the engine treats both as primitives on the asset. Rule of thumb: if it has a library page and a hunter could assign it during recon, it's a gadget yield. If nobody would ever assign it because it can only be achieved, it's self-contained.",{"id":1353,"title":1354,"titles":1355,"content":1356,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#grant-modes","Grant modes",[192],"When a playbook declares more than one yield, a Grant all yields on success toggle appears in the Yields panel: On (default) — every yield is granted automatically when the playbook is marked successful.Off — the hunter is prompted to pick which yields actually applied on that target. Real runs are messy; this keeps the record honest. Playbooks with a single yield don't need the toggle — it grants when it succeeds.",{"id":1358,"title":1359,"titles":1360,"content":1361,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#endpoint-prompt-on-earn","Endpoint prompt on earn",[192],"The gear icon on a yield opens its configuration: Prompt for endpoint when earned — when on, granting this yield asks which endpoint it was discovered on, and stores it on the earned link. This feeds the same endpoint discipline that powers co-location.",{"id":1363,"title":1364,"titles":1365,"content":1366,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#removing-a-yield","Removing a yield",[192],"A self-contained yield: Delete yield — it disappears from the playbook (and is revoked wherever it was earned, via the normal retraction cascade).A gadget yield: Remove yield (keeps gadget linked) — the gadget stays a requirement; only the yield marking is removed.",{"id":1368,"title":337,"titles":1369,"content":1370,"level":271},"\u002Fplaybooks\u002Fdeclare-yields#whats-next",[192],"Yields and Primitives — the model behind this page.Requirements — how a later playbook requires an earned primitive.",{"id":197,"title":196,"titles":1372,"content":1373,"level":265},[],"Open a suggestion, read it, execute, record — and what each outcome does.",{"id":1375,"title":1376,"titles":1377,"content":1378,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#where-suggestions-live","Where suggestions live",[196],"Open an asset → Suggestions → Playbooks. You'll see ranked suggestion cards (sortable by Score or Name), with the checklist sections above them. Click a card to open the playbook in a read-only view — the body, requirements, and yields — with a back button to return. The card's menu opens the playbook's own notespace if you need to edit it. Work the suggestions the engine actually produced. Executing unrelated playbooks burns time and poisons the outcome history with noise.",{"id":1380,"title":1381,"titles":1382,"content":1383,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#read-it-before-you-run-it","Read it before you run it",[196],"Every suggestion shows its reasoning: which requirements matched, how specific the match is, and what the playbook yields if it succeeds. If a match looks wrong, fix the underlying data before testing — editing a link, correcting a polarity, adding the endpoint that was missing.",{"id":1385,"title":1386,"titles":1387,"content":1388,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#execute","Execute",[196],"Do the work outside Nimbus Vault, within program rules. The vault is where knowledge lives, not where exploitation happens.",{"id":1390,"title":1391,"titles":1392,"content":1393,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#record-the-outcome","Record the outcome",[196],"Each suggestion card carries three actions: ActionTooltipWhat it does✓Mark playbook as successfulGrants the playbook's yields as primitives✗Mark playbook as failedRetires the suggestion — the engine stops surfacing it−Mark playbook as not applicableRetires it as irrelevant, without recording a failed test On success, yields are attached to the asset. If the playbook is set to grant all, that happens silently; if it's set to hunter-picks, you're prompted to select which earned primitives actually applied. Yields configured with \"Prompt for endpoint when earned\" also ask where the capability was discovered — record it when you can; it feeds co-location. Whichever outcome you choose, the card moves into the asset's History under Playbooks.",{"id":1395,"title":1396,"titles":1397,"content":1398,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#after-a-success","After a success",[196],"The earned capabilities appear in the asset's Primitives panel — read-only, the permanent record of what was achieved.Playbooks that require those primitives can now appear as new suggestions. That cascade is the vault working as intended (how chains form).",{"id":1400,"title":1401,"titles":1402,"content":1403,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#retracting","Retracting",[196],"Mistakes are correctable: open the asset's History → Playbooks and retract the outcome. A retracted success revokes the yields it granted, and anything that was standing on them is re-evaluated — downstream playbooks that lose a required primitive revert with a visible notice. The history trail stays intact.",{"id":1405,"title":337,"titles":1406,"content":1407,"level":271},"\u002Fplaybooks\u002Frun-a-playbook#whats-next",[196],"Keep the loop tight: back to mapping as you discover more.See the full vocabulary in the glossary.",{"id":201,"title":200,"titles":1409,"content":1410,"level":265},[],"Build playbooks that fire at the right moment — the detection-path method.",{"id":1412,"title":1413,"titles":1414,"content":1415,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#a-hunting-tool-not-a-reference-document","A hunting tool, not a reference document",[200],"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":1417,"title":1418,"titles":1419,"content":1420,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#the-detection-path-question","The detection path question",[200],"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":1422,"title":1423,"titles":1424,"content":1341,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#the-building-blocks","The building blocks",[200],{"id":1426,"title":1427,"titles":1428,"content":1429,"level":439},"\u002Fplaybooks\u002Fauthoring-guide#required-is-an-and-gate","Required is an AND gate",[200,1423],"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.",{"id":1431,"title":1432,"titles":1433,"content":1434,"level":439},"\u002Fplaybooks\u002Fauthoring-guide#optional-components-shape-confidence","Optional components shape confidence",[200,1423],"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":1436,"title":1437,"titles":1438,"content":1439,"level":439},"\u002Fplaybooks\u002Fauthoring-guide#encode-blind-spots-as-required-quirks","Encode blind spots as required quirks",[200,1423],"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":1441,"title":1442,"titles":1443,"content":1444,"level":439},"\u002Fplaybooks\u002Fauthoring-guide#categories","Categories",[200,1423],"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":1446,"title":1447,"titles":1448,"content":1449,"level":439},"\u002Fplaybooks\u002Fauthoring-guide#tags-and-category-tag","Tags and category + tag",[200,1423],"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":1451,"title":1452,"titles":1453,"content":1454,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#the-seven-principles","The seven principles",[200],"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":1456,"title":1457,"titles":1458,"content":1459,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#case-study-zip-slip","Case study: Zip Slip",[200],"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":1461,"title":1462,"titles":1463,"content":1464,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#before-you-finalize","Before you finalize",[200],"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":1466,"title":1467,"titles":1468,"content":1469,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#the-deeper-principle","The deeper principle",[200],"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":1471,"title":337,"titles":1472,"content":1473,"level":271},"\u002Fplaybooks\u002Fauthoring-guide#whats-next",[200],"Requirements — every assignment level and property in detail.Yields and Primitives — what playbooks produce, and how chains form.",{"id":205,"title":204,"titles":1475,"content":1476,"level":265},[],"Every assignment level and property a playbook requirement can carry.",{"id":1478,"title":1479,"titles":1480,"content":1481,"level":271},"\u002Fplaybooks\u002Frequirements#what-a-requirement-is","What a requirement is",[204],"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":1483,"title":1484,"titles":1485,"content":1486,"level":271},"\u002Fplaybooks\u002Frequirements#assignment-levels","Assignment levels",[204],"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":1488,"title":1489,"titles":1490,"content":1341,"level":271},"\u002Fplaybooks\u002Frequirements#properties","Properties",[204],{"id":1492,"title":1493,"titles":1494,"content":1495,"level":439},"\u002Fplaybooks\u002Frequirements#required-the-hard-gate","Required — the hard gate",[204,1489],"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":1497,"title":1498,"titles":1499,"content":1500,"level":439},"\u002Fplaybooks\u002Frequirements#optional-the-confidence-signal","Optional — the confidence signal",[204,1489],"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":1502,"title":1503,"titles":1504,"content":1505,"level":439},"\u002Fplaybooks\u002Frequirements#enabling-and-mitigating-quirks","Enabling and mitigating quirks",[204,1489],"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":1507,"title":1508,"titles":1509,"content":1510,"level":439},"\u002Fplaybooks\u002Frequirements#present-and-absent-quirk-polarity","Present and absent — quirk polarity",[204,1489],"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":1512,"title":1513,"titles":1514,"content":1515,"level":439},"\u002Fplaybooks\u002Frequirements#version-constraints","Version constraints",[204,1489],"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":1517,"title":1518,"titles":1519,"content":1520,"level":439},"\u002Fplaybooks\u002Frequirements#co-location","Co-location",[204,1489],"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":1522,"title":1523,"titles":1524,"content":1525,"level":439},"\u002Fplaybooks\u002Frequirements#primitive-requirements","Primitive requirements",[204,1489],"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":1527,"title":1528,"titles":1529,"content":1530,"level":271},"\u002Fplaybooks\u002Frequirements#how-the-engine-treats-requirements","How the engine treats requirements",[204],"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":209,"title":208,"titles":1532,"content":1533,"level":265},[],"What playbooks produce on success, and how earned capabilities form chains.",{"id":1535,"title":1536,"titles":1537,"content":1538,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#yields-what-a-playbook-produces","Yields: what a playbook produces",[208],"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":1540,"title":1541,"titles":1542,"content":1543,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#primitives-earned-not-observed","Primitives: earned, not observed",[208],"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":1545,"title":1546,"titles":1547,"content":1548,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#granting-yields","Granting yields",[208],"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":1550,"title":1551,"titles":1552,"content":1553,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#yield-gating-the-chain-mechanic","Yield-gating: the chain mechanic",[208],"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":1555,"title":557,"titles":1556,"content":1557,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#meta-playbooks",[208],"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":1559,"title":1560,"titles":1561,"content":1562,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#a-worked-chain","A worked chain",[208],"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":1564,"title":1565,"titles":1566,"content":1567,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#retraction-and-the-cascade","Retraction and the cascade",[208],"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":1569,"title":337,"titles":1570,"content":1571,"level":271},"\u002Fplaybooks\u002Fyields-and-primitives#whats-next",[208],"Outcomes and History — recording runs the engine can trust.Chains — how chains are recognized as a methodology.",{"id":213,"title":212,"titles":1573,"content":1574,"level":265},[],"Recording what actually happened — the feedback loop between a run and the engine.",{"id":1576,"title":1577,"titles":1578,"content":1579,"level":271},"\u002Fplaybooks\u002Foutcomes-and-history#three-outcomes","Three outcomes",[212],"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":1581,"title":1582,"titles":1583,"content":1584,"level":271},"\u002Fplaybooks\u002Foutcomes-and-history#what-recording-a-run-does","What recording a run does",[212],"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":1586,"title":1587,"titles":1588,"content":1589,"level":271},"\u002Fplaybooks\u002Foutcomes-and-history#history-per-asset","History per asset",[212],"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":1591,"title":1592,"titles":1593,"content":1594,"level":271},"\u002Fplaybooks\u002Foutcomes-and-history#the-discipline","The discipline",[212],"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":1596,"title":337,"titles":1597,"content":1598,"level":271},"\u002Fplaybooks\u002Foutcomes-and-history#whats-next",[212],"The loop closes here and reopens at the top: map what you learned, and the engine reasons from better data.",{"id":178,"title":10,"titles":1600,"content":1601,"level":265},[],"Requirements in, capabilities out — the recipes of your threat library.",{"id":1603,"title":1604,"titles":1605,"content":1606,"level":271},"\u002Fplaybooks#a-playbook-is-a-recipe","A playbook is a recipe",[10],"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":1608,"title":1233,"titles":1609,"content":1610,"level":271},"\u002Fplaybooks#in-this-section",[10],"Create a Playbook — the Add Playbook drawer, the body, and the notespace.Link Components to a Playbook — build the trigger: modes, required\u002Foptional, scoping, every field.Declare Yields — give the playbook outputs other playbooks can require.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":1612,"title":337,"titles":1613,"content":1614,"level":271},"\u002Fplaybooks#whats-next",[10],"See the machinery that decides which playbook applies: the Nexus Engine.",{"id":224,"title":223,"titles":1616,"content":1617,"level":265},[],"Give an AI agent scoped access to your workspace over MCP.",{"id":1619,"title":1620,"titles":1621,"content":1622,"level":271},"\u002Ftools\u002Fai-agent-connections#what-a-connection-does","What a connection does",[223],"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":1624,"title":1625,"titles":1626,"content":1627,"level":271},"\u002Ftools\u002Fai-agent-connections#creating-a-connection","Creating a connection",[223],"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  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  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:claude mcp add --transport http nimbus https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp \\\n  --header \"Authorization: Bearer nv_live_…\"\nFor JSON-based clients (Claude Desktop, Cursor):{\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  Ask your agent: \"Use Nimbus to show my workspace context.\" The first exchange flips the connection from Never to recently used — proof the loop works.",{"id":1629,"title":1630,"titles":1631,"content":1632,"level":271},"\u002Ftools\u002Fai-agent-connections#what-the-agent-can-do","What the agent can do",[223],"The agent receives a curated tool surface — the read and write operations that map to the vault's workflows: Read — 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.",{"id":1634,"title":1635,"titles":1636,"content":1637,"level":271},"\u002Ftools\u002Fai-agent-connections#managing-connections","Managing connections",[223],"Status 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.",{"id":1639,"title":1640,"titles":1641,"content":1642,"level":271},"\u002Ftools\u002Fai-agent-connections#security-model","Security model",[223],"Workspace-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.",{"id":1644,"title":337,"titles":1645,"content":1646,"level":271},"\u002Ftools\u002Fai-agent-connections#whats-next",[223],"Share and Collaborate — the human side of working together.Search the Workspace — the same surface, driven by you.",{"id":228,"title":227,"titles":1648,"content":1649,"level":265},[],"Work the Nimbus loop from a side panel while you browse your target.",{"id":1651,"title":1652,"titles":1653,"content":1654,"level":271},"\u002Ftools\u002Fbrowser-extension#what-the-extension-is","What the extension is",[227],"The browser extension puts the vault next to the target. Instead of switching between your notes and the application you're testing, a side panel lets you map components, read suggestions, and record outcomes without leaving the page. It is built for Chrome (Manifest V3) and connects to the same workspace as the web app — same account, same permissions. The extension is in a limited rollout: it is not listed publicly yet and is distributed to users directly. If you'd like access, ask in the workspace or reach out to the team.",{"id":1656,"title":1657,"titles":1658,"content":1659,"level":271},"\u002Ftools\u002Fbrowser-extension#what-you-can-do-from-the-panel","What you can do from the panel",[227],"See the proactive checklist for the asset you're working, and resolve prompts in place — ticking a component links it to the asset immediately.Read ranked suggestions for the current target, including chain-tagged playbooks, and open them inline to review requirements and the body.Record outcomes — mark playbooks successful, failed, or not applicable, and grant earned primitives when yields come with a choice.Watch the vault update — a link you add from the panel sharpens suggestions on the web app the moment you switch back.",{"id":1661,"title":1662,"titles":1663,"content":1664,"level":271},"\u002Ftools\u002Fbrowser-extension#how-it-fits-the-loop","How it fits the loop",[227],"The extension does not replace the web app — it removes the context switch from the mapping stage. Longer sessions, authoring, and workspace administration stay in the web app; the panel is for the moment you're staring at the target and want to record what you see.",{"id":1666,"title":337,"titles":1667,"content":1668,"level":271},"\u002Ftools\u002Fbrowser-extension#whats-next",[227],"Map an Asset — the mapping flow the panel accelerates.AI Agent Connections — the other way Nimbus meets you outside the app.",{"id":217,"title":10,"titles":1670,"content":1671,"level":265},[],"Capabilities that extend the workspace beyond the web app.",{"id":1673,"title":1674,"titles":1675,"content":1676,"level":271},"\u002Ftools#beyond-the-app","Beyond the app",[10],"A workspace is more useful when your tools can meet it halfway. These are the complementary features that plug into Nimbus Vault from outside the web app. AI Agent Connections — give an AI agent scoped access to your workspace over MCP, with capability toggles, expiry, and revocation under your control.Browser Extension — work the Nimbus loop from a side panel while you browse your target. The section grows as more complementary features ship.",{"id":239,"title":238,"titles":1678,"content":1679,"level":265},[],"Every Nimbus Vault term in one place.",{"id":1681,"title":1682,"titles":1683,"content":1684,"level":271},"\u002Freference\u002Fglossary#targets","Targets",[238],"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":1686,"title":1687,"titles":1688,"content":1689,"level":271},"\u002Freference\u002Fglossary#library","Library",[238],"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":1691,"title":1692,"titles":1693,"content":1694,"level":271},"\u002Freference\u002Fglossary#engine","Engine",[238],"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":1696,"title":1697,"titles":1698,"content":1699,"level":271},"\u002Freference\u002Fglossary#work","Work",[238],"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":243,"title":242,"titles":1701,"content":1702,"level":265},[],"Use the command center to find anything in the vault — and to hunt horizontally.",{"id":1704,"title":1705,"titles":1706,"content":1707,"level":271},"\u002Freference\u002Fsearch-the-workspace#one-search-across-everything","One search across everything",[242],"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":1709,"title":1710,"titles":1711,"content":1712,"level":271},"\u002Freference\u002Fsearch-the-workspace#finding-the-thing-in-front-of-you","Finding the thing in front of you",[242],"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":1714,"title":1715,"titles":1716,"content":1717,"level":271},"\u002Freference\u002Fsearch-the-workspace#hunting-horizontally","Hunting horizontally",[242],"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":1719,"title":1720,"titles":1721,"content":1722,"level":271},"\u002Freference\u002Fsearch-the-workspace#practical-habits","Practical habits",[242],"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":1724,"title":337,"titles":1725,"content":1726,"level":271},"\u002Freference\u002Fsearch-the-workspace#whats-next",[242],"Search syntax reference — every filter, alias, and operator.Map an asset — keep the vault worth searching.",{"id":247,"title":246,"titles":1728,"content":1729,"level":265},[],"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":1731,"title":1732,"titles":1733,"content":1734,"level":271},"\u002Freference\u002Fsearch-syntax#entity-types","Entity types",[246],"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":1736,"title":1737,"titles":1738,"content":1739,"level":271},"\u002Freference\u002Fsearch-syntax#presence","Presence",[246],"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":1741,"title":1489,"titles":1742,"content":1743,"level":271},"\u002Freference\u002Fsearch-syntax#properties",[246],"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":1745,"title":1746,"titles":1747,"content":1748,"level":271},"\u002Freference\u002Fsearch-syntax#version","Version",[246],"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":1750,"title":1751,"titles":1752,"content":1753,"level":271},"\u002Freference\u002Fsearch-syntax#link-modes","Link modes",[246],"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":1755,"title":1756,"titles":1757,"content":1758,"level":271},"\u002Freference\u002Fsearch-syntax#time","Time",[246],"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":1760,"title":1761,"titles":1762,"content":1763,"level":271},"\u002Freference\u002Fsearch-syntax#interaction","Interaction",[246],"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":1765,"title":1766,"titles":1767,"content":1768,"level":271},"\u002Freference\u002Fsearch-syntax#examples","Examples",[246],"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":251,"title":250,"titles":1770,"content":1771,"level":265},[],"What lives in account settings vs. workspace settings.",{"id":1773,"title":1774,"titles":1775,"content":1776,"level":271},"\u002Freference\u002Fsettings#account-settings","Account settings",[250],"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":1778,"title":1779,"titles":1780,"content":1781,"level":271},"\u002Freference\u002Fsettings#workspace-settings","Workspace settings",[250],"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 or exporting when you only need a fresh start.",{"id":1783,"title":1784,"titles":1785,"content":1786,"level":271},"\u002Freference\u002Fsettings#plan-limits","Plan limits",[250],"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":255,"title":254,"titles":1788,"content":1789,"level":265},[],"What each number on the dashboard means — and what to do about it.",{"id":1791,"title":1792,"titles":1793,"content":1794,"level":271},"\u002Freference\u002Fdashboard-metrics#attack-coverage","Attack Coverage",[254],"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":1796,"title":1797,"titles":1798,"content":1799,"level":271},"\u002Freference\u002Fdashboard-metrics#blind-spots","Blind Spots",[254],"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":1801,"title":1802,"titles":1803,"content":1804,"level":271},"\u002Freference\u002Fdashboard-metrics#playbook-coverage-rate","Playbook Coverage Rate",[254],"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":1806,"title":1807,"titles":1808,"content":1809,"level":271},"\u002Freference\u002Fdashboard-metrics#knowledge-velocity","Knowledge Velocity",[254],"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":1811,"title":1812,"titles":1813,"content":1814,"level":271},"\u002Freference\u002Fdashboard-metrics#popular-components","Popular Components",[254],"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":259,"title":258,"titles":1816,"content":1817,"level":265},[],"Quick answers to the questions that come up most.",{"id":1819,"title":1820,"titles":1821,"content":1822,"level":439},"\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?",[258],"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":1824,"title":1825,"titles":1826,"content":1827,"level":439},"\u002Freference\u002Ffaq#why-did-a-suggestion-disappear","Why did a suggestion disappear?",[258],"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":1829,"title":1830,"titles":1831,"content":1832,"level":439},"\u002Freference\u002Ffaq#why-doesnt-my-scoped-quirk-match-the-playbook","Why doesn't my scoped quirk match the playbook?",[258],"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":1834,"title":1835,"titles":1836,"content":1837,"level":439},"\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?",[258],"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":1839,"title":1840,"titles":1841,"content":1842,"level":439},"\u002Freference\u002Ffaq#failed-or-not-applicable-whats-the-difference","Failed or not applicable — what's the difference?",[258],"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":1844,"title":1845,"titles":1846,"content":1847,"level":439},"\u002Freference\u002Ffaq#how-do-i-undo-a-recorded-outcome","How do I undo a recorded outcome?",[258],"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":1849,"title":1850,"titles":1851,"content":1852,"level":439},"\u002Freference\u002Ffaq#why-cant-i-create-another-workspace","Why can't I create another workspace?",[258],"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":1854,"title":1855,"titles":1856,"content":1857,"level":439},"\u002Freference\u002Ffaq#how-do-ai-agents-access-my-workspace","How do AI agents access my workspace?",[258],"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":232,"title":10,"titles":1859,"content":1860,"level":265},[],"Lookup material — the vocabulary, and the details behind the workflow.",{"id":1862,"title":1863,"titles":1864,"content":1865,"level":271},"\u002Freference#quick-lookups","Quick lookups",[10],"Glossary — every Nimbus Vault term, defined.Search the Workspace — the command center, and how to hunt horizontally.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":1867,"title":1868,"titles":1869,"content":1870,"level":265},"\u002F","Nimbus Vault Docs",[],"Everything you need to run Nimbus Vault — from your first asset to playbook-driven exploitation.",{"id":1872,"title":1873,"titles":1874,"content":1875,"level":271},"\u002F#what-is-nimbus-vault","What is Nimbus Vault?",[1868],"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.",{"id":1877,"title":467,"titles":1878,"content":1879,"level":271},"\u002F#where-to-start",[1868],"Getting started — create a workspace, seed your library, see your first suggestions.Workspace — scope, mapping, and collaboration.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.Tools — AI agent connections and the browser extension.Glossary — every term in one place.",{"id":1881,"title":223,"body":1882,"description":1617,"extension":2293,"meta":2294,"navigation":2295,"path":224,"pro":25,"seo":2296,"stem":225,"type":2297,"updatedAt":2298,"__hash__":2299},"docs\u002F6.tools\u002F1.ai-agent-connections.md",{"type":1883,"value":1884,"toc":2285},"minimark",[1885,1889,1893,1901,1908,1911,2172,2175,2178,2194,2201,2204,2207,2236,2239,2265,2268,2281],[1886,1887,1620],"h2",{"id":1888},"what-a-connection-does",[1890,1891,1892],"p",{},"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.",[1890,1894,1895,1896,1900],{},"Everything below happens in ",[1897,1898,1899],"strong",{},"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.",[1902,1903,1905],"callout",{"type":1904},"pro",[1890,1906,1907],{},"Agent connections are a Pro feature. Each member can hold up to 10 connections per workspace.",[1886,1909,1625],{"id":1910},"creating-a-connection",[1912,1913,1914,1915,1914,1931,1914,1941,1914,2157],"steps",{},"\n  ",[1916,1917,1919],"step",{"title":1918},"New connection",[1890,1920,1921,1922,1926,1927,1930],{},"Open the Integrations tab and create one. Give it a name you will recognize later — ",[1923,1924,1925],"code",{},"Claude Code — laptop"," beats ",[1923,1928,1929],{},"test"," — and choose an expiry: 90 days by default, or 30 \u002F 90 \u002F 365 \u002F never.",[1916,1932,1934],{"title":1933},"Copy the token — once",[1890,1935,1936,1937,1940],{},"The connection token (",[1923,1938,1939],{},"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.",[1916,1942,1944,1958,2012,2015],{"title":1943},"Wire up your client",[1890,1945,1946,1947,1950,1951,1950,1954,1957],{},"Pick your client and paste the pre-filled snippet — the dialog provides one for ",[1897,1948,1949],{},"Claude Code",", ",[1897,1952,1953],{},"Claude Desktop",[1897,1955,1956],{},"Cursor",", and a generic \"Other\" form. For Claude Code:",[1959,1960,1964],"pre",{"className":1961,"code":1962,"language":1963,"meta":1341,"style":1341},"language-bash shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","claude mcp add --transport http nimbus https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp \\\n  --header \"Authorization: Bearer nv_live_…\"\n","bash",[1923,1965,1966,1997],{"__ignoreMap":1341},[1967,1968,1970,1974,1978,1981,1984,1987,1990,1993],"span",{"class":1969,"line":265},"line",[1967,1971,1973],{"class":1972},"sBMFI","claude",[1967,1975,1977],{"class":1976},"sfazB"," mcp",[1967,1979,1980],{"class":1976}," add",[1967,1982,1983],{"class":1976}," --transport",[1967,1985,1986],{"class":1976}," http",[1967,1988,1989],{"class":1976}," nimbus",[1967,1991,1992],{"class":1976}," https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp",[1967,1994,1996],{"class":1995},"sTEyZ"," \\\n",[1967,1998,1999,2002,2006,2009],{"class":1969,"line":271},[1967,2000,2001],{"class":1976},"  --header",[1967,2003,2005],{"class":2004},"sMK4o"," \"",[1967,2007,2008],{"class":1976},"Authorization: Bearer nv_live_…",[1967,2010,2011],{"class":2004},"\"\n",[1890,2013,2014],{},"For JSON-based clients (Claude Desktop, Cursor):",[1959,2016,2020],{"className":2017,"code":2018,"language":2019,"meta":1341,"style":1341},"language-json shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","{\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","json",[1923,2021,2022,2027,2045,2059,2083,2104,2139,2145,2151],{"__ignoreMap":1341},[1967,2023,2024],{"class":1969,"line":265},[1967,2025,2026],{"class":2004},"{\n",[1967,2028,2029,2032,2036,2039,2042],{"class":1969,"line":271},[1967,2030,2031],{"class":2004},"  \"",[1967,2033,2035],{"class":2034},"spNyl","mcpServers",[1967,2037,2038],{"class":2004},"\"",[1967,2040,2041],{"class":2004},":",[1967,2043,2044],{"class":2004}," {\n",[1967,2046,2047,2050,2053,2055,2057],{"class":1969,"line":439},[1967,2048,2049],{"class":2004},"    \"",[1967,2051,2052],{"class":1972},"nimbus",[1967,2054,2038],{"class":2004},[1967,2056,2041],{"class":2004},[1967,2058,2044],{"class":2004},[1967,2060,2062,2065,2069,2071,2073,2075,2078,2080],{"class":1969,"line":2061},4,[1967,2063,2064],{"class":2004},"      \"",[1967,2066,2068],{"class":2067},"sbssI","type",[1967,2070,2038],{"class":2004},[1967,2072,2041],{"class":2004},[1967,2074,2005],{"class":2004},[1967,2076,2077],{"class":1976},"http",[1967,2079,2038],{"class":2004},[1967,2081,2082],{"class":2004},",\n",[1967,2084,2086,2088,2091,2093,2095,2097,2100,2102],{"class":1969,"line":2085},5,[1967,2087,2064],{"class":2004},[1967,2089,2090],{"class":2067},"url",[1967,2092,2038],{"class":2004},[1967,2094,2041],{"class":2004},[1967,2096,2005],{"class":2004},[1967,2098,2099],{"class":1976},"https:\u002F\u002Fworkspace.nimbusvault.app\u002Fmcp",[1967,2101,2038],{"class":2004},[1967,2103,2082],{"class":2004},[1967,2105,2107,2109,2112,2114,2116,2119,2121,2125,2127,2129,2131,2134,2136],{"class":1969,"line":2106},6,[1967,2108,2064],{"class":2004},[1967,2110,2111],{"class":2067},"headers",[1967,2113,2038],{"class":2004},[1967,2115,2041],{"class":2004},[1967,2117,2118],{"class":2004}," {",[1967,2120,2005],{"class":2004},[1967,2122,2124],{"class":2123},"swJcz","Authorization",[1967,2126,2038],{"class":2004},[1967,2128,2041],{"class":2004},[1967,2130,2005],{"class":2004},[1967,2132,2133],{"class":1976},"Bearer nv_live_…",[1967,2135,2038],{"class":2004},[1967,2137,2138],{"class":2004}," }\n",[1967,2140,2142],{"class":1969,"line":2141},7,[1967,2143,2144],{"class":2004},"    }\n",[1967,2146,2148],{"class":1969,"line":2147},8,[1967,2149,2150],{"class":2004},"  }\n",[1967,2152,2154],{"class":1969,"line":2153},9,[1967,2155,2156],{"class":2004},"}\n",[1916,2158,2160],{"title":2159},"First prompt",[1890,2161,2162,2163,2167,2168,2171],{},"Ask your agent: ",[2164,2165,2166],"em",{},"\"Use Nimbus to show my workspace context.\""," The first exchange flips the connection from ",[1897,2169,2170],{},"Never"," to recently used — proof the loop works.",[1886,2173,1630],{"id":2174},"what-the-agent-can-do",[1890,2176,2177],{},"The agent receives a curated tool surface — the read and write operations that map to the vault's workflows:",[2179,2180,2181,2188],"ul",{},[2182,2183,2184,2187],"li",{},[1897,2185,2186],{},"Read"," — workspace context, search across the vault, programs and assets, an asset's component digest, ranked suggestions, the checklist, history, and change feeds.",[2182,2189,2190,2193],{},[1897,2191,2192],{},"Act"," — link observed components, resolve prompts, record outcomes, and create library entries, following the same methodology the docs describe.",[1890,2195,2196,2197,2200],{},"Each connection has ",[1897,2198,2199],{},"capability toggles"," — open a connection's row to tune exactly which of those the agent may use. Start narrow; widen deliberately.",[1890,2202,2203],{},"Agents also receive Nimbus's working guide as part of the connection, so they follow the same map → suggest → confirm → record loop you do.",[1886,2205,1635],{"id":2206},"managing-connections",[2179,2208,2209,2215,2221,2227,2233],{},[2182,2210,2211,2214],{},[1897,2212,2213],{},"Status chips"," — Active, Expired, or Revoked, at a glance.",[2182,2216,2217,2220],{},[1897,2218,2219],{},"Rename \u002F renew \u002F rotate"," — lifecycle actions for the owner. Rotate immediately if a token leaks.",[2182,2222,2223,2226],{},[1897,2224,2225],{},"Revoke"," — owners revoke their own; admins can revoke any. Revocation takes effect at the next exchange, and live sessions end shortly after.",[2182,2228,2229,2232],{},[1897,2230,2231],{},"Delete"," — removes revoked or expired rows permanently.",[2182,2234,2235],{},"Leaving or being removed from a workspace deletes your connections for it.",[1886,2237,1640],{"id":2238},"security-model",[2179,2240,2241,2247,2253,2259],{},[2182,2242,2243,2246],{},[1897,2244,2245],{},"Workspace-scoped."," A token reaches one workspace and nothing else.",[2182,2248,2249,2252],{},[1897,2250,2251],{},"No secret at rest."," The raw token is never stored or logged — only a hash, used to mint short-lived sessions.",[2182,2254,2255,2258],{},[1897,2256,2257],{},"Expiry by default."," Connections come with an end date unless you deliberately choose otherwise.",[2182,2260,2261,2264],{},[1897,2262,2263],{},"Audited."," Connecting, revoking, and every write the agent makes are recorded in the workspace's audit log.",[1886,2266,337],{"id":2267},"whats-next",[2179,2269,2270,2276],{},[2182,2271,2272,2275],{},[2273,2274,137],"a",{"href":138}," — the human side of working together.",[2182,2277,2278,2280],{},[2273,2279,242],{"href":243}," — the same surface, driven by you.",[2282,2283,2284],"style",{},"html pre.shiki code .sBMFI, html code.shiki .sBMFI{--shiki-light:#E2931D;--shiki-default:#FFCB6B;--shiki-dark:#FFCB6B}html pre.shiki code .sfazB, html code.shiki .sfazB{--shiki-light:#91B859;--shiki-default:#C3E88D;--shiki-dark:#C3E88D}html pre.shiki code .sTEyZ, html code.shiki .sTEyZ{--shiki-light:#90A4AE;--shiki-default:#EEFFFF;--shiki-dark:#BABED8}html pre.shiki code .sMK4o, html code.shiki .sMK4o{--shiki-light:#39ADB5;--shiki-default:#89DDFF;--shiki-dark:#89DDFF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .spNyl, html code.shiki .spNyl{--shiki-light:#9C3EDA;--shiki-default:#C792EA;--shiki-dark:#C792EA}html pre.shiki code .sbssI, html code.shiki .sbssI{--shiki-light:#F76D47;--shiki-default:#F78C6C;--shiki-dark:#F78C6C}html pre.shiki code .swJcz, html code.shiki .swJcz{--shiki-light:#E53935;--shiki-default:#F07178;--shiki-dark:#F07178}",{"title":1341,"searchDepth":439,"depth":439,"links":2286},[2287,2288,2289,2290,2291,2292],{"id":1888,"depth":271,"text":1620},{"id":1910,"depth":271,"text":1625},{"id":2174,"depth":271,"text":1630},{"id":2206,"depth":271,"text":1635},{"id":2238,"depth":271,"text":1640},{"id":2267,"depth":271,"text":337},"md",{},true,{"title":223,"description":1617},"guide","2026-10-06","1dB71lbS9WXrvRwSjVfCnhnJu5rYZqPDCTnTghy6FsM",[2301,2302],{"title":10,"path":217,"stem":221,"description":1671,"children":-1},{"title":227,"path":228,"stem":229,"description":1649,"children":-1},1791412539494]