@x12i/memorix-format 2.2.0 → 2.2.2

package/README.md

@@ -1,20 +1,25 @@
 # @x12i/memorix-format
 
-Memorix **product** record format — profiles and conventions on top of
+Memorix **product** record format — open-bucket conventions and migrate tooling layered on
 [`@x12i/memorix-base-format`](https://www.npmjs.com/package/@x12i/memorix-base-format).
 
 | Package | Owns |
 |---|---|
 | `@x12i/memorix-base-format` | Fixed skeleton: `recordId`, `concept`, `data`, `_…`; unnamed open buckets; ContentTypeMeta |
-| `@x12i/memorix-format` | Memorix open-bucket meanings, `associated*` rules, snapshot SCOPE, built-in profiles |
+| `@x12i/memorix-format` | Known open-bucket meanings, `associated*` rules, snapshot SCOPE, built-in profiles, **migrate** CLI |
 
-Product meta-metadata is packaged under [`meta/`](./meta/) (open buckets, content types, association conventions, profiles). Managed-descriptor inventory lives in `meta/inventory/` and is not format law.
+**Object types belong in Catalox descriptors, not here.** Format docs and examples use abstract names (`items`, `groups`, `locations`, `documents`) so domain packs are never confused with format law.
 
-Migrate older envelopes with:
+Product meta lives under [`meta/`](./meta/). Managed-descriptor inventory in `meta/inventory/` is not format law.
 
-```bash
-npx memorix-format migrate ./records/ --out=./clean/
-```
+Normative: [docs/memorix-format-requirements.md](./docs/memorix-format-requirements.md). Narrative: [docs/memorix-format.md](./docs/memorix-format.md).
+
+## Layering
+
+1. Base envelope (identity / core / underscore / open).
+2. Product open buckets when present: `analytics`, `enrichment`, `insights`, `associated*`.
+3. **SCOPE:** full open-bucket surface primarily on **snapshots**; other content types keep substance in `.data` unless ContentTypeMeta opts in.
+4. Readers / human projection **omit** root `_…` and `concept._extIdentifier` by default; keep `recordId` for joins.
 
 ## Install
 
@@ -23,6 +28,27 @@ npm install @x12i/memorix-format
 # pulls @x12i/memorix-base-format
 ```
 
+## Abstract snapshot example
+
+```json
+{
+  "recordId": "rec-item-1",
+  "concept": {
+    "_extIdentifier": {
+      "kind": "sku",
+      "sku": "SKU-100",
+      "key": "sku:SKU-100"
+    },
+    "title": "Blue widget"
+  },
+  "data": { "sku": "SKU-100", "color": "blue" },
+  "associatedData": [{ "locationCode": "WH-A", "qty": 12 }],
+  "analytics": { "linkedLocations": { "total": 1 } },
+  "insights": { "priority": { "level": "high", "confidence": 0.9 } },
+  "_system": { "state": "active" }
+}
+```
+
 ## SDK
 
 ```ts
@@ -33,14 +59,12 @@ import {
   snapshotsContentTypeMeta,
 } from "@x12i/memorix-format";
 
-// Product validation (base + ASSOC/SCOPE + optional profile)
 validateMemorixRecord(record, {
   profile: "snapshots",
-  objectType: "vulnerabilities",
+  objectType: "items",
   contentType: "snapshots",
 });
 
-// Base only (no product vocabulary)
 validateMemorixBaseRecord(record);
 classifyRootKey("associatedData"); // "open"
 ```
@@ -48,13 +72,44 @@ classifyRootKey("associatedData"); // "open"
 ## CLI
 
 ```bash
-npx memorix-format validate ./record.json --profile=snapshots --object-type=assets
+npx memorix-format validate ./record.json --profile=snapshots --object-type=items
 npx memorix-format validate ./dir/ --content-type=events
 npx memorix-format profiles
 npx memorix-format docs memorix-format-requirements.md
 ```
 
-## Migration from 1.0.0
+## Migrate (recommended transform)
+
+Present-tense format only. Transform exports / sample JSON; **live Mongo apply is a separate ops checklist**.
+
+```bash
+# Dry-run (stdout summary; validates after transform)
+npx memorix-format migrate ./export-dir/ --content-type=snapshots
+
+# Write cleaned files
+npx memorix-format migrate ./export-dir/ --out=./clean-dir/
+
+# Overwrite in place after validation passes
+npx memorix-format migrate ./records.json --in-place
+```
+
+Defaults applied by migrate:
+
+- `concept.identifier` → `concept._extIdentifier` (`identifierKey` → `key`)
+- root `identity` / `lifecycle` / `sourceFacts` / `index` removed (lifecycle events folded into `_system.lifecycle`)
+- root `_graphRuns` / `_jobTypeRuns` → under `_system`
+- `_system.state` set to `active` when missing (maps old `lifecycle.status` when present)
+
+Writers set `_system.state: "active"` on new records. Pipeline format enforce defaults to **hard** (`MEMORIX_FORMAT_ENFORCE=warn` to soften during cutover).
+
+### Runbook
+
+1. Dry-run against an export or package examples.
+2. Write `--out` and re-validate.
+3. Only then apply to Mongo under ops change control (not part of this package’s default workflow).
+
+## Related
 
-See [CHANGELOG.md](./CHANGELOG.md). Envelope validation moved to base-format;
-this package no longer pretends product bucket names are part of the base law.
+- Base envelope SOT: [`@x12i/memorix-base-format`](https://www.npmjs.com/package/@x12i/memorix-base-format)
+- Associations: [docs/association-format.md](./docs/association-format.md)
+- Changelog: [CHANGELOG.md](./CHANGELOG.md)

package/docs/association-format.md

@@ -15,9 +15,9 @@ Record-to-record association is always resolved from **snapshot record to snapsh
 3. Use the matched target snapshot's `recordId` to fetch non-snapshot content (`discovery`, `analysis`, `decisions`, etc.).
 4. Copy flat `content.data` into `associated<ObjectType><ContentType>` on the source snapshot.
 
-The snapshot resolves the link; embedded content is always fetched **after** snapshot match by `recordId` (or equivalent link field such as `concept.identifier.recordId` or `data.sourceRecordId`).
+The snapshot resolves the link; embedded content is always fetched **after** snapshot match by `recordId` (or equivalent link field such as `concept._extIdentifier.recordId` or `data.sourceRecordId`).
 
-**Never join a source snapshot directly to a non-snapshot content collection by business keys** (for example `vulnerabilities-snapshots.data.assetIp` → `vulnerabilities-discovery.data.assetIp`). Same-object associations still match snapshots first, then fetch content by matched snapshot `recordId`.
+**Never join a source snapshot directly to a non-snapshot content collection by business keys** (for example `findings-snapshots.data.sku` → `findings-discovery.data.sku`). Same-object associations still match snapshots first, then fetch content by matched snapshot `recordId`.
 
 ---
 
@@ -64,7 +64,7 @@ Same copy forms as above, but candidates are **sorted by importance** then **cap
 
 Example: `associatedTopVulnerabilitiesAnalysis`
 
-**Importance** comes from the linked object type’s descriptor `importanceIndicator` (e.g. vulnerabilities → `data.severity`), or from the association rule’s `rankBy` override.
+**Importance** comes from the linked object type’s descriptor `importanceIndicator` (e.g. findings → `data.severity`), or from the association rule’s `rankBy` override.
 
 **Default cap:** `5` (`DEFAULT_TOP_ASSOCIATED_ITEMS`). Override per rule with `maxItems`.
 
@@ -80,11 +80,11 @@ Example: `associatedTopVulnerabilitiesAnalysis`
     "order": "desc"
   },
   "match": {
-    "collection": "vulnerabilities-snapshots",
-    "joinPaths": ["data.assetIp"]
+    "collection": "findings-snapshots",
+    "joinPaths": ["data.sku"]
   },
   "content": {
-    "collection": "vulnerabilities-analysis",
+    "collection": "findings-analysis",
     "linkPaths": ["data.sourceRecordId", "recordId"]
   },
   "payload": { "source": "target.data", "format": "v2" }
@@ -153,7 +153,7 @@ Rules:
 
 Copies a root property from the associated **snapshot** record (not a separate content collection).
 
-Example: `associatedVulnerabilitiesGroupsSnapshotsAnalytics` — copies `analytics` from `vulnerabilities-groups-snapshots`.
+Example: `associatedVulnerabilitiesGroupsSnapshotsAnalytics` — copies `analytics` from `item-groups-snapshots`.
 
 ```json
 {
@@ -175,7 +175,7 @@ When `system.include` is true, the item is wrapped as `{ _system, value }`. Pref
 - Presets: `.operational/analytics-rollups/presets/*.json`
 - Runner: `scripts/memorix-2.0-migrate/patches/run-analytics-rollups.mjs`
 
-Use the **same join keys** as association presets (`assetIp`, `name`↔`vulnerabilityName`, CIDR). Writing `analytics` on the target is a rollup; copying another record’s `analytics` into an `associated*SnapshotsAnalytics` array is still an association (form 2 above).
+Use the **same join keys** as association presets (`sku`, `name`↔`vulnerabilityName`, CIDR). Writing `analytics` on the target is a rollup; copying another record’s `analytics` into an `associated*SnapshotsAnalytics` array is still an association (form 2 above).
 
 ### 2b. Enrichment association
 
@@ -183,9 +183,9 @@ Use the **same join keys** as association presets (`assetIp`, `name`↔`vulnerab
 
 Copies the linked **snapshot** root `enrichment` object **flat** (same shape as content associations: fields beside optional `_system`, not wrapped in `value`).
 
-`enrichment` is an envelope bucket on snapshots (CVSS, EPSS, KEV, compositeScore, …) — **not** a separate `*-enrichment` content-type collection.
+`enrichment` is an envelope bucket on snapshots (external feed values as received) — **not** a separate `*-enrichment` content-type collection.
 
-Example: `associatedVulnerabilitiesGroupsEnrichment` on `vulnerabilities-snapshots`.
+Example: `associatedVulnerabilitiesGroupsEnrichment` on `findings-snapshots`.
 
 ```json
 {
@@ -210,7 +210,7 @@ Example: `associatedVulnerabilitiesGroupsEnrichment` on `vulnerabilities-snapsho
     "includeRecordId": false
   },
   "target": {
-    "collection": "vulnerabilities-groups-snapshots",
+    "collection": "item-groups-snapshots",
     "joinPaths": ["data.name"]
   }
 }
@@ -219,8 +219,8 @@ Example: `associatedVulnerabilitiesGroupsEnrichment` on `vulnerabilities-snapsho
 Rules:
 
 - Omit the property when no linked snapshot has a non-empty `enrichment` object.
-- Do not invent a `vulnerabilities-groups-enrichment` collection for this form.
-- Naming helper: `buildAssociatedPropertyName({ form: "enrichment", objectType: "vulnerabilities-groups" })`.
+- Do not invent a `item-groups-enrichment` collection for this form.
+- Naming helper: `buildAssociatedPropertyName({ form: "enrichment", objectType: "item-groups" })`.
 
 ### 3. Concepts association
 
@@ -294,7 +294,7 @@ Strip `_system` when presenting associated content to humans, LLMs, or downstrea
 
 ## Identifier and identity matching
 
-Prefer the linked snapshot's `identity` or `concept.identifier`:
+Prefer the linked snapshot's `identity` or `concept._extIdentifier`:
 
 ```json
 { "identity": "group-name:Domain Admins" }
@@ -306,25 +306,25 @@ Prefer the linked snapshot's `identity` or `concept.identifier`:
 }
 ```
 
-Canonical location is `concept.identifier`. Root `identifier` / `identity` are accepted when present.
+Canonical location is `concept._extIdentifier`. Root `identifier` / `identity` are accepted when present.
 
-Generate identity strings deterministically: join identifier values in order with `:` (e.g. `assetIp:10.100.18.64`).
+Generate identity strings deterministically: join identifier values in order with `:` (e.g. `sku:10.100.18.64`).
 
-Association rules declare join paths in `sourceJoinPaths` and snapshot match paths in `match.joinPaths` (or legacy `target.joinPaths` for snapshot-only rules). Content fetch rules add `content.linkPaths` that reference the matched snapshot `recordId`. v2 rules should target `concept.identifier` or generated `identity` where possible.
+Association rules declare join paths in `sourceJoinPaths` and snapshot match paths in `match.joinPaths` (or legacy `target.joinPaths` for snapshot-only rules). Content fetch rules add `content.linkPaths` that reference the matched snapshot `recordId`. v2 rules should target `concept._extIdentifier` or generated `identity` where possible.
 
 Associator request shape for content associations:
 
 ```json
 {
-  "sourceJoinPaths": ["data.assetIp"],
+  "sourceJoinPaths": ["data.sku"],
   "match": {
-    "collection": "vulnerabilities-snapshots",
-    "joinPaths": ["data.assetIp", "concept.identifier.assetIp", "recordId"]
+    "collection": "findings-snapshots",
+    "joinPaths": ["data.sku", "concept._extIdentifier.sku", "recordId"]
   },
   "content": {
-    "collection": "vulnerabilities-discovery",
+    "collection": "findings-discovery",
     "contentType": "discovery",
-    "linkPaths": ["concept.identifier.recordId", "data.sourceRecordId", "recordId"]
+    "linkPaths": ["concept._extIdentifier.recordId", "data.sourceRecordId", "recordId"]
   }
 }
 ```
@@ -365,7 +365,7 @@ Process:
 
 1. Start from `users-snapshots` record.
 2. Read join values from `data.securityGroups`.
-3. Match against `security-groups-snapshots` via `concept.identifier` / identity.
+3. Match against `security-groups-snapshots` via `concept._extIdentifier` / identity.
 4. Use matched snapshot `recordId` to fetch `security-groups-analysis` records.
 5. Copy each analysis record's `data` flat into `associatedSecurityGroupsAnalysis`.
 
@@ -383,7 +383,7 @@ Result:
       "_system": {
         "association": {
           "fromProperty": "data.securityGroups",
-          "toProperty": "concept.identifier",
+          "toProperty": "concept._extIdentifier",
           "associatedAt": "2026-07-08T09:00:00.000Z"
         }
       },
@@ -414,41 +414,41 @@ New associations should be added as registry entries + presets using v2 naming a
 
 Snapshot-mediated flow:
 
-1. Read source `vulnerabilities-snapshots.data.assetIp`.
-2. Match target `vulnerabilities-snapshots` by snapshot paths (`data.assetIp`, `concept.identifier.assetIp`, `identity`, `recordId`).
+1. Read source `findings-snapshots.data.sku`.
+2. Match target `findings-snapshots` by snapshot paths (`data.sku`, `concept._extIdentifier.sku`, `identity`, `recordId`).
 3. Take matched target snapshot `recordId`.
-4. Fetch `vulnerabilities-discovery` / `vulnerabilities-decisions` by record-id link (`concept.identifier.recordId`, `data.sourceRecordId`, or root `recordId`).
+4. Fetch `findings-discovery` / `findings-decisions` by record-id link (`concept._extIdentifier.recordId`, `data.sourceRecordId`, or root `recordId`).
 5. Copy flat `content.data` into `associatedVulnerabilitiesDiscovery` / `associatedVulnerabilitiesDecisions`.
 
 | Property | Match collection | Content collection | Join key |
 |----------|------------------|--------------------|----------|
-| `associatedVulnerabilitiesDiscovery` | `vulnerabilities-snapshots` | `vulnerabilities-discovery` | `data.assetIp` → snapshot → `recordId` |
-| `associatedVulnerabilitiesDecisions` | `vulnerabilities-snapshots` | `vulnerabilities-decisions` | `data.assetIp` → snapshot → `recordId` |
+| `associatedVulnerabilitiesDiscovery` | `findings-snapshots` | `findings-discovery` | `data.sku` → snapshot → `recordId` |
+| `associatedVulnerabilitiesDecisions` | `findings-snapshots` | `findings-decisions` | `data.sku` → snapshot → `recordId` |
 
-Target source collection: `vulnerabilities-snapshots` (`MEMORIX_EVENTS_DB`).
+Target source collection: `findings-snapshots` (`MEMORIX_EVENTS_DB`).
 
 Refresh rule keys:
 
-- `vulnerabilities.vulnerabilities.discovery.by-assetIp`
-- `vulnerabilities.vulnerabilities.decisions.by-assetIp`
+- `findings.findings.discovery.by-sku`
+- `findings.findings.decisions.by-sku`
 
 ### Pilot: asset-side vulnerability analysis (v2)
 
-Snapshot-mediated flow (source is **assets**, not vulnerabilities):
+Snapshot-mediated flow (source is **items**, not findings):
 
-1. Read source `assets-snapshots.data.assetIps` (also `data.assetIp`, `data.ip_address`).
-2. Match `vulnerabilities-snapshots` by `data.assetIp` / `concept.identifier.assetIp`.
+1. Read source `items-snapshots.data.skus` (also `data.sku`, `data.ip_address`).
+2. Match `findings-snapshots` by `data.sku` / `concept._extIdentifier.sku`.
 3. Take matched snapshot `recordId`.
-4. Fetch `vulnerabilities-analysis` by record-id link.
+4. Fetch `findings-analysis` by record-id link.
 5. Copy flat `content.data` into `associatedVulnerabilitiesAnalysis` on the asset snapshot.
 
 | Property | Match collection | Content collection | Join key |
 |----------|------------------|--------------------|----------|
-| `associatedVulnerabilitiesAnalysis` | `vulnerabilities-snapshots` | `vulnerabilities-analysis` | `data.assetIps` → snapshot `data.assetIp` → `recordId` |
+| `associatedVulnerabilitiesAnalysis` | `findings-snapshots` | `findings-analysis` | `data.skus` → snapshot `data.sku` → `recordId` |
 
-Target source collection: `assets-snapshots` (`MEMORIX_ENTITIES_DB`).
+Target source collection: `items-snapshots` (`MEMORIX_ENTITIES_DB`).
 
-Refresh rule key: `assets.vulnerabilities.analysis.by-assetIp`
+Refresh rule key: `items.findings.analysis.by-sku`
 
 ---
 

package/docs/memorix-format-additions.md

@@ -58,7 +58,7 @@ type MemorixSnapshotRecord = {
 
 This is the rich, readable, consumption-friendly version of the object.
 
-Other content types under the same object type do not need to carry all of these blocks. Memorix already stores records by object type and content type, for example `assets-snapshots` or `vulnerabilities-snapshots`.
+Other content types under the same object type do not need to carry all of these blocks. Memorix already stores records by object type and content type, for example `items-snapshots` or `findings-snapshots`.
 
 So the rule is:
 
@@ -81,15 +81,15 @@ Not every collection under an object type should look like a full snapshot.
 For example:
 
 ```txt id="evq5gl"
-assets-snapshots
-assets-events
-assets-facts
-assets-chunks
-assets-history
-assets-profiles
+items-snapshots
+items-events
+items-facts
+items-chunks
+items-history
+items-profiles
 ```
 
-Only `assets-snapshots` needs the full record surface.
+Only `items-snapshots` needs the full record surface.
 
 Other content types should have the required Memorix structure, but not unnecessary blocks.
 
@@ -141,7 +141,7 @@ For a CVE record:
 ```json id="lqeccc"
 {
   "data": {
-    "cveId": "CVE-2022-29464",
+    "docId": "DOC-9",
     "severity": "critical",
     "description": "Unrestricted file upload vulnerability in WSO2 products.",
     "publishedAt": "2022-04-18"
@@ -161,9 +161,9 @@ These are facts about the CVE itself.
 
 It is not the record’s native truth, but it is very useful for consumption.
 
-For example, a CVE record may need to show the assets affected by that CVE.
+For example, a CVE record may need to show the items affected by that CVE.
 
-Those assets are not part of the CVE itself, so they should not live in `data`.
+Those items are not part of the CVE itself, so they should not live in `data`.
 
 But consumers still need them.
 
@@ -175,12 +175,12 @@ So they belong in `associatedData`.
     "affectedAssets": [
       {
         "assetName": "prod-api-01",
-        "assetIp": "10.100.18.64",
+        "sku": "10.100.18.64",
         "recordId": "entity:asset:10.100.18.64"
       },
       {
         "assetName": "prod-db-02",
-        "assetIp": "10.100.18.65",
+        "sku": "10.100.18.65",
         "recordId": "entity:asset:10.100.18.65"
       }
     ]
@@ -188,7 +188,7 @@ So they belong in `associatedData`.
 }
 ```
 
-This gives consumers the useful joined view without pretending that affected assets are native CVE fields.
+This gives consumers the useful joined view without pretending that affected items are native CVE fields.
 
 ### Rule
 
@@ -209,15 +209,15 @@ It is used when the record has links to lists of other records, and Memorix want
 For example:
 
 ```txt id="omk77f"
-CVE -> affected assets
-asset -> related vulnerabilities
+CVE -> affected items
+asset -> related findings
 document -> exposed users
 user -> accessible sensitive files
 group -> member users
 policy -> affected resources
 ```
 
-If a CVE is linked to many affected assets, then `analytics.affectedAssets` contains numbers about that list.
+If a CVE is linked to many affected items, then `analytics.affectedAssets` contains numbers about that list.
 
 ```json id="uerbc6"
 {
@@ -285,7 +285,7 @@ Bad:
     "affectedAssets": [
       {
         "assetName": "prod-api-01",
-        "assetIp": "10.100.18.64"
+        "sku": "10.100.18.64"
       }
     ]
   }
@@ -300,7 +300,7 @@ Good:
     "affectedAssets": [
       {
         "assetName": "prod-api-01",
-        "assetIp": "10.100.18.64"
+        "sku": "10.100.18.64"
       }
     ]
   },
@@ -333,15 +333,15 @@ It is the place for judgments, assessments, analysis, scores, conclusions, recom
       "level": "critical",
       "score": 92,
       "confidence": 0.84,
-      "reason": "Critical CVE affecting production and internet-exposed assets."
+      "reason": "Critical CVE affecting production and internet-exposed items."
     },
     "priority": {
       "level": "urgent",
-      "reason": "Affected assets include production systems."
+      "reason": "Affected items include production systems."
     },
     "recommendations": [
       {
-        "action": "Patch affected assets",
+        "action": "Patch affected items",
         "urgency": "high"
       }
     ]
@@ -367,7 +367,7 @@ This is an insight:
 {
   "riskScore": 92,
   "priority": "urgent",
-  "recommendedAction": "Patch affected assets"
+  "recommendedAction": "Patch affected items"
 }
 ```
 
@@ -396,7 +396,7 @@ Example:
 ```json id="3n6qlf"
 {
   "data": {
-    "cveId": "CVE-2022-29464",
+    "docId": "DOC-9",
     "severity": "critical"
   },
 
@@ -404,11 +404,11 @@ Example:
     "affectedAssets": [
       {
         "assetName": "prod-api-01",
-        "assetIp": "10.100.18.64"
+        "sku": "10.100.18.64"
       },
       {
         "assetName": "prod-db-02",
-        "assetIp": "10.100.18.65"
+        "sku": "10.100.18.65"
       }
     ]
   },
@@ -424,7 +424,7 @@ Example:
   "insights": {
     "risk": {
       "level": "critical",
-      "reason": "The CVE affects production assets, including one internet-exposed asset."
+      "reason": "The CVE affects production items, including one internet-exposed asset."
     }
   }
 }
@@ -466,7 +466,7 @@ Example:
         "target": {
           "recordId": "entity:asset:10.100.18.64",
           "target": "entity",
-          "objectType": "assets"
+          "objectType": "items"
         },
         "display": {
           "name": "prod-api-01"
@@ -581,10 +581,10 @@ resolve   → bounded runtime context (jobMemory.context)
 
 Join paths use the same dot-path convention as descriptors: from document root, typically under `data.*`.
 
-Example operator flow for `assets → subnets`:
+Example operator flow for `items → locations`:
 
 ```http
-GET /api/hippox/join-discovery?sourceObjectType=assets&targetObjectType=subnets
+GET /api/hippox/join-discovery?sourceObjectType=items&targetObjectType=locations
 POST /api/hippox/links/simulate
 POST /api/hippox/links/:id/approve
 POST /api/hippox/context/resolve
@@ -647,8 +647,8 @@ The full-scale shape should be expected mainly in snapshot collections.
 Example:
 
 ```txt id="ot7c3i"
-vulnerabilities-snapshots
-assets-snapshots
+findings-snapshots
+items-snapshots
 users-snapshots
 documents-snapshots
 ```
@@ -671,10 +671,10 @@ Other content types should stay smaller and purpose-specific.
 Example:
 
 ```txt id="i0znxj"
-vulnerabilities-events
-vulnerabilities-facts
-vulnerabilities-chunks
-vulnerabilities-history
+findings-events
+findings-facts
+findings-chunks
+findings-history
 ```
 
 These may only need:
@@ -705,10 +705,10 @@ Other content types are specialized records.
   "_id": "667f00000000000000000001",
 
   "identity": {
-    "recordId": "entity:cve:CVE-2022-29464",
+    "recordId": "entity:cve:DOC-9",
     "target": "entity",
-    "targetId": "entity:cve:CVE-2022-29464",
-    "objectType": "vulnerabilities",
+    "targetId": "entity:cve:DOC-9",
+    "objectType": "findings",
     "contentType": "snapshots",
     "version": "memorix-record.2.0"
   },
@@ -722,14 +722,14 @@ Other content types are specialized records.
 
   "concept": {
     "kind": "cve",
-    "name": "CVE-2022-29464",
-    "title": "CVE-2022-29464",
+    "name": "DOC-9",
+    "title": "DOC-9",
     "summary": "Critical unrestricted file upload vulnerability affecting WSO2 products.",
-    "keywords": ["CVE-2022-29464", "WSO2", "critical"]
+    "keywords": ["DOC-9", "WSO2", "critical"]
   },
 
   "data": {
-    "cveId": "CVE-2022-29464",
+    "docId": "DOC-9",
     "severity": "critical",
     "description": "Unrestricted file upload vulnerability affecting WSO2 products.",
     "publishedAt": "2022-04-18"
@@ -739,12 +739,12 @@ Other content types are specialized records.
     "affectedAssets": [
       {
         "assetName": "prod-api-01",
-        "assetIp": "10.100.18.64",
+        "sku": "10.100.18.64",
         "recordId": "entity:asset:10.100.18.64"
       },
       {
         "assetName": "prod-db-02",
-        "assetIp": "10.100.18.65",
+        "sku": "10.100.18.65",
         "recordId": "entity:asset:10.100.18.65"
       }
     ]
@@ -768,7 +768,7 @@ Other content types are specialized records.
       "level": "critical",
       "score": 92,
       "confidence": 0.84,
-      "reason": "The CVE affects production assets, including one internet-exposed asset."
+      "reason": "The CVE affects production items, including one internet-exposed asset."
     },
     "priority": {
       "level": "urgent",
@@ -776,7 +776,7 @@ Other content types are specialized records.
     },
     "recommendations": [
       {
-        "action": "Patch affected assets",
+        "action": "Patch affected items",
         "urgency": "high"
       }
     ]
@@ -784,9 +784,9 @@ Other content types are specialized records.
 
   "index": {
     "text": {
-      "title": "CVE-2022-29464",
+      "title": "DOC-9",
       "summary": "Critical unrestricted file upload vulnerability affecting WSO2 products.",
-      "keywords": ["CVE-2022-29464", "critical", "prod-api-01", "prod-db-02"]
+      "keywords": ["DOC-9", "critical", "prod-api-01", "prod-db-02"]
     },
     "facets": {
       "severity": "critical",
@@ -801,7 +801,7 @@ Other content types are specialized records.
         "target": {
           "recordId": "entity:asset:10.100.18.64",
           "target": "entity",
-          "objectType": "assets"
+          "objectType": "items"
         },
         "display": {
           "name": "prod-api-01"
@@ -815,7 +815,7 @@ Other content types are specialized records.
         "target": {
           "recordId": "entity:asset:10.100.18.65",
           "target": "entity",
-          "objectType": "assets"
+          "objectType": "items"
         },
         "display": {
           "name": "prod-db-02"
@@ -840,7 +840,7 @@ Other content types are specialized records.
 
   "_system": {
     "memorix": {
-      "entity": "vulnerabilities",
+      "entity": "findings",
       "contentType": "snapshots",
       "operation": "upsert"
     },
@@ -911,11 +911,11 @@ full record-level index projections
 So for example:
 
 ```txt id="cpyqdi"
-vulnerabilities-snapshots  ✅ full record shape
-vulnerabilities-events     ❌ not full shape
-vulnerabilities-facts      ❌ not full shape
-vulnerabilities-chunks     ❌ not full shape
-vulnerabilities-history    ❌ not full shape
+findings-snapshots  ✅ full record shape
+findings-events     ❌ not full shape
+findings-facts      ❌ not full shape
+findings-chunks     ❌ not full shape
+findings-history    ❌ not full shape
 ```
 
 The clean rule:

package/docs/memorix-format-for-dummies-association-corrections.md

@@ -16,7 +16,7 @@ source snapshot (join value from data / identifier / identity)
   → copy flat content.data into associated<ObjectType><ContentType>
 ```
 
-**Never** join a source snapshot directly to a non-snapshot collection by business keys such as `data.assetIp`.
+**Never** join a source snapshot directly to a non-snapshot collection by business keys such as `data.sku`.
 
 ---
 
@@ -24,9 +24,9 @@ source snapshot (join value from data / identifier / identity)
 
 ### Cover / Chapter 0 — Vulnerability patch framing
 
-**Incorrect:** The vulnerability patch wires `vulnerabilities-snapshots` directly to `vulnerabilities-discovery` / `vulnerabilities-decisions` by `data.assetIp`.
+**Incorrect:** The vulnerability patch wires `findings-snapshots` directly to `findings-discovery` / `findings-decisions` by `data.sku`.
 
-**Correct:** The patch enriches `vulnerabilities-snapshots` using snapshot-mediated resolution: match snapshots first (including same-object `vulnerabilities-snapshots`), then fetch discovery/decisions content linked to the matched snapshot `recordId`.
+**Correct:** The patch enriches `findings-snapshots` using snapshot-mediated resolution: match snapshots first (including same-object `findings-snapshots`), then fetch discovery/decisions content linked to the matched snapshot `recordId`.
 
 ### Chapter 4 — Core association rules
 
@@ -38,10 +38,10 @@ source snapshot (join value from data / identifier / identity)
 
 Replace the direct-join walkthrough with:
 
-1. Read source `vulnerabilities-snapshots.data.assetIp`.
-2. Match target `vulnerabilities-snapshots` by snapshot paths such as `data.assetIp`, `concept.identifier`, or `identity`.
+1. Read source `findings-snapshots.data.sku`.
+2. Match target `findings-snapshots` by snapshot paths such as `data.sku`, `concept._extIdentifier`, or `identity`.
 3. Take matched target snapshot `recordId`.
-4. Fetch `vulnerabilities-discovery` / `vulnerabilities-decisions` by a record-id link field such as `data.sourceRecordId`, `concept.identifier.recordId`, or root `recordId`.
+4. Fetch `findings-discovery` / `findings-decisions` by a record-id link field such as `data.sourceRecordId`, `concept._extIdentifier.recordId`, or root `recordId`.
 5. Copy flat `content.data` into `associatedVulnerabilitiesDiscovery` / `associatedVulnerabilitiesDecisions`.
 
 Payload rules for this pilot:
@@ -71,10 +71,10 @@ Payload rules for this pilot:
 ## Replacement example (vulnerability discovery/decisions)
 
 ```markdown
-1. Read source `vulnerabilities-snapshots.data.assetIp`.
-2. Match target `vulnerabilities-snapshots` by snapshot paths such as `data.assetIp`, `concept.identifier`, or `identity`.
+1. Read source `findings-snapshots.data.sku`.
+2. Match target `findings-snapshots` by snapshot paths such as `data.sku`, `concept._extIdentifier`, or `identity`.
 3. Take matched target snapshot `recordId`.
-4. Fetch `vulnerabilities-discovery` / `vulnerabilities-decisions` by a record-id link field such as `data.sourceRecordId`, `concept.identifier.recordId`, or root `recordId`.
+4. Fetch `findings-discovery` / `findings-decisions` by a record-id link field such as `data.sourceRecordId`, `concept._extIdentifier.recordId`, or root `recordId`.
 5. Copy flat `content.data` into `associatedVulnerabilitiesDiscovery` / `associatedVulnerabilitiesDecisions`.
 ```
 
@@ -84,7 +84,7 @@ Payload rules for this pilot:
 
 | Aspect | Incorrect (PDF Chapter 5) | Correct |
 |--------|---------------------------|---------|
-| Join path | `vulnerabilities-snapshots.data.assetIp` → `vulnerabilities-discovery.data.assetIp` | `vulnerabilities-snapshots.data.assetIp` → `vulnerabilities-snapshots` (snapshot match) → `recordId` → `vulnerabilities-discovery` (by `concept.identifier.recordId`) |
+| Join path | `findings-snapshots.data.sku` → `findings-discovery.data.sku` | `findings-snapshots.data.sku` → `findings-snapshots` (snapshot match) → `recordId` → `findings-discovery` (by `concept._extIdentifier.recordId`) |
 | Phase count | One-phase direct content join | Two-phase: snapshot match, then content fetch |
 | Same-object rule | Exception allowing direct snapshot→content | Same-object still matches snapshots first |
 | Bridge pattern | Implicit direct join | Explicit `match` + `content` in associator rules |
@@ -95,15 +95,15 @@ Payload rules for this pilot:
 
 ```json
 {
-  "sourceJoinPaths": ["data.assetIp"],
+  "sourceJoinPaths": ["data.sku"],
   "match": {
-    "collection": "vulnerabilities-snapshots",
-    "joinPaths": ["data.assetIp", "concept.identifier.assetIp", "identity", "recordId"]
+    "collection": "findings-snapshots",
+    "joinPaths": ["data.sku", "concept._extIdentifier.sku", "identity", "recordId"]
   },
   "content": {
-    "collection": "vulnerabilities-discovery",
+    "collection": "findings-discovery",
     "contentType": "discovery",
-    "linkPaths": ["concept.identifier.recordId", "data.sourceRecordId", "recordId"]
+    "linkPaths": ["concept._extIdentifier.recordId", "data.sourceRecordId", "recordId"]
   },
   "associatedProperty": "associatedVulnerabilitiesDiscovery",
   "payload": { "format": "v2", "source": "target.data", "includeRecordId": false }

package/docs/memorix-format.md

@@ -55,33 +55,29 @@ Every piece of business data lives in **exactly one** of these buckets (plus the
 
 | Bucket | Contents |
 |---|---|
-| **`data`** | Raw facts about the entity itself — IP, severity, session timeout, zone name |
-| **`analytics`** | Rollups and counts computed from other records — vulnerability totals, affected-asset counts |
-| **`enrichment`** | External, sourced values joined from feeds or prior systems — CVSS, EPSS, KEV, VPR |
-| **`insights`** | AI-generated judgments — exploitability, potential impact, classification, risk narratives |
+| **`data`** | Native facts about the subject itself |
+| **`analytics`** | Numeric rollups computed from other records |
+| **`enrichment`** | External / prior-system values as received |
+| **`insights`** | Judgments, scores, recommendations |
 | **`associatedData`** | Linked snapshot/data content copied from associated records' `data` payloads |
 | **`associatedDiscovery`** | Linked discovery content copied from associated records' `data` payloads |
 | **`associatedAnalysis`** | Linked analysis content copied from associated records' `data` payloads |
-| **`associatedSiblings`** | Self-association: other snapshot `data` payloads sharing the same join key (e.g. assets by shared `data.subnetCidr` in `data.subnetCidrs[]`); each item includes linked `recordId`. Default cap: 99 items. |
-| **`associatedChildren`** | Parent-to-child association (subnets only today): asset `data` payloads whose `data.subnetCidrs` contains the subnet `data.cidr`; each item includes linked `recordId`. Default cap: 99 items. |
+| **`associatedSiblings`** | Self-association: other snapshot `data` payloads sharing the same join key; each item includes linked `recordId`. Default cap: 99 items. |
+| **`associatedChildren`** | Parent-to-child association: child `data` payloads whose join key matches the parent; each item includes linked `recordId`. Default cap: 99 items. |
 
 Do not duplicate a value across buckets. When reshaping legacy records, promote `sourceFacts` values into the correct bucket rather than wrapping them.
 
-Associated properties are always arrays and are omitted when no linked data was resolved. Do not write empty arrays, and do not switch between object and array shape. Custom associated content uses the same root-level pattern: `associatedCompliance`, `associatedBusinessContext`, `associatedExposure`, and so on.
+Associated properties are always arrays and are omitted when no linked data was resolved. Do not write empty arrays, and do not switch between object and array shape. Custom associated content uses the same root-level pattern: `associatedCompliance`, `associatedBusinessContext`, and so on.
 
-**Ranked top associations** use `associatedTop<ObjectType><ContentType>` (e.g. `associatedTopVulnerabilitiesAnalysis`). Candidates are sorted by the linked object type’s `importanceIndicator` (or rule `rankBy`) and capped (default 5). See [association-format.md](../memorix-pipeline/docs/association-format.md).
+**Ranked top associations** use `associatedTop<ObjectType><ContentType>` (e.g. `associatedTopItemsAnalysis`). Candidates are sorted by the linked object type’s `importanceIndicator` (or rule `rankBy`) and capped (default 5). See [association-format.md](./association-format.md).
 
-**Enrichment associations** use `associated<ObjectType>Enrichment` (e.g. `associatedVulnerabilitiesGroupsEnrichment`). They copy the linked snapshot’s root `enrichment` bucket (external feed values: CVSS, EPSS, KEV, compositeScore) as a flat object array — not a separate `*-enrichment` content collection. See [association-format.md](../memorix-pipeline/docs/association-format.md).
+**Enrichment associations** use `associated<ObjectType>Enrichment` (e.g. `associatedItemGroupsEnrichment`). They copy the linked snapshot’s root `enrichment` bucket as a flat object array — not a separate `*-enrichment` content collection. See [association-format.md](./association-format.md).
 
 Associated items contain the linked record's `data` payload (or `enrichment` / `concept` / root property for the specialized forms). Legacy associations may also include inline `recordId` and `contentType`; v2 associations store traceability in optional item-level `_system.association` metadata. Do not wrap associated items with redundant envelope keys; failure and diagnostic details belong in `<objectType>-failed` collections instead.
 
 **Associated property metadata:** Consumers should prefer Memorix associated-property metadata when available (`@x12i/memorix-associator`). Associated snapshot properties are exposed through managed descriptors plus discovery. Until metadata is available, or when reading older/custom records, fall back to the prefix rule: root-level fields on snapshots whose names start with `associated`. The well-known names `associatedData`, `associatedDiscovery`, and `associatedAnalysis` are conventions only — the complete set comes from metadata plus the `associated*` fallback rule.
 
-When a field can naturally have more than one value, processing contracts use array shape even if the current record has only one value. For assets, `data.assetIps`, `data.subnets[]`, and `data.subnetCidrs[]` are the normalized join fields. Each `data.subnets[]` entry is a structured subnet object `{ cidr, networkAddress, prefixLength, mask }` — one resolved subnet per asset IP, chosen by longest-prefix match. Multiple entries exist only when multiple asset IPs resolve to different canonical subnets. `data.subnetCidrs[]` is the derived flat join index used by association rules.
-
-For subnets, `data.cidr` is the canonical join key. Subnet records also carry structured `data.subnet` plus flattened `data.networkAddress`, `data.prefixLength`, and `data.mask`, all derived deterministically from `data.cidr`.
-
-Assets also carry `data.assetIpClassifications[]` when topology resolution runs. Each item records `{ ip, scope, confidence, reason, reasoning, matchedSubnetCidr?, matchedSubnetIp? }`, where `scope` is `inside`, `outside`, or `unknown`. Convenience arrays `data.insideAssetIps`, `data.outsideAssetIps`, and `data.unknownAssetIps` may be populated from those classifications. `inside` means the IP either matched canonical topology with high confidence, or is RFC1918 private space without a matching topology CIDR with medium confidence. `outside` means public/non-RFC1918 with no topology match. `unknown` covers invalid, loopback, and link-local addresses.
+When a field can naturally have more than one value, processing contracts use array shape even if the current record has only one value. Join-key recipes (which paths and shapes) are defined on **entity descriptors** for each Catalox object type — not in this format package.
 
 ---
 
@@ -89,49 +85,45 @@ Assets also carry `data.assetIpClassifications[]` when topology resolution runs.
 
 ```ts
 type MemorixConcept = {
-  identifier: {
+  _extIdentifier: {
     kind: string;
     /** Primary value — property name matches `kind`. */
     [kind: string]: string;
     /**
      * Deterministic join key: `kind` first, then the kind-named value,
      * then any other scalar fields in sorted key order, joined by `:`.
-     * See `.operational/fr/2026-07-09-memorix-format-identifier-key.md`.
      */
-    identifierKey: string;
+    key: string;
   };
   title: string;
 };
 ```
 
-`identifier` is a discriminated object: `kind` names the id type, and a same-named property holds the value. `identifierKey` is required on every identifier (root and nested concepts).
+`_extIdentifier` is a discriminated object: `kind` names the id type, and a same-named property holds the value. `key` is required. How `kind` / title are derived for an object type is defined on the **entity descriptor**, not here.
 
 ```json
 "concept": {
-  "identifier": {
-    "kind": "ipAddress",
-    "ipAddress": "10.150.68.31",
-    "identifierKey": "ipAddress:10.150.68.31"
+  "_extIdentifier": {
+    "kind": "sku",
+    "sku": "SKU-100",
+    "key": "sku:SKU-100"
   },
-  "title": "BGAK105-002"
+  "title": "Blue widget"
 }
 ```
 
-`concept.name` is not used. `title` is the human-readable display name; it may differ from the identifier value (e.g. hostname vs IP).
+`concept.name` is not used. `concept.identifier` / `identifierKey` are legacy — migrate to `_extIdentifier` / `key`. `title` is the human-readable display name; it may differ from the identifier value.
 
-### Identifier `kind` by object type
+### Identifier `kind` (illustrative — not format law)
 
-| Object type | `kind` | Example identifier |
+| Object type (abstract) | `kind` | Example |
 |---|---|---|
-| Assets | `ipAddress` | `{"kind":"ipAddress","ipAddress":"10.150.68.31","identifierKey":"ipAddress:10.150.68.31"}` |
-| Vulnerability groups | `pluginId` (preferred) or `cveId` | `{"kind":"pluginId","pluginId":"142594","identifierKey":"pluginId:142594"}` |
-| Vulnerability instances (host findings) | `hostVulnerability` | `{"kind":"hostVulnerability","hostVulnerability":"10.100.18.64::pluginId:160208","assetIp":"10.100.18.64","vulnerabilityGroupIdentifierKey":"pluginId:160208","identifierKey":"hostVulnerability:10.100.18.64::pluginId:160208:10.100.18.64:pluginId:160208"}` |
-| Subnets | `cidr` (canonical) or `subnetIp` (legacy, quarantined) | `{"kind":"cidr","cidr":"1.1.1.5/32","identifierKey":"cidr:1.1.1.5/32"}` |
-| Topology zones | `zoneName` | `{"kind":"zoneName","zoneName":"LAN","identifierKey":"zoneName:LAN"}` |
-| Topology VRs | `vrName` | `{"kind":"vrName","vrName":"VR-UPB-MED","identifierKey":"vrName:VR-UPB-MED"}` |
-| Users | `sessionKey` | `{"kind":"sessionKey","sessionKey":"med\\cap\|10.39.44.205\|UIA","identifierKey":"sessionKey:med\\cap\|10.39.44.205\|UIA"}` |
+| Items | `sku` | `{"kind":"sku","sku":"SKU-100","key":"sku:SKU-100"}` |
+| Groups | `groupCode` | `{"kind":"groupCode","groupCode":"G-42","key":"groupCode:G-42"}` |
+| Locations | `locationCode` | `{"kind":"locationCode","locationCode":"WH-A","key":"locationCode:WH-A"}` |
+| Documents | `docId` | `{"kind":"docId","docId":"DOC-9","key":"docId:DOC-9"}` |
 
-Vulnerability groups are **plugin-scoped**: prefer `pluginId` whenever present. Use `cveId` only when there is no plugin id — the same CVE can appear on multiple plugins, so CVE is not a unique group key. Keep `data.cveId` for display/filter. Vulnerability **instances** also denormalize `vulnerabilityGroupIdentifierKey` at the record root for queries.
+Domain packs (Catalox) may use different `kind` values; those recipes live on descriptors.
 
 ---
 
@@ -143,6 +135,7 @@ System metadata — provenance, processing history, graph-run stamps — never b
 type MemorixLifecycleEvent = { process: string; processedAt: string };
 
 type MemorixSystemBlock = {
+  state?: "active" | "archived" | "superseded";
   lifecycle?: MemorixLifecycleEvent[];
   _graphRuns?: Record<string, GraphRunEntry>;
   _jobTypeRuns?: Record<string, GraphRunEntry>;
@@ -164,8 +157,8 @@ Root-level `lifecycle` is gone. Processing events live at `_system.lifecycle`:
 - Each entry is `{ process, processedAt }`.
 - When `createdAt`, `modifiedAt`, and `capturedAt` are identical (the common snapshot case), emit a single `"enriched"` event rather than three duplicate timestamps.
 - Distinct events (e.g. a future re-enrichment) append as additional array entries.
-- `status` is not stored; it was uniformly `"active"` across all records.
-- Omit `lifecycle` entirely when no timestamp is known (e.g. Users records with no source dates) — do not emit an empty array.
+- Omit `lifecycle` entirely when no timestamp is known — do not emit an empty array.
+- `_system.state` is the present-tense lifecycle state enum (`active` \| `archived` \| `superseded`).
 
 `_system.provenance.enrichedAt` (when present) is separate provenance metadata about a prior enrichment step, not a substitute for `lifecycle`.
 
@@ -179,102 +172,59 @@ Dot-path references: `_system._graphRuns.<graphId>`, `_system._jobTypeRuns.<jobT
 
 ## Complete example
 
-Vulnerability group record showing all envelope fields and every bucket:
+Abstract item snapshot showing envelope fields and open buckets:
 
 ```json
 {
-  "_id": "6914a132880706529ece3da1",
-  "recordId": "69d216ed358778e93215787e",
+  "recordId": "rec-item-1",
   "concept": {
-    "identifier": {
-      "kind": "pluginId",
-      "pluginId": "142594",
-      "identifierKey": "pluginId:142594"
+    "_extIdentifier": {
+      "kind": "sku",
+      "sku": "SKU-100",
+      "key": "sku:SKU-100"
     },
-    "title": "Oracle WebLogic Server RCE (CVE-2020-14882)"
+    "title": "Blue widget"
   },
   "data": {
-    "name": "Oracle WebLogic Server RCE (CVE-2020-14882)",
-    "vulnerability_family": "Web Servers",
-    "vulnerability_type": "cve",
-    "cveId": "CVE-2020-14882",
-    "severity": "critical",
-    "pluginId": 142594
+    "sku": "SKU-100",
+    "color": "blue",
+    "family": "widgets"
   },
   "associatedData": [
-    { "assetIp": "10.100.24.31", "hostname": "BGAK105-002" },
-    { "assetIp": "10.100.24.41", "hostname": "BGAK105-003" }
+    { "locationCode": "WH-A", "qty": 12 },
+    { "locationCode": "WH-B", "qty": 3 }
   ],
   "analytics": {
-    "affectedAssets": { "total": 2 }
+    "linkedLocations": { "total": 2 }
   },
   "enrichment": {
-    "cvss": {
-      "baseScore": 9.8,
-      "cvssVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
-    },
-    "epss": { "epss": 0.94454, "percentile": 0.99992 },
-    "kev": { "isKnownExploited": true },
-    "compositeScore": 0.974,
-    "riskLevel": "CRITICAL",
-    "vprScore": "9.2"
+    "catalogScore": 0.91,
+    "sourceSystem": "erp-feed"
   },
   "insights": {
-    "exploitability": { "level": "HIGH", "confidence": 0.92 },
-    "potentialImpact": { "level": "CRITICAL", "confidence": 0.88 }
+    "priority": { "level": "high", "confidence": 0.9 }
   },
   "_system": {
+    "state": "active",
     "provenance": {
-      "sourceId": "6914a132880706529ece3da1",
-      "snapshotRecordId": "69d216ed358778e93215787e",
       "source": {
-        "database": "poc-data-mapping",
-        "collection": "vulnerabilities-groups-rawdata",
-        "server": "default"
+        "database": "example-db",
+        "collection": "items-rawdata"
       }
     },
     "lifecycle": [
       { "process": "enriched", "processedAt": "2026-04-05T08:01:15.511Z" }
-    ],
-    "_graphRuns": {
-      "graph-t92669z": {
-        "status": "done",
-        "startedAt": "2026-07-01T23:41:23.233Z",
-        "completedAt": "2026-07-01T23:42:05.604Z",
-        "lastJobRunId": "f7af7f7a-0c5c-4825-9282-d39bea836682",
-        "attempts": 1,
-        "result": {
-          "target": "entity",
-          "entityName": "vulnerabilities-groups",
-          "contentType": "inferences",
-          "recordId": "75de9244-8d44-43b8-8698-7e22621b1087"
-        }
-      }
-    }
+    ]
   }
 }
 ```
 
-Not every record populates every bucket. Assets typically have `data`, `analytics`, and optionally `insights` and `associatedData`; only vulnerability groups carry `enrichment` today.
+Not every record populates every bucket. Non-snapshot content types usually keep substance in `.data` only (SCOPE).
 
 ---
 
 ## Migration notes
 
-- Reshape scripts (`scripts/memorix-neo-reshape/transform-20-to-clean.mjs`) convert 2.0 envelopes to this format.
-- Fixed POC reference data lives in `temp/data-and-format-fixes/` with per-collection change notes in `CHANGES.md`.
-- Type definitions: `memorix-descriptors/src/record/envelope.ts`.
-
-### Subnets / topology subnets merge (2026-07-05)
-
-`topology-subnets` was merged into `subnets`. Canonical `subnets` records are topology
-CIDR segments (`concept.identifier.kind: "cidr"`), spread across content types
-`snapshots` / `core` / `inferences` / `scoped`. A subset of the old, pre-merge `subnets`
-records (subnetIp-only, no CIDR) had zero overlap with any canonical CIDR and were
-quarantined rather than dropped — they live in the `legacy` content type
-(`subnets-legacy`), keyed by `concept.identifier.kind: "subnetIp"`, with an explicit
-`_system.quarantine` block (`legacy: true`, `status`, `reason`) marking them as not
-eligible for `assets -> subnets` joins. `assets.data.subnetCidr` (precomputed via CIDR
-containment against canonical `subnets-snapshots`) is the join key used for that
-relation — see `scripts/memorix-subnets-merge/` for the migration and backfill scripts,
-and `temp/part-b-implementation-design-2026-07-05T06-20-00Z.md` for the full design.
+- Prefer **`npx memorix-format migrate`** for transforms (dry-run → `--out` → validate). Live Mongo apply is a separate ops step.
+- Historical reshape scripts under `scripts/` are not the recommended path.
+- Thin envelope helpers may still be re-exported from `@x12i/memorix-descriptors`; **format packages are the SOT**.

package/docs/memorix-workflow-format.md

@@ -73,7 +73,7 @@ type WorkflowTask = {
 
 Catalog id: `memorix-workflow-field-schemas`
 
-One item per object type (natural id e.g. `assets-workflow-fields`):
+One item per object type (natural id e.g. `items-workflow-fields`):
 
 ```ts
 type WorkflowFieldSchemaItem = {

package/examples/valid-snapshot.json

@@ -1,25 +1,25 @@
 {
-  "recordId": "69d216ed358778e93215787e",
+  "recordId": "rec-item-1",
   "concept": {
     "_extIdentifier": {
-      "kind": "pluginId",
-      "pluginId": "142594",
-      "key": "pluginId:142594"
+      "kind": "sku",
+      "sku": "SKU-100",
+      "key": "sku:SKU-100"
     },
-    "title": "Oracle WebLogic Server RCE (CVE-2020-14882)"
+    "title": "Blue widget"
   },
   "data": {
-    "cveId": "CVE-2020-14882",
-    "severity": "critical"
+    "sku": "SKU-100",
+    "color": "blue"
   },
   "associatedData": [
-    { "assetIp": "10.100.24.31", "hostname": "BGAK105-002" }
+    { "locationCode": "WH-A", "qty": 12 }
   ],
   "analytics": {
-    "affectedAssets": { "total": 1 }
+    "linkedLocations": { "total": 1 }
   },
   "insights": {
-    "exploitability": { "level": "HIGH", "confidence": 0.92 }
+    "priority": { "level": "high", "confidence": 0.9 }
   },
   "_system": {
     "state": "active",

package/meta/inventory/managed-descriptors.json

@@ -72,6 +72,7 @@
     "allContentTypesCoveredInContentTypesJson": true,
     "platformOpenBucketsPresentInOpenBucketsJson": ["analytics", "enrichment", "insights"],
     "associatedNamesFollowPrefixConvention": true,
-    "noObjectTypesInFormatLawJson": true
+    "noObjectTypesInFormatLawJson": true,
+    "conceptRecipesOnEntityDescriptors": true
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@x12i/memorix-format",
-  "version": "2.2.0",
+  "version": "2.2.2",
   "description": "Memorix product format on @x12i/memorix-base-format: open buckets, associations, SCOPE, migrate CLI.",
   "type": "module",
   "main": "./dist/index.js",