We have to think about the child-parent relationship under the new ontractStructure

[Brammertz]

The child parent relationship was defined yet at a time, when underlying children were directly linked to the parent contracts. In such cases, it was possible to write for example SD only in the parent level. The SD for the associated children was implicitly given.
Now we have decoupled parent and child. The relationship is only know indirectly via contractStructure. If we have for example a SWAPS contract with different states, then it is also likely, that the children might have different different states. I wrote "might" to point to the fact, that it is possible to have a single version of the fixed leg of the Swap while the variable leg has clearly multiple versions and states.

We must also think about the different cases. The first case, where the child is an underlying contract (CNTRL=UDL). In this case some of the child-parent relationships might make sense. In the case of CEC/CEG and also securitization, it is clear, that the child parent relationship don't make sense.

How to deal with this?

1. We have to go through the parent child relationship one by one. Some still make sense, but some must go.
2. We must take into consideration the different cases.
3. Update the DD

[ce-teuf]

Now we have decoupled parent and child. The relationship is only know indirectly via contractStructure. If we have for example a SWAPS contract with different states, then it is also likely, that the children might have different different states. I wrote "might" to point to the fact, that it is possible to have a single version of the fixed leg of the Swap while the variable leg has clearly multiple versions and states.

I was thinking of swaps legs as practical/technical concepts to design the parent Swap contract type.

Follow-up (naive) question:
Can we theoretically (and practically) build a swap contract using already existing independent contracts (PAM, ANN...) ?

---

Just sharing a series of thought regarding "related contracts" linked to some contract types, since I am currently thinking about the same thing for my own implementation :

How to create a more general link between the 'host' contract and the 'related'/'linked' contracts to this parent contract. I also agree, a direct, so-called, 'parent-child' link seems too strong and restrictive to me (in many configurations). I imagine a structure of the following kind, carried and defined CT by CT :

related_contracts : 
    contract_set : HashSet<ContractElem>
    contract_structure: Option<ContractStructure> // None or Some of ContractStructure

with :

struct ContractElem
    contract_elem : CT 
    dependence : Option<Owned or Reference> // None or Some of an enum with Owned et Reference variants

Struct and attributes naming are not the same as in the current implementation, this is just an idea, a pseudo structure..

related_contracts is composed of a contract_set to which we will eventually implement a contract_structure : computational rules on/between these contracts and/or with the 'host' (parent) contract, define reference roles ect... => defined contract type by contract type.

ContractElem is of any contract type with an attribute dependence which state if the given contract have an independent existence elsewhere so we could only Reference it or if it is dependent of the "host" contract, ie has no independent existence elsewhere, the contract is Owned by the host contract.

If a contract in a contract_set is Owned, then external data and unscheduled events must pass through the "host" (parent);
If a contract in a contract_set is a Reference, external data and events pass through this contract; the parent contract “undergoes” the "modification" of one of its linked ContractElem.

Also I was thinking about not allowing MarketObjectCode type contract structure element (as in FUTUR, OPTION), like its currently is in Java implementation, allowing only the structure above.

By thinking through this, I was also tempted to define a portfolio concept, but I decided to keep it deliberately abstract here: I ultimately thought that the portfolio concept should be reserved for project/libraries using actus-core, not to be defined in actus-core, since Portfolio concept have specific meaning and usefulness.

I don't know if this kind of structure could map all possible configurations. I need to further think about it and get more knowledge about non yet implemented contract types and real-world usage of such instruments.

[tahoeblue]

Owing to the diverse nature of financial contract arrangements, there are a number of different modalities and configurations between and among a set of contracts that are related in specific ways. The more general approach to describing these relationships will be more a graph than a hierarchy, although there are certainly simpler cases in which a hierarchy of contracts under a governing 'master' will clearly suffice. The notion of relationships established by references to unique contract identifiers provides the flexibility needed to establish such a graph, and this does open up the types of structured contracts that can be described. It does mean that there needs to be a way to resolve the references in order to access, instantiate and/or model contracts that have been individually defined. The so-called "inline" version -- in which a top-level contract includes the details of all "underlying" contracts literally by inclusion -- avoids the requirement to access related contracts by their unique identifier and is a more explicit form that "pre-joins" the related contracts together in a single specification.

The declarative nature of the Contract Structure notation does not prescribe a physical implementation, and would ideally be a single version of the truth that any or all counterparties to the structure could interrogate. I quite agree that, in the general case, the implementation (whether for analytical or transactional purposes) of a more robust Contract Structure specification involving actus-core will require some form of orchestration or interpretation agent that understands Contract Structure and invokes and utilizes actus-core contracts as needed.