Re Round 10 — revenue_recognition join chain, lock_value_distribution line-item path

Ask 1 — revenue.revenue_recognition silver and person_id

No revenue_recognition silver endpoint exists today. The three live Revenue silver endpoints are deferred-release-schedule, refund-items, and ad-spend-reconciled. A revenue_recognition silver face hasn't shipped yet.

The revenue_recognitions Postgres table does not carry person_id or customer_id directly. The canonical join chain to resolve person_id is a two-hop:

revenue_recognitions.source_credit_ledger_entry_id
  → credit_ledger_entries.credit_account_id
  → credit_accounts.person_id

credit_accounts.person_id carries the canonical per_<UUID v7> identity per ADR-0002. All three tables are in @@schema("revenue").

Revenue will build the silver endpoint and flatten person_id at the API layer — the response row will carry person_id directly, so Platform's compute doesn't need to traverse the two-hop join. The endpoint will follow the keyset-pagination shape established by the other silver endpoints (cursor on id, optional since lower bound).

Revenue tracks this as a pending P3/S commitment in this memo's frontmatter.

Ask 2 — lock_value_distribution and lesson_count

revenue.order carries no denormalized lesson_count column. The orders table has: id, client_id, status, currency, amount_due_cents, amount_paid_cents, payment_collection_method, ordered_at, paid_at, timestamps. No lesson count.

Platform's compute needs to count line items from order_items (schema: revenue):

SELECT o.id AS order_id, COUNT(oi.id) AS lesson_count
FROM revenue.orders o
JOIN revenue.order_items oi ON oi.order_id = o.id
GROUP BY o.id

Each order_items row represents one line item. The quantity column records the per-item quantity (default 1); if an offering can appear in a single line item with quantity > 1, summing quantity rather than counting rows is the safer form:

SUM(oi.quantity) AS lesson_count

For lock_value_distribution (lesson count at first lock), the anchor is person_first_locks.first_credit_reservation_id → credit_reservations.credit_account_id → credit_accounts → the funding credit_ledger_entries row (type GRANT) with a non-null order_item_id → order_items.order_id → orders.id. That chain resolves the specific order that funded the credit account at first-lock time. Platform can then apply the SUM(quantity) above on that order's items.

All five tables (person_first_locks, credit_reservations, credit_accounts, credit_ledger_entries, order_items) are in @@schema("revenue").

Ask 3 — reserved_credit_liability_cents (FYI)

Acked. Option 3 (HTTP) confirmed per Round 9. No action owed at Revenue.