create-filegrc 0.5.1 → 0.6.0

package/README.md

@@ -11,7 +11,7 @@ npm run serve
 
 Setup asks for the legal organization name, the initial program lead and their organization job title and email, a security reporting address, and the program timezone. The generated Person records the lead’s actual position, while a separate dated Policy Owner Appointment owns the starter work. The generated private project includes a starter Security program, Program Readiness, a policy-driven Work Queue, Policy Events that add linked tasks, later audit preparation, evidence packets, and one dependency: `filegrc`.
 
-Creation has two layers. The six-record foundation contains workspace settings, the initial program lead, the Policy Owner Appointment, the oversight team, renderer settings, and the filegrc system of record. The default `security` starter adds the framework references, proposed policies, controls, obligations, documents, and training records. Pass `--starter foundation` when you want to stop before selecting a framework.
+Creation has two layers. The twelve-record foundation contains Workspace and Program settings, the initial program lead, two starter Appointments, the oversight Team, renderer settings, four Classifications, and the FileGRC repository Component. The default `security` starter adds Framework references, proposed Policies, Controls, Obligations, Documents, and Training records. Pass `--starter foundation` when you want to stop before selecting a Framework.
 
 For one noninteractive run, pass company and service fields together or use `--config setup.json`. The optional `setup` object defines the service boundary and management goal after installation. Use `--filegrc-package <directory>` to exercise unpublished local engine changes instead of installing the registry release. This writes a machine-local `file:` dependency, so replace it with a released version before sharing the generated workspace.
 

package/package.json

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

package/src/defaults.js

@@ -34,18 +34,18 @@ const FILEGRC_SOURCE_CONTROL_CODES = new Set([
   "VEN-02"
 ]);
 const SOURCE_FAMILIES = [
-  ["workforce", "Workforce System"],
+  ["workforce", "Workforce"],
   ["training-acknowledgement", "Training and Acknowledgements"],
-  ["identity-access", "Identity and Access Systems"],
-  ["production-change", "Production Change Systems"],
-  ["security-monitoring", "Security Monitoring Systems"],
+  ["identity-access", "Identity and Access"],
+  ["production-change", "Production Change"],
+  ["security-monitoring", "Security Monitoring"],
   ["vulnerability-management", "Vulnerability Management"],
-  ["endpoint-asset", "Endpoint Management Systems"],
+  ["endpoint-asset", "Endpoint Management"],
   ["backup-recovery", "Backup and Recovery"],
   ["vendor-management", "Vendors"],
   ["exception-finding", "Exceptions and Findings"],
   ["data-handling", "Data Protection Configuration"],
-  ["network-security", "Network Security Systems"],
+  ["network-security", "Network Security"],
   ["governance", "Governance"],
   ["risk-management", "Risk Management"]
 ];
@@ -1082,9 +1082,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
     title: `${reference}: ${name}`,
     frameworkId: FRAMEWORK_ID,
     reference,
-    applicability: "undetermined",
     description,
-    applicabilityRationale: "Confirm applicability against the selected service, scope, and auditor guidance before accepting this starter criterion.",
     tags: ["security", "common-criteria"]
   }));
   const descriptionRequirements = descriptionCriteria.map(([reference, name, description]) => ({
@@ -1093,9 +1091,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
     title: `${reference}: ${name}`,
     frameworkId: DESCRIPTION_FRAMEWORK_ID,
     reference,
-    applicability: "undetermined",
     description,
-    applicabilityRationale: "Confirm applicability against the selected service and auditor guidance before accepting this starter description criterion.",
     tags: ["description-criteria"]
   }));
   const controlRecords = controls.map((control) => ({
@@ -1113,7 +1109,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
     operationPattern: control.operationPattern,
     policyIds: control.policies,
     ...(FILEGRC_SOURCE_CONTROL_CODES.has(control.code)
-      ? { evidenceSourceIds: ["system-filegrc-program-repository"] }
+      ? { evidenceSourceComponentIds: ["component-filegrc-program-repository"] }
       : {})
   }));
   const team = {
@@ -1126,17 +1122,18 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
     chairIds: []
   };
   const programRepository = {
-    id: "system-filegrc-program-repository",
-    type: "system",
+    id: "component-filegrc-program-repository",
+    type: "component",
     title: "filegrc Program Repository",
-    status: "active",
+    status: "planned",
+    componentKind: "software",
     criticality: "high",
     ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
     description: "The Git repository that is authoritative for filegrc governance records, approvals, exceptions, findings, acknowledgements, evidence indexes, and their revision history.",
-    systemKind: "governance-system-of-record",
     environment: "Git repository",
     classificationId: "confidential",
     internetExposed: false,
+    systemUses: [],
     evidenceSourceKinds: FILEGRC_SOURCE_FAMILIES,
     evidenceOwnerIds: [POLICY_OWNER_APPOINTMENT_ID]
   };
@@ -1167,8 +1164,8 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
       title: `${title} coverage`,
       status: filegrcManaged ? "active" : "planned",
       sourceFamilyId,
-      coverageKind: filegrcManaged ? "filegrc" : "external-system",
-      scopeResourceIds: ["workspace"],
+      coverageKind: filegrcManaged ? "filegrc" : "external-component",
+      scopeResourceIds: ["program-soc-2"],
       ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
       ...(filegrcManaged ? {
         collectionCadence: "Record work when it occurs and export the complete population for the audit period.",
@@ -1180,7 +1177,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
   });
 
   const foundation = [
-    recordFile("systems", programRepository),
+    recordFile("components", programRepository),
     recordFile("teams", team)
   ];
   if (starter === "foundation") return foundation;

package/src/index.js

@@ -397,16 +397,22 @@ async function applyStarterScope(target, starter, effectiveDate) {
   const workspacePath = join(target, "data", "workspace.json");
   const workspace = JSON.parse(await readFile(workspacePath, "utf8"));
   const ids = (type) => records.filter((record) => record.type === type).map((record) => record.id);
-  await writeFile(workspacePath, `${JSON.stringify({
-    ...workspace,
+  await writeFile(workspacePath, `${JSON.stringify(workspace, null, 2)}\n`, "utf8");
+  const programPath = join(target, "data", "programs", "program-soc-2.json");
+  const program = JSON.parse(await readFile(programPath, "utf8"));
+  await writeFile(programPath, `${JSON.stringify({
+    ...program,
     frameworkIds: ids("framework"),
-    requirementIds: ids("requirement"),
+    requirementApplicability: ids("requirement").map((requirementId) => ({
+      requirementId,
+      decision: "undetermined"
+    })),
     controlIds: ids("control")
   }, null, 2)}\n`, "utf8");
 }
 
 function starterStages(starter, counts) {
-  const foundationTypes = new Set(["workspace", "renderer-settings", "person", "appointment", "team", "system"]);
+  const foundationTypes = new Set(["workspace", "program", "renderer-settings", "person", "appointment", "team", "system", "component", "classification", "information-type"]);
   const foundation = Object.entries(counts.byType)
     .filter(([type]) => foundationTypes.has(type))
     .reduce((total, [, count]) => total + count, 0);
@@ -516,13 +522,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.5.1",
+    version: "0.6.0",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.5.1",
+        version: "0.6.0",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -81,7 +81,7 @@ Use a dedicated private repository for your FileGRC workspace. The browser commi
 - In a monorepo, never include application changes in FileGRC-generated commits.
 - Treat detached and feature-branch copies as read-only unless an explicit development override is active.
 
-New workspaces use trunk repository mode with `main` as the authoritative branch and `origin` as the remote. Each browser mutation checks the whole Git worktree, fetches the remote, fast-forwards only, rechecks the edited revision, writes through the normal domain function, validates the workspace, stages only this FileGRC workspace, creates a focused commit, and pushes it. Browser onboarding commits its related workspace, system, and renderer changes together.
+New workspaces use trunk repository mode with `main` as the authoritative branch and `origin` as the remote. Each browser mutation checks the whole Git worktree, fetches the remote, fast-forwards only, rechecks the edited revision, writes through the normal domain function, validates the workspace, stages only this FileGRC workspace, creates a focused commit, and pushes it. Browser onboarding commits its related Workspace, Program, System, Component, and renderer changes together.
 
 The Repository page reports `Synced`, `Syncing`, `Not synced`, `Read-only checkout`, or `Git setup required`. Browser saves return after the validated local commit, then push in the background. Treat `Syncing` as locally durable but not yet durable on the remote, and wait for `Synced` before starting another write. A failed push keeps the local FileGRC commit and offers Retry sync when every ahead commit changes only this workspace. FileGRC never pushes an ahead commit that includes files outside this workspace, and it never merges, rebases, switches branches, resolves conflicts, or changes files outside the workspace.
 
@@ -103,9 +103,9 @@ If the installed CLI reports that this workspace uses an unsupported model, star
 npx filegrc migrate --to-model 3 --preview --json
 ```
 
-Model v1 workspaces migrate to v2 first. Review the v3 preview’s automatic, review-required, and unsupported classifications before applying it with the same options and `--yes`. The migration creates no approvals, holders, evidence, or historical dates.
+Older workspaces migrate one version at a time. Review the v4 preview’s automatic, review-required, and unsupported classifications before applying it with the same options and `--yes`. The migration creates no approvals, holders, Evidence Artifacts, or historical dates.
 
-The [model v3 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v3.md) explains the classifications, automatic changes, and required post-migration review.
+The [model v4 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v4.md) explains System classification decisions, relationship changes, and required post-migration review.
 
 Run these commands when working with records:
 
@@ -210,7 +210,7 @@ The Evidence Ready gate requires:
 3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Work Queue schedule running.
 4. Every selected Control mapped to active authoritative Systems with the required evidence source roles, current access owners, and repeatable extraction instructions in Record Markdown.
 
-Onboarding does not create External Evidence records. Complete authoritative source Systems as part of Control implementation. For every incomplete family in Program Readiness, update the Control with its authoritative evidence source Systems, then give each source the required evidence role, current access owners, and repeatable retrieval instructions in Record Markdown. Use `npx filegrc evidence-map --json` when you want only those source checks. During Step 4, create External Evidence only when a real artifact exists. Select its source System, attach or reference the result, link the Controls and operating record it supports, record its collector and classification, then have another person verify it before audit use.
+Onboarding does not create Evidence Artifacts. Complete authoritative source Components as part of Control implementation. For every incomplete family in Program Readiness, update the Control with its authoritative `evidenceSourceComponentIds`, then give each source Component the required evidence role, current access owners, and repeatable retrieval instructions in Record Markdown. Use `npx filegrc evidence-map --json` when you want only those source checks. During Step 4, create an Evidence Artifact only when a real artifact exists. Select its `sourceComponentId`, attach or reference the result, link the Controls and operating record it supports, record its collector and Classification, then have another person verify it before audit use.
 
 When the gate passes, set `workspace.candidatePeriodStart` to the date reliable evidence collection begins. Do not backdate it. `candidatePeriodStart` and `candidatePeriodEnd` express management’s target. They do not establish the final report period.
 
@@ -235,15 +235,15 @@ The audit record’s `typeOneAsOf`, `periodStart`, and `periodEnd` are the dates
 Review both evidence paths against the exact firm-agreed date or period:
 
 1. filegrc Evidence consists of dated Step 4 operating records. Complete each applicable record, link it to the Controls it supports, record the result in structured fields or Markdown, and link any external artifact needed to support that result.
-2. External Evidence consists of verified `evidence` records from authoritative Systems. Confirm the source System, audit date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
+2. Evidence Artifacts are verified `evidence` records from authoritative Components. Confirm the source Component, audit date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
 
-Audit Readiness reports coverage for both paths. The packet includes the matching filegrc records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
+Audit Readiness reports coverage for both paths. The packet includes the matching filegrc records and Markdown with Git history, plus Evidence Artifacts, retained attachments, delivery indexes, and checksums.
 
 Near the end of fieldwork, link a verified fixed-format copy of the signed management representation letter to its engagement-specific document. Date it on or after the Type 1 date or Type 2 period end. A representation that is still marked for later blocks packet delivery.
 
-Catalog each authoritative source under Systems and assign its `evidenceSourceKinds`. A third-party application is still a System because it operates controls or produces evidence. Create a separate Vendor for its provider and connect the System through `vendorId`; keep contracts, due diligence, and supplier risk on the Vendor. Name the people who can access system reports and keep extraction instructions in the System's Record Markdown. For each Type 2 population, select one source system and export the exact audit period. Split a population when different systems or queries produce its items. Link a verified `population-export` evidence record that names the same source system and stores the query or report parameters, generation time, timezone, count, completeness check, and accuracy check. A zero count still requires the source export and query. A population linked to an in-scope control cannot be marked not applicable.
+Catalog each authoritative source as a Component and assign its `evidenceSourceKinds`. A third-party application is a Component when it supports a bounded System, a Control, Evidence, or relevant operations. Create a separate Vendor for its provider and connect the Component through `vendorId`; keep contracts, due diligence, and supplier risk on the Vendor. Name the people who can access reports and keep extraction instructions in the Component's Record Markdown. For each Type 2 population, select one source Component and export the exact audit period. Split a population when different Components or queries produce its items. Link a verified `population-export` Evidence Artifact that names the same source Component and stores the query or report parameters, generation time, timezone, count, completeness check, and accuracy check. A zero count still requires the source export and query. A population linked to an in-scope Control cannot be marked not applicable.
 
-Every evidence record names its collector. Verified evidence also names its verifier and verification date. Use `sourceSystemId` for system exports, `sourceResourceIds` for filegrc records, and `sourceCommit` to bind the evidence to repository state.
+Every Evidence Artifact names its collector. Verified Evidence Artifacts also name their verifier and verification date. Use `sourceComponentId` for source exports, `sourceResourceIds` for FileGRC records, and `sourceCommit` to bind the Evidence Artifact to repository state.
 
 Preview coverage before writing output:
 
@@ -253,7 +253,7 @@ npx filegrc evidence-packet --audit audit-2026-type-2
 npx filegrc evidence-packet --audit audit-2026-type-2 --preview --require-ready
 ```
 
-The packet includes records explicitly related to the selected engagement, its systems, controls, criteria, policies, evidence, and dependencies. It does not include unrelated dated records from the workspace. A Type 2 packet adds filegrc Evidence, recurring obligation occurrences, event workflows, and management population reconciliations. Output includes a control matrix with separate filegrc Evidence and External Evidence columns, source-system index, external-evidence delivery index, population index, evidence index, committed historical source versions, and SHA-256 checksums. Output under `.filegrc/evidence-packets/` is derived and must not be hand-edited or committed.
+The packet includes records explicitly related to the selected engagement, its bounded Systems, Controls, criteria, policies, Evidence, and dependencies. It does not include unrelated dated records from the workspace. A Type 2 packet adds filegrc Evidence, recurring obligation occurrences, event workflows, and management population reconciliations. Output includes a control matrix with separate filegrc Evidence and Evidence Artifact columns, source-Component index, Evidence Artifact delivery index, population index, evidence index, committed historical source versions, and SHA-256 checksums. Output under `.filegrc/evidence-packets/` is derived and must not be hand-edited or committed.
 
 Treat a packet as ready for management delivery only when its status is `delivery-ready`, its review list is clear, and its manifest names a clean Git revision. This means filegrc's management checks passed. It does not mean the engagement team found the evidence sufficient or appropriate. The generator copies raw records, Markdown, and local fixed attachments. It never fetches external references. Reconcile `external-evidence-index.csv` to the auditor portal or other approved delivery system before telling the engagement team that submission is complete.
 

package/template/README.md

@@ -19,7 +19,7 @@ npm run serve
 
 Requires Node.js 20 or newer and Git.
 
-Existing model v2 workspaces must run `npx filegrc migrate --to-model 3 --preview --json` after installing a model v3 package. Review each automatic, review-required, and unsupported item before applying the same migration with `--yes`. Model v1 workspaces migrate to v2 first. See the [model v3 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v3.md).
+Existing model v3 workspaces must run `npx filegrc migrate --to-model 4 --preview --json` after installing a model v4 package. Review each automatic, review-required, and unsupported item, supply explicit System classification decisions where needed, then apply the same migration with `--yes`. Older workspaces migrate one model version at a time. See the [model v4 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v4.md).
 
 ## How it works
 
@@ -45,7 +45,7 @@ Detached and feature-branch checkouts are read-only in the browser by default. D
 4. **Operate the program.** Run scheduled and event-driven work, maintain risk, and retain dated evidence.
 5. **Audit.** Set up the CPA engagement, support fieldwork, and prepare the evidence packet.
 
-Control implementation includes evidence-source readiness. Use `npx filegrc program-readiness --json` to find incomplete Control or System records. `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create External Evidence during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists.
+Control implementation includes evidence-source readiness. Use `npx filegrc program-readiness --json` to find incomplete Control or Component records. `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create an Evidence Artifact during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists.
 
 The Program Overview shows what is done, what is blocked, and what to do next.
 

package/template/data/AGENTS.md

@@ -98,9 +98,9 @@ JSON is for stable metadata used by validation, relationships, filters, schedule
 
 If `guide` marks a Markdown slot recommended, fill it before treating the deliverable as complete. Keep observations and report details in the source record’s Markdown. Create a Finding only for a confirmed gap that needs its own remediation lifecycle. Create an Action Item only when follow-up needs a separate assignee, deadline, and completion proof. Set each child record’s `sourceResourceId` to the record that produced it; do not maintain reverse Finding or Action Item arrays on the source. Do not put a report’s entire variable structure into new JSON fields.
 
-When `guide` returns a collection review requirement, review the listed type-specific criteria and use `npx filegrc review-collection RESOURCE_TYPE --scaffold`. Fill the management conclusion, rationale, reviewer, and date, then preview and apply the payload. Do not invent `collectionRevision`; FileGRC calculates it from the current records and material Workspace scope. Any later change makes the confirmation stale and requires another review.
+When `guide` returns a collection review requirement, review the listed type-specific criteria and use `npx filegrc review-collection RESOURCE_TYPE --scaffold`. Fill the management conclusion, rationale, reviewer, and date, then preview and apply the payload. Do not invent `collectionRevision`; FileGRC calculates it from the current records and material Program scope. Any later change makes the confirmation stale and requires another review.
 
-Store a relationship only on its authoritative record. Control Tests store `auditId`; External Evidence stores `auditIds`; Commitments store `systemIds` and `controlIds`; Controls store `policyIds` and `requirementIds`; Risks store `controlIds`; Systems store their direct `vendorId`. Use `references` to inspect derived inbound links.
+Store a relationship only on its authoritative record. Control Tests store `auditId`; Evidence Artifacts store `auditIds`; Commitments store `systemIds` and `controlIds`; Controls store `policyIds`, `requirementIds`, `systemIds`, `componentIds`, and `evidenceSourceComponentIds`; Risks store `controlIds`; Components store their `vendorId` and `systemUses`. Use `references` to inspect derived inbound links.
 
 Use explicit business dates. Git records when a file changed, but it does not replace `occurredOn`, `scheduledFor`, `completedOn`, `approvedOn`, or similar fields.
 
@@ -110,7 +110,7 @@ Status is an assertion. Before moving a record to a completed, approved, impleme
 
 1. Run `guide RESOURCE_TYPE --json` and satisfy every conditional field.
 2. Write the actual work and conclusion in Markdown when recommended.
-3. Link source systems, evidence, risks, findings, exceptions, and actions that support the result.
+3. Link source Components, Evidence Artifacts, risks, findings, exceptions, and actions that support the result.
 4. Use the real completion or approval date.
 5. Confirm the named people performed and reviewed the work.
 
@@ -159,11 +159,11 @@ npx filegrc detach EVIDENCE_ID source-export.csv --yes --expected-revision REVIS
 
 filegrc will not delete an evidence record that still has local attachments.
 
-Never invent evidence, dates, approvals, results, people, or source-system details. If a required fact is unavailable, leave the record in a non-final state and report the missing input.
+Never invent Evidence, dates, approvals, results, people, or source-Component details. If a required fact is unavailable, leave the record in a non-final state and report the missing input.
 
 ## Implement Controls and Their Evidence Sources
 
-Finish each applicable Control and its authoritative source Systems together. Use Program Readiness as the completion check:
+Finish each applicable Control and its authoritative source Components together. Use Program Readiness as the completion check:
 
 ```sh
 npx filegrc program-readiness --json
@@ -174,11 +174,11 @@ The Control stage reports both Control implementation items and evidence-family
 1. Choose an existing System or scaffold the System that is authoritative for the family.
 2. Set the System to `active`, add the matching `evidenceSourceKinds`, and name current `evidenceOwnerIds`.
 3. Put the exact report, filters, date range, timezone, export format, and reconciliation steps in the System’s Record Markdown.
-4. Add the System ID to `evidenceSourceIds` on every Control in the family that it supports.
+4. Add the Component ID to `evidenceSourceComponentIds` on every Control in the family that it supports.
 5. Finish the Control’s owner, procedure, scope, operation pattern, mappings, and implementation date. Put every calendar or event schedule in an Obligation.
 6. Run `program-readiness --json` again and resolve every failed Control or source check before marking the Controls implemented or starting the candidate period.
 
-Use `get RESOURCE_ID --mutation` and `update` so JSON and Markdown change together. `evidence-map --json` remains available when you want only the evidence-family checks. Do not create an Evidence record while designing or implementing a Control. Create External Evidence during Step 4 only when the real export, report, screenshot, signed file, or approved external reference exists.
+Use `get RESOURCE_ID --mutation` and `update` so JSON and Markdown change together. `evidence-map --json` remains available when you want only the evidence-family checks. Do not create an Evidence Artifact while designing or implementing a Control. Create one during Step 4 only when the real export, report, screenshot, signed file, or approved external reference exists.
 
 ## Scheduled and event work
 

package/template/data/audit-populations/AGENTS.md

@@ -5,9 +5,9 @@ Use one `audit-population` for one complete Type 2 population produced by one au
 Reconcile after the period closes:
 
 1. Confirm the exact audit period and related controls.
-2. Select the cataloged source system whose `evidenceSourceKinds` covers the population.
+2. Select the cataloged source Component whose `evidenceSourceKinds` covers the population.
 3. Export the complete population with fixed parameters and timezone.
-4. Create verified `population-export` evidence with the same source system, period, query, generation time, count, completeness check, and accuracy check.
+4. Create a verified `population-export` Evidence Artifact with the same source Component, period, query, generation time, count, completeness check, and accuracy check.
 5. Link the export with `sourceEvidenceId`, name the reconciler, record the date and conclusion, and write the method and exceptions in Record Markdown.
 
 A zero count still needs its query, fixed export, and reconciliation. A population linked to an in-scope control cannot be marked not applicable.

package/template/data/audits/AGENTS.md

@@ -18,9 +18,9 @@ Preparation creates engagement-specific management documents and, for Type 2, po
 Review both evidence paths for the exact formal date or period:
 
 1. filegrc Evidence consists of dated Step 4 operating records. Complete the record, link it to the applicable Controls, record the result in its fields or Markdown, and link any external artifact needed to support that result.
-2. External Evidence consists of verified `evidence` records from other Systems. Confirm the source System, date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
+2. Evidence Artifacts are verified `evidence` records from source Components. Confirm the source Component, date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
 
-The packet compiles both paths. It includes filegrc records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
+The packet compiles both paths. It includes FileGRC records and Markdown with Git history, plus Evidence Artifacts, retained attachments, delivery indexes, and checksums.
 
 Run readiness repeatedly and fix source records. Preview the packet before writing it:
 

package/template/data/classifications/confidential.json

@@ -0,0 +1,8 @@
+{
+  "id": "confidential",
+  "type": "classification",
+  "title": "Confidential",
+  "status": "active",
+  "rank": 2,
+  "description": "Disclosure could harm the organization, a customer, or another person."
+}

package/template/data/classifications/internal.json

@@ -0,0 +1,8 @@
+{
+  "id": "internal",
+  "type": "classification",
+  "title": "Internal",
+  "status": "active",
+  "rank": 1,
+  "description": "Intended for the workforce and approved partners."
+}

package/template/data/classifications/public.json

@@ -0,0 +1,8 @@
+{
+  "id": "public",
+  "type": "classification",
+  "title": "Public",
+  "status": "active",
+  "rank": 0,
+  "description": "Approved for public release."
+}

package/template/data/classifications/restricted.json

@@ -0,0 +1,8 @@
+{
+  "id": "restricted",
+  "type": "classification",
+  "title": "Restricted",
+  "status": "active",
+  "rank": 3,
+  "description": "Disclosure or alteration could cause severe harm or trigger legal duties."
+}

package/template/data/collection-reviews/collection-review-complementary-control.json

@@ -5,6 +5,6 @@
   "status": "planned",
   "resourceType": "complementary-control",
   "scopeResourceIds": [
-    "workspace"
+    "program-soc-2"
   ]
 }

package/template/data/collection-reviews/collection-review-component.json

@@ -0,0 +1,10 @@
+{
+  "id": "collection-review-component",
+  "type": "collection-review",
+  "title": "Scoped Components review",
+  "status": "planned",
+  "resourceType": "component",
+  "scopeResourceIds": [
+    "program-soc-2"
+  ]
+}

package/template/data/collection-reviews/collection-review-framework.json

@@ -5,6 +5,6 @@
   "status": "planned",
   "resourceType": "framework",
   "scopeResourceIds": [
-    "workspace"
+    "program-soc-2"
   ]
 }

package/template/data/collection-reviews/collection-review-person.json

@@ -5,6 +5,6 @@
   "status": "planned",
   "resourceType": "person",
   "scopeResourceIds": [
-    "workspace"
+    "program-soc-2"
   ]
 }

package/template/data/collection-reviews/collection-review-system.json

@@ -1,10 +1,10 @@
 {
   "id": "collection-review-system",
   "type": "collection-review",
-  "title": "Service and system boundary review",
+  "title": "Bounded System scope review",
   "status": "planned",
   "resourceType": "system",
   "scopeResourceIds": [
-    "workspace"
+    "program-soc-2"
   ]
 }

package/template/data/collection-reviews/collection-review-vendor.json

@@ -1,10 +1,10 @@
 {
   "id": "collection-review-vendor",
   "type": "collection-review",
-  "title": "Vendor and subservice scope review",
+  "title": "Vendor inventory review",
   "status": "planned",
   "resourceType": "vendor",
   "scopeResourceIds": [
-    "workspace"
+    "program-soc-2"
   ]
 }

package/template/data/components/component-filegrc-program-repository.md

@@ -0,0 +1,9 @@
+# filegrc Program Repository
+
+This Git repository is the authoritative Component for FileGRC governance records and their revision history. It can supply the training and acknowledgement catalog, exception and finding populations, policy and document approvals, risk register and assessments, Vendor inventory and reviews, oversight records, obligation history, Policy Event workflows, and management evidence indexes.
+
+## Evidence extraction
+
+Run FileGRC from a clean commit. Use resource dates and Audit links to select the exact engagement date or period, save the query or agent instructions with the export, and retain the fixed result behind an Evidence Artifact. Record a zero count when the committed source query returns no relevant items.
+
+The repository is authoritative only for records stored here. Identity, workforce, source control, deployment, monitoring, endpoint, backup, vulnerability, and external Vendor systems remain authoritative for the activity they perform.

package/template/data/documents/document-soc2-period-completeness.md

@@ -19,7 +19,7 @@ Management reconciled every audit-population record linked to this engagement to
 | Backup failures and restoration tests | [Population ID] | [Result] |
 | Security exceptions and control findings | [Population ID] | [Result] |
 
-For a population with zero items, retain the source-system export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
+For a population with zero items, retain the source-Component export or report that produced the zero count. Describe any source limitation, omitted item, or reconciliation difference below.
 
 ## Exceptions and Source Limitations
 

package/template/data/evidence/AGENTS.md

@@ -1,8 +1,8 @@
-# External Evidence Instructions
+# Evidence Artifact Instructions
 
 An evidence record explains what a proof item is, where it came from, what period it supports, who collected it, and which records or controls it supports. The attachment alone is not enough.
 
-Do not create placeholder or collection-test Evidence. Control implementation maps Controls to complete authoritative Systems; `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create External Evidence during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists. When an operating record needs fixed supporting proof, create or update an External Evidence record and link its ID from that record. Keep new evidence as `draft` until the artifact exists. Set it to `collected` only after selecting the source System, attaching or referencing the result, and recording the source, date, classification, and collector. Set it to `verified` only after another named person checks it.
+Do not create placeholder or collection-test Evidence. Control implementation maps Controls to complete authoritative source Components; `npx filegrc evidence-map --json` remains available as a focused diagnostic. Create an Evidence Artifact during Step 4 only when a real export, report, screenshot, signed file, or approved external reference exists. When an operating record needs fixed supporting proof, create or update an Evidence Artifact and link its ID from that record. Keep it as `draft` until the artifact exists. Set it to `collected` only after selecting the source Component, attaching or referencing the result, and recording the source, date, Classification, and collector. Set it to `verified` only after another named person checks it.
 
 ## Create evidence
 
@@ -27,6 +27,6 @@ For a rendered page capture, record the route, filters, audit period, exact Git
 
 For a signed acknowledgement, bind the attestation to the exact content Git revision and store the signed file as evidence.
 
-For a `population-export`, also record the authoritative `sourceSystemId`, exact period, generation timestamp, timezone, query or report parameters, item count, completeness check, and accuracy check. A zero-item population still needs its source export and query.
+For a `population-export`, also record the authoritative `sourceComponentId`, exact period, generation timestamp, timezone, query or report parameters, item count, completeness check, and accuracy check. A zero-item population still needs its source export and query.
 
 Do not commit secrets, session data, regulated data, or personal data that may need erasure. Use an approved external reference when Git is not an appropriate store.

package/template/data/programs/program-soc-2.json

@@ -0,0 +1,37 @@
+{
+  "id": "program-soc-2",
+  "type": "program",
+  "title": "{{program_title}}",
+  "status": "planned",
+  "assuranceGoal": "none",
+  "systemIds": [],
+  "frameworkIds": [],
+  "requirementApplicability": [],
+  "controlIds": [],
+  "ownerIds": [
+    "appointment-policy-owner"
+  ],
+  "riskMethodology": {
+    "method": "5x5 likelihood and impact",
+    "likelihoodScale": [
+      "Rare",
+      "Unlikely",
+      "Possible",
+      "Likely",
+      "Almost certain"
+    ],
+    "impactScale": [
+      "Negligible",
+      "Minor",
+      "Moderate",
+      "Major",
+      "Severe"
+    ],
+    "ratingBands": {
+      "low": "1-4",
+      "medium": "5-9",
+      "high": "10-16",
+      "critical": "17-25"
+    }
+  }
+}

package/template/data/workspace.json

@@ -1,38 +1,9 @@
 {
-  "dataModelVersion": "3",
+  "dataModelVersion": "4",
   "id": "workspace",
   "type": "workspace",
   "title": "{{program_title}}",
   "organizationName": "{{company_name}}",
   "timezone": "{{timezone}}",
-  "description": "{{program_description}}",
-  "riskMethodology": {
-    "method": "5x5 likelihood and impact",
-    "likelihoodScale": [
-      "Rare",
-      "Unlikely",
-      "Possible",
-      "Likely",
-      "Almost certain"
-    ],
-    "impactScale": [
-      "Negligible",
-      "Minor",
-      "Moderate",
-      "Major",
-      "Severe"
-    ],
-    "ratingBands": {
-      "low": "1-4",
-      "medium": "5-9",
-      "high": "10-16",
-      "critical": "17-25"
-    }
-  },
-  "classificationDefinitions": {
-    "public": "Approved for public release.",
-    "internal": "Intended for the workforce and approved partners.",
-    "confidential": "Disclosure could harm the organization, a customer, or another person.",
-    "restricted": "Disclosure or alteration could cause severe harm or trigger legal duties."
-  }
+  "description": "{{program_description}}"
 }

package/template/package.json

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

package/template/data/systems/system-filegrc-program-repository.md

@@ -1,9 +0,0 @@
-# filegrc Program Repository
-
-This Git repository is the system of record for filegrc governance records and their revision history. It can supply the training and acknowledgement catalog, exception and finding populations, policy and document approvals, risk register and assessments, vendor inventory and reviews, oversight records, obligation history, Policy Event workflows, and management evidence indexes.
-
-## Evidence Extraction
-
-Run filegrc from a clean commit. Use resource dates and audit links to select the exact engagement date or period, save the query or agent instructions with the export, and retain the fixed result behind an evidence record. Record a zero count when the committed source query returns no relevant items.
-
-The repository is authoritative only for records stored here. Identity, workforce, source-control, deployment, monitoring, endpoint, backup, vulnerability, and external vendor-management systems remain authoritative for the activity they perform.