Knowledge about writing control implementation responses, rules, parameters, component-level responses, inheritance, and leveraged SSPs in Compliance Trestle. Use when users ask about writing control responses, implementation status, rules, parameters, component definitions, SSP implementation details, or compliance documentation content.
From compliance-trestlenpx claudepluginhub ethanolivertroy/compliance-trestle-skillsThis skill is limited to using the following tools:
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
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
Each control statement part gets responses from each component:
Replace the HTML comment placeholders with actual implementation text:
### My Component
This component implements access control policy by...
Rules come from component definitions and are read-only in SSP markdown:
x-trestle-comp-def-rules:
Component Name:
- name: rule-id
description: What the rule checks
Parameters for rules can have values overridden in SSP:
x-trestle-comp-def-rules-param-vals:
Component Name:
- name: param-name
values:
- component default
ssp-values:
- SSP override
Set per-component using these values:
| Status | Meaning |
|---|---|
implemented | Fully implemented |
partial | Partially implemented |
planned | Implementation planned |
alternative | Alternative implementation exists |
not-applicable | Not applicable to this component |
In markdown: #### Implementation Status: implemented
When a system inherits controls from a provider:
## This System: Component Name
### Provided Statement Description
Description of what the provider system provides.
### Responsibility Statement Description
Description of customer responsibilities.
### Satisfied Statement Description
How the inheriting system satisfies its responsibilities.
Tracks where control implementation comes from:
organization - Organization-wide policy/proceduresystem-specific - Specific to this systemcustomer-configured - Customer configures provider capabilitycustomer-provided - Customer provides the implementationinherited - Inherited from provider systemProfiles can add sections to controls:
x-trestle-sections:
guidance: Guidance
implgdn: Implementation Guidance
expevid: Expected Evidence
These sections appear in the markdown and can be edited:
## Implementation Guidance
Organization-specific implementation guidance here.
## Expected Evidence
Evidence required to demonstrate implementation.
<REPLACE_ME> placeholders with actual valuespartial or planned when appropriate---
x-trestle-set-params:
ac-2_prm_1:
values:
- organization-defined account types
ssp-values:
---
# ac-2 - Account Management
## Control Statement
...
______________________________________________________________________
## Implementation for part a.
### Identity Provider
<!-- Add control implementation description here for part a. -->
#### Implementation Status: planned
### This System
<!-- Add control implementation description here for part a. -->
#### Implementation Status: planned
---
x-trestle-set-params:
ac-2_prm_1:
values:
- organization-defined account types
ssp-values:
- privileged, non-privileged, system, service, and temporary accounts
---
# ac-2 - Account Management
## Control Statement
...
______________________________________________________________________
## Implementation for part a.
### Identity Provider
The Identity Provider (IdP) manages all user account types including privileged,
non-privileged, and service accounts. Account provisioning is handled through
the IdP's administrative console with SCIM integration to downstream systems.
#### Rules:
- rule-ac-2-account-types
#### Implementation Status: implemented
### This System
The system integrates with the organization's Identity Provider for account
lifecycle management. Local service accounts are managed through
infrastructure-as-code templates with mandatory approval workflows.
#### Implementation Status: implemented
## Implementation for part b.
### Identity Provider
Account managers are designated through the IdP's delegation model. Each
organizational unit has a primary and backup account manager assigned in the
IdP administrative hierarchy.
#### Implementation Status: implemented
### This System
System-level account managers are documented in the System Security Plan
Appendix A and are drawn from the operations team as designated by the ISSO.
#### Implementation Status: implemented
Parameter values flow through three levels, with each level able to override the previous:
| Level | Field | Source | Purpose |
|---|---|---|---|
| 1. Catalog | values | Catalog parameter definition | Default/suggested value |
| 2. Profile | profile-values | Profile set-parameters | Baseline-specific tailoring |
| 3. SSP | ssp-values | SSP control markdown header | System-specific implementation value |
The SSP-level ssp-values always wins. If ssp-values is set, it overrides both profile-values and catalog values. If ssp-values is empty, the profile value is used. If the profile doesn't set a value, the catalog default applies.
Example showing the same parameter at all three levels:
# Catalog defines: ac-1_prm_1 values: ["organization-defined frequency"]
# Profile sets: profile-values: ["annually"]
# SSP overrides:
x-trestle-set-params:
ac-1_prm_1:
values:
- organization-defined frequency
profile-values:
- annually
ssp-values:
- at least every 365 days or upon policy change
In the assembled SSP, the resolved value is at least every 365 days or upon policy change.
OSCAL controls often have statement parts (a, b, c...) and sometimes sub-parts (a.1, a.2). Each maps to a specific markdown structure.
Each lettered part gets its own ## Implementation for part X. heading:
## Implementation for part a.
### My Component
[Response for part a]
## Implementation for part b.
### My Component
[Response for part b]
Nested sub-parts use extended identifiers:
## Implementation for part a.1.
### My Component
[Response for sub-part a.1]
______________________________________________________________________) accept implementation proseWhen a control requirement cannot be met as stated, document a compensating control:
Set implementation status to alternative:
#### Implementation Status: alternative
Describe the compensating control in the implementation prose:
### This System
The system cannot implement centralized session termination as specified
due to architectural constraints in the legacy middleware layer. As a
compensating control, the system enforces aggressive idle timeouts
(15 minutes) at the application layer and requires re-authentication
for all privileged operations. This compensating control was approved
by the AO on 2024-06-15 (see POA&M item PM-2024-042).
Reference the POA&M entry if one exists for tracking the gap
| Mistake | Impact | Fix |
|---|---|---|
Leaving <!-- Add control implementation --> comments | Assemble silently includes them as empty content — auditors see blank responses | Replace every placeholder with actual prose or remove it |
| Wrong YAML indentation in headers | Assemble fails with a YAML parse error | Use 2-space indentation consistently, never tabs |
Missing ssp-values when values are required | Parameters resolve to catalog defaults which may be vague placeholders | Set explicit ssp-values for every parameter |
| Writing generic responses like "The system implements this control" | Fails ATO review — assessors need specific detail | Reference specific tools, processes, configurations, and responsible roles |
| Not addressing every statement part separately | Assemble may silently drop unaddressed parts | Add a response (even "Not applicable to this component") for each part per component |
Confusing values vs ssp-values | Assembled SSP uses the wrong parameter value | values = catalog default; ssp-values = what this system actually uses |
| Editing content above the horizontal rule | Changes are overwritten on the next generate | Only edit content below the ______________________________________________________________________ divider |
Rules that appear in SSP markdown (under x-trestle-comp-def-rules) originate from the
component definition authoring supply chain — they are not authored in the SSP.
CSV spreadsheet (vendor-authored rules, parameters, control mappings)
--> trestle task csv-to-oscal-cd (produces component-definition JSON)
--> trestle author component-generate (produces component markdown with rules + editable prose)
--> Edit markdown: write implementation responses
--> trestle author component-assemble (merges prose into component-definition JSON)
--> trestle author ssp-generate --compdefs ... (pulls rules into SSP markdown)
The rules section in SSP control markdown is populated from component definitions during
ssp-generate. Editing rules directly in SSP markdown has no effect — they will be
overwritten on the next ssp-generate run.
To change a rule: Edit the source component definition (CSV or component markdown), reassemble it, then regenerate the SSP.
trestle task csv-to-oscal-cd to rebuild the component definitiontrestle author component-generate and write the prose responsetrestle author component-assembletrestle author ssp-generate to pull the new rule into SSP markdownFor the full two-phase component definition workflow, see trestle-compliance-pipeline.