Reasoning about your org, not just retrieving it

From retrieval to reasoning

The first job of sf-intelligence is retrieval: pull one read-only metadata snapshot of a Salesforce org, build a local graph, and answer "what is this field / who references it / where is this used" - grounded in real metadata and cited to canonical IDs, never a training-data guess.

But the questions that actually block a change are implication questions. Does deleting this master-detail parent cascade-delete its children? Do these three record-triggered flows run in a defined order? Is this Apex class an unenforced entry point? Answering those means going one step past retrieval - from facts to consequences. That step is resolve → interpret → synthesize: resolve the component, interpret its structure, fold the result into the answer.

Two graphs, one deterministic join

The reasoning model is built on two separate graphs that never mix:

• Graph A - your org's grounded vault slice. A minimal slice of your real metadata graph assembled around the component in question. It carries the org specificity, and everything it contributes is citable by canonical ID.
• Graph B - the Concept Model. A curated, org-independent library of general Salesforce truth: 94 concepts / 143 rules about how the platform behaves - save order, sharing posture, cascade semantics, async boundaries, and more. No org data ever lives in it.

sfi.interpret is the deterministic join of the two: it fires the Concept Model's rules against your grounded slice and returns the structural implications that hold. No inference engine, no language model, no live org call - the same inputs always produce the same claims.

     Graph A (your org)                 Graph B (ships with the package)
  ┌────────────────────┐          ┌──────────────────────────┐
  │ grounded vault     │          │ Concept Model            │
  │ slice — real IDs   │          │ 94 concepts / 143 rules  │
  │ CustomField:...    │          │ org-independent, no      │
  │ Flow:...  Apex:... │          │ org data — ever          │
  └─────────┬──────────┘          └────────────┬─────────────┘
            └──────────────┬───────────────┘
                     ▼  sfi.interpret  (deterministic · offline)
            ┌───────────────────────────────────┐
            │ cited, confidence-tiered claims   │
            │ groundedIn: [CustomField:...]     │
            └───────────────────────────────────┘

Every claim is cited and confidence-tiered

Two honesty properties are baked into the output:

• No citation, no claim. Every interpretation carries a groundedIn list - the exact component IDs it matched. A claim the engine cannot ground is never emitted.
• Claim confidence is a second axis. It reuses the declared | parsed | heuristic words but is computed, not read off one edge: the weakest of the concept rule's ceiling and the grounding edges the claim matched. It is deliberately distinct from the per-edge confidence of a single relationship.

Honesty is load-bearing

What 0.2.0 shipped

0.2.0 was a capability-and-correctness release. It expanded the advertised tool roster to 196, broadened metadata coverage across schema, automation, sharing, frontend, integration, and OmniStudio, added what-if / impact analysis and coverage-aware destructive verdicts, and introduced the opt-in, read-only live plane (sfi.live_*) for the assignment questions an offline vault cannot answer - all consent- and budget-gated.

What 0.2.1 added

• Concept Model grew to 94 concepts / 143 rules (from 48 / 84) - all org-independent, curated general-Salesforce truth. The shape of sfi.interpret output is unchanged; there is simply more it can reason about.
• 18 adversarially-verified correctness fixes. Every already-correct rule is byte-identical; only the over-claiming cases were fixed - e.g. a without sharing class no longer implies it enforces CRUD/FLS, and a unique-field violation reports the right status code.
• New endpoint-type predicate. Edge rules now fire only when the endpoint node is of the intended type (fail-closed), so a permission-set grant is never mislabelled a Profile grant, nor an Apex callout a named-credential binding.
• Two lossless Flow tools - sfi.flow_graph (a lossless structural projection of a Flow) and sfi.flow_trace (declared-logic tracing over a caller-supplied record map). Advertised roster 196 → 198.
• Truthful concept disambiguation. disambiguate_concepts now computes counts and recommendations over the full match set with an explicit boundary disclosure, instead of an alphabetically-biased slice.

A worked example

Ask about a master-detail field and interpret returns the cascade implication, grounded in the field's own ID:

# resolve → interpret → synthesize (deterministic, offline)
interpret(componentId: "CustomField:Invoice_Line__c.Invoice__c")

→ claim: deleting the master (Invoice__c) cascade-deletes its
        detail records; the child cannot exist without a parent.
→ groundedIn: [CustomField:Invoice_Line__c.Invoice__c]
→ confidence: declared   # from the field's declared master-detail relationship

Placeholder component IDs - the model carries no org data; your real IDs come only from your own grounded slice.

Learn more

• The full capability map - the eight areas you can ask about, plus the live plane.
• Glossary: the reasoning / concept model and claim confidence.
• Quality & trust - how it is tested and the explicit boundaries of static analysis.