ConvertibleAcceptance

Carta has no convertible-acceptance transaction or acceptance field. OCF's TX_CONVERTIBLE_ACCEPTANCE is a standalone *event* recording that a stakeholder accepted/countersigned a previously-issued convertible. Carta's transaction set (grepping the pinned bundle for …Transaction $defs) covers issuance, cancellation, exercise, transfer, settlement, and conversion — but there is **no *AcceptanceTransaction** of any kind, and specifically nothing for convertibles. The event/date has no Carta home, but the accepted convertible's identity can be retained on its enclosing ConvertibleTransactionItem.securityId.

Where acceptance lives in Carta — and why date still can't land there. Carta does model the *fact* of acceptance, but only as a passive attribute on the security/grant object, never as its own transaction: the June 22 bundle has exactly three such fields — OptionGrant.stakeholderAcceptanceDate, RestrictedStockAward.stakeholderAcceptanceDate, and RestrictedStockUnit.stakeholderAcceptanceDate (each $ref: #/$defs/Iso8601CompleteCalendarDate, a plain calendar date — verified against the pinned bundle). The April bundle also carried Interest.acceptanceDate, but Interest was removed. Critically, ConvertibleNote carries no acceptance field at all (its properties are the convertible economics — interestRate, priceCap, discountPercentage, conversionTrigger, maturityDatetime, etc. — plus id/securityId/issuerId/stakeholderId/securityLabel/dates), and neither does ConvertibleIssuanceTransaction. So there is no convertible-side acceptanceDate slot for date to populate; the convertible objects that would be this transaction's natural home simply do not record acceptance. Mapping date onto one of the non-convertible acceptance-date fields (an OptionGrant/RSA/RSU) would be semantically wrong (wrong security type) and is therefore not a valid target. (Contrast the sibling EquityCompensationAcceptance, where date *does* map to OptionGrant.stakeholderAcceptanceDate precisely because an equity-comp grant is a Carta security object that carries an acceptance field; the convertible has no such field, so only its security_id can be retained.)

date (no-equivalent). The transaction date — when the convertible was accepted — would be the one substantive payload of this object, but per the point above Carta exposes no convertible acceptance-date field. Granularity is moot here since there is no target at all, but for the record the existing Carta acceptance fields are a mix: every retained acceptance field (OptionGrant/RSA/RSU stakeholderAcceptanceDate) is a plain calendar date (Iso8601CompleteCalendarDate), matching OCF date's format: date. Marked no-equivalent because the target field is absent for convertibles, not merely lossy.

security_id → ConvertibleTransactionItem.securityId (rename). This is the foreign key tying the acceptance to its convertible (the security_id minted by the originating TX_CONVERTIBLE_ISSUANCE). Carta's ConvertibleTransactionItem is the enclosing lifecycle aggregate and carries the identity for the note; it is the defensible place to preserve which convertible the OCF acceptance references, even though it cannot represent the acceptance event itself.

id, object_type, comments (ocf-internal). Standard OCF object scaffolding, handled exactly as in the Issuer precedent. id is OCF's own object identifier (Carta assigns identifiers server-side); object_type is the fixed discriminator constant TX_CONVERTIBLE_ACCEPTANCE that OCF uses for positional typing and which Carta does not need; comments is free-text with no Carta slot.

Consistency. Across the acceptance family, Carta never models the acceptance event as a transaction. Where a corresponding security/aggregate has an acceptance-date field, date is folded onto it; where it does not, date remains no-equivalent. The shared security_id reference is preserved on the corresponding Carta identity/container wherever one exists.