ConvertibleTrigger -- what to do if the "trigger_type" is unknown

[pjohnmeyer]

https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/blob/234f5ea279f849da4cdb75b2306c6cc743dd3d0a/docs/schema/types/conversion_triggers/ConvertibleTrigger.md

There are convertibles in our system for which we do not know the trigger; that is embedded in uploaded documentation and not represented in the data model. Since this version of OCF does not have a document model, we do not have a way to share this information.

While we do want to capture trigger information, we have a lot of legacy data that does not have it. Suggestions:

Add an "unknown" value to the enum.
We have shied away from this in the past, because with an option like this there's an easy out to implementing without providing the data at all. But I want to include it as an option in case it had merit. UNKNOWN, UNSPECIFIED, NOT PROVIDED, etc.

Make the trigger_type optional
If we have the conversion rights, and we have the ConvertibleConversion in the transaction log (or not), does that give us a good enough picture of the state of the cap table?

Make the trigger_type compatible with PreReleaseOmission
Allowing it to be explicitly omitted in the beta but requiring it later.

[JSv4]

@pjohnmeyer just wondering if we can get creative with the custom conversion trigger here... are these convertibles that already converted and we just don't know the trigger, or are these convertibles that could convert but we don't know the trigger? For backfill of old data, I wonder if being cute with custom triggers is better than letting people create unknown triggers going forward?

[pjohnmeyer]

are these convertibles that already converted and we just don't know the trigger, or are these convertibles that could convert but we don't know the trigger?

Some of both.

I wonder if being cute with custom triggers is better than letting people create unknown triggers going forward?

I'll need a concrete example of what you're proposing. I don't see a custom option under "triggers", only under "mechanisms".

[JSv4]

@pjohnmeyer, yup, you're right there is no custom trigger type (example here from the ConvertibleTrigger):

Maybe the right way to handle this is to consider these of trigger type ELECTIVE_ON_CONDITION and then provide some bare bones context in the trigger_condition field? E.g. "User / platform permits user to trigger conversion manually, but any requisite conditions are not known." ?

I do worry though that the nuance will get lost, so maybe you're right we should add another trigger type like ELECTIVE_ON_CONDITION_NOT_PROVIDED or something similar that conveys there is a condition but we don't know what it is? Practically, that would be treated as ELECTIVE_AT_WILL by the platform, relying on the user to properly follow the terms of the convertible.

[JSv4]

TWG Call Notes:

We don't want to force people to pick an enum that's not accurate. UNKNOWN is a bit too unclear. We want to be extremely clear that what's happening here is a it's assumed this will be manually handled on the platform.

Couple of possibles for another enum option:

1. UNSPECIFIED <-- We like this one
2. NOT_PROVIDED_BY_SYSTEM_OF_RECORD
3. INFORMATION UNAVAILABLE

We should make it clear what this should be used for in the documentation.

[JSv4]

Incorporated as part of #226