trestle-control-implementation

Control Implementation in Trestle

Writing Control Responses

SSP Control Markdown Structure

Each control markdown file in an SSP has this structure:

---
x-trestle-set-params:
  ac-1_prm_1:
    values:
      - organization-defined value
    ssp-values:
      - actual SSP value
x-trestle-comp-def-rules:
  My Component:
    - name: rule-ac-1
      description: Ensure access control policy exists
x-trestle-comp-def-rules-param-vals:
  My Component:
    - name: rule-param-1
      values:
        - default value
      ssp-values:
        - SSP override value
---

# ac-1 - [Access Control] Policy and Procedures

## Control Statement
[Control statement text with {{ insert: param, ac-1_prm_1 }} placeholders]

## Control guidance
[Guidance text]

______________________________________________________________________

## Implementation for part a.

### My Component

<!-- Add control implementation description here for part a. -->
Implementation prose for component addressing part a.

#### Rules:
  - rule-ac-1

#### Implementation Status: implemented

### This System

<!-- Add control implementation description here for part a. -->
Implementation prose for the overall system addressing part a.

#### Implementation Status: partial

Component-Level Responses

Each control statement part gets a response from each component:

1. Named Components (from component-definitions): Have rules, parameters, status
2. This System component: Overall system-level response (always present)

First run without component definitions: If you run ssp-generate without --compdefs, the generated markdown contains only This System sections. Named component sections such as Identity Provider appear only after you load component definitions and pass them with --compdefs. This result is expected. It is not an error.

Adding Implementation Prose

Replace the HTML comment placeholders with implementation text:

### My Component
This component implements access control policy by...