Compliance Pack
What this screen is for
This screen shows one compliance pack: the definition of one regulatory regime or governance framework as this release declares it. It is where you read what the regime says, which primary sources it comes from, and which of its points the platform evaluates from its own state. Nothing here can be edited; a pack changes only with a release.
A pack gates nothing. What your tenants may use is decided by the edition, the compliance lock and tenant narrowing, with or without packs.
What must exist first
The screen opens from a resolved pack chip on the License screen, in system context.
- The permission to read the platform algorithm catalogue shows the pack. The same roles that read the licence hold it.
- A pack identifier this release defines. An identifier from a licence issued under an earlier release may resolve to no pack; its chip on the License screen has no link, so this screen is not reached for it.
Decisions you make here
Reading the summary and the sources
The header gives the pack's title, its kind (a regime, or governance), its version and a short summary. The version is the day of the change, with a suffix such as .2 for a later change on the same day; it changes whenever any source, control, calendar entry, context statement or not-offered entry of the pack changes.
Each source is listed with its edition as printed, its publication date at the precision the source prints, and a link to the primary document. A source marked DRAFT is a draft: every calendar entry taken from it is a draft statement, and the pack never presents it as final.
Reading the controls
Each control names the source section it transcribes, the source's own force (SHALL, SHOULD, MAY, SHOULD NOT, SHALL NOT) and how it could be evaluated. Platform-observable means the platform's own state is enough; Attested by the customer means the evidence lies outside the platform, such as an organisation-wide inventory or procurement.
A satisfied platform-observable control does not mean the regime is satisfied, and the screen says so. This screen shows the definition only; how your tenants' keys stand against it is on the evaluation screen.
Reading the calendar
The calendar is grouped by use category, in the source's own words. For a Deprecated after, Disallowed after, Not to be used alone after or Recommended until milestone, the date shown is the last day the earlier state holds. For Supported and preferred by and Used exclusively by, it is an inclusive deadline. When the source gives only the year a state begins, as in "from 2027", the new state holds from the first day of that year, whatever the milestone.
A date the source gives as a year is shown as the year. A milestone the source states without a date shows the source's wording instead, and a context statement that names no date shows none. This screen compares no date with today: nothing is shown here as past, pending or in effect. The evaluation reads the calendar on a reference day.
Entries scoped by risk, as in the EU roadmap, carry their risk class; classifying your own use cases is not done here.
Reading what is not offered
Not offered lists what the regime requires or recommends that the platform does not offer, with its source reference. An identifier entry names one parameter set, with the source's spelling beside it; a class entry names a group and says why it is absent.
How it relates to other screens
The licence names the packs it was issued with, and each resolved chip there opens this screen.
Compliance Evaluation shows the pack evaluated across tenants: