Ask a general question about Oracle Fusion and you get a general answer. It will be about Fusion, it will sound right, and roughly a third of the time it will be about a release you are not on, an offering you have not enabled, or an integration route you do not use.
That is not a model problem. It is a context problem. Nothing in the question told it which Fusion you mean.
The facts that change the answer
We keep a short list at the top of CLAUDE.md. Short matters. A long file gets skimmed, by people and by models.
- Release and update level, written as the version string your pod actually reports
- Which offerings are enabled, and which are explicitly not
- How you integrate: REST, BI Publisher, FBDI, OIC, or some combination, and which is preferred
- Where the local REST catalogue lives in the repo
- Your naming conventions for extensions, flexfields and value sets
- The rules, stated as rules
Ours looks roughly like this, with the identifying detail changed.
# Oracle Fusion context
Environment: Fusion Cloud Applications, release 25D
Offerings enabled: Procurement, Financials, Product Management
Offerings NOT enabled: HCM, SCM Execution
Integration:
- Preferred: REST. Catalogue in docs/rest-catalogue/ (source of truth).
- Bulk loads: FBDI only. Templates in docs/fbdi/.
- Reporting: BI Publisher. OTBI for ad hoc only.
Naming: extensions prefixed XX_, DFF contexts prefixed XXP_.
Rules:
- Never propose changing a seeded object. Extend instead.
- Do not invent REST paths. Cite the file in docs/rest-catalogue/
that contains the endpoint, or say you cannot find it.
- Sanitise before pasting: no supplier names, no invoice numbers,
no pod URLs.
What this stopped
Three things, fairly quickly.
Answers stopped drifting into E-Business Suite. Ask about approval routing and, without context, you get a reasonable amount of AME and workflow builder, which is useless on Fusion. Stating the release and the offerings ended it.
Endpoint paths stopped being invented. This was the big one. A plausible looking REST path costs you twenty minutes before you find out it does not exist. The rule that it must cite a file from the local catalogue, or admit it cannot find one, converted a confident wrong answer into a fast honest one.
Suggestions stopped touching seeded objects. Not because the model is reckless, but because the general internet is full of advice written for on-premises Oracle where that is normal.
The catalogue is the real work
The rules only work because there is something local to cite. We pull the REST endpoint list for the modules we use into the repo as plain files, one per resource, and refresh them when we take an update. It is an afternoon to set up and about twenty minutes per quarterly update.
Without it, the "do not invent paths" rule just produces "I cannot find that endpoint" every time, which is honest but not useful.
Where it still goes wrong
Fusion changes quarterly, and any model has a training cutoff. Anything about a feature newer than that cutoff needs the documentation in front of it. Stating the release helps it tell you it is unsure, which is most of the value.
It also still guesses at flexfield behaviour. That has been our most persistent source of wrong answers, and we have not solved it with context alone. For now we check anything DFF related by hand.
The sanitisation rule
Worth keeping in the file even though it is aimed at humans. Written down, it gets applied. Left implicit, somebody pastes a supplier list at 6pm on a Friday.
Join the group and send us your version of this file. We are collecting them.