Require preactivation channel and schedule-set review; release 0.17.0

AGENTS.md

@@ -87,7 +87,7 @@ Treat headless use as a first-class interface. An agent with no FileGRC context
 
 ## Data rules
 
-The active authoritative model registry is the standalone `packages/filegrc/model/v11.json`. Models v1 through v10 are published and frozen for migrations, compatibility tests, and reference. Breaking changes belong in a new model version with an explicit migration path. Keep the active model, starter data, generated docs, and tests in sync.
+The active authoritative model registry is the standalone `packages/filegrc/model/v12.json`. Models v1 through v11 are published and frozen for migrations, compatibility tests, and reference. Breaking changes belong in a new model version with an explicit migration path. Keep the active model, starter data, generated docs, and tests in sync.
 
 - Use UTF-8 JSON for structured records and Markdown for long-form content.
 - Store canonical long-form Markdown beside its structured JSON record. FileGRC derives companion names from the JSON location and Markdown slot; do not store those paths in record data.

docs/architecture.md

@@ -769,3 +769,9 @@ Core derives an optional FileGRC Autopilot recommendation after Step 3 implement
 The persistent renderer entry links to the Autopilot setup guide when no valid connection marker exists. An always-visible Autopilot button sits in a compact explanatory box above the organization area at the bottom of the sidebar and opens setup before signup or the dashboard when a valid `.filegrc/hosted-automation.json` v1 marker exists. Configured repositories omit the page-level hosted offers and connection descriptions. Shared domain logic exposes configured local state through the browser, recommendations, and `filegrc automation`; live status remains unknown. Dashboard links include an optional normalized GitHub origin repository hint, never a raw remote or credential. Invalid and unsupported markers produce warnings without blocking local work. Removing the marker does not disconnect service. The hosted service reads Git content and sends follow-up while the local app is closed. Its dashboard manages connections, billing, confirmed person links, and delivery health. Core has no hosted credentials, dependencies, or automatic policy writes. Program contacts remain in Git; the service database holds notification settings, Person-to-Slack links, credentials, and operational delivery state. Source systems and local users still perform and record the work.
 
 At the Step 3 cutover, `program-path --next` names FileGRC Autopilot as `step.nextAction` and `primaryRecommendation`. `secondaryAction` names Continue to content activation without Autopilot and preserves the required activation action, context, and commands. The recommendation remains outside readiness calculations. Step 4 retains the prominent recommended offer beside the Work Queue for later opt-in, while `step.nextAction` continues to name operating work. The shared operating recommendation is discoverable through text and JSON `obligations` and `workflow` output, with the local Work Queue as the continuation path. Both Step 3 and Step 4 explain that owner reminders continue when the local app is closed, with email first and optional Slack escalation. They use the same blue gradient hero treatment; neither tracks a clicked link as setup completion.
+
+## Pre-activation review in model v12
+
+Reporting Channel Set proposals require committed independent approval during Step 1. Step 3 checks the approved revision, live support, and exact effective interval at content cutover. The same derived reporting check runs in activation planners and validation.
+
+Each Program has an exact-revision Obligation Collection Review. Its complete population includes linked active schedules, unresolved proposals, and retired duplicates. Per-schedule decisions distinguish adopted rules, adopted replacements, retired schedules, and intentional inapplicability. Pending alternative rule proposals need explicit exclusion. Changes to schedules, rules, selected scope, or governing content invalidate this approval; the approved-to-active content transition preserves its design binding. Ordinary setup Collection Reviews retain their existing historical confirmation semantics.

docs/data-model.md

@@ -1,8 +1,8 @@
 # GRC Data Model
 
-<!-- Generated from packages/filegrc/model/v11.json. Do not edit by hand. -->
+<!-- Generated from packages/filegrc/model/v12.json. Do not edit by hand. -->
 
-Model version: `11`
+Model version: `12`
 
 Model v11 lets Control owners record implementation directly and moves Control oversight into periodic, Git-bound collection reviews. Independent Policy, Document, and Training approvals remain unchanged.
 
@@ -162,8 +162,8 @@ Relationship fields use the named groups below. The registry expands each group
 | Group | Resource types |
 | --- | --- |
 | `accountable-party` | `person`, `team`, `appointment` |
-| `collection-review-population` | `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control` |
-| `appointment-scope` | `workspace`, `person`, `service-account`, `team`, `system`, `asset`, `document`, `evidence`, `obligation`, `obligation-event`, `framework`, `requirement`, `commitment`, `complementary-control`, `control`, `control-test`, `finding`, `exception`, `action-item`, `policy`, `policy-review`, `attestation`, `meeting`, `training`, `risk`, `risk-assessment`, `vendor`, `vendor-review`, `access-grant`, `access-review`, `vulnerability`, `vulnerability-scan`, `incident`, `exercise`, `backup-test`, `penetration-test`, `data-request`, `audit`, `audit-population`, `audit-request`, `source-coverage`, `control-activity`, `retention-schedule-item`, `requirement-mapping`, `obligation-rule`, `obligation-occurrence`, `reporting-route`, `reporting-route-set` |
+| `collection-review-population` | `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control`, `obligation` |
+| `appointment-scope` | `workspace`, `person`, `service-account`, `team`, `system`, `asset`, `document`, `evidence`, `obligation`, `obligation-event`, `framework`, `requirement`, `commitment`, `complementary-control`, `control`, `control-test`, `finding`, `exception`, `action-item`, `policy`, `policy-review`, `attestation`, `meeting`, `training`, `risk`, `risk-assessment`, `vendor`, `vendor-review`, `access-grant`, `access-review`, `vulnerability`, `vulnerability-scan`, `incident`, `exercise`, `backup-test`, `penetration-test`, `data-request`, `audit`, `audit-population`, `audit-request`, `source-coverage`, `control-activity`, `retention-schedule-item`, `requirement-mapping`, `obligation-rule`, `obligation-occurrence`, `reporting-route`, `reporting-route-set`, `program` |
 | `obligation-scope` | `workspace`, `person`, `appointment`, `service-account`, `team`, `system`, `asset`, `document`, `framework`, `requirement`, `commitment`, `complementary-control`, `control`, `policy`, `training`, `risk`, `vendor`, `access-grant`, `vulnerability`, `incident`, `audit`, `source-coverage`, `retention-schedule-item`, `requirement-mapping`, `component`, `information-type` |
 | `obligation-template` | `person`, `system`, `asset`, `document`, `control`, `policy`, `training`, `retention-schedule-item`, `requirement-mapping` |
 | `completion-record` | `access-grant`, `asset`, `control`, `document`, `evidence`, `control-test`, `finding`, `exception`, `action-item`, `policy-review`, `policy`, `attestation`, `meeting`, `risk-assessment`, `risk`, `vendor`, `vendor-review`, `access-review`, `vulnerability-scan`, `incident`, `exercise`, `backup-test`, `penetration-test`, `data-request`, `audit-population`, `audit-request`, `source-coverage`, `control-activity`, `retention-schedule-item`, `requirement-mapping` |
@@ -188,6 +188,7 @@ FileGRC derives record issues, but it cannot infer that management finished an a
 | `information-type` | Information Type inventory | `complete`, `zero-population` | Review near-duplicate names and choose one canonical Information Type only after confirming they mean the same thing. Retire superseded records through a reviewed migration that rewrites every relationship. Confirm every active Information Type has an approved classification and a retention schedule item or an explicit management-review prompt. |
 | `retention-schedule-item` | Data Retention Schedule | `complete`, `zero-population` | Confirm the owner completed every row proposal, then review the Data Retention Schedule document, its Markdown, and every proposed row as one revision. Confirm schedule coverage across the Systems, Components, Vendors, source families, logs, backups, audit records, and FileGRC records the organization actually uses. Confirm every proposed item has a reviewed cutoff, retention period, disposition action, owner, and exact source revisions; keep undecided behavior planned. |
 | `control` | Control implementation oversight | `complete` | Perform this one setup review after Controls, evidence sources, and Obligations are ready, before management activates the approved program content. Confirm owners, procedures, scope, operation patterns, mappings, Obligations, and authoritative evidence sources remain current. Record follow-up work separately when the review finds a gap. |
+| `obligation` | Obligation schedule set | `complete`, `zero-population` | Review every active and proposed schedule and every pending rule revision against the governing requirements. Confirm adopted rules cover recurring and event work, owners, populations, deadlines, and the intended cutover. Name adopted replacements or explain exclusions; do not activate unused starter proposals. |
 
 ## Relationship constraints
 
@@ -663,6 +664,17 @@ Key format: `namespace`.
 | `reason` | string | Yes |  |
 | `evidenceIds` | array of id | Yes | References: `evidence` |
 
+### `schedule-disposition`
+
+| Property | Type | Required | Notes |
+| --- | --- | --- | --- |
+| `obligationId` | id | Yes | References: `obligation` |
+| `disposition` | enum | Yes | Values: `adopted`, `replaced`, `retired`, `inapplicable` |
+| `ruleId` | id | No | References: `obligation-rule` |
+| `replacementObligationIds` | array of id | Conditional | References: `obligation` Required when `disposition` is `replaced`. |
+| `excludedRuleIds` | array of id | No | References: `obligation-rule` |
+| `rationale` | string | Yes |  |
+
 ## Common fields
 
 | Field | Type | Required | Meaning |
@@ -968,7 +980,7 @@ Record Markdown: available when needed as an implicit companion file.
 | Field | Type | Required | Notes |
 | --- | --- | --- | --- |
 | `status` | enum | Yes | Values: `planned`, `active`, `retired` |
-| `resourceType` | enum | Yes | Reviewed resource type Values: `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control` Values come from the `collectionReviews` registry. |
+| `resourceType` | enum | Yes | Reviewed resource type Values: `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control`, `obligation` Values come from the `collectionReviews` registry. |
 | `decision` | enum | Conditional | Values: `complete`, `zero-population`, `externally-managed`, `not-applicable` Required when `status` is `active`. |
 | `rationale` | string | Conditional | Required when `status` is `active`. |
 | `reviewedByIds` | array of id | Conditional | Reviewed by References: `person` Required when `status` is `active`. |
@@ -981,7 +993,8 @@ Record Markdown: available when needed as an implicit companion file.
 | `supersedesId` | id | No | References: `collection-review` |
 | `coverage` | object (`coverage-period`) | No | Reviewed temporal coverage |
 | `knowledgeCutoffAt` | timestamp | No | Knowledge cutoff |
-| `populationResourceIds` | array of id | No | Reviewed population Relation group: `collection-review-population`. References: `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control` |
+| `populationResourceIds` | array of id | No | Reviewed population Relation group: `collection-review-population`. References: `person`, `framework`, `vendor`, `system`, `complementary-control`, `component`, `classification`, `information-type`, `retention-schedule-item`, `control`, `obligation` |
+| `scheduleDecisions` | array of object (`schedule-disposition`) | Conditional | Schedule decisions Required when `resourceType` is `obligation` and `status` is `active` and `decision` is `complete`. Allowed when `resourceType` is `obligation`. |
 
 #### `requirement-mapping`
 
@@ -1075,7 +1088,7 @@ Record Markdown: available when needed as an implicit companion file.
 | `status` | enum | Yes | Values: `planned`, `active`, `ended` |
 | `appointmentKind` | string (id) | Yes | Appointment kind |
 | `holderId` | id | Conditional | Holder References: `person` Required when `status` is one of `active`, `ended`. |
-| `scopeResourceIds` | array of id | Yes | Scope Relation group: `appointment-scope`. References: `workspace`, `person`, `service-account`, `team`, `system`, `asset`, `document`, `evidence`, `obligation`, `obligation-event`, `framework`, `requirement`, `commitment`, `complementary-control`, `control`, `control-test`, `finding`, `exception`, `action-item`, `policy`, `policy-review`, `attestation`, `meeting`, `training`, `risk`, `risk-assessment`, `vendor`, `vendor-review`, `access-grant`, `access-review`, `vulnerability`, `vulnerability-scan`, `incident`, `exercise`, `backup-test`, `penetration-test`, `data-request`, `audit`, `audit-population`, `audit-request`, `source-coverage`, `control-activity`, `retention-schedule-item`, `requirement-mapping`, `obligation-rule`, `obligation-occurrence`, `reporting-route`, `reporting-route-set` |
+| `scopeResourceIds` | array of id | Yes | Scope Relation group: `appointment-scope`. References: `workspace`, `person`, `service-account`, `team`, `system`, `asset`, `document`, `evidence`, `obligation`, `obligation-event`, `framework`, `requirement`, `commitment`, `complementary-control`, `control`, `control-test`, `finding`, `exception`, `action-item`, `policy`, `policy-review`, `attestation`, `meeting`, `training`, `risk`, `risk-assessment`, `vendor`, `vendor-review`, `access-grant`, `access-review`, `vulnerability`, `vulnerability-scan`, `incident`, `exercise`, `backup-test`, `penetration-test`, `data-request`, `audit`, `audit-population`, `audit-request`, `source-coverage`, `control-activity`, `retention-schedule-item`, `requirement-mapping`, `obligation-rule`, `obligation-occurrence`, `reporting-route`, `reporting-route-set`, `program` |
 | `startsOn` | date | Conditional | Required when `status` is one of `active`, `ended`. |
 | `endsOn` | date | Conditional | Required when `status` is `ended`. |
 | `appointedByIds` | array of id | No | Appointed by References: `person` |

docs/upgrading-to-model-v12.md

@@ -0,0 +1,31 @@
+# Upgrade to model v12
+
+Model v12 requires management to review the complete Obligation schedule set before activating program content. It also requires independent Reporting Channel Set approval in Step 1 and checks channel usability and effective coverage at Step 3 cutover.
+
+Commit the current v11 workspace first so existing activation history remains retrievable. Preview the migration, then apply the same target:
+
+```sh
+npx filegrc migrate --to-model 12 --preview --json
+npx filegrc migrate --to-model 12 --yes --json
+```
+
+The migration changes only the Workspace model version. It preserves content, approvals, operating rules, historical occurrences, and prior Collection Reviews. It does not infer adoption or exclusion decisions. Existing operation remains recorded, while readiness exposes missing reviews. Older workspaces migrate one version at a time.
+
+For each Program, inspect its Controls, governing content, linked Obligations, and all active and proposed rules. Commit the reviewed source records, then scaffold the review:
+
+```sh
+npx filegrc review-collection obligation --program PROGRAM_ID --scaffold > schedules.json
+npx filegrc review-collection obligation --program PROGRAM_ID schedules.json --preview --json
+npx filegrc review-collection obligation --program PROGRAM_ID schedules.json --yes --json
+```
+
+Fill each `scheduleDecisions` entry with a rationale and one disposition:
+
+- `adopted`: the active schedule and approved rule cover the work at cutover. Name the current rule-chain head as `ruleId` for rule-based schedules; the exact review also covers its approved predecessors at their effective intervals. Name `ruleId` and explicitly list unused pending rule proposals in `excludedRuleIds`.
+- `replaced`: name adopted `replacementObligationIds` covering the same selected Controls and required event. The original must be proposed or retired.
+- `retired`: the schedule is a retired duplicate with its recorded lifecycle reason.
+- `inapplicable`: explain why the proposed or retired schedule does not apply to this Program.
+
+The review needs an independent active Person, today's workspace-local date, and the exact displayed `expectedCollectionRevision`. It covers active rules as well as proposals. A changed schedule, rule, governing requirement, or selected scope requires another review before activation. Content activation itself does not reopen the schedule review.
+
+Do not activate every starter proposal. Resolve the intended schedules and exclusions, finish Control oversight, then preview `activate-content` with the intended effective date. Reporting channels need a committed independent approval of the exact proposal and must be usable and effective when the governing requirement starts. Approval alone does not establish operational readiness.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "filegrc-monorepo",
-  "version": "0.16.36",
+  "version": "0.17.0",
   "private": true,
   "workspaces": [
     "packages/filegrc",

packages/create-filegrc/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.16.36",
+  "version": "0.17.0",
   "description": "Create a filegrc workspace for a SOC 2 program",
   "license": "MIT",
   "repository": {

packages/create-filegrc/src/index.js

@@ -524,13 +524,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.16.36",
+    version: "0.17.0",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.16.36",
+        version: "0.17.0",
         dependencies: { filegrc: versionRange }
       }
     }