---
name: halo-ssp-asset-model
description: Dictionary of the Halo SSP asset spine — Capability / Component / Control Implementation / Implemented Requirement / Implementation Statement / Set Parameter asset types plus the Site-level system_information front-matter. Covers the spine model, relationship semantics, AFUUID conventions, and read-side audits; per-type field schemas + OSCAL mapping tables live in reference-docs/halo-ssp-asset-schemas.md. Load for WHAT the spine IS — field schemas, dtypes, relationship semantics, AFUUID rules. For workflow routing and write-chain order, load the `ssp` skill instead; the two compose (ssp = router, this = dictionary).
---

# Halo SSP asset model

## References

| Reference | Type | Location | When to Use |
|---|---|---|---|
| `halo-ssp-asset-write-conventions` | Skill | `plugins/grcitsm-analyst/skills/halo-ssp-asset-write-conventions/` | Write discipline for this asset model (read-merge-write, two-pass framework CFs, write order, verification) |
| `ssp-capability-seed-list` | Skill | `plugins/grcitsm-analyst/skills/ssp-capability-seed-list/` | Seeded Capabilities with starter Component mappings |
| `grcitsm` | Skill | `plugins/grcitsm-analyst/skills/grcitsm/` | Broader create_asset → update_asset chain doctrine |
| SSP asset schemas | Reference | `reference-docs/halo-ssp-asset-schemas.md` | Per-type field schema tables, OSCAL mapping table, relationship allow-list table, when-to-use detail, system_information field map |
| Data model | Reference | `reference-docs/halo-platform/data-model.md` | §8 asset dtypes + typed relationship ids (SSP spine) |
| Write semantics | Reference | `reference-docs/halo-platform/write-semantics.md` | Null-handling (§2), lookup-value rules (§3), framework-CF ordering (§5), payload cliff (§8) |
| `ssp-spine-reference.md` | File | `reference-docs/ssp-spine-reference.md` | Reconcile pattern that materializes Capabilities / CIs / IRs per Site |

## Summary

A System Security Plan in a GRCITSM Halo tenant is composed from **six asset types plus a Site-level front-matter view**. The model maps to OSCAL SSP — Capability is a Halo-only organizational layer; Component is the OSCAL `component`; Control Implementation is the OSCAL `control-implementation` envelope (one per Site × Catalog); Implemented Requirement is the OSCAL `implemented-requirement` (one per control-id); Implementation Statement is the OSCAL `by-component` narrative (per Component × control); Set Parameter is the OSCAL `set-parameter` leaf (the system's chosen value for a control's organization-defined parameter slot). **Halo is the source of truth, not OSCAL JSON** — OSCAL emerges at export time.

The spine (asset-type `dtype` numbers per the standard GRCITSM tenant schema; dtype + relationship-id tables: `reference-docs/halo-platform/data-model.md` §8):

```
Site (system_information row — SSP front-matter)
  │
  ├── Capability                       dtype 178
  │     │  rel 6
  │     │
  │     └── Component                  dtype 173
  │           │  rel 8
  │           │
  │           └── Implementation       dtype 191  (per Component × control)
  │               Statement                ↑
  │                                        │ rel 7
  │                                        │
  │           Implemented Requirement     dtype 190  (per control-id)
  │                ↑                  │ rel 12
  │                │ rel 10           └──► Set Parameter   dtype 193  (per-control ODP)
  │                │
  │           Control Implementation     dtype 192  (per Site × Catalog)
  │           (Site-scoped via Device.dsite + CFBaseline)
  │                │ rel 11
  │                └──► Set Parameter        dtype 193  (system-wide ODP)
  │
  ├── Cloud Asset                      dtype 188
  │     │  rel 9 (inventory → component)
  │     └── Component (above)
  │
  └── Hardware Asset                   dtype 189   (inventory side, same role)

KB article ──(asset association, via get_asset(...).kbs[])──► exactly ONE Component
             documentary Component Types only; Titles must match. Never to an IR or IS.
```

**Three layers of upstream parents on a fully-wired IS**: Component (rel 8) → IR (rel 7) → CI (rel 10). One CI envelope per (Site × Catalog) groups all IRs for that catalog; one IR per (Catalog × Control-ID) groups all IS rows that satisfy that control; one IS per (Component × control-coverage-intent) holds the narrative.

This page is the router every SSP read/write agent reads. Pair it with `reference-docs/halo-ssp-asset-schemas.md` for the field-level dictionary (per-type schemas, OSCAL mapping table, when-to-create rules, system_information field map), with [[halo-ssp-asset-write-conventions]] for write discipline (read-merge-write, lookup-value rules, framework-CF ordering, citation-via-change-history), and with [[grcitsm]] § Asset-side workflow for the broader create-asset → update-asset chain.

## When to use which asset type

One Capability per functional area (Components roll up under exactly one); one Component per discrete tool / service / document; one CI per entry on `Site.CFBaselines`; one IR per (in-scope-Control, Catalog) pair — enhancements and KSI families are separate rows; one IS per (Component, control-coverage) phrase; one SP per ODP slot the system fills; exactly one `system_information` row per Site. Full per-type definitions, examples, and creation rules: `reference-docs/halo-ssp-asset-schemas.md` § When to use which asset type.

## OSCAL ↔ Halo terminology — beware the inversion

A naming caution: OSCAL has both `implemented-requirement` and `statement` as nested elements with specific meanings. **Halo's `Implementation Statement` asset type maps to OSCAL `by-component`, not to OSCAL's `statement`** (which is the sub-control-part layer, AC-2(a), AC-2(b)…). OSCAL `statement`-level granularity is captured in Halo via the IS's Requirements CF (`CFAFedRAMPRequirements` storing `AC-02a.[01][02]`), not as a separate asset. Full element-by-element mapping table: `reference-docs/halo-ssp-asset-schemas.md` § OSCAL ↔ Halo mapping table.

## Asset relationships

Typed relationship ids (6/7/8/9/10/11/12): `reference-docs/halo-platform/data-model.md` §8; the full allow-list table with restriction ids + labels: `reference-docs/halo-ssp-asset-schemas.md`. Semantics beyond the bare table:

Writes that create or modify these links go through `set_asset_relationships`. Any link outside the allow-list will be refused by Halo at write time. The IS layer carries **two** parent links — one Component (rel 8) and one-to-many Implemented Requirements (rel 7). Each IR can be parented by exactly one Control Implementation (rel 10) — its catalog envelope. A Set Parameter parents to **exactly one** of either an Implemented Requirement (rel 12, when the value scopes to one control) or a Control Implementation (rel 11, when the value is system-wide) — never both, never orphaned on the Site. Verify relationship integers against `asset_relationship_restrictions` before designing any relationship write.

## KB articles reach the spine through a Component — never directly

A KB article carries the actual documentary content (the policy, the procedure, the plan) that a control response cites. It is **not** a spine asset and has no typed relationship of its own; it associates to an asset and is read back via `get_asset(...).kbs[]`. Four rules, binding:

1. **Exactly one Component.** A KB article associates with a single Component asset — never several, never zero. The article's place in the SSP is that one Component's place.
2. **Documentary Component Types only.** The associated Component's `Component Type` must be one of `Policy`, `Process/Procedure`, `Plan`, `Guidance`, `Standard`, or `Document`. The other eight values in the lookup — `System`, `Interconnection`, `Software`, `Hardware`, `Service`, `Physical`, `Validation`, `Network` — are implementing technology, not documentation, and never carry an article. (Enum verified live against `asset_type_fields`, field id 200; note `Process/Procedure` is singular.)
3. **Titles must match exactly.** `Component.Title` == the KB article title, character for character. This is the correlation key: there is no foreign key between the two, so the title IS the join. A renamed article with an unrenamed Component silently breaks correlation — rename both in the same change.
4. **Never associate a KB article with an Implemented Requirement or an Implementation Statement.** It looks like a shortcut — the article does after all evidence a control — but it fabricates a second, unreconcilable path into the spine.

**Why the indirection is the point.** The spine is defined by the Component and *its* relationships (Capability rel 6 up, Implementation Statement rel 8 down, Cloud/Hardware Asset rel 9 in). A KB article inherits all of that by attaching to the Component and nothing else. Attach it to an IR or IS instead and the article's control coverage is asserted twice — once through the Component graph, once directly — and the two drift the moment either side is edited, with no reconciler owning the conflict. One documentary Component per document, one article on it, and the graph walk answers every "what covers this control" question from a single source.

Consequence for reads: to find the documentation behind a control, walk IR → IS (rel 7) → Component (rel 8) → `kbs[]`. Do not search the KB corpus and work backwards; that path has no authority and, per the write-surfaces reference, the KB search tools are currently blind on this integration anyway.

## Out of scope for v1

These belong to the SSP conceptually but are **not** modeled in the asset spine described above:

- **Diagrams** (authorization boundary, network architecture, data flow). The narrative-only fields cover the prose.
- **User Roles** (OSCAL `system-implementation/users`). Reused as-is via the `system_pocs` tool — no User Role asset type.
- **Inventory items beyond Cloud Asset / Hardware Asset.** The Cloud Asset → Component link (rel 9) is the path for inventory rollup; expansion of inventory modeling is a separate concern.

## AFUUID conventions

Halo `tagprefix` per asset type: 178=`CPBL`, 173=`CMPN`, 190=`IR`, 191=`IS`, 192=`CI`, 193=`SP`. AFUUID shapes per asset type, plus the `<CATALOGSHORT>` resolution from `CTBaselines.CFBLShortCode` and `<SystemName>` from `system_information.System Name`, live in [[halo-ssp-asset-write-conventions]] Rule 2. Do not hardcode short codes; resolve via `baseline_catalog` or `CTBaselines`.

## Audit checks during graph walks

A graph walk down the spine (Capability → Component → IR → IS) is the implementation map; corroborating sources must validate it. Two audits fire on every read-side walk; both feed `gaps.md`.

### Mapping corroboration via `category_control_mappings`

After walking capability → component → IR → IS to assemble each control's record, audit the mapping against `mcp__grcitsm__CF_category_control_mappings` — Halo's stored capability-to-control mapping. If a capability claims to satisfy a control that `category_control_mappings` does not corroborate, flag the per-control record with `mapping_corroborated: false` rather than silently accept the graph walk. A corroborated mapping is `mapping_corroborated: true`; an absent or unknown mapping is `null`. Downstream gap analysis treats `false` as drift requiring human review.

### Active-inventory cross-check (decommissioned-asset detection)

For every asset surfaced via `get_asset` graph walks (Cloud Asset rel 9 → Component; use `asset_summary` for the bulk id roll-up, then `get_asset` per row), cross-check the asset ID against `mcp__grcitsm__CF_active_inventory`. If the asset is not in active inventory (decommissioned, retired, archived), surface it as a flag on the per-control record — do NOT silently drop the asset. The SSP may cite an asset no longer in production, and the reader/auditor needs to know. Convention: keep the asset in `supporting_assets` and add `"<asset_id>: decommissioned per active_inventory"` to the per-control `flags` array.

### KB correlation audit

On every read-side walk, check each documentary Component (`Component Type` in `Policy` / `Process/Procedure` / `Plan` / `Guidance` / `Standard` / `Document`) against its `kbs[]`:

- **Component with zero KB articles** → the document is declared but its content is absent. Flag `"<AFUUID>: documentary Component has no KB article"`.
- **Component with more than one** → the one-article rule is broken; flag all titles so the reviewer can decide which belongs.
- **Title mismatch** between the Component and its article → flag both strings verbatim. This is the failure the rule exists to prevent and the only one nothing else detects, since neither side errors.
- **KB article found on an IR or IS** → flag as a structural violation, not a gap; it is a write that should never have landed.

These are `gaps.md` entries, never silent corrections — a read-side walk reports, it does not repair. A non-documentary Component with no KB article is normal and is not flagged.

## Cross-references

- `reference-docs/halo-ssp-asset-schemas.md` — per-type field schemas, OSCAL mapping table, relationship allow-list, system_information field map.
- [[halo-ssp-asset-write-conventions]] — write discipline for this asset model (read-merge-write, two-pass framework CFs, write order, verification).
- [[ssp-capability-seed-list]] — the seeded Capabilities with starter Component mappings.
- [[grcitsm]] § Asset-side workflow — broader create_asset → update_asset chain doctrine.
- `reference-docs/halo-platform/write-semantics.md` — null-handling, lookup-value rules, and payload-size bounds that drive the write conventions.
- `reference-docs/ssp-spine-reference.md` — the reconcile pattern that materializes Capabilities / CIs / IRs and their relationships per Site.
