open-cap-table-coalition / ocx Goto Github PK

Scope

From https://github.com/captable/ocx/files/11265982/OCX.v.0.4.xlsx

Desired outcome

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Scope

v1.0 reference

Desired Outcome

For each Stock Plan:

• TBD

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Scope

Desired Outcome

1 row per preferred stock class

• Initial closing date: ⚠️ Calculated, needs requirements from working group(s)
• Most recent closing date: ⚠️ Calculated, needs requirements from working group(s)
• Original issue price: From STOCK_CLASS object
• Adjusted conversion price: ⚠️ Calculated, needs requirements
• Conversion ratio: Use existing calculation
• Liquidation multiple: From STOCK_CLASS object
• Participating: Y if STOCK_CLASS has a participation cap, N otherwise
• Participation cap: From STOCK_CLASS object

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

⚠️ Note any Warrants implementation in OCX is dependent on the resolution of Open-Cap-Table-Coalition/Open-Cap-Format-OCF#410

This is the same question as #26, but for warrants.

In v0.4 of the OCX sample spreadsheet, the conversion ratio for a stock class appears on the Context sheet, which is used on the Stakeholder Snapshot sheet to calculated "as converted" numbers.

In v1.0.0 of the OCF specification, however, every stock class can have more than one possible "StockClassConversionRight", each of which can have its own separate ratio. Note that this is a list:

Desired Outcome

Per discussion with members of the Law Firm Working Group, the "normal" case is that each Preferred Stock Class will convert to a particular Common Stock Class with 1 vote per share as the "underlying" instrument for everything. There are other arrangements, of course, so we agreed the algorithm should be something like this:

1. If only one StockClassConversionRight converts to a common stock class, use that one's ratio
2. If more than one StockClassConversionRight converts to different common stock classes, choose the conversion ratio that corresponds with the common stock class with the lowest non-zero votes per share.
3. If there are no conversions to common, but there are conversion to another preferred stock class, recursively continue to apply steps 1 and 2 until a single common stock class is found -- multiplying all of the multipliers along the way.
4. ERROR otherwise

These rules only apply, however, if the StockClassConversionRight converts_to_stock_class_id -- if it converts_to_future_round we have no information on the target class. Classes that converts_to_future_round can have a ratio with no target common or preferred class to implement this against, so there are more questions to answer here -- or improvements to be made to OCF.

To-Do

• If necessary, determine necessary in-tool calculations and document for review and approval, if necessary
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

⚠️ NOTE: This requires changes to the OCF schema proposed in Open-Cap-Table-Coalition/Open-Cap-Format-OCF#397

⚠️ NOTE: This also depends on the answer to #26

Scope

Desired Outcome

TBD

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Related to #17.

Scope

From https://github.com/captable/ocx/files/11265982/OCX.v.0.4.xlsx

Desired outcome

• There should be one row for this value. Note the row of padding between this and the actual stakeholders.
• The value should be 0 for every column that does not represent a STOCK_PLAN
• The value should be calculated for each column that does represent a STOCK_PLAN

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Scope

In v0.4 of the OCX sample spreadsheet, the Stakeholder Snapshot sheet includes the preferred stock conversion multiplier in the header, to 4 decimal places. However, when the conversion ratio is not a whole number, this value is approximated, and the user needs to be aware of this.

To improve the user experience, we need to update the display logic to indicate when the preferred stock conversion multiplier is approximated.

Desired outcome

Display the approximated value with a tilde (~) to signal to the user that the value is not exact. For example, if the conversion ratio is 3 → 8, which is 2 2/3, we will display ~2.6667 in the header.

To-Do

• If necessary, determine necessary in-tool calculations and document for review and approval, if necessary
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Currently, for ease of use, the CLI applies a set of heuristics to find a manifest file within the provided folder.

In the odd case that these heuristics incorrectly flag an error, or that a user has multiple packages in a single folder, it might be useful to allow some combination or arguments or options for specifying which file in the package is the manifest file, e.g.:

Approach 1: Positional argument can be directory or single file

ocf2ocx ./path/to/package would apply the existing heuristic as it does today
ocf2ocx ./path/to/package/manifest.json would skip the heuristic and load the specified file as the manifest

Approach 2: Additional option to specify which file is the manifest

ocf2ocx ./path/to/package would apply the existing heuristic as it does today
ocf2ocx ./path/to/package --manifest manifest.json would skip the heuristic and load the specified file, relative to the package, as the manifest

There are of course other options but I prefer Approach 1.

In some cases, percentages in the spreadsheet could be near zero but not zero, for example, 0.0018%. These display as 0.00%, the same as actual 0.

Some options:

• We could apply the same approach we have elsewhere where zeroes are displayed as -. This would be a consistent visual distinction between zero and near zero, but it might still be confusing to see both - and 0.00% in the same column.
• We could use conditional formatting to make these non-zeroes italics or highlight them somehow, but I'd rather avoid conditional formatting unless absolutely necessary.
• We could use a different formula; e.g. instead of =H7/$H$26 we could do =IF(H7/$H$26<0.00005,0.0001,H7/$H$26) -- essentially rounding up to the lowest representable value.
• Or we could just leave it alone and let the user adjust the number of decimal places for themselves, as they see fit.

Any of these approaches could be combined with also displaying more decimal places by default.

Thoughts?

Scope

From https://github.com/captable/ocx/files/11265982/OCX.v.0.4.xlsx

Desired outcome

• Fully Diluted Shares total include all as converted holdings (and "Options Remaining for Issuance") highlighted light green above, regardless of security type. Thus, the only columns excluded from this total are the outstanding columns for Preferred Stock (lowlighted grey) with a conversion ratio != 1.0. (This should be reflected in the calculations documentation.)
• Calculations here are all in Excel, not in-tool.

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

What can we help you with?

Should Fully Diluted Shares and % Fully Diluted include conversion shares for Outstanding Convertible Securities such as convertible notes or SAFE?

As a data point the below points that "occasionally" it would be included:
Understanding your company's pre-money fully diluted capitalization: 4 items to consider

Scope

v1.0 reference

Desired Outcome

Derived from STOCK_PLAN and TX_STOCK_PLAN_POOL_ADJUSTMENT objects.

"Initial adoption" rows are populated from the STOCK_PLAN:

• Plan name comes from the object
• date comes from the object
• Action = 'Initial adoption'
• Stockholder approval date comes from the object
• Number of shares comes from the object
• Total shares reserved comes from the object

"Increase/Decrease" rows are populated from TX_STOCK_PLAN_POOL_ADJUSTMENT and their associated STOCK_PLAN

• Plan name comes from the STOCK_PLAN
• date comes from the TX object
• Action = Dynamic based on new shares_reserved vs previous
• stockholder approval date comes from the TX object
• number of shares: Calculated delta between new total shares and previous total shares
• total shares reserved comes from the TX object

⚠️ Unknown: How are multiple stock plans ordered in this table?

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Scope

Desired Outcome

For each VALUATION object of type 409A, ordered by ascending valuation date:

• valuation date comes from the object
• Price Per Share (Common) -- comes from VALUATION object
  • ERROR if stock class in valuation object is not a common stock class
• Options Outstanding at Valuation -- ⚠️ Calculated, need requirements
• Valuation Firm -- provider in VALUATION object

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Scope

On the Stakeholder Snapshot sheet, with "Show Formulas" on:

In v0.4 of the OCX sample spreadsheet, the "as converted" columns use a single numeric value from the Context sheet to calculate outstanding shares on the Stakeholder Snapshot sheet. This, however, does not take into account the rounding method associated with the conversion ratio.

Desired outcome

The function used in these cells needs to correspond to the actual rounding_type in the OCF data.

To-Do

• If necessary, determine necessary in-tool calculations and document for review and approval, if necessary
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

⚠️ Note any Warrants implementation in OCX is dependent on the resolution of Open-Cap-Table-Coalition/Open-Cap-Format-OCF#410

⚠️ Answers to #27 and #28 must be known before this can be correctly implemented.

Scope

From https://github.com/captable/ocx/files/11265982/OCX.v.0.4.xlsx

Desired outcome

• There should be one column for each group of warrants, grouped by the common stock class they convert to per the same algorithm as #22.
• The left-to-right column ordering places Warrant groups to the right of Stock Options. If there are multiple Warrant groups, they should be ordered from oldest common stock class board_approval_date to most recent, with nulls last, and name as tie-breaker.
• When a Warrant converts to preferred stock, we should seek out the "winning" common stock by following the same algorithm for handling multiple stock class conversion rights for preferred stock classes. Therefore, the function used in the Warrant cells needs to show the converted value (actual holdings * ratio). Nothing should change in the header.

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

In v0.4 of the reference Stakeholder Snapshot sheet, the "Stock Options" column looks like this:

but the name of the stock plan on the Context sheet is "Startup, Inc.2018 Stock Plan"

Does the header imply that we group all options by underlying instrument, and not stock plan? In other words, if there were two Stock Plans that both convert to Class A Common, would there be one "Class A Common" column on the Stakeholder Snapshot sheet that lumps both together, or would there be a separate column for each Stock Plan?

If an OCF Package is within a .zip file, it would be nice if the user did not have to unzip it themselves before running ocf2ocx on it.

The CLI could handle this with either of the approaches identified in #29. However, any dependency adopted for dealing with zip files would ideally support running in-browser as well.

This task DOES NOT include the "Options Remaining for Issuance" row yet which is documented in #18.

Scope

From https://github.com/captable/ocx/files/11265982/OCX.v.0.4.xlsx

Desired outcome

• There should be one column for each STOCK_PLAN in the OCF package, even if the STOCK_PLAN has no associated transactions.
• The left-to-right column ordering places Stock Plans to the right of Stock Classes. If there are multiple Stock Plans, they should be ordered from oldest STOCK_PLAN.board_approval_date to most recent, with nulls last, and name as tie-breaker.

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Steps to reproduce

Run

ocf2ocx ./test/fixtures/example-inc

or

npm run cli ./test/fixtures/example-inc

Expected behavior

Normal Excel output

Actual behavior

pj@LTSE-Q293FVD2T0 ocx % ocf2ocx ./test/fixtures/example-inc
node:internal/modules/cjs/loader:998
  throw err;
  ^

Error: Cannot find module 'src/logging'
Require stack:
- /Users/pj/code/ocx/dist/src/model/calculations.js
- /Users/pj/code/ocx/dist/src/model/index.js
- /Users/pj/code/ocx/dist/src/index.js
- /Users/pj/code/ocx/dist/src/cli/index.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:995:15)
    at Function.Module._load (node:internal/modules/cjs/loader:841:27)
    at Module.require (node:internal/modules/cjs/loader:1067:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/Users/pj/code/ocx/dist/src/model/calculations.js:9:35)
    at Module._compile (node:internal/modules/cjs/loader:1165:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1219:10)
    at Module.load (node:internal/modules/cjs/loader:1043:32)
    at Function.Module._load (node:internal/modules/cjs/loader:878:12)
    at Module.require (node:internal/modules/cjs/loader:1067:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/Users/pj/code/ocx/dist/src/model/index.js:7:24)
    at Module._compile (node:internal/modules/cjs/loader:1165:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1219:10)
    at Module.load (node:internal/modules/cjs/loader:1043:32)
    at Function.Module._load (node:internal/modules/cjs/loader:878:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/Users/pj/code/ocx/dist/src/model/calculations.js',
    '/Users/pj/code/ocx/dist/src/model/index.js',
    '/Users/pj/code/ocx/dist/src/index.js',
    '/Users/pj/code/ocx/dist/src/cli/index.js'
  ]
}

What OS and version are you running on?

MacOS 12.6

What Node version(s) are you using?

16.19

Anything else we need to know?

No response

Currently, after running npm install https://github.com/captable/ocx, the binary ocf2ocx is available for use but one cannot require('ocx') from the node console or import OCX from 'ocx'. This should be ironed out so the code can be used from other code, not just from the command line.

In v0.4 of the OCX sample spreadsheet, the Stakeholder Snapshot sheet includes the preferred stock conversion multiplier in the header, to 4 decimal places. Should we do something to indicate to the user when this is approximated?

For example if the conversion ratio is 3 → 8, this number is 2 2/3. In this case we could display, amongst other options, any of the following:

1. 2.6666 (truncated)
2. 3.6667 (round away from zero)
3. ~2.6666 (truncated with indicator)
4. ~2.6667 (round away from zero with indicator)

@pjohnmeyer prefers option 4.

In an initial discussion with Joe @ Gunderson, @pjohnmeyer initially proposed option 4. Joe's proposal was to increase the number of digits to 10 and implement option 2; in this case it would be displayed as 2.6666666667.

In v0.4 of the reference Stakeholder Snapshot sheet, the "Stock Options" columns look like this:

It is unclear what the behavior should be here if a Stock Plan converts to preferred stock. This depends somewhat on the answers to #25 as well.

A few possible interpretations:

1. We seek out the "winning" common stock by following the same algorithm in #22 and perform the multiplication in-tool. This would be different than how we do stock classes since in those cases we show two columns for outstanding and as-converted.
2. We display two columns, in the same way that we do for preferred stock with non-zero conversion ratios. Only the "as-converted" values would count towards Fully Diluted numbers.
3. Others?

Scope

https://github.com/captable/ocx/files/11883157/OCX.v.1.0.xlsx

Desired Outcome

• As of date should come from OCF manifest
• "Generated on" date should come from OCF manifest
• "OCX Version" should read 1.0, not 0.5 like the reference sheet shows
• Update title

To-Do

• Determine necessary in-tool calculations and document for review and approval
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

⚠️ Note any Warrants implementation in OCX is dependent on the resolution of Open-Cap-Table-Coalition/Open-Cap-Format-OCF#410

In v0.4 of the reference Stakeholder Snapshot sheet, the "Stock Warrants" columns look like this:

However, a single issuance can be linked to multiple stock classes because Warrant Issuances have multiple possible conversion rights.

In a previous call we determined an algorithm for Preferred->Common, which I documented and elaborated on in #22. It makes sense to me that we would use the same algorithm for consistency, but I wanted to ask the question rather than assume.

Scope

On the Stakeholder Snapshot sheet, the "Stock Options" columns look like this:

When a stock plan converts to preferred stock, it is unclear what the behavior should be. One possible interpretation is to seek out the "winning" common stock by following the same algorithm for handling multiple stock class conversion rights for preferred stock classes. This would involve an additional layer in the tree diagram in issue #22, where vested options are converted to the preferred stock and then traversed to determine the "winning" common stock with the lowest non-zero vote count.

Desired outcome

In the case of conversion, the function used in the stock plan cells needs to show the converted value (actual holdings * ratio). Nothing should change in the header

To-Do

• If necessary, determine necessary in-tool calculations and document for review and approval, if necessary
• ocf-package: Are the necessary OCF Files being processed?
• model: Are the necessary OCF Objects being consumed?
• Develop workbook against Model interfaces.
• Implement actual Model
• Integrate and test end-to-end

Per the resolution of #23:

Per the LFWG, we will continue to display only 2 digits, so very small values will display as 0.00% -- the reader will have to expand the precision in Excel manually. True zero values will display as - the same as other numeric cells.

The excel-js numFmt for this still needs to be determined, but it should be derived from the default numeric format of:

https://github.com/captable/ocx/blob/3b23b2f9a4b3e3a1e1c84abefae8b0f8a88108eb/src/workbook/styles.ts#LL62C7-L62C58