guide Updated 2026-10-06
Map an Asset
Turn a target you have observed into a structured component inventory.
Mapping is the highest-leverage habit in Nimbus Vault. Everything the engine can ever tell you is bounded by what you record here.
Create the asset
Under the program it belongs to, create an asset for one concrete thing you are testing — a host, an API, an app. Name it exactly as you think about it, then start exploring.
Link what you observe
Every time you notice something real — a technology in the stack, a feature in the UI, a framework behavior — link it to the asset. Search the library first: most things already exist, and linking beats recreating. Only add a new component when it passes the [library test](/components#what-earns-a-place-in-the-library).
Scope what belongs to what
A quirk inside a specific technology, a vector inside a specific functionality — link it as a scoped child of that parent, not as a flat sibling. Scoped matches rank higher because they are more specific.
Record endpoints
When you know where a capability was observed — the specific URL or path — record it on the link. Endpoints are what let the engine decide whether two capabilities actually meet.
Watch suggestions arrive
Open the asset's suggestions panel. Playbooks whose requirements you have satisfied appear immediately, ranked. If nothing appears yet, that is information too — check the checklist for what the engine is asking for.
Map in one sitting when you can. The value of the inventory comes from completeness — a half-mapped asset produces half-trustworthy suggestions.
Variations
- Existing target list? Import assets via CSV, then map the ones worth pursuing.
- Children — model sub-parts (an API under an app, a service under a host) as child assets when they have their own components and endpoints.
- Not sure of the exact value? Use a wildcard link so matching still works until you confirm the concrete one.
What's next
The engine now has something to think about: work the prompts it generates.