A local command-line tool that reads a Salesforce SFDX repository and writes back a verified knowledge base: one page per component, a complete dependency graph, and an output shaped so that a language model or an MCP client can query it directly. Deterministic, incremental, and offline by construction: no cloud, no network call, nothing leaves the machine.
PS C:\work> uv run orgintel run --customer customer.yaml scan every metadata file parse one fact sheet per component graph typed edges, hardcoded too generate a Markdown page per component check 0 errors · 0 warnings · 0 stale stats coverage 100.0 % · debt by domain html browsable mirror + dependency viewer docs-rag/ ready — 0 network calls, 0 bytes sent, 0 tokens spent
Coverage, network calls and tokens do not depend on the size of the org: the pipeline checks all three itself on every run, and a run that misses one fails.
After ten years of delivery, a mature Salesforce estate is a system whose behaviour lives in tens of thousands of metadata files, and whose written description, if any, was accurate the week it was written.
A wiki page states what someone intended. The repository states what the org does. The two diverge from the first hotfix onward, and no one can tell which pages are still true.
Git is the only truth, so every sentence OrgIntel writes is derived from parsed metadata, never inferred from a naming convention that looks about right.
“Where is this used” finds only what the platform registered. The ones that break a release are hardcoded: an API name in a formula, a queue concatenated into a SOQL string, a record type in a custom setting.
OrgIntel reads the text as well as the structure, says unresolved rather than guessing, and draws parents and children at once.
Point an assistant at tens of thousands of raw metadata files and it either exhausts its context window or invents an API name that sounds plausible. Retrieval needs a curated corpus, not a directory.
OrgIntel produces that corpus: progressive disclosure, stable field names, every claim traceable back to a real source path, so an answer can be checked rather than believed.
Point it at an SFDX repository already retrieved from the org. It reads; it never writes to Salesforce, and it never calls it.
Objects, fields, Apex classes and triggers, Flows, Lightning Web Components, Aura bundles, Visualforce, FlexiPages, permission sets and profiles, queues, roles, Einstein Bots, Agentforce agents, prompts, named credentials: each becomes one Markdown page with its facts, its security, its relations and a link back to the exact source file.
Output is French by default, English on request, with human-written blocks that survive every regeneration byte for byte.
Typed edges (SOQL reads, DML writes, trigger targets, callouts, permission grants, configuration references, plain identifier references), resolved against every known component and stored in SQLite.
An interactive viewer ships with the output: one self-contained HTML file, depth-N cascade, filters on confidence and origin, no server and no external script.
The tree follows a file-based retrieval norm: YAML front matter, sharded indexes, a relations file, an overview, and implementation references pointing at real SFDX paths, so retrieval is navigation, not similarity search.
An optional read-only MCP server exposes the same catalogue to Claude Code, GitHub Copilot, Agentforce Vibes or any client, over standard input and output. No port, no daemon, no writer.
Each stage is a command you can run on its own, each records what it did, each supports --dry-run, and each one re-run on unchanged inputs produces zero diff. That property is enforced by a blocking test.
The seven stages are one command or seven; the catalogue is the only thing between them. Nothing in this figure crosses a network boundary and nothing in it calls a model: the whole diagram is deterministic code, which is why re-running it costs a few minutes of CPU and nothing else.
orgintel scanWalks the package directories and registers every metadata file: path, Metadata API type, API name, SHA-256. A file matching no known convention falls to a generic classifier that derives its type from the file suffix, and anything it still cannot name stays unknown rather than being guessed.
orgintel parseTurns each group of files into one fact sheet, by pure deterministic extraction. XML through lxml; Apex through a documented regular-expression ruleset that strips strings and comments first, then reads class headers, method signatures, SOQL, DML, callouts and referenced identifiers. No model is involved at this layer, ever.
orgintel graphCross-references identifiers across every fact sheet into a typed edge table. A name matching two components is not silently assigned: the edge is marked ambiguous and queued for a human, carrying the file it was cited in so the reviewer can verify rather than trust.
orgintel generateRenders the pages and the derived indexes through Jinja2, one directory per Metadata API type, mirroring the SFDX source format. Manual blocks in an existing page are extracted and re-injected byte for byte; a page whose inputs did not change is not rewritten at all.
orgintel checkValidates the output against the rules that make it trustworthy: front matter present and valid, links resolving, implementation references still on disk, no manual block lost, and a second run producing an identical tree. Errors set a non-zero exit code, so the whole thing works as a continuous-integration gate.
orgintel stats · qualityTwo reports, human and machine. Stats counts components by type, coverage, the most connected hubs, orphans, and the breakdown by business domain. Quality audits the org's own documentation debt (missing descriptions, missing help text, missing security classification), ranked worst-documented domain first, and by graph degree so the debt that hurts most comes up first.
orgintel htmlMirrors the Markdown tree into a browsable site with a landing dashboard, global client-side search, faceted filtering, hover preview cards, an entity-relationship diagram, rendered Flow diagrams, a guided first-visit tour, and a print stylesheet. One folder, no server, no content delivery network: it opens off a shared drive.
Five tables, no server, no vector store. Decision is the only table a human writes, and it lives in the client's own repository as YAML so a judgement made once is never asked again. Edge is where the honesty is: a reference that resolves to two candidates keeps both, with the rule that proposed them, the file it was cited in and the line inside that file.
Every artefact carries a content hash and a lineage pointer. Change one Apex class and the next run recomputes that fact sheet, the edges it touches and the handful of pages that cite it, not the org. A cold run and an incremental run are the same code path with a different work list.
Reverse-documentation is parsing. Every page, every edge, every report on this site comes out of deterministic Python: no prompt, no completion, no context window, nothing metered. The one job that genuinely needs a model is the one no parser can do: reading prose a human wrote and deciding whether it still matches the facts.
The boundary is architectural, not a setting. The offline chain has no code path that can reach a model, which is what makes it safe to point at a regulated estate on a locked-down laptop. The comparison layer is a separate command, off by default, and it can run entirely on-premises.
Reading every metadata file and writing a page per component is string handling. XML through a parser, Apex through a documented regular-expression ruleset, identifiers cross-referenced against a name registry, pages rendered from templates.
Deciding whether a wiki page still describes the org is a judgement about natural language, and no parser makes it. That step and the optional business narrative are the only places a model is invited in.
A working miniature of the generated front end: twenty-two fixtures instead of a whole org, but the same shapes: the tree, search over the corpus, a generated page, the dependency viewer and the documentation-debt report. Click anything. Push the depth past 2 and watch the cascade open in both directions at once. It also demonstrates itself while you read.
Objet personnalisé « Sinistre » (Claim__c), modèle de partage Private. 4 champs, 1 type d'enregistrement, 2 règles de validation.
Porte les sinistres auto déclarés par le réseau d'agences. Le flux d'affectation s'appuie sur Is_Large__c pour router vers l'équipe grands comptes.
| champ | type | requis | détails |
|---|---|---|---|
| Amount__c | Currency | oui | précision 18, échelle 2 |
| Is_Large__c | Formula | non | Amount__c > 10000 |
| Policy__c | Lookup | non | → Policy__c |
| Status__c | Picklist | non | ensemble global, restreint |
ClaimService — lit l'objet (SOQL) et écrit 2 champs (DML)Claim_Assignment — flux déclenché après créationclaimList, claimSummary — composants LightningClaims_Agent — accorde lecture / création / modification← ce qui en dépend · la sélection · ce dont il dépend →
Claim__c — utilisé par ClaimRepository (SOQL, DML), ClaimTriggerHandler (DML), Claim_Assignment (flux), ClaimNotifier (SOQL), Claims_Agent et Claims_Manager (accordent) ; et plus haut par ClaimService, ClaimTrigger, Claim_Escalation, Claims_Ops, ClaimController, claimList, claimSummary, ClaimRecordPage. Dépend de Policy__c, lui-même de Account.
Cliquez un nœud pour recentrer la cascade : parents et enfants sont tracés en même temps, aussi loin que vous le demandez. En tirets ambre, une référence non résolue. ACME_Legacy_API est une chaîne codée en dur dans une classe Apex ; ClaimHelper existe à la fois en classe et en LWC. Aucune ne reçoit de vainqueur silencieux : les deux partent en file de revue avec le fichier où elles sont citées.
Part des composants portant une description, un texte d'aide et une classification de sécurité. Classé du pire au meilleur, puis par degré dans le graphe : la dette dont le plus de choses dépendent passe avant celle que personne ne touche.
Progressive disclosure is the whole design. An overview names the domains, a sharded index names the components of one domain, and a component page names its neighbours, so each hop narrows the corpus instead of widening it. An agent walks that structure the way a developer walks a repository, which is why the same corpus serves orgintel query on a terminal and an MCP client in an IDE without a second pipeline.
Generating the corpus costs nothing: that is the point of the previous section. But reading it costs whatever an agent has to load, and that is where most retrieval designs quietly become expensive: a flat corpus forces the model to pull dozens of chunks and hope the right one is among them.
Here the structure does the narrowing. Three small files answer a question that would otherwise mean holding every metadata file of the org (or a few hundred similarity-matched fragments) in a context window. Fewer, better-chosen tokens on the way in is also a shorter, more accurate answer on the way out, and every claim in it still points at a file on disk.
They are what makes the output usable in a regulated estate, and each one is enforced by a test rather than by discipline.
Everything generated is derived from parsed metadata. Nothing is inferred from a naming convention or a plausible pattern.
A fact that cannot be parsed is emitted as unknown. An ambiguous reference is marked ambiguous. A missing planner directory is reported as missing, not silently resolved.
Fact extraction is pure code. The one command allowed to call a language model is deliberately outside the pipeline, and off by default.
Stable sort order everywhere. Re-running any command on unchanged inputs must produce no diff at all, and a failing idempotence check is a blocking error.
No network call anywhere in the offline chain. No service, no container, no vector database. The reference platform is a locked-down corporate Windows 11 laptop.
The engine is generic and driven by one configuration file per client. Its own test suite runs on synthetic fixtures: no client metadata ever enters the tool's repository.
The same generated tree answers a developer's question and a business analyst's, because the technical facts and the business grouping are two views of one catalogue, not two documents to keep in sync.
Hubs, orphans, cycles, the real integration surface, and an audit of an estate you did not build, before you commit to a remediation plan.
Who uses this field, what this class depends on, and which permission set grants it, answered before the change rather than discovered in production.
Components grouped into business domains, a glossary for every badge and term, a user guide, and a documentation-debt report naming the worst-covered domain first.
Four read-only tools over the catalogue (search, who-uses, dependencies, page), reachable over MCP, plus the same answers on a terminal for a human checking the agent's work.
The offline chain is complete and validated on a full reference estate at every data-truth milestone. What follows is the state of the tool as it stands, not a roadmap.
One output directory per client: the catalogue, the fact sheets, the Markdown tree, its browsable mirror, and the reports.
One command for the whole chain, or any stage on its own. Every command takes --dry-run, every command logs a run record.
The tool audits itself on every commit: secret scanning, static analysis, dependency and supply-chain checks, with every suppression required to carry a written reason.
And it audits the client's org: orgintel sf-audit wraps Salesforce Code Analyzer, adds the checks it misses (sharing bypasses, dynamic SOQL, callouts around Named Credentials, over-broad grants) and ranks findings by severity × reachability in the graph. Advisory by design: it never blocks a build.
Every reference the tool could not resolve with certainty becomes a decision a human can make: the candidates, the rule that proposed them, the confidence, and the exact metadata file the name was cited in.
Decisions are committed as a small YAML file in the client's own repository, so a judgement made once survives every future run.
A separate mode writes the functional layer a fact sheet cannot: what a component is for, one chapter per business domain. The facts are injected by code; the model only writes the connective prose, and is forbidden from inventing a name, a figure or a behaviour.
It is off by default and never part of the offline chain, runs against a local model or an API key you supply, and caches by content so a second run costs nothing.
The offline chain answers what the org contains. The next milestone answers something harder: whether the documentation your teams rely on is still true.
End-to-end chain with incrementality and security gates; correct edges through reference packs, org snapshots, universal reference mining and a name registry; exhaustive metadata coverage down to Einstein Bots, Omni-Channel and Agentforce; the quality audit; and the whole browsable front end: dashboard, search, facets, graph viewer, entity-relationship diagram, mobile and print.
Including provenance on every ambiguous reference: 100 % of the decisions in the review queue now name the metadata file the name was cited in, structural and mined references alike.
The file is shipped; the line number is not, yet. A reviewer already opens the exact metadata file a disputed name came from; what is on the bench now is landing the offset inside that file, so the reviewer arrives on the statement rather than on the document.
Alongside it, extending the standard-component reference pack: 60 % of the remaining unresolved edges point at names Salesforce ships, and resolving those takes no action from the client at all.
Ingest the client's own documentation, align each claim to a real component, and produce the gap report that matters: documented but absent, present but undocumented, contradicted by the facts, each with the evidence attached. This is where the tool stops describing an org and starts arguing with its wiki.
The Lite contracts were designed so the larger architecture plugs in without rework: hybrid lexical and vector retrieval for fuzzy business questions, an entity-linked graph over documentation and tickets, release-note impact reports crossed against your own components, generated documentation published through pull requests, and telemetry that turns unanswered queries into a documentation backlog.
OrgIntel is production-ready and in use. It started as my own initiative and Capgemini now offers it to its clients as a Capgemini asset. It is not a product you can download, and it is not sold as one. If it is relevant to an estate you are responsible for, the conversation starts on LinkedIn.