Code mapping
Use code mapping to compare report evidence, evidence_fingerprint, candidate_paths and confidence before drafting review-only patches or ticket fallback.
Developers and agencies
Feature availability
Product, package, provider and deployment boundaries for this page.
- Available from
- Current documentation
- Providers
- githubgithub-enterprise
- Deployment modes
- cloudself-hosted
Before mapping code
Use this page after read-only indexing completes and before any patch is drafted. Code mapping connects report evidence to candidate source files, components or configuration locations without modifying the repository. Do not map from a finding title alone. The affected URL, issue evidence, evidence_fingerprint, issue_fingerprint and indexed repository context should explain why a candidate path is plausible.
Map evidence to candidate files
Follow the path `Report finding → Evidence fingerprint → Indexed paths → Candidate file confidence → Review-only patch or ticket fallback`.
- Open /reports/{report} and choose the finding that needs repository context. Result: issue evidence, affected URL, evidence_fingerprint and remediation context are visible before file mapping.
- Confirm read-only indexing is complete for the connected repository. Result: candidate_paths can come from indexed metadata instead of guessed or pasted source.
- Compare the finding evidence, URL, selector, component hints and issue fingerprint with indexed paths. Result: code mapping uses observed evidence rather than title wording alone.
- Review code_mapping_status, confidence and mapped-file reason. Result: high-confidence mappings can continue while low-confidence mappings stay review-only or ticket-only.
- Keep unmapped or unsupported findings out of patch generation. Result: WebRiskOps does not invent file paths, components or source changes.
- Continue to Review-only patches only after mapping is explainable. Result: patch drafts have customer-reviewable file context and no write action has happened yet.
Ready mapping states
Continue only when the product shows a ready or reviewable state.
- Mapped means code_mapping_status is ready and candidate_paths explain likely file or component ownership.
- High confidence means evidence, URL or component hints strongly match the indexed path.
- Review-only candidate means a patch draft may be prepared for customer review without changing repository state.
- Unmapped means the product explains why a patch is unavailable and should route to ticket-only fallback.
- Evidence mismatch means report evidence and repository context do not support the same code location.
Blocked or unsafe states
Do not work around an unsafe access state. Use the product fallback or revoke path.
- Low confidence means do not generate a patch automatically; keep the finding in review-only or ticket-only flow.
- Missing index means return to Read-only indexing before mapping files.
- Unsupported finding means use Ticket-only fallback instead of inventing a repository change.
- Secret boundary risk means stop before source context enters prompts, tickets or reports.
- Wrong repository means return to repository connection and correct repository_full_name.
- Ambiguous component means ask for customer review through the product workflow before drafting a patch.
Continue to review-only patches
Continue to Review-only patches only when mapping is explainable and scoped. Use Ticket-only fallback when mapping is inconclusive, low-confidence, unsupported or blocked by no-secret boundaries. Use Report evidence or Issue fingerprints when the mapping needs more observed context before a repository action is safe.
Related documentation
Was this page helpful?
Feedback goes into the product documentation review queue.

