What does this plugin actually do?
Dynamics tells you a plugin is registered. It does not tell you what the plugin does, and the person who wrote it may be three employers away. Pathix reads the compiled assembly and writes back what it does in plain English: the trigger, the branch logic, and the exact columns it writes and reads. Same for classic workflows, cloud flows, and custom APIs.
Trigger, logic, and every column it touches.
This is a real narration of a plugin, not a summary of one. It names the format string it builds, the thresholds it compares against, and the fallbacks it uses when a value is missing. Underneath, the assembly notes say what the six plugins on that table do to each other, which is the part no single component page can tell you.
The message, table, and stage it registers on.
What it does, in prose, including the branches and the fallbacks.
Every column, listed and counted, not summarised.
What the whole assembly does together: which plugins fire on the same event, where ordering is not enforced, which ones swallow their exceptions.
The model that wrote it, the confidence it carried, and the assembly version it read next to the version currently scanned.
Those last two lines matter more than they look. A narration is written once per version of the source and served from cache after that, so the version it read sits next to the version currently scanned. When they diverge, the narration is stale and says so, instead of confidently describing code that has since been replaced.
four component types, and a reason the list stops there.
These are the surfaces where the source is large, thrown away after parsing, and hard for a structural parser to read completely. That combination is the whole test. A surface earns narration only when it passes all three, which is why the list is short and stays short.
The trigger it registers on, the branch logic in plain English, the exact columns it writes and reads, and how it handles its own exceptions.
What starts it, the conditions that gate each step, and which columns each step sets, including the steps that never fire because an earlier condition rules them out.
The trigger and its column filters, every Dataverse action in the run, the expressions that read columns without naming them in a field list, and the child flows it calls.
What the operation actually does behind its contract, its request and response parameters, and the columns the implementation touches on the way through.
An inventory that skips your plugins covers the easy half.
Most of the logic worth documenting in a mature environment was compiled years ago. The registration metadata tells you a plugin fires on Update of account; it cannot tell you that it writes three other columns on a related record first. So Pathix decompiles the assembly, walks the IL, and narrates what it finds there.
This is opt-in and off by default. You confirm decompilation is permitted for your environment, you exclude any publisher you do not want read, and the raw bytes are discarded once the parse is done. Only the structural rows and the narration are kept. Set it up so it covers the code your organisation owns and the vendor code your agreements let you inspect, and leave the rest excluded.
The full read and retention picture, including what never leaves the wrapper boundary, is on Your data and Privacy.
Form scripts get edges, not narration.
Script is the one place where the deterministic parser already gives the better answer, so narrating it would spend tokens to say something less precise. Pathix parses it properly instead, and those edges come out as Parsed, on the same footing as anything read from XAML or flow JSON.
An Esprima AST walk with a dataflow tier: setValue and getValue calls, Xrm.WebApi calls, FetchXML string literals, four handle-shape variants, and conditional detection by brace depth.
Embedded JavaScript is extracted and put through the same walk, plus a recognizer for jQuery AJAX calls against the Dataverse endpoints.
What AI does contribute on these surfaces is the second half of its job: candidate edges. Where the deterministic walk cannot prove a write, an optional sweep can propose one as AI-derived, attached to the evidence it read. Those edges are net-new and additive only. AI never produces a Declared or Parsed edge, never overrides or alters a deterministic one, and never emits an edge without evidence behind it. In the list below, the form script resolved deterministically; the AI-derived row is a plugin the walker could not prove alone.
How the tiers work, and what an unresolved edge means, is on dependency analysis.
Optional, on your key, never the source of truth.
Anthropic, OpenAI, or Azure OpenAI, including Azure Government. You bring the key and the calls go out from your own tenant. Pathix does not resell tokens.
With no AI configured at all, the deterministic side is untouched: parsing, the graph, findings, cascade, reports, export, and the MCP all work exactly the same.
A person can validate or dismiss an AI-derived edge. That decision is recorded as an overlay and never rewrites where the edge came from, and it never deletes it.
A narration is written to be checked, which is why the model and its confidence sit at the bottom of every one. Treat it as a strong, sourced first draft of the documentation nobody wrote at the time, and confirm it before you act on it. The whole AI posture →
Narration is an input, not a deliverable.
On its own it documents a component. Where it earns its keep is everything downstream that reads it.
Handing an agent the narrated behaviour of a plugin, rather than asking it to guess from a table schema.
Read on →Reading what the logic bound to a table actually does before deciding what to rewrite, keep, or retire.
Read on →The same narrations and edges, callable over the Pathix MCP from Claude, Cursor, or whatever you run.
Read on →See a narration on a plugin you did not write.
The demo runs the real console on sample data, so you can read a narration end to end before anyone touches your environment.