Horus Eye · Deep Read
AI that reads Salesforce metadata like an architect, not a parser
Select a Flow, Apex class, field, permission set, report, Lightning page — most metadata types — and ask for a Deep Read. Horus investigates against the org’s own structure and explains what a senior architect would: apparent business purpose, dependencies, health, overlap, change risk, and what to do about it — with the diagrams the context calls for. It is the closest thing to a Salesforce documentation tool that writes itself: living documentation of what each component does, generated from the org — Salesforce metadata AI analysis with the honesty gates an architect would demand, every claim labelled observed or inferred.
The line this page exists to say
Evidence vs inferenceHorus Eye distinguishes directly observed configuration from AI-inferred business intent and shows the evidence behind its conclusions. An observed claim cites the configuration or dependency record it came from. An inferred claim — “this Flow appears to prepare commercial approval” — is labelled as inference, carries a confidence rating, and is phrased as a hypothesis for the owner to confirm. A hedging validator rejects output that states inference as fact before it ever renders. That discipline is what makes an AI read usable in a change plan.
Two kinds of Deep Read
Finding · componentDeep Read of a finding
Horus investigates the finding against the org using read-only retrieval tools, then writes The short version — one impact bullet per business lens the finding carries — The call that stays yours — the one question only the owner can answer — and the fix plan, each step sanctioned-executable or guided.
Deep Read of a component
For any of dozens of metadata types: why it exists, what it does, what depends on it, what it overlaps with, whether it is healthy, and what changing it could affect — with a validation plan and the diagrams that fit the context.
The diagrams are drawn from the evidence, not decoration: dependency graph, save-path, field- writer map, permission path, call graph, report lineage, blast radius, overlap map — whichever the component’s situation calls for.
What Fix it may touch — the whole vocabulary
16 sanctioned operationsEvery executable step in a Horus fix plan is one of sixteen sanctioned, reversible operations — in plain English: tightening access (withdrawing object, field and Apex grants; removing policy-bypass permissions; removing duplicate grants), retiring unused permission sets, cleaning inactive-user assignments, consolidating record types and validation rules, and decomposing a god object into extension objects (create the extension, move the fields, migrate and backfill the data, map the permissions). Anything outside that vocabulary is a guided Setup step, stated as such.
And three gates stand before any write: the deployment switch, a per-org write grant in Settings, and your per-step approval — then zero-write validation, then execution, with rollback that re-grants exactly what was removed, refusal on managed-package components, and a re-scan that distinguishes “resolved” from “still present, but changed”.
The safety model, in one place
Opt-in AIAI is off by default and enabled per org, with a daily cap. What goes to the model is structured scan evidence fetched by read-only retrieval tools — component details, neighbours, live org facts, field writers, audit trail, structure comparisons — never record data, never source bodies. Every output is model-stamped, dated, confidence-rated, and marked “verify before acting.” The model can propose; only the gates above can touch.
Frequently asked questions
Straight answersWhat does Horus Eye send to the model?
Structured scan evidence only: details, dependencies, flags, live org facts. Never record data, never Apex/Flow source, never template contents or query text.
Which types can I Deep Read?
Most of the estate: Flows, objects, fields, triggers, Apex classes, LWC/Aura/Visualforce, Lightning pages, layouts, quick actions, validation rules, permission sets and groups, profiles, sharing rules, reports and dashboards, and integration and configuration types.
Can it be wrong?
Yes — that is why evidence and inference are separated, confidence is rated, and the hedging validator exists. An inferred purpose is a hypothesis to confirm, and the product never lets it read otherwise.
Does it change my org?
No. Reading is read-only; changing goes through the three Fix it gates, zero-write validation, and your per-step approval — reversibly.
Protected AI — the Trust Layer
Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.
Ask the org a question it can finally answer
Pick the component you’ve always wondered about and let Horus read it — evidence first, inference labelled, diagrams included.
Try Horus Eye Explore Deep Read All Horus Eye pages