Apply approved retention rules to new services; release 0.19.2

docs/architecture.md

@@ -819,3 +819,27 @@ Operating ownership can use existing implemented Control procedures and approved
 Tokenized resource navigation projects the same snapshot-scoped workflow section used by root navigation. Previously, detail requests repeated full synchronous workflow and Git-history work on the HTTP thread after the shared worker had already calculated it. Detail now joins or reuses that worker calculation, retains each caller's deadline and verifies live file and Git signatures before responding. The 10-second request budgets remain unchanged. Tests cover warm computation bounds, concurrent cold requests, recovery after an earlier caller deadline, transient Git failures and invalidation after source changes.
 
 Finalized operating proof freezes explicit completion, Evidence, Exception and Attestation relationships at the owner's first finalized Git revision. Evidence source-resource links describe context, so current Controls, inventories and ongoing reviews can evolve without rewriting that proof. Source links to Evidence, Exceptions and Attestations still protect those proof records. Mutation guards and historical validation share the same traversal; historical validation resolves the traversal from committed records rather than current links. Evidence packets retain committed source versions alongside current context.
+
+## Retention rule applications
+
+The independent Data Retention Schedule review binds rule semantics and governing
+sources. Its original committed revision remains verifiable after routine service
+inventory growth. Owner-reviewed `retention-application` records separately bind
+an approved rule to service data use, purpose and practical disposal. They name the
+actual Policy Owner, authority and review date, retain the committed independent
+approval, and confirm the full cutoff, disposition, holds and duties.
+
+The shared domain verifies the original approval before comparing rule semantics.
+Changed rule notes, Markdown or governing decisions require independent review.
+New or materially changed service uses require an explicit applicability decision;
+provider or agreement changes invalidate prior disposal-fit review. Service labels
+and unrelated metadata do not change the fit. Applications do not change original
+approved rows and do not add approval requirements for equivalent service mappings.
+Periodic independent schedule review exposes the current applications for oversight.
+
+Model v13 adds these optional records in FileGRC 0.19.2. Shared validation rejects
+adoption until the consumer manifest and lockfile support them, including generic
+CRUD and hand-edited source files. Hosted runtimes must upgrade before repositories
+publish applications. Preview binds current service facts; save rejects changed
+bindings. Retirement records the actual owner, date and reason, preserves the
+original decision and cannot reactivate an old application.

docs/data-model.md

@@ -728,6 +728,16 @@ Key format: `namespace`.
 | --- | --- | --- | --- |
 | `amendmentId` | id | Yes | References: `nonmaterial-amendment` |
 
+### `retention-application-confirmations`
+
+| Property | Type | Required | Notes |
+| --- | --- | --- | --- |
+| `purposeMatches` | boolean | Yes | The record purpose and boundaries fit the approved rule. |
+| `cutoffMatches` | boolean | Yes | The same cutoff event applies. |
+| `dispositionFeasible` | boolean | Yes | The full disposition can be carried out in this service. |
+| `holdsPreserved` | boolean | Yes | All approved holds and required records remain protected. |
+| `noConflictingDuties` | boolean | Yes | No legal, contractual or other duty conflicts with this application. |
+
 ## Common fields
 
 | Field | Type | Required | Meaning |
@@ -1618,6 +1628,41 @@ Record Markdown: available when needed as an implicit companion file.
 | `confirmations` | object (`nonmaterial-amendment-confirmations`) | No |  |
 | `withdrawnProposalId` | id | No | References: `reporting-route-set` |
 
+#### `retention-application`
+
+An owner decision applying one unchanged independently approved retention rule to additional services. It preserves the original schedule approval and never changes the approved rule.
+
+Instructions: Apply the complete unchanged independently approved rule to actual services after owner review of purpose, cutoff, disposal, holds and duties.
+
+Policy basis: Apply the complete approved rule, including record purpose, cutoff, period, disposition and holds. Matching a duration alone is insufficient. New categories, conflicting duties, unsupported disposal or any changed rule require normal independent schedule approval.
+
+Timing: Review applicability when the service data use or disposal capability changes and include applications in periodic independent retention oversight. Use apply-retention-rule to scaffold exact bindings. Retire an obsolete application and record a new decision; preserve history. Requires a committed repository dependency and lockfile for FileGRC 0.19.2 or newer in the 0.19 line.
+
+Path: `data/retention-applications/<id>.json`
+
+Record Markdown: available when needed as an implicit companion file.
+
+| Field | Type | Required | Notes |
+| --- | --- | --- | --- |
+| `status` | enum | Yes | Values: `active`, `retired` |
+| `ruleId` | id | Yes | Approved rule References: `retention-schedule-item` |
+| `ruleRevision` | string | Yes | Exact rule decision |
+| `approvalId` | id | Yes | Independent schedule approval References: `collection-review` |
+| `approvalRevision` | string | Yes |  |
+| `programId` | id | Yes | References: `program` |
+| `scopeResourceIds` | array of id | Yes | Services covered References: `system`, `component`, `vendor` |
+| `informationTypeIds` | array of id | Yes | References: `information-type` |
+| `reviewedScopeRevisions` | object (`string-map`) | Yes |  |
+| `reviewedById` | id | Yes | References: `person` |
+| `authorityAppointmentId` | id | Yes | References: `appointment` |
+| `reviewedOn` | date | Yes |  |
+| `purpose` | string | Yes | Record purpose and boundaries |
+| `rationale` | string | Yes |  |
+| `disposalImplementation` | string | Yes | How the complete rule will operate |
+| `confirmations` | object (`retention-application-confirmations`) | Yes |  |
+| `approvalCommit` | string | Yes | Committed independent approval |
+| `statusTransition` | object (`status-transition`) | Conditional | Required when `status` is `retired`. Allowed when `status` is `retired`. |
+
 ### Risk
 
 #### `exception`

package.json

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

packages/create-filegrc/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.19.1",
+  "version": "0.19.2",
   "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.19.1",
+    version: "0.19.2",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.19.1",
+        version: "0.19.2",
         dependencies: { filegrc: versionRange }
       }
     }

packages/create-filegrc/template/AGENTS.md

@@ -264,3 +264,15 @@ Model v13 checks completed full-program risk assessment, current workforce train
 Use `npx filegrc amend-nonmaterial RESOURCE_ID --scaffold` for a model-supported administrative label correction or verified equivalent reporting email alias. Fill the actual owner, scoped authority, rationale, time and supporting fixed evidence; preview with `--preview`, then save with `--yes` and commit. The source record, Markdown and independent approval remain unchanged. `get RESOURCE_ID --workflow --json` includes the current administrative view and amendment IDs. The browser exposes the same action on supported record pages.
 
 Email aliases require the owner to confirm the same underlying destination, recipients, access boundaries, availability and dependencies. This decision does not independently verify its Evidence or create a new independent approval. A matching proposed alias successor may be withdrawn atomically. Never use an amendment for changed commitments, recipients, access, scope, retention periods, cadence, deadlines, governed prose or evidence conclusions. Keep those normal reviews. Preserve committed amendments and the observations and captures supporting them; correct them through a subsequent amendment. Later independent verification may add verification metadata without rewriting those observations.
+
+## Applying approved retention rules to services
+
+The independent schedule review governs the complete retention rule. Adding a
+service does not require another independent approval when the owner can apply
+that exact rule without changing its category, purpose, cutoff, period, disposition,
+holds or required duties. Use `filegrc apply-retention-rule RULE_ID --scaffold`, fill
+an honest owner applicability decision, preview it, then save the preview with
+`--yes`. The browser offers **Apply approved rule** on an active rule. Keep original
+approved rows and approval metadata unchanged. Use normal independent review for
+material changes or when no existing rule fully fits. Include service applications
+in periodic independent retention oversight.

packages/create-filegrc/template/package.json

@@ -1,6 +1,6 @@
 {
   "name": "{{project_name}}",
-  "version": "0.19.1",
+  "version": "0.19.2",
   "private": true,
   "description": "filegrc workspace for a SOC 2 program",
   "type": "module",

packages/filegrc/README.md

@@ -131,3 +131,29 @@ Choose a tested runtime in the repository's line that supports its model and the
 Patch releases must preserve readable records and generated records across their compatibility line. An incompatible record format, model requirement, or API contract needs a new compatibility line and an explicit upgrade path, rather than relaxed validation.
 
 Model v13 adds scoped source retrieval, proof preservation, baseline execution and operating ownership checks. Existing v12 programs explicitly preview `npx filegrc migrate --to-model 13 --preview --json` before applying the upgrade. Use `npx filegrc program-readiness --json` for the missing facts, existing records, tangible checks and read/scaffold/preview/save commands shared with the browser. Active programs repair current gaps using actual dates and preserve historical activation and Control oversight. Reuse unchanged approvals; new or changed governed content, schedules and retention decisions use their existing independent reviews. See the [model v13 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v13.md).
+
+### Apply an approved retention rule
+
+Independent review approves the retention decision: data category and purpose,
+cutoff, period, disposition, holds and required duties. The Policy Owner can apply
+that complete unchanged rule to another service without approving the schedule
+again. Matching a duration alone does not establish a fit.
+
+```sh
+npx filegrc apply-retention-rule RULE_ID --scaffold > application.json
+# Fill the service scope, existing Information Types, actual owner authority,
+# purpose, disposal implementation and every fit confirmation.
+npx filegrc apply-retention-rule RULE_ID application.json --preview > reviewed-application.json
+npx filegrc apply-retention-rule RULE_ID reviewed-application.json --yes
+```
+
+Preview binds the current service facts. Save rejects a changed service, rule or
+approval instead of silently updating the decision. The browser's **Apply approved
+rule** action uses the same checks. Original rule and approval records stay intact;
+new applications retain the actual owner, date and exact approved source. Review
+applications during periodic independent schedule oversight.
+
+Use normal independent schedule review for a new category or purpose, a changed
+cutoff or period, conflicting duties, unsupported disposal, or a material exception.
+An application cannot supply missing independent approval. Retire an obsolete
+application and record a new owner decision when the service facts change.