Skip to main content
Use /v2/prioritize when the caller provides environment context and asks what matters now.

Environment Profile

Include the context that changes priority:

Workflow

  1. Call /v2/prioritize with environment, time_window_days, and max_items.
  2. Review top signals by priority_score, confidence_score, and environment_match_reasons.
  3. Validate the top 1-3 signals with evidence and relationships.
  4. Run the relevant assessment for each material item.
  5. Return an action plan ordered by priority.

Interpret Ranking Fields

  • priority: human-friendly urgency label
  • priority_score: deterministic rank score
  • confidence_score: confidence in the signal and supporting data
  • activity_level: current activity signal
  • novelty_score: how new the signal is to the request context
  • freshness_score: recency of supporting data
  • environment_match_reasons: why this matters to the provided environment
  • suppression_reasons: why a signal was lowered or deprioritized
  • what_changed: changes since the requester’s last view
  • recommended_action_type: action category for follow-up

Assess one CVE against structured inventory

Pass the same product names to environment_context.products when you investigate one CVE. The request below uses a synthetic CVE identifier; substitute a resolved CVE from your investigation.
Send it to POST /v2/environment-assessments. Use names from your inventory; prose such as “Linux-only fleet” is not parsed into inventory. Assessment inventory accepts up to 100 product names, each at most 200 characters. For a controlled example whose known source products contain only Windows: Windows and Microsoft Windows are recognized aliases. Arbitrary abbreviations, ambiguous unqualified names, and incomplete version/edition labels stay unknown. The API does not accept CVE scan findings as an applicability input. A product name alone cannot establish vulnerable-version applicability; preserve the full response qualifications.