What breaks if I delete this?

Last updated 2026-07-29

claude mcp add --transport stdio --scope user sf-intelligence-demo -- npx -y sf-intelligence demo

The verdict shape

A delete simulation returns three things, in this order: the coverage caveat, the dependent list, and the verdict. The caveat comes first on purpose - a verdict is only as strong as the metadata families behind it, so you read the limits before you read the conclusion.

› is it safe to delete Contact.Legacy_Status__c?
▸ verdict: review-first — 4 dependents found
  ValidationRule "Status_Required" · Flow "Contact_Router" · ApexClass "ContactSvc" · Report
  coverageCaveat: reports & dashboards fully modeled; dynamic Apex not checked

The verdict is a label, not a permission slip. review-first means dependents exist and a human has to decide what to do about each one. A clean verdict means no static evidence of a dependent was found in the families that were checked - which is a narrower claim than "unused," and the tool words it that way rather than rounding up to reassurance.

What counts as a dependent, and how it was found

Every dependent in the list carries the edge confidence that produced it, so you can tell a fact stated in the XML from a regex match that needs a second look before you act on it.

Structural consequence, not just a dependent count

Dependents are one half of the answer; the other is the structural consequence of the field's own shape. interpret reads that from the graph deterministically: a master-detail field is what makes its child records cascade-delete with the parent, and an object whose two master-detail fields make it a junction (many-to-many) behaves differently again. Those are cited, confidence-tiered claims - joined from an org-independent concept model, not an LLM guess - folded in alongside the dependent list.

The claim confidence on an interpretation is a separate axis from the edge confidence on a dependency. An interpretation reports the weakest of its concept rule's ceiling and the grounding edges it matched, and it names the exact component ids it matched under groundedIn. A claim the engine cannot ground is never emitted at all.

The exact tool calls

You type the question; the router picks the tool. These are the ones it reaches for on a delete question, in case you want to call them directly:

• safe_to_delete_field - the delete simulation itself: verdict, dependent list, coverage caveat.
• get_impact - the raw dependency subgraph (what references this, N hops out), with no verdict layered on top.
• interpret - the structural consequence of the field's shape (master-detail cascade, junction object) as a cited claim.
• what_if_change_field_type - the sibling simulation for a type change rather than a delete.
• what_if_make_field_required - the sibling simulation for tightening a field instead of removing it.
• coverage_report - which metadata families your last refresh actually retrieved, which is what the coverage caveat is computed from.

Every one of them is read-only. There is no write path to the org anywhere in this product - the simulation is the whole point, and executing the delete stays your job in Setup or a deploy.

Honest limits

A destructive verdict is only as strong as the coverage behind it. sf-intelligence renders the coverage caveat before the verdict, distinguishes "not in the vault" from "not in the org", and marks dynamic references heuristic. Static analysis cannot see dynamic SOQL, reflective Apex, or a reference added since your last refresh, so treat a clean verdict as "no static evidence of a dependent", then spot-check. See how it's tested.

The method behind the verdict

This page is the product surface: the tool calls, the verdict shape, the caveats. It deliberately does not re-teach the decision method, because that has its own home. If you want the reasoning - why field population is the wrong evidence, which references block a delete outright versus break something quietly afterwards, the four-verdict taxonomy that makes a cleanup backlog actionable, and what to do with a tool's zero - read the dependency-first field cleanup method. Run the simulation here; decide with the method there.

For the reverse direction - listing every place a field is referenced without asking for a verdict - see where is a Salesforce field used. For the same question on an object, Flow, or Apex class rather than a field, see Salesforce impact analysis.