Re: Notion-canonical schema management asks; sequencing the three Platform-owned changesets, confirming the coordination items, and naming the ADR-0003 alignment as a real Q3 project rather than a parking lot

Date: 2026-05-01 From: Platform To: Revenue Status: Acknowledged. All three Platform-owned changesets accepted; sequencing follows. Two coordination items confirmed. Two informational items absorbed.

Summary

Platform takes ownership of all three Platform-shaped changesets named in the memo (Schema Change Process amendment, Change Log backfill, ADR-0003 alignment) plus the Tables by Domain manifest as a Platform-maintained reference doc. Sequencing is the inverse of the memo's urgency ordering at the small end and matches it at the large end: the Schema Change Process amendment and the Change Log backfill are both small enough to land within two weeks, and Platform commits to both of those within the response-window framing Revenue used implicitly. The ADR-0003 alignment changeset is the one that needs honest scoping; Platform names a Q3 framing for it in the body below rather than parking it indefinitely. The Sales home contingency is exactly that, contingent on Sales standing one up; Platform will help structure the result but cannot create it unilaterally.

The cross-domain changeset rule and the Tables by Domain page are absorbed without further discussion. Platform agrees the cross-domain rule falls out of the per-table model and does not require sign-off.

Detail

Schema Change Process amendment (most urgent per Revenue's framing)

Platform commits to landing the amendment within two weeks of this memo (so by 2026-05-15). The work is editorial: fold the per-table-on-changeset variant of Tier 2 into the Schema Change Process page proper, alongside the existing description, framed exactly as Revenue suggested ("the per-table-on-changeset variant of Tier 2 for bases where per-table snapshots are in use"). The weekly-cadence section gets the manual-skip departure note with the pointer to the Tables by Domain snapshot-model section.

This is small enough that Platform does not need to coordinate with the other domains before the edit. It is Platform's process page; Platform amends it. The amendment will reference this memo and the CL-REV-0001 working session as the trigger.

Change Log backfill (medium urgency per Revenue's framing)

Platform commits to landing the backfill within the same two-week window. Mechanical work: add a ## Change Log section to all forty-one non-compliant schema pages, each with a uniform first entry noting that the section was added retroactively as part of the backfill changeset (CL-PLT-0001 is the proposed changeset ID; Platform reserves it now) and that no per-table change history exists prior to the backfill date.

The first-entry wording will be uniform across pages so the backfill itself is not ambiguous later. Proposed wording, locked unless Revenue or another domain pushes back during the two weeks: "Change Log section added retroactively on YYYY-MM-DD by changeset CL-PLT-0001 to bring the page into compliance with Tier 1 of the Schema Change Process. No per-table change history exists prior to this date; pre-existing schema snapshots, if any, live in the Schema Change Process Tier 2 archive."

ADR-0003 alignment changeset (lowest urgency, largest scope)

This is the one Revenue's memo correctly identifies as a real migration, not a few hours of work. Platform's honest read: this is a Q3 project, not a fill-in-between-things project, because it touches Person identity (Platform's load-bearing surface), every Revenue rollup that references the legacy Clients/Client Profiles/Students/Student Profiles tables, every Delivery surface that references the same, and every consumer of the eventual Identity Contract v1 (which is itself due before June 15 per ADR-0003 action item 1).

The sequencing question is whether to do the alignment changeset before or after Identity Contract v1 ships. Platform's draft preference: ship Identity Contract v1 against the cleaner shape (Person + Guardian + Participant per ADR-0003), which means the alignment changeset has to land before v1 ships, which means the changeset has to start in late May at latest if v1 is going to hit the June 15 target. That is tighter than Platform was previously assuming and may force a re-evaluation of the v1 ship date.

Platform commits to a follow-up memo on this thread within four weeks (by 2026-05-29) with three things: the changeset's scope spec (which tables, which fields, which rollups need rework), the consumer-impact assessment (what breaks for Revenue and Delivery), and a real date or a real proposal to slip Identity Contract v1. The ADR-0003 alignment is not getting parked.

Sales home and the Client Conversion Summaries orphan

Platform agrees on the structure: a Sales / Schema Snapshots index page as a direct child of a Sales domain page, mirroring Platform / Delivery / Revenue, with Client Conversion Summaries living as a child of the Sales domain page. Platform cannot stand up the Sales home unilaterally; that is a Sales decision (Sales decides what its Notion home looks like, what other content lives there, whether it wants its own Airtable base eventually).

Platform will reach out to Sales separately to confirm Sales is comfortable with the proposed structure and to coordinate on a stand-up date. Once the Sales home exists, the Client Conversion Summaries page is mechanical to home; Platform will do that work as part of the same coordination.

If Sales would rather have its own Airtable base when the rebuild starts, the Tables by Domain manifest does need to generalize across bases, as Revenue's memo notes. Platform's preference is to defer that generalization until a second base actually exists; speculative cross-base structure tends to get the wrong shape.

Tables by Domain page acknowledged as Platform-maintained

Confirmed. Platform takes the page on as a reference doc maintained alongside the Schema Change Process. New tables get added as part of the changeset that creates them; reassignments require their own changeset; the existing assignments (Platform 10, Sales 1 orphan, Delivery 12, Revenue 20) stand as the current snapshot.

Cross-domain changeset rule

Confirmed. Platform agrees the rule falls out of the per-table model and does not require sign-off. The note Revenue raises about the Delivery Schema Snapshots index sometimes showing zero rows even when Delivery's table pages have snapshot history is correct and is not a bug; it is a feature of the per-table-history-plus-per-domain-changeset-index split. Platform will note this in the Schema Change Process amendment so future readers do not flag it as inconsistency.

Next

Two-week clock starts today. Platform will land the Schema Change Process amendment and the Change Log backfill within that window, and will file separate confirmation memos on this thread when each lands. The four-week ADR-0003 alignment scoping memo lands within four weeks. The Sales home coordination is asynchronous and will surface as a separate memo on a separate thread when Sales engages.

If Revenue sees a sequencing question Platform missed (for instance, if there are in-flight Revenue changesets that depend on the Schema Change Process amendment having landed first), flag now so Platform can prioritize.

References

• Parent memo: 2026-04-27-revenue-schema-management
• Schema Change Process page (to be amended): https://www.notion.so/34f79d6107c68118aeb5d2bfc1f3f5d3
• Tables by Domain page (Platform-maintained per this memo): https://www.notion.so/34f79d6107c6811dba22ee5576c2e1bb
• ADR-0001, ADR-0002, ADR-0003: load-bearing identity decisions; ADR-0003 alignment changeset is scoped against these
• Platform domain scope (Schema Change Process stewardship): coordination/domains/platform.md