# Halo SSP asset spine — per-type schemas and OSCAL mappings

Field-level dictionary for the six SSP-spine asset types plus the Site-level `system_information` front-matter. The spine overview, relationship semantics, AFUUID summary, and read-side audit checks live in `skills/halo-ssp-asset-model/SKILL.md`; write discipline lives in `skills/halo-ssp-asset-write-conventions/`; asset dtypes + relationship ids also appear in `reference-docs/halo-platform/data-model.md` §8.

**Tenant ids are examples, never constants.** Every numeric field/CF/lookup id in this document reflects the standard GRCITSM tenant schema and can differ per tenant. Resolve names → ids live at run start (`asset_type_fields` per asset type, catalog reads for lookups) and fail loudly on a miss. A hardcoded id that happens to resolve is not a hardcoded id that is correct — id-keyed writes against a differently-configured tenant succeed silently with the wrong semantics.

## When to use which asset type

| Layer | What it is | When to create one |
|---|---|---|
| **Capability** | A top-level functional grouping in the SSP — IAM, Monitoring/Logging, Cryptography, Network Boundary, etc. Halo-only organizational layer with no OSCAL SSP equivalent (its OSCAL home is the Component Definition model). Seeded list lives at [[ssp-capability-seed-list]]. | One per functional area in the SSP. Components roll up under exactly one Capability. |
| **Component** | A specific tool, service, policy, or document that participates in the system implementation. Examples: Entra ID, AWS KMS, Conditional Access, Defender XDR, Incident Response Plan, Information Security Policy. Halo's `Component Type` lookup is a superset of OSCAL: `System \| Interconnection \| Software \| Hardware \| Service \| Policy \| Physical \| Process/Procedure \| Plan \| Guidance \| Standard \| Validation \| Network \| Document`. Maps to OSCAL `component`. | One per discrete tool / service / document that implements one or more controls. |
| **Control Implementation** | The **OSCAL `control-implementation` envelope** — one per (Site × Catalog). Holds the system-wide narrative for the catalog and groups all Implemented Requirements for that catalog. AFUUID `CI-<SystemName>-<CATALOGSHORT>`. `CFBaseline` (Custom Field 503) carries the structured catalog binding. | One per entry on `Site.CFBaselines`. A Site with FedRAMP Rev5 Class C + FedRAMP 20x Class C → 2 CI rows. |
| **Implemented Requirement** | The **per-control row** — one per (Catalog × Control-ID). Holds the control's title (`AC-02: Account Management`) and a Description (system-wide narrative for that control). Parented by exactly one Control Implementation (rel 10). Children are the Implementation Statements that satisfy it (rel 7). Maps to OSCAL `implemented-requirement`. AFUUID encodes System + catalog source (`IR-ACME-FR5CC-AC-02`, `IR-ACME-FR20XCC-IAM-AAM` for KSI families) — short code resolved from `CTBaselines.CFBLShortCode`. | One per (in-scope-Control, Catalog) pair. Enhancements are separate rows (`IR-ACME-FR5CC-AC-02-03` for `AC-2(3)`). KSI families get their own IRs (`IR-ACME-FR20XCC-IAM-AAM`). |
| **Implementation Statement** | The **per-(Component, Control) narrative leaf** — how this Component implements this part of this control. Holds the Implementation Statement narrative, Implementation State, Control Origination, Responsible Role, and the validation sub-set. Parents = one Component (rel 8) plus N Implemented Requirements (rel 7), one per catalog the IS satisfies. Maps to OSCAL `by-component`. | One per (Component, control-coverage) phrase. Framework-agnostic Title `{Component} – {Descriptive phrase}` and AFUUID `IS-<CMPN>-<ACRONYM>` mean one IS can satisfy a FedRAMP Control + a 20x KSI + a CMMC practice via parallel IR parents. |
| **Set Parameter** | The **organization's chosen value for one ODP slot** — a control's `[Assignment: organization-defined ...]` placeholder. Maps to OSCAL `set-parameter`. Holds the chosen value plus the slot's Index, Label, and Scope. Parented by either an Implemented Requirement (rel 12, Scope=`Control` — the value applies to that one control) or a Control Implementation (rel 11, Scope=`System` — the value applies system-wide). AFUUID `SP-<SystemName>-<CATALOGSHORT>-<CONTROL>[-<REQSUFFIX>]-<IDX>`. | One per ODP slot the system fills. A FedRAMP Rev5 requirement row can carry ≥2 ODP slots (~25% do), so a single IR can parent several SPs disambiguated by Index. System-wide values (one value reused across controls) parent to the CI instead. Only FedRAMP Rev5 carries ODP prose in `CTControlRequirements`; CMMC + 20x have none, but SPs can still be authored for them as data. |
| **system_information** | Site-level row (NOT a Device asset — a `Site` extension) holding SSP front-matter: System Name, FIPS-199 Impact Level, Service/Deployment Model, FedRAMP Package ID, DIL, Authorization date, Baselines, and the four narrative blocks (General Description / Authorization Boundary / Network Architecture / Data Flow). Read via the `system_information` tool, written via `update_system_information`. Maps to OSCAL `system-characteristics`. | Exactly one per Site. Populated by ingest, read by SSP generation. |

## OSCAL ↔ Halo mapping table

| OSCAL SSP element | Halo asset |
|---|---|
| `system-characteristics` | `system_information` (Site-level) |
| `system-implementation.components[].component` | Component (dtype 173) |
| `control-implementation` (envelope, singular per SSP file) | **Control Implementation (dtype 192)** — one per Site × Catalog |
| `control-implementation.implemented-requirements[].implemented-requirement` (one per control-id) | **Implemented Requirement (dtype 190)** |
| `implemented-requirement.by-components[].by-component` (per control × component) | **Implementation Statement (dtype 191)** |
| `implemented-requirement.set-parameters[].set-parameter` (per-control ODP value) | **Set Parameter (dtype 193)**, Scope=`Control`, parented by the IR (rel 12) |
| `control-implementation.set-parameters[].set-parameter` (system-wide ODP value) | **Set Parameter (dtype 193)**, Scope=`System`, parented by the CI (rel 11) |
| `statement` (AC-2(a), AC-2(b)…) | Requirements CF on IS (flat string IDs) |
| Capability | Capability (dtype 178) — Halo-only grouping, no OSCAL SSP equivalent |

## Asset relationships (DeviceRelationshipRestriction allow-list)

Halo's allow-list for the SSP spine:

| Restriction ID | Upstream | Downstream | Relationship ID | Relationship Label |
|---|---|---|---|---|
| 3 | Capability (178) | Component (173) | 6 | Capability Has Components |
| 7 | Component (173) | Implementation Statement (191) | 8 | Component Has Implementation Statements |
| 5 | Implemented Requirement (190) | Implementation Statement (191) | 7 | Implemented Requirement Has Implementation Statements |
| 8 | Control Implementation (192) | Implemented Requirement (190) | **10** | **Control Implementation Has Implemented Requirements** |
| 6 | Cloud Asset (188) | Component (173) | 9 | Inventory Item Implements Components |
| — | Implemented Requirement (190) | Set Parameter (193) | **12** | **Implemented Requirement Has Set Parameters** (per-control ODP, Scope=`Control`) |
| — | Control Implementation (192) | Set Parameter (193) | **11** | **Control Implementation Has Set Parameters** (system-wide ODP, Scope=`System`) |

## Conceptual identity per asset type

What makes two rows **the same entity** — the question the AFUUID answers. Used by the idempotency rule in [[halo-ssp-asset-write-conventions]] Rule 2, which owns the AFUUID shapes themselves.

| Asset type | Conceptual identity |
|---|---|
| Capability | Title — `Identity and Access Management` is one Capability, never two. |
| Component | (Title, Provider) pair. |
| Implemented Requirement | (System, Catalog, Control-ID, Enhancement) — `AC-2(3)` is a separate row from `AC-2`; KSI families are separate rows. |
| Implementation Statement | (parent Component AFUUID, requirement-intent acronym) — one IS per `(Component, distinct intent)`; multiple framework attributions share one IS via parallel parent IRs (rel 7). |
| Set Parameter | (parent scope, control, ODP-slot index) — one SP per ODP slot, distinguished by Index, never merged. |

Identity collisions on first ingest (two artifacts appearing to describe the same Component under different names) stage as a CHANGE-PLAN "merge candidate" for human resolution — never a silent merge, and never a UUID overwrite.

## Per-type field schema

The `(default)` Field Group is the only group in use for all SSP-spine asset types. All asset types share the same global Custom Fields (CFs) used for framework attribution.

### Capability (asset type 178)

**3 Asset Fields + the shared Custom Fields.** Tag prefix `CPBL`.

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` → param `uuid` | free-form | — | Idempotency key (AFUUID). Convention: `CAP-<SystemID>-<Acronym>` (e.g. `CAP-ACME-IAM`). |
| Title | Asset Field | `AFTitle` → param `title` | free-form | — | Display name matching the seed list verbatim (e.g. `Identity and Access Management`). |
| Description | Asset Field | `AFDescription` → param `description` | free-form | — | Narrative purpose / scope of the Capability. |
| FedRAMP Controls | Custom Field | `CFAFedRAMPControls` | lookup (multi) | NIST SP 800-53 control IDs zero-padded (`AC-02`, `AC-02 (01)`) | Aggregated upward from child IRs is the convention; direct writes work. |
| FedRAMP Requirements | Custom Field | `CFAFedRAMPRequirements` | lookup (multi) | FedRAMP requirement IDs with bracketed letters | **Write Controls first, Requirements in a follow-up call** — the Requirements lookup is filtered by the asset's current Controls value. |
| FedRAMP KSIs | Custom Field | `CFAFedRAMPKSIs` | lookup (multi) | `KSI-<XXX>-<YYY>` family IDs (strip any `.NN` specific-code suffix — Halo's KSI catalog stores family IDs only) | Reserved for 20x KSI attribution. |
| CMMC Controls | Custom Field | `CFACMMCControls` | lookup (multi) | CMMC L1/L2/L3 control IDs (`AC.L2-3.1.5`) | Same comma-no-spaces / zero-pad rules. |
| CMMC Requirements | Custom Field | `CFACMMCRequirements` | lookup (multi) | CMMC requirement IDs | Same Controls-first ordering. |

### Component (asset type 173)

**7 Asset Fields + the shared Custom Fields.** Tag prefix `CMPN`.

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` → param `uuid` | free-form | — | Convention: `CMPN-<NAME>` (e.g. `CMPN-ENTRAID`). |
| Component Type | Asset Field | `AFComponent Type` | lookup | `System` \| `Interconnection` \| `Software` \| `Hardware` \| `Service` \| `Policy` \| `Physical` \| `Process/Procedure` \| `Plan` \| `Guidance` \| `Standard` \| `Validation` \| `Network` \| `Document` | Halo superset of OSCAL component types — broader on purpose. **Documentary subset** — `Policy`, `Process/Procedure`, `Plan`, `Guidance`, `Standard`, `Document` — is the only set a KB article may associate with ([[halo-ssp-asset-model]] § KB articles reach the spine through a Component). |
| Title | Asset Field | `AFTitle` | free-form | — | Component's display name (e.g. `Entra ID`, `Defender XDR`, `Incident Response Plan`). **On a documentary Component carrying a KB article, the Title MUST equal the article title exactly** — it is the only correlation key between the two. |
| Description | Asset Field | `AFDescription` | free-form | — | What the Component is / does. |
| Purpose | Asset Field | `AFPurpose` | free-form | — | Why this Component is in the system boundary. |
| CMMC Asset Type | Asset Field | `AFCMMC Asset Type` | lookup | `SPA` \| `CUI` \| `SPD` \| `CRMA` \| `OOS` | CMMC asset categorization. |
| Provider | Asset Field | `AFProvider` | free-form | — | Vendor / responsible party (e.g. `Microsoft`, `AWS`, `Huntress`). |
| (shared framework CFs) | Custom Field | same as Capability | lookup (multi) | — | Same set, same Controls-before-Requirements ordering. |

### Control Implementation (asset type 192)

**3 Asset Fields + the shared Custom Fields.** Tag prefix `CI`. **This is the OSCAL `control-implementation` envelope** — one per (Site × Catalog). A Site with `CFBaselines = "FedRAMP Rev5 Class C,FedRAMP 20x Class C"` should end up with two CI rows: one for FedRAMP Rev5 Class C, one for FedRAMP 20x Class C.

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` → param `uuid` | free-form | — | Idempotency key. Convention: `CI-<SystemName>-<CATALOGSHORT>` (e.g. `CI-ACME-FR5CC`, `CI-ACME-FR20XCC`, `CI-ACME-CMMCL2`). |
| Title | Asset Field | `AFTitle` | free-form | — | Display name. Convention: the verbatim CFBaseline value (`FedRAMP Rev5 Class C`, `FedRAMP 20x Class C`). |
| Description | Asset Field | `AFDescription` | free-form | — | System-wide narrative for how the system addresses this catalog overall. Maps to OSCAL `control-implementation.description`. Optional — most narrative lives on child IS rows. |
| CFBaseline (id 503) | Custom Field | `CFBaseline` | lookup (validate=V, single-select, scalar string) | Same Lookup as `Site.CFBaselines` with site-scope filter — only baselines the parent Site is authorized against appear in the dropdown | The structured catalog binding. Lets `/ssp-generate` filter CIs by baseline cleanly. CF id 503 per the standard GRCITSM tenant schema. |
| (shared framework CFs) | Custom Field | same as Capability | lookup (multi) | — | Typically left empty on a CI envelope — the per-control attribution lives on the child IR / IS rows. |

### Implemented Requirement (asset type 190)

**4 Asset Fields + the shared Custom Fields.** Tag prefix `IR`. **This is the per-control-id row** — one per (Catalog, Control ID, Enhancement).

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` → param `uuid` | free-form | — | Idempotency key. Convention: `IR-<SystemName>-<CATALOGSHORT>-<CONTROL>` (e.g. `IR-ACME-FR5CC-AC-02`, `IR-ACME-FR5CC-AC-02-03` for the enhancement, `IR-ACME-FR20XCC-IAM-AAM` for 20x KSIs). `<SystemName>` from `system_information.System Name`. |
| Title | Asset Field | `AFTitle` | free-form | — | Convention: `{Control-ID}: {Control Name}` (e.g. `AC-02: Account Management`, `KSI-IAM-AAM: Automating Account Management`). |
| Description | Asset Field | `AFDescription` | free-form | — | System-wide narrative for how the system addresses this control. Optional — many narratives live on the child IS rows instead. |
| Implementation State | Asset Field | `AFImplementation State` | lookup | `Implemented` \| `Partial` \| `Planned` \| `Alternative` \| `Not Applicable` \| `Not Implemented` | **DERIVED by default — write it only if you have to.** The `Rollup Implemented Requirement Status` runbook (event on Asset created/updated, plus a scheduled sweep) computes it from the linked child Implementation Statements' own state. Normal path: set state on the IS leaves and let the rollup settle. A direct write is a deliberate override, not routine — it is **not durable** (the next asset event on that IR or any child IS recomputes it), so use it only where no IS leaf can carry the value (e.g. an IR with no child ISs yet) and expect it to be transient. Same value set as the IS field (id 225). |
| (shared framework CFs) | Custom Field | same as Capability | lookup (multi) | — | The IR's own framework attribution (typically a single value matching its AFUUID — e.g. an IR for `AC-02` has `CFAFedRAMPControls=[AC-02]`). |

### Implementation Statement (asset type 191)

**13 Asset Fields + the shared Custom Fields.** Tag prefix `IS`. Allowed statuses: `Active` \| `Inactive` \| `Draft` \| `Rejected` \| `Ready For Review`. **This is the per-(Component × control) narrative leaf** — maps to OSCAL `by-component`.

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` → param `uuid` | free-form | — | Idempotency key. Convention: `IS-<CMPN>-<ACRONYM>` (e.g. `IS-KMS-ROT`); no Capability segment. When instantiating from the IS library, this equals `IS-<CFISAcronym>`. |
| Title | Asset Field | `AFTitle` | free-form | — | Framework-agnostic — see [[halo-ssp-asset-write-conventions]] Rule 4. Shape: `{Component} – {Descriptive phrase}` (en-dash). No Control or KSI IDs in the Title — framework attribution lives in the framework CFs + the parent IR relationships. |
| Related Component | Asset Field | `AFRelated Component` | free-form | — | **Free-text mirror** of the Component Title. The structural Component link is the `Component Has Implementation Statements` DeviceChild relationship (rel 8) via `set_asset_relationships`. Keep this field consistent with the linked Component's Title for human readability. |
| Implementation State | Asset Field | `AFImplementation State` | lookup | `Implemented` \| `Partial` \| `Planned` \| `Alternative` \| `Not Applicable` \| `Not Implemented` | OSCAL adds `Not Implemented` for gap tracking. `Partial` = covers part of the control coverage; `Alternative` = compensating control. OSCAL crosswalk: OSCAL's `partially` → Halo `Partial`; OSCAL's `not-applicable` → Halo `Not Applicable` (spaced). Match exactly. |
| Control Origination | Asset Field | `AFControl Origination` | lookup (validate=W, multi) | `Organization` \| `System Specific` \| `Customer Configured` \| `Customer Provided` \| `Inherited` | Halo collapses OSCAL's `sp-system` + `sp-corporate` into `Organization`. Validate=W requires the `[{value,label}]` array shape. |
| Responsible Role | Asset Field | `AFResponsible Role` | lookup (validate=V) | `Self` \| `Third Party` \| `Managed Service Provider` \| `Cloud Service Provider` | Halo expresses this as party-type, not as a specific role ID. |
| Implementation Statement | Asset Field | `AFImplementation Statement` | free-form (long, mandatory) | — | **The narrative payload** — this is what OSCAL emits as `by-component.description`. Subject to the runtime payload cliff — keep one long-form field per update call where possible (see halo-platform/write-semantics.md in reference-docs). |
| Validated Component Details | Asset Field | `AFValidated Component Details` | free-form | — | Free-text on what about the Component was validated. |
| Validation Name | Asset Field | `AFValidation Name` | free-form | — | Short label for the validation procedure. |
| Validation Method | Asset Field | `AFValidation Method` | lookup (validate=V) | `Machine Based` \| `Non-Machine Based` | |
| Validation Process | Asset Field | `AFValidation Process` | free-form | — | Long-form procedure description. Same payload-cliff caveat as Implementation Statement. |
| Validation Pass/Fail Criteria | Asset Field | `AFValidation Pass/Fail Criteria` | free-form | — | The objective criterion that determines pass vs fail. |
| Validation Test | Asset Field | `AFValidation Test` | free-form | — | Actual test or evidence-collection step. |
| (shared framework CFs) | Custom Field | same as Capability | lookup (multi) | — | The IS's control attribution — the lookup that ties the IS to its baseline control IDs. **In sync with the parent IR relationships** — if `CFAFedRAMPControls=[AC-02]` the IS must also have IR `IR-ACME-FR5CC-AC-02` as a rel-7 upstream. See [[halo-ssp-asset-write-conventions]] for the source-of-truth rule. |

### Set Parameter (asset type 193)

**6 Asset Fields + the shared Custom Fields.** Tag prefix `SP`. `(default)` Field Group; fields live on an **"OSCAL Details"** tab. Reuses the spine's 5 native statuses. **This is the OSCAL `set-parameter` leaf** — the organization's CHOSEN VALUE for one control `[Assignment: organization-defined ...]` (ODP) slot. A Set Parameter parents to **either** an Implemented Requirement (rel 12, Scope=`Control` → OSCAL `implemented-requirement.set-parameters[]`) **or** a Control Implementation (rel 11, Scope=`System` → OSCAL `control-implementation.set-parameters[]`), never both.

| Field | Source | API name | Type | Allowed values | Notes |
|---|---|---|---|---|---|
| UUID | Asset Field | `AFUUID` (field 209) → param `uuid` | free-form | — | Idempotency key. Convention: `SP-<SystemName>-<CATALOGSHORT>-<CONTROL>[-<REQSUFFIX>]-<IDX>` (e.g. `SP-GRCITSM-FR5CC-AU-11-1`). `<IDX>` disambiguates multiple ODP slots in one requirement row. |
| Title | Asset Field | `AFTitle` (field 213) | free-form | — | **Value-free** — a stable human handle, NOT the chosen value (the value lives in Parameter Value). E.g. `AU-11 audit-record retention period`. |
| Parameter Index | Asset Field | `AFParameter Index` (field 237) | integer | — | Ordinal of this ODP slot within its requirement row, 1-based. Load-bearing: ~25% of FedRAMP Rev5 Class C requirement rows carry ≥2 ODP slots and the catalog has no discrete param-id, so Index + Label identify which slot this value fills. |
| Parameter Label | Asset Field | `AFParameter Label` (field 238) | free-form | — | Short label naming the slot (e.g. `time period`, `frequency`). Pairs with Index to identify the slot. |
| Parameter Scope | Asset Field | `AFParameter Scope` (field 239) | lookup (lookup id 265) | `Control` \| `System` | `Control` → the value applies to this one control (parent = IR, rel 12). `System` → the value is reused system-wide (parent = CI, rel 11). Drives the parent type and the OSCAL placement. |
| Parameter Value | Asset Field | `AFParameter Value` (field 236) | free-form (long) | — | **The chosen value** — what OSCAL emits as `set-parameter.value`. Free-form because ODP values range from `30 days` to multi-clause organization-defined prose. Subject to the runtime payload cliff. |
| (shared framework CFs) | Custom Field | same as Capability | lookup (multi) | — | `CFBaseline` (503) plus the framework CFs — `CFAFedRAMPControls`, `CFAFedRAMPKSIs`, `CFACMMCControls`, optionally the Requirements CFs and `CFAFedRAMPRules`. Framework-CF numeric ids are TENANT-SPECIFIC examples, never constants: resolve them live BY NAME before any write and fail loudly on a miss (observed drift: the Rules CF resolved at 597 on a live tenant where earlier revisions of this row pinned 385). The SP's framework attribution ties it to the control whose ODP it fills. Subject to the two-phase CF write — see [[halo-ssp-asset-write-conventions]]. |

There is deliberately **no origination or status field** on the SP schema: OSCAL `set-parameter` carries only `@param-id` + `value[]` + `remarks`, and the SP's lifecycle rides the native asset status. The value-free Title keeps the handle stable when the chosen value changes.

## system_information field map (SSP front-matter)

The `system_information` view is one row per Site (Site ID ≡ System ID — Halo's "System" is an attribute set on the Site row, not a separate entity). Read via the `system_information` tool; write via `update_system_information`.

| Field | Purpose | Notes |
|---|---|---|
| Client ID / Client Name | Tenant scope | Names resolved via `client_details` separately — `system_information` returns IDs only. |
| Site ID / Site Name / System ID / System Name | System identity | `Site ID` and `System ID` are the same integer. `System Name` is the display name used as the SSP title. |
| FedRAMP Package ID | FedRAMP filing identifier | Free-form. |
| Service Model | SaaS / PaaS / IaaS (or combinations) | Comma-separated. Example: `PaaS,SaaS`. |
| Deployment Model | Public Cloud / Private Cloud / Hybrid Cloud / Community Cloud / Government Only Cloud | Lookup. |
| Impact Level | FIPS PUB 199 level | `Low` \| `Moderate` \| `High`. |
| FIPS PUB 199 Level | Redundant alias of Impact Level | Both fields exist; keep aligned. |
| Digital Identity Level (DIL) Determination | IAL / FAL / AAL composite | Example: `IAL3/FAL3/AAL3`. |
| Fully Operational as of | Authorization / ATO date | Date string. |
| Baselines | The control baselines the system is authorized against | **CSV of display names**, not IDs. Example: `CMMC L2,FedRAMP 20x Class C,FedRAMP Rev5 Class C`. Drives which baseline catalogs the SSP generator walks. Values must match the baseline catalog's display names verbatim (including the `FedRAMP` prefix on 20x baselines) or downstream catalog joins silently miss. |
| General System Description | SSP §9 narrative | Free-form, multi-paragraph. Payload-cliff applies. |
| Authorization Boundary Description | SSP §9 narrative | Free-form. Diagrams are NOT modeled in v1. |
| Network Architecture Description | SSP §9 narrative | Free-form. |
| Data Flow Description | SSP §9 narrative | Free-form. |
