Steve,
I'm not surprised you're struggling. As indicated in the somewhat wordy details at the end of my previous response (https://www.ormfoundation.org/forums/p/666/1983.aspx#1983), the join path support in NORMA is still in its early stages. I'll make the editor to do this publicly available when the verbalization and validation for the paths are done. The reason I need all verbalization and validation in place is that join paths are an advanced feature that are inherently non-trivial to conceptualize and implement, so I need the verbalization feedback loop solid before I let this out the door.
For this case, the two role sequences for the equality constraint should cover (role to select marked with <>) {{1.1=<ContractItem> is part of Contract, 1.2=Contractee contracts with <ServiceProvider>},{2.1=<ContractItem> is for ServicePackageOffered, 2.2=ServicePackage is offered by <ServiceProvider>}}. This will give you compatible role players for your two columns. The implementation you have will show two validation errors at this point indicating that you need a join path. There is nothing you can do to fix these errors without the additional editors I'm working on. You can, however, turn off display of the error with ErrorDisplay dialog that is available through the Properties Window with a diagram selection (Inside 'Constraint Structure Errors', uncheck 'Join Required for Multiple Fact Types').
Both join paths in this case are also complicated by the fact that they involve the link fact types that are implied between the objectifying entity type and the role players of the objectified fact type. These fact types are automatically generated with the objectification and can be seen with in the Model Browser or the Reading Editor window. To see/change readings for these implied fact types, select a role in the objectified fact type and open the 'Implied Fact Type Readings' branch in the Reading Editor. In this case, I should be able to jump across the objectification and add an automatic join path, so the errors may be self healing in later versions (not done at this point, although similar patterns with uniqueness constraints do automatically traverse the join path in the pre-release code).
With the join paths in place, the verbalization will look something like this (additions underlined):
For each ContractItem and ServiceProvider,
that ContractItem is part of some Contract that involves some ServiceProvider if and only if that ContractItem is for some ServicePackageOffered that involves that ServiceProvider.
Please be patient with join paths, and wait for the editors that you don't have yet.
-Matt
PS We're also considering some alternate verbalizations to emphasize the objectification relationship instead of using the default readings on the join fact types. This would give something like:
For each ContractItem and ServiceProvider,
that ContractItem is part of some Contract that objectifies 'some Contractee contracts with some ServiceProvider' if and only if that ContractItem is for some ServicePackageOffered that objectifies 'that ServiceProvider offers some ServicePackage'.
I'm not sure I like this second form, especially since the objectified fact type is often implied in the name of the objectifying entity type and this makes it more wordy, but it is something to consider as user option.