Disciplines · Proposals

YSD-14206 — Institutional deployment policy terms

A school, studio, or enterprise deploying the study workspace must operate under a policy covering local processing, retention, minors, educator access, audit, export, account closure, and data residency.

6sections2 minread
Markdown source
On this page
  • Status: approved (2026-08-14)
  • Priority: EXT — non-blocking (the adoption gate refuses an unstated policy, so nothing ships on a default)
  • Decision owner: @GreyChimp
  • Drafted: 2026-08-11 by Claude Code (Opus 5)
  • Approval: approved as recommended by @GreyChimp on 2026-08-14; outcome recorded in decision-log.json; review by 2027-08-14

Question#

A school, studio, or enterprise deploying the study workspace must operate under a policy covering local processing, retention, minors, educator access, audit, export, account closure, and data residency. Which of those terms does this product DECIDE, and which does it require each institution to state for itself?

The two are different products. Deciding them centrally means one set of terms every customer accepts and one legal review; requiring them per institution means the customer's own counsel sets the terms and the product's job is to refuse an institution that has not set them.

Recommendation#

Require them per institution, and refuse to operate on an unstated policy. The product decides the SHAPE (eight dimensions, every one mandatory, with floors such as the audit-retention minimum and the minor-data lane) and the institution decides the VALUES. A term this product invented on a customer's behalf would be a term nobody with standing over that customer's learners had agreed to.

Options considered#

  • One central policy every institution accepts — rejected: data residency and minors are jurisdictional, and a single set of terms is wrong somewhere.
  • Optional dimensions with product defaults — rejected: a default retention period is precisely the proposed default this programme refuses to treat as approval, and the institution that never looked would never know it had one.
  • Per-institution and mandatory — recommended.

Consequences#

  • Every institution completes all eight dimensions before any of its learners can be served; there is no partial adoption.
  • The product carries no institutional terms of its own, so an institution's counsel reviews its own values rather than negotiating ours.
  • Onboarding is longer, and the failure mode is a blocked institution rather than a silently mis-configured one.

Machine-enforced outcome#

The eight dimensions are a closed register and adoption throws InstitutionalPolicyError naming every unstated or non-conforming dimension, so an institution cannot be served under a policy it has not written.

Control in force#

Approval settles WHOSE terms these are, and the refusal it authorises was already the only behaviour available: INSTITUTIONAL_POLICY_DIMENSIONS names exactly the eight dimensions the checklist item lists, nothing in the product supplies a value for any of them, and adoptInstitutionalControls collects every policy issue together with every control issue and refuses the whole set — so an institution learns all of what it has not written, not the first thing.

What changes with the signature is the standing of the silence. Before it, a product carrying no institutional terms was an unfinished product; after it, that absence is the decision: a term this product invented on a customer's behalf would be a term nobody with standing over that customer's learners had agreed to. An institution that has stated no policy is refused, and the refusal now has a reason behind it rather than a gap.