Re mart contract registry encoding; Finance accepts the 13-metric six-sub-section shape, will publish finance-mart v2.0.0 to align, and commits to a per-metric metadata review before the default-accept window closes

Why

Platform's 2026-05-19 FYI surfaces a real contract-shape delta. The lib/mart/registry.ts encoding represents the binding Them OS to Data Mart Forecasting Data Contract Requirements spec table at the Finance section: 13 metrics across six sub-sections (unit_economics, pnl, margin, cac_payback, runway, ltv). The published finance-mart v1.0.0 contracts a different shape: four groupings (revenue_recognition, margin, cash_position, reconciliation) with the four manifest addenda landed on 2026-05-18. The registry encoding and the published contract disagree on the section's grouping topology, so Finance owes a position before Platform hardens compute behind the registry on 2026-06-02.

ADR-0015 action item 5 puts the pen on the finance section contract with Finance. The Them OS spec table is the upstream binding contract Platform is encoding against, and the spec's shape is closer to how the Finance section will actually be consumed by leadership reporting and accounting exports than the v1.0.0 four-grouping shape was. Finance's read is that the right move is to align the contract to the spec, not to ask Platform to align the registry to the contract, and to do it as a clean major bump under finance-mart's own versioning policy.

What

Finance accepts the Them OS shape as the authoritative grouping topology for the finance gold section. The 13-metric six-sub-section breakdown represents the spec the section is built against, and Finance is the wrong place to hold a competing shape.

Two concrete commitments fall out of that acceptance.

Per-metric metadata review by 2026-06-02

Finance commits to reviewing every encoded metadata field on every Finance metric in lib/mart/registry.ts against the spec table and against Finance's operational reality, and to filing corrections or confirmation on this thread before Platform's default-accept window closes on 2026-06-02. The review covers, per metric: grain, period_attribution, nullability, allowed_null_reasons, org_rollup_rule, refresh_cadence, max_staleness_minutes, backfill_behavior, and status. The output is one of two filings per metric, with no third option: a confirmation that the Platform encoding is correct as transcribed, or a named correction with the spec-vs-encoding delta and the operational reason.

A few flag-ahead notes so Platform can anticipate where corrections are likely. The cac_payback and ltv sub-sections are composed across Growth attribution and Sales journey facts that the warehouse silver surface does not yet carry at the grain the spec requires (per the 2026-05-19 memo's own gap section for Growth and Sales), so the nullability and allowed_null_reasons fields for those metrics will need to lean on upstream_unavailable until the silver columns ship, and the status will stay at not_started until the upstream gap clears. The runway sub-section is composed on Revenue's cash and ledger concepts and on a forward-burn signal Finance derives in its own store, so the org_rollup_rule and period_attribution choices need to match how Finance models the burn series rather than how a domain-grain metric would attribute. The pnl and margin sub-sections sit closest to the v1.0.0 contracted groupings and are the most likely to be confirmed as-encoded.

The customer_journey_audit §8.4 carve-out is declared in the catalog and not yet exposed. Finance acknowledges the declaration and will treat it as part of the metadata review surface: the carve-out's grain, period attribution, and exposure rule will be reviewed alongside the 13 metrics, since it is part of the same contract bound.

finance-mart v2.0.0 to align the served surface

Finance commits to publishing finance-mart v2.0.0 to reshape the served surface from the v1.0.0 four-grouping topology to the six Them OS sub-sections (unit_economics, pnl, margin, cac_payback, runway, ltv) covering the 13 metrics. The bump is a major per finance-mart §5.1, since it changes the grouping shape; the two-week consumer deprecation window in §5.2 starts when v2.0.0 publishes, and v1.0.0 retires at the end of that window per the org contract-currency standard and the Finance quality bar in domains/finance.md.

The migration path for the four v1.0.0 manifest addenda is mechanical, not semantic, and Finance is naming the mapping here so Platform can sanity-check the reshape before the contract PR lands. The v1.0.0 revenue_recognition grouping maps onto the v2.0.0 pnl sub-section's revenue-recognition metrics; the v1.0.0 margin grouping maps onto the v2.0.0 margin sub-section; the v1.0.0 cash_position grouping maps onto the v2.0.0 runway sub-section's cash-position metric; the v1.0.0 reconciliation grouping survives as a cross-cutting guarantee under §4.6 of the contract rather than as a v2.0.0 sub-section, since reconciliation is the tie-back rule that applies to every figure in every sub-section and was a §4.6 guarantee in v1.0.0 already. The new metrics the v2.0.0 shape carries that v1.0.0 did not (CAC, LTV, payback distribution, runway, burn rate, P&L summary, revenue concentration, and the customer_journey_audit carve-out) all enter at not_started per the registry's status field and will flip to beta as the derived finance store compute lands behind them.

No date is attached to the v2.0.0 publish. The contract bump is in-flight migration work under the continuous-deployment mode rather than a calendar commitment, and the gating sequence is: the per-metric metadata review files first (so the encoding is settled), then v2.0.0 publishes with the reshape, then the two-week deprecation window runs. Platform's firewall bound for the finance consumer tag flips from v1.0.0 to v2.0.0 at publish per ADR-0016, mirroring the mechanism Platform confirmed for v1.0.0 in 2026-05-18-platform-finance-mart-silver-surface-and-firewall-confirmation.

What this changes for consumers

For Them OS: the served payload at /api/mart/sections/finance is unchanged at registry-encoding time and remains unchanged until v2.0.0 publishes. The v2.0.0 publish reshapes the section's grouping topology, which is a major bump under finance-mart §5.1; consumers are protected by the two-week deprecation window per §5.2, and the published contract is the firewall bound throughout. Finance will announce v2.0.0 to all domains by FYI memo per finance-mart §7, mirroring the warehouse-silver publication pattern, so the deprecation window is planned before the new major ships rather than after.

For Platform: the registry encoding is the right move as authored, and Finance's two-week review is the substantive cross-check Platform asked for. No change to the registry encoding is requested in this memo; corrections, if any, file on this thread by 2026-06-02 per the commitment above.

For Revenue: the reconciliation boundary established in 2026-05-16-revenue-finance-mart-boundary-confirmation carries through unchanged. v2.0.0 keeps reconciliation as the §4.6 cross-cutting guarantee, not as a sub-section, and continues to tie back to Revenue's transaction-grain ledger per ADR-0006 within the per-figure tolerances the v1.0.0 manifest addenda named. The migration does not restate Revenue's commercial truth or compete with it; it reshapes Finance's served topology only.

Asks

Platform confirmations, none urgent, all on the same 2026-06-02 default-accept timeline:

1. Confirm that v2.0.0 publishing against the six Them OS sub-sections and 13 metrics is the right move from Platform's side, and that Platform will refloat the firewall bound to v2.0.0 at publish per the ADR-0016 mechanism. If Platform sees a reason to keep the v1.0.0 four-grouping shape as the contracted surface and treat the registry as an internal Platform encoding only, say so on this thread so Finance can hold v1.0.0 and reshape the registry-bound semantics instead.

2. Confirm that Finance's commitment to file the per-metric metadata review on this thread by 2026-06-02 is the right cross-check shape, or name a different shape Platform would rather have (a per-section pull request against lib/mart/registry.ts, a structured CSV in coordination/contracts/finance-mart/validation/, or a comment-thread review on the registry file). The deliverable is the same either way; only the surface differs.

3. Confirm that the customer_journey_audit §8.4 carve-out's encoding (grain, period attribution, exposure rule) is in scope for the metadata review, since it sits inside the contract bound even though it is not one of the 13 metrics. If Platform would rather treat the carve-out as a separate review track, say so and Finance will file the carve-out review separately.

Analytics questions

The finance-mart v2.0.0 reshape is a contract change for an artifact downstream analytics consumers read, so naming the analytics questions the new shape supports, per standards/engineering/warehouse-model-discipline.md §1:

1. What is our P&L for a given period, and how do recognized revenue, margin, and operating costs compose into it? Answered by the pnl sub-section, keyed by reporting period and sliced by the geography hierarchy. v1.0.0's revenue_recognition grouping rolls up into this; the new P&L summary and revenue concentration metrics extend it.

2. What is our unit economics posture, namely CAC, LTV, and payback, sliced by acquisition cohort and geography? Answered by the unit_economics, cac_payback, and ltv sub-sections, composed across Growth attribution and Sales journey silver facts (gated on those silver columns landing) and against Revenue's cash and ledger concepts. v1.0.0 did not contract this surface; v2.0.0 carries it because the Them OS spec requires it.

3. What is our cash runway and burn rate, and does the period's reported revenue reconcile to Revenue's transaction-grain ledger? Answered by the runway sub-section paired with the §4.6 cross-cutting reconciliation guarantee. v1.0.0's cash_position and reconciliation groupings carry forward into this question's coverage, with runway and burn rate as new metrics the v2.0.0 shape adds.

References

• memos/2026/2026-05-19-platform-mart-contract-registry-encoded.md (parent FYI, the registry encoding this memo responds to)
• memos/2026/2026-05-18-platform-finance-mart-silver-surface-and-firewall-confirmation.md (Platform's v1.0.0 firewall confirmation, the bound that flips at v2.0.0 publish)
• memos/2026/2026-05-18-finance-mart-manifest-commitment.md (Finance's v1.0.0 manifest commitment, completed)
• memos/2026/2026-05-16-revenue-finance-mart-boundary-confirmation.md (Revenue's reconciliation boundary confirmation, carrying through v2.0.0)
• memos/2026/2026-05-14-finance-mart-contract.md (the v1.0.0 contract publication memo, the thread this reshape descends from in substance)
• contracts/finance-mart/README.md (v1.0.0, the contract this reshape will bump to v2.0.0)
• contracts/warehouse-silver/README.md (v1.1.0, the silver bound the registry encoding composes over)
• ADR-0015 (Finance and Portfolio as cross-domain reporting domains, action item 5 puts the contract pen with Finance)
• ADR-0016 (Medallion warehouse data access model, the firewall mechanism that refloats at v2.0.0 publish)
• ADR-0006 (Revenue's credit-reservation-lock state machine, the transaction-grain ledger reconciliation ties back to)
• domains/finance.md (Finance quality bar, including the two-week deprecation window)
• standards/engineering/warehouse-model-discipline.md (consumer-side discipline binding finance-mart's served surface)