OCF Validation Policy

OCF Validation Policy

The OpenCapTable contracts implement the official Open Cap Format (OCF). They do not extend OCF with Fairmint-specific data-validity requirements.

Source of truth

A contract may reject OCF data only when the rejection is required by an official OCF source:

1. A JSON Schema rule, such as required, type, enum, const, format, pattern, numeric bounds, array cardinality, uniqueness, or an explicit conditional/composition rule.
2. An explicit rule in the official OCF documentation that defines behavior across objects or transactions, such as the terminal-transaction traversal rules.

Field names, field descriptions, examples, tutorials, legal/accounting expectations, and relationships that merely appear inferable from the model are not enough to create a new contract failure condition. An ADR may explain how OCP implements an OCF requirement, but it may not authorize stricter data validity than OCF.

When the official sources are ambiguous, the contract must accept the data until the OCF project clarifies the rule. A proposed stronger invariant belongs upstream in OCF first.

Cross-object references

An identifier field does not automatically require the referenced object to be present in the same cap table. Referential existence, type, ownership, date, quantity, or lifecycle checks are enforced only when the official OCF sources explicitly require them.

For example, StockIssuance.stock_legend_ids is a required array field, but the schema does not require a non-empty array and does not require a matching STOCK_LEGEND_TEMPLATE object. The contract must therefore accept [] and must not reject an issuance solely because a listed legend object is absent. OCP must not fabricate legend text or require users to create placeholder legal data.

Review checklist

Every new validation PR must:

• link to a pinned official OCF schema or documentation revision;
• quote or identify the exact keyword or explicit rule that requires each rejection;
• include a positive boundary test and a negative test for that exact requirement;
• avoid combining required schema validation with inferred consistency rules;
• verify representative OCF payloads with the official validator when the rule is schema-based.

If a proposed failure can only be justified with words such as “implied,” “expected,” “should be consistent,” or “legally/accountingly necessary,” it is outside contract-validation scope unless those words are part of an explicit official OCF requirement.

Data-sync validation

Dev and production replay workflows are conformance tests for the contracts. A replay failure is actionable only when the rejected object violates an official OCF requirement. The workflow must not be made green by fabricating optional objects, inventing legal text, or normalizing away invalid source data. Conversely, OCP must not classify schema-valid data as bad merely because a locally inferred invariant rejects it.