That's a really broad question. :-)
Knowledge Fusion (KF) is at the core of every seat of NX.
The language used to create formulas in NX Expressions is KF. And so every time an NX model updates, the KF engine is keeping track of any and all relationships between expressions. All of the OOTB functions available in the Expressions dialog are created and consumed using KF. This mechanism is open by design, and customer can fairly easily add your own functions to the Expressions environment as needed.
A number of tools like Product Template Studio (PTS) use KF internally to persistently store various kinds of rules and information within NX part files. The custom user interfaces described by PTS are stored using a set of KF rules, for example. Many of the process automation tools created by the KDA devellopment group leverage KF in similar ways.
Tools like Check-Mate leverage the language and rules engine of KF to perform model quality validation, evaluating checking rules either on model update, on part save, or on demand. Similarly, the Requirements Validation application uses the engine to execute validation checks at the appropriate time during NX update and report back meaningful results.
The KF language can also be used like our traditional APIs to write NX automation applications as well, though for novice users, the more common languages (Visual Basic, C#, Python, Java, C++, etc.) may be more approachable. For programmatic users, a "Knowledge Fusion Author" license will light up a number of programming and debugging tools inside NX.
Does that help?
Apart from the precise and expert definition of KF from Taylor Anderson i would like to add some more experience i had with KF as a user.
I don't have the knowledge of NX-Open but have used KF at many occasions (for example just as in programming language you can utilize Loops/conditions etc for creating /editing/validating something). I remember i used it for a naive Gear Profile Creation program a long time back. But what really sets KF apart from other programming tools is ....the hybrid approach (you can create something using normal modeling commands and then adopt it as a KF feature inside the part navigator and further manipulate it taking advantage of the KF classes).
I am attaching one video (very old one but will surely give you a look into KF strengths).
This video is about how we can impart different colors to part family members.
You're right... It's easy to forget about things like KF "Adoption" when I've been doing this so long. ;-)
"Adoption" in KF is somewhat similar to "Journaling" in the other API languages:
With Journaling, you can record a series of actions in NX, and save this sequence of operations as NX API language code (C#, Java, Visual Basic, Python or C++), either for future playback, if desired, or for use as the basis of a more involved piece of NX Open automation.
With KF the process involves creating a set of objects and then using the "Adopt Existing Object" command to create a set of KF rules describing these objects. As you've described, the difference with KF is that these rules are first created inside the current NX session, where they can be adjusted and manipulated as desired, and then optionally exported as KF code that can be reused in various ways.
Both methods work very well. Generally speaking, KF will be more useful in the quick creation of smart, associative objects that need to live and breathe as part of a parametric model. The traditional APIs will be better for sequential kinds of automation tasks, and for cases where you don't want the automation to create persistent objects inside a part.
Although to be clear, there is a new capability in the NX 11 NX Open API for creating bona-fide "Features" using the API. (And it doesn't use the older UDO architecture.)
Hope that helps!
Thanks for the reminder.
Solution Center has an article titled "Getting Started with NXOpen : Index". It contains links to 24 "Getting Started" articles that should give you a head start on NX Open programming.
The articles were written by Amy Webster and Frank Berger who are part of the GTAC NX Programming support team. Good luck!