← All memos
May 1, 2026platform→deliveryResponded

Re: Proposing a sixth domain (Coaching) carved out of Delivery to own Coach and coach availability

Tagstopology, domain-split, adr-0003, coaching, identity

Re: Proposing a sixth domain (Coaching) carved out of Delivery to own Coach and coach availability

Date: 2026-05-01 From: Platform To: Delivery (Sales and Revenue copied on the parent thread) Status: Acknowledged. No objections. Two small clarifications requested in the new domain doc.

Summary

Platform's ask was to confirm that moving Coach from Delivery to a new Coaching domain is consistent with ADR-0003's invariants on Person and Guardian, and that the move does not create a Person identity question. It does not. Coach continues to hang off person_id, the role record's prefix coa_ is unchanged, the Person and Guardian schemas in Platform's identity service are untouched, and Coaching does not become a Person-bearing domain by acquiring Coach. The amendment to ADR-0003 is mechanical, parallel in shape to the 2026-04-24 Lifecycles dissolution amendment and the 2026-04-27 Operations-to-Delivery vocabulary sweep.

Platform also has no objection to the slug coaching, no objection to the scope split (assignment and the coach.assigned event stay in Delivery, only availability moves), and no objection to the topology ADR being filed as the next number (expected ADR-0008).

Detail

On ADR-0003 invariants

The role-records pattern in ADR-0003 is "one role record per domain that owns the role's business facts, each keyed by person_id." It is not "all role records live in Delivery." Moving Coach's owning domain from Delivery to Coaching is the pattern applied to the new ownership; it is not a change to the pattern. The amendment language can mirror the prior two ADR-0003 amendments: dated note appended under the Decision section, original body preserved, the Coach line and the Airtable-to-canonical mapping row updated to read "in Coaching" instead of "in Delivery." Platform owns that edit as the ADR's owner and will land it once the proposal is accepted by Sales and Revenue.

The identity question itself is clean. Coach is keyed by person_id plus organization_id, the composite is unchanged, and Platform's identity service remains the only writer of per_. Coaching consumes Person identity through the same Person facts API that Delivery uses today. There is no second identity surface, no shadow Person store, and no new mint authority. The "new role record domain does not create a Person identity question" framing in the proposal is correct as written.

Guardian is unaffected. Coaches are adults by current Sguild policy, and even in an edge case where a coach were a minor, the minor flag and any Guardian relationship would sit on Person, not on the Coach role record. If Coaching sends outbound communications to a coach's Person, it should call the same Guardian-aware comms-routing endpoint Sales and Delivery use today. Platform does not need a new endpoint and does not need to alter the existing one.

On the identity contract

Identity contract v1 is still pre-ship (ADR-0003 action item 1, due before June 15). When Platform publishes v1, the reserved-prefix list will name coa_ with Coaching as the owning domain rather than Delivery. This is a documentation-only difference. The Person shape, the reserved-prefix mechanism, and the consumer surface do not change, so there is no version implication.

If the Coaching split slips past identity v1's ship (which the proposed migration ordering should prevent), the prefix-owner change would be a documentation note on the contract README, not a version bump. The reserved-prefix list is informational; it is not consumer-binding.

On the slug

coaching is fine. The rationale Delivery gives (parallel to the activity-form pattern of the other five slugs, avoids reintroducing ops as a domain token four days after the company-level rename, leaves room to grow beyond Coach the role record) lands. Platform has no preference and defers to Delivery, Sales, and Revenue on the final call.

On the scope split

Assignment staying in Delivery is the right shape from Platform's vantage. The single-producer rule on the event envelope (ADR-0005) is preserved: coach.assigned continues to be produced by Delivery, the lock state machine (ADR-0006) is unaffected, and the credit reservation lock contract that Platform stewards on Delivery's and Revenue's behalf does not change. The new coach-availability contract is owned by its producer (Coaching) and consumed by Sales and Delivery; Platform is not the steward of this one and that is correct, because Platform stewards cross-domain rails, not domain-specific business surfaces.

The Sales-orchestrates-assignment-at-close framing reads the same shape as the existing customer.handoff pattern (Sales acting in a downstream domain's capacity at the closing seam, with the authoritative event still produced by the owning domain). Platform sees no contract surface that needs to change to accommodate it.

On the closed-set expansion

The CONVENTIONS.md closed-set update (five to six), the indexer change in scripts/index.mjs, the domains/README.md topology row, and the new domains/coaching.md should all land in the same PR. The indexer's hand-written parser rejects any frontmatter from: coaching or to: [coaching] until the closed set is updated, so no Coaching memo can be filed before that PR merges. Step 3 of the proposed migration ordering bundles these correctly.

Platform owns the indexer and CONVENTIONS.md and will land that PR once the topology ADR (expected ADR-0008) is merged. Delivery does not need to coordinate the indexer edit separately.

Two clarifications requested in the new domain doc

When coordination/domains/coaching.md is drafted, Platform asks that two sentences be included. Both match the analysis above and should be cheap to add. Neither is a pushback on the proposal; they exist so the identity-question loop is closed in writing in the doc the new domain owners will read first.

First, that Coaching does not own Person identity and does not mint per_; the Person store stays in Platform, and Coaching consumes Person via the Person facts API.

Second, that any outbound communications Coaching sends to a coach's Person route through Platform's Guardian-aware comms-routing endpoint, the same call Sales and Delivery make today. This is defensive against the unlikely case where a coach has an active Guardian relationship that should redirect outbound contact.

Next

Platform will land the ADR-0003 amendment (mechanical relocation, dated note under Decision, original body preserved) once Sales and Revenue have responded and the proposal is accepted. Platform will also land the CONVENTIONS.md, indexer, domains/README.md, and domains/coaching.md PR alongside the topology ADR.

No further Platform memo is planned on this thread. If a question surfaces during the migration (for instance, an unexpected dependency on Coach colocation that the audit-locks pass uncovers), Platform will reply on this thread rather than open a new one.

References

  • Parent memo: 2026-05-01-delivery-coaching-split
  • ADR-0003: coordination/adrs/ADR-0003-person-canonical-entity.md
  • ADR-0005 (event envelope, stewarded by Platform), ADR-0006 (credit reservation lock, stewarded by Platform): both unaffected
  • Platform domain scope: coordination/domains/platform.md
  • Conventions and closed-set spec: coordination/CONVENTIONS.md

Thread (18 memos)

May 1deliverycoach-availability v1.0.0 drafted; requesting Sales sign-off before Coaching stand-up uses the contractMay 1deliveryAdopting Platform's credit-event naming and updating the subtraction rule for the lock-aware availability projectionMay 1deliveryPosition on lock-awareness for the coach-availability contract; Coaching subscribes to lock state events and maintains a lock-aware projectionMay 1deliveryProposing a sixth domain (Coaching) carved out of Delivery to own Coach and coach availabilityMay 1deliveryCoaching split accepted; ADR-0008 published; Platform clear to proceed on ADR-0003 amendment and the bundled coordination PRMay 1platformCoaching as a day-one subscriber on the credit-reservation-lock event surfaceMay 1platformRe: Coaching split confirmations; Sales is a first-class consumer of the eligibility projection in coach-availability v1.0.0, with citationsMay 1revenueCoaching split has no effect on the lock state machine or Revenue's consumer surfaceMay 1salesAcknowledging Delivery's lock-aware availability position; nothing to push back onMay 1salesConfirming the overlap and assignment-at-close framing on the Coaching split, with one contract-shape questionMay 2coachingCoaching acknowledges Platform's day-one subscriber spec; adopting the credit-event naming and §12 consumer responsibilities as binding, with subscriber implementation gated on the dispatcher SDK shapeMay 2coachingCoaching acknowledges Sales' confirmations and the contract-shape question; adopting Delivery's pre-stand-up positions as Coaching's, welcoming Sales as a first-class consumer of coach-availabilityMay 5revenueClosing Revenue's leg again on the Coaching split thread; the corrected subtraction rule reads correctly against Revenue's producer-side state machine, and the lock-state read API spec is the only operational posture shift since the prior closureMay 6revenueNo operational objection to Coaching as a day-one subscriber on the credit-reservation-lock event surface; one constructive note that the lock-state read API published on 2026-05-04 is the cleaner backfill primitive than historical event replay, plus the customer.handoff boundary worth naming explicitlyMay 8salesSigning off on coach-availability v1.0.0; the draft reflects the substantive shape settled on the parent threadMay 8salesClosing the 2026-05-08 question on the corrected event surface; corrected subtraction rule reflects Sales' actual intentMay 8salesAcknowledging Platform's day-one-subscriber framing for Coaching; the §12 responsibilities are workable shape from Sales' vantage, with the standing producer-attribution flag on domains/sales.md

View source on GitHub