Make Stakeholder.current_relationship a list

[kedder]

Currently Stakeholder.current_relationship is a scalar enumeration - only one value is allowed. However, in real life some stakeholders can have several roles at the same time, e.g. Founder & Executive or Investor & Board Member. It could be hard to pick a single relationship out of several in such cases.

Suggesting to make it a list of enums instead.

P.S. Not sure if this belongs to "Issues" or "Discussions" section on github. Let me know how you would prefer to receive suggestions like this.

[rayshan]

Thanks for the suggestion Andrey. How do you use relationships? What do you think about making this field current_primary_relationship? Even if we have a list of relationships, the data consumer may still needs to know what the primary relationship is.

Background: we considered having a list of relationships when we first added relationship metadata to LTSE Equity. We decided against it because our primary use case, ASC 718 stock based compensation reporting, is better served with just the primary relationship at a point in time. I believe Carta went through similar thinking.

In a future version of OCF that supports changelogs, we will track the full history of a stakeholder's primary relationships. Making relationships lists and tracking what's primary drastically complicates the data schema.

[kedder]

How do you use relationships?

We have a concept of "roles", which is similar to what is called "relationship" here. Stakeholders are given additional permissions in the app basd on these "roles". E.g. "Investor" can see their holdings, and "Board Member" can approve decisions. Even if we call it current_primary_relationship, it is not obvious whether "Investor" or "Board Member" has to be "primary" in this case.

If this field is targeted for ASC-718 report, maybe the field description should indicate that explicitly and only contain values that are important to ASC-718?

[rayshan]

I see. OCF's goal is to record fact data. All stakeholders are recorded. Whether a stakeholder has access, and what kind of access they have, don't belong in the OFC. Role definition can be different for each platform.

I'd like to reuse the relationship field for multiple use cases instead of having use case-specific fields. This is what LTSE Equity and Carta do. Relationship is a universal concept. ASC-718 is specific to the U.S. If there are 200 ASC-718-like reporting requirements around the world, OCF shouldn't include 200 fields.

That said, your original ask is still valid. For example, in a filtering use case, a user may want to see a filtered list of employees and a filtered list of founders. A founder is an employee, so a founder should should show up in both lists. We discussed this during a TWG call. We wanted to keep things simple for v1, because a single primary relationship works for multiple platforms. Carta was not on the call.

@tmccnnll what do you think?

[JSv4]

@kedder, @rayshan & @tmccnnll, where do you guys come out on this?

• One single primary relationship field
• A list of relationship fields
  • Possibly with a way to flag which is "primary"?

[kedder]

From my POV, there can be a concept of "primary" relationship if some kind of intuition is given on how to pick one. IOW some relationships should have a defined priority over the others. E.g, if some stakeholder is both Founder and Executive and Board Member, it should be easy to tell which of these relationships should be considered "primary".

[JSv4]

@EricVogl-carta, you have any thoughts on this?

[JSv4]

This discussion can continue, but the spec works as-is and this can be added in future releases in a non-breaking way if we leave current_relationship alone and add another field for past or non-primary relationships. Marking out of scope for now.