# YSD-14206 — Institutional deployment policy terms

- **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.