@x12i/memorix-format 2.2.1 → 2.2.3

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 2.2.3
+
+- Docs hygiene: drop identity-era appendix and ebook correction notes; association doc is a thin present-tense stub pointing at `meta/associated-conventions.json` + pipeline ops docs.
+
 ## 2.2.0
 
 - Depends on `@x12i/memorix-base-format@^1.2.0` (`concept._extIdentifier`, `_system.state`).

package/README.md

@@ -1,38 +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 existing databases
+Product meta lives under [`meta/`](./meta/). Managed-descriptor inventory in `meta/inventory/` is not format law.
 
-Present-tense format only. To transform stored JSON / exports:
+Normative: [docs/memorix-format-requirements.md](./docs/memorix-format-requirements.md). Narrative: [docs/memorix-format.md](./docs/memorix-format.md).
 
-```bash
-# Dry-run validate after transform (stdout summary)
-npx memorix-format migrate ./export-dir/ --content-type=snapshots
-
-# Write cleaned files
-npx memorix-format migrate ./export-dir/ --out=./clean-dir/
-
-# Or overwrite in place after validation passes
-npx memorix-format migrate ./records.json --in-place
-```
-
-Defaults applied by migrate:
+## Layering
 
-- `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).
+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
 
@@ -41,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
@@ -51,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"
 ```
@@ -66,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

@@ -1,466 +1,44 @@
 # Association format
 
-An **association** connects one snapshot record to one or more related records. Associated content is stored as root-level properties on snapshot records using the reserved `associated` prefix.
+Associated content is stored as **root-level open buckets** on snapshot records using the reserved `associated` prefix.
 
-Associations are materialized by `@x12i/memorix-associator` presets, orchestrated by `@x12i/memorix-pipeline` enrichment. See [Running associations](./running-associations.md).
+**Normative naming / forms:** packaged [`meta/associated-conventions.json`](../meta/associated-conventions.json).  
+**Operational detail** (presets, apply, enrichment orchestration): [`memorix-pipeline/docs/association-format.md`](../../memorix-pipeline/docs/association-format.md) and [running-associations.md](../../memorix-pipeline/docs/running-associations.md).
 
----
-
-## Core rule
-
-Record-to-record association is always resolved from **snapshot record to snapshot record first**:
-
-1. The lookup starts from the current object's snapshot record.
-2. The matching target is another snapshot record in a `*-snapshots` collection.
-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`).
-
-**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`.
+This package validates association **shape** (ASSOC rules in [memorix-format-requirements.md](./memorix-format-requirements.md)); it does not invent object-type names.
 
 ---
 
-## Naming conventions
-
-### Legacy (live data today)
-
-Short names without object type segment: `associatedData`, `associatedDiscovery`, `associatedAnalysis`, `associatedAssets`, `associatedSubnets`, etc.
-
-- Remain on existing records; not bulk-migrated.
-- Registry entries carry `"namingConvention": "legacy"`.
-- Legacy items may include inline `recordId` on copied payloads.
-
-### v2: `associated<ObjectType><ContentType>`
-
-| Segment | Rule | Example |
-|---------|------|---------|
-| Prefix | `associated` (reserved) | — |
-| ObjectType | PascalCase canonical object type | `security-groups` → `SecurityGroups` |
-| ContentType | PascalCase canonical content type | `discovery` → `Discovery` |
-
-Examples:
-
-```ts
-associatedSecurityGroupsAnalysis
-associatedVulnerabilitiesGroupsDiscovery
-associatedVulnerabilitiesGroupsSnapshots
-associatedUsersDecision
-```
-
-Do **not** pluralize the content type (`Discovery`, not `Discoveries`). The property is already an array.
-
-Registry entries for new associations carry `"namingConvention": "v2"`.
-
-### Ranked top associations: `associatedTop<ObjectType><ContentType>`
-
-Same copy forms as above, but candidates are **sorted by importance** then **capped**.
-
-| Segment | Rule | Example |
-|---------|------|---------|
-| Prefix | `associatedTop` | — |
-| ObjectType | PascalCase | `Vulnerabilities` |
-| ContentType | PascalCase | `Analysis` |
-
-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.
-
-**Default cap:** `5` (`DEFAULT_TOP_ASSOCIATED_ITEMS`). Override per rule with `maxItems`.
-
-**Empty results:** omit the property entirely (never write `[]`).
-
-```json
-{
-  "associatedProperty": "associatedTopVulnerabilitiesAnalysis",
-  "maxItems": 5,
-  "rankBy": {
-    "path": "data.severity",
-    "valueKind": "severity",
-    "order": "desc"
-  },
-  "match": {
-    "collection": "vulnerabilities-snapshots",
-    "joinPaths": ["data.assetIp"]
-  },
-  "content": {
-    "collection": "vulnerabilities-analysis",
-    "linkPaths": ["data.sourceRecordId", "recordId"]
-  },
-  "payload": { "source": "target.data", "format": "v2" }
-}
-```
-
-For snapshot-mediated rules, `rankBy.path` is evaluated on the **matched snapshot** (not the copied content). Severity order: `critical > high > medium > low > none`.
-
-### Derived (not copy-form associations)
-
-Resolver outputs such as `associatedTopology` are **derived** fields computed during pipeline resolution — not associator copy forms. Document separately; do not rename to v2 copy naming.
-
----
-
-## Association forms
-
-The associator supports four copy forms via `rule.payload.source` (see request schema in `@x12i/memorix-associator`).
-
-### 1. Normal data association
-
-**Property:** `associated<ObjectType><ContentType>`
-
-**Copy:** linked record's `data` object (flat, not wrapped).
-
-```json
-{
-  "associatedSecurityGroupsAnalysis": [
-    {
-      "_system": {
-        "association": {
-          "fromProperty": "data.securityGroups",
-          "toProperty": "identifier",
-          "associatedAt": "2026-07-08T09:00:00.000Z",
-          "recordId": "security-group-record-id-1"
-        }
-      },
-      "summary": "The group appears to provide privileged access.",
-      "impact": "High",
-      "classification": "Privileged Security Group"
-    }
-  ]
-}
-```
-
-Request payload:
-
-```json
-{
-  "payload": {
-    "format": "v2",
-    "source": "target.data",
-    "system": { "include": true, "fromProperty": "data.securityGroups", "toProperty": "identifier" }
-  }
-}
-```
-
-Rules:
-
-- Business data stays flat beside `_system`.
-- Do **not** wrap copied data inside another `data` object.
-- `_system` is optional. Omit when consumed as business or LLM context.
-
-### 2. Snapshot root property association
-
-**Property:** `associated<ObjectType>Snapshots<RootProperty>`
-
-Copies a root property from the associated **snapshot** record (not a separate content collection).
-
-Example: `associatedVulnerabilitiesGroupsSnapshotsAnalytics` — copies `analytics` from `vulnerabilities-groups-snapshots`.
-
-```json
-{
-  "payload": {
-    "format": "v2",
-    "source": { "snapshotRootProperty": "analytics" },
-    "system": { "include": true }
-  }
-}
-```
-
-When `system.include` is true, the item is wrapped as `{ _system, value }`. Prefer the dedicated enrichment form below when copying the `enrichment` bucket (flat copy, no `value` wrapper).
-
-### Analytics rollups (sibling — not association)
-
-**Do not** use association rules to *compute* counts into the source record’s own `analytics` bucket. Associations **copy** linked payloads into `associated*`. Numeric rollups are a separate JSON rule type:
-
-- Spec: `.operational/analytics-rollups/FORMAT.md` (`memorix.analyticsRollup.v1`)
-- 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).
-
-### 2b. Enrichment association
-
-**Property:** `associated<ObjectType>Enrichment`
-
-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.
-
-Example: `associatedVulnerabilitiesGroupsEnrichment` on `vulnerabilities-snapshots`.
-
-```json
-{
-  "associatedVulnerabilitiesGroupsEnrichment": [
-    {
-      "cvss": { "baseScore": 9.8 },
-      "epss": { "epss": 0.94 },
-      "kev": { "isKnownExploited": true },
-      "compositeScore": 0.97,
-      "riskLevel": "CRITICAL"
-    }
-  ]
-}
-```
-
-```json
-{
-  "associatedProperty": "associatedVulnerabilitiesGroupsEnrichment",
-  "payload": {
-    "format": "v2",
-    "source": "target.enrichment",
-    "includeRecordId": false
-  },
-  "target": {
-    "collection": "vulnerabilities-groups-snapshots",
-    "joinPaths": ["data.name"]
-  }
-}
-```
-
-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" })`.
-
-### 3. Concepts association
-
-**Property:** `associated<ObjectType>Concepts`
-
-Copies `concept` from associated snapshot records (not full `data`).
-
-```json
-{
-  "associatedSecurityGroupsConcepts": [
-    {
-      "identifier": { "kind": "group-name", "groupName": "Domain Admins" },
-      "title": "Domain Admins"
-    }
-  ]
-}
-```
-
-```json
-{
-  "payload": {
-    "format": "v2",
-    "source": "target.concept",
-    "system": { "include": true }
-  }
-}
-```
-
-### 4. Record IDs association
-
-**Property:** `associated<ObjectType>RecordIds` (use `RecordIds`, not `RecordsIds`)
-
-**Value:** array of strings. Must **not** include `_system`.
-
-```json
-{
-  "associatedSecurityGroupsRecordIds": [
-    "security-group-record-id-1",
-    "security-group-record-id-2"
-  ]
-}
-```
-
-```json
-{
-  "payload": {
-    "format": "v2",
-    "source": "target.recordId"
-  }
-}
-```
-
----
-
-## `_system.association` metadata
-
-Reserved for technical traceability — not business data.
-
-| Field | Meaning |
-|-------|---------|
-| `fromProperty` | Path on the source snapshot that supplied the join value |
-| `toProperty` | Path on the linked snapshot used for matching |
-| `associatedAt` | ISO date-time when the association was created or refreshed |
-| `recordId` | Linked snapshot `recordId` (v2, when enabled) |
-
-Included when `payload.format === "v2"` and `payload.system.include === true`. All fields are optional even when `_system` is present.
-
-Strip `_system` when presenting associated content to humans, LLMs, or downstream analysis.
-
----
-
-## Identifier and identity matching
-
-Prefer the linked snapshot's `identity` or `concept.identifier`:
-
-```json
-{ "identity": "group-name:Domain Admins" }
-```
-
-```json
-{
-  "identifier": { "kind": "group-name", "groupName": "Domain Admins" }
-}
-```
-
-Canonical location is `concept.identifier`. Root `identifier` / `identity` are accepted when present.
-
-Generate identity strings deterministically: join identifier values in order with `:` (e.g. `assetIp:10.100.18.64`).
+## Core rule
 
-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 is always **snapshot-first**:
 
-Associator request shape for content associations:
+1. Start from the source object’s snapshot.
+2. Match a target **snapshot** (`*-snapshots`).
+3. Use the matched snapshot’s `recordId` to fetch non-snapshot content (`discovery`, `analysis`, `decisions`, …).
+4. Copy flat content into an `associated…` array on the source snapshot.
 
-```json
-{
-  "sourceJoinPaths": ["data.assetIp"],
-  "match": {
-    "collection": "vulnerabilities-snapshots",
-    "joinPaths": ["data.assetIp", "concept.identifier.assetIp", "recordId"]
-  },
-  "content": {
-    "collection": "vulnerabilities-discovery",
-    "contentType": "discovery",
-    "linkPaths": ["concept.identifier.recordId", "data.sourceRecordId", "recordId"]
-  }
-}
-```
+Never join a source snapshot directly to a non-snapshot collection by business keys.
 
 ---
 
-## Worked example: security group analysis into users
-
-Collections:
-
-```text
-users-snapshots
-security-groups-snapshots
-security-groups-analysis
-```
-
-User snapshot source:
-
-```json
-{
-  "data": { "securityGroups": ["Domain Admins", "VPN Users"] }
-}
-```
-
-Security group snapshot identifier:
+## Naming
 
-```json
-{
-  "recordId": "security-group-record-id-1",
-  "concept": {
-    "identifier": { "kind": "group-name", "groupName": "Domain Admins" },
-    "title": "Domain Admins"
-  }
-}
-```
+| Form | Pattern | Example (abstract) |
+|---|---|---|
+| Legacy short names | `associatedData`, `associatedDiscovery`, … | still present on older records |
+| v2 content | `associated<ObjectType><ContentType>` | `associatedItemGroupsAnalysis` |
+| Ranked top | `associatedTop<ObjectType><ContentType>` | `associatedTopItemsAnalysis` |
+| Enrichment copy | `associated<ObjectType>Enrichment` | `associatedItemGroupsEnrichment` |
 
-Process:
-
-1. Start from `users-snapshots` record.
-2. Read join values from `data.securityGroups`.
-3. Match against `security-groups-snapshots` via `concept.identifier` / identity.
-4. Use matched snapshot `recordId` to fetch `security-groups-analysis` records.
-5. Copy each analysis record's `data` flat into `associatedSecurityGroupsAnalysis`.
-
-Result:
-
-```json
-{
-  "recordId": "user-record-id-1",
-  "data": {
-    "username": "ami",
-    "securityGroups": ["Domain Admins"]
-  },
-  "associatedSecurityGroupsAnalysis": [
-    {
-      "_system": {
-        "association": {
-          "fromProperty": "data.securityGroups",
-          "toProperty": "concept.identifier",
-          "associatedAt": "2026-07-08T09:00:00.000Z"
-        }
-      },
-      "summary": "The group appears to provide privileged access.",
-      "impact": "High",
-      "classification": "Privileged Security Group"
-    }
-  ]
-}
-```
+Object-type segments come from Catalox descriptors — not from this format package.
 
 ---
 
-## Implementation status
-
-| Capability | Status |
-|------------|--------|
-| Legacy `associatedData` / `associatedDiscovery` / … presets | **Live** — registry `namingConvention: "legacy"` |
-| v2 property naming | **Target** — new registry entries use `associated<ObjectType><ContentType>` |
-| v2 payload forms (`target.data`, `target.concept`, `target.recordId`, snapshot root) | **Supported** in `@x12i/memorix-associator` request schema |
-| v2 `_system.association` metadata | **Supported** when `format: "v2"` and `system.include: true` |
-| Registry-driven preset generation | **Live** — `generate-presets-from-registry.mjs` |
-| Full enrichment orchestration | **Live** — `run-enrichment-pipeline.mjs` |
-
-New associations should be added as registry entries + presets using v2 naming and payload format. Existing legacy properties continue to refresh through their current presets without rename.
-
-### Pilot: vulnerability discovery and decisions (v2)
-
-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`).
-3. Take matched target snapshot `recordId`.
-4. Fetch `vulnerabilities-discovery` / `vulnerabilities-decisions` by record-id link (`concept.identifier.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` |
-
-Target source collection: `vulnerabilities-snapshots` (`MEMORIX_EVENTS_DB`).
-
-Refresh rule keys:
-
-- `vulnerabilities.vulnerabilities.discovery.by-assetIp`
-- `vulnerabilities.vulnerabilities.decisions.by-assetIp`
-
-### Pilot: asset-side vulnerability analysis (v2)
-
-Snapshot-mediated flow (source is **assets**, not vulnerabilities):
-
-1. Read source `assets-snapshots.data.assetIps` (also `data.assetIp`, `data.ip_address`).
-2. Match `vulnerabilities-snapshots` by `data.assetIp` / `concept.identifier.assetIp`.
-3. Take matched snapshot `recordId`.
-4. Fetch `vulnerabilities-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` |
-
-Target source collection: `assets-snapshots` (`MEMORIX_ENTITIES_DB`).
-
-Refresh rule key: `assets.vulnerabilities.analysis.by-assetIp`
-
----
+## Payload rules
 
-## Legacy properties reference
+- Associated properties are **arrays of plain objects** (linked payloads), never full envelopes.
+- **Omit** the property when empty — never write `[]`.
+- Prefer traceability in optional item-level `_system.association` (v2) rather than wrapping envelopes.
 
-| Property | Typical link |
-|----------|--------------|
-| `associatedData` | Linked snapshots / generic data |
-| `associatedDiscovery` | Linked discovery |
-| `associatedAnalysis` | Linked analysis |
-| `associatedAssets` | Asset snapshots by IP |
-| `associatedSubnets` | Subnet snapshots (explicit) |
-| `associatedTopology` | Derived (resolver, not associator copy) |
-| `associatedVulnerabilityGroup` | Vuln-group snapshots (explicit) |
-| `associatedZoneAnalysis` | Topology-zone analysis |
+See requirements **ASSOC-*** and the pipeline association doc for matching / payload forms.