Knowledge about OSCAL model types, their relationships, and how they are managed in Compliance Trestle. Use when users ask about OSCAL documents, model types, catalogs, profiles, SSPs, component definitions, or how different compliance models relate to each other.
From compliance-trestlenpx claudepluginhub ethanolivertroy/compliance-trestle-skillsThis skill is limited to using the following tools:
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
| Model Type | CLI Name | Directory | Description |
|---|---|---|---|
| Catalog | catalog | catalogs/ | Collection of security controls (e.g., NIST 800-53) |
| Profile | profile | profiles/ | Selection and modification of controls from catalogs |
| Component Definition | component-definition | component-definitions/ | How a component implements controls |
| System Security Plan | system-security-plan | system-security-plans/ | Complete system security documentation |
| Assessment Plan | assessment-plan | assessment-plans/ | Plan for assessing security controls |
| Assessment Results | assessment-results | assessment-results/ | Results of security assessment |
| POA&M | plan-of-action-and-milestones | plan-of-action-and-milestones/ | Remediation tracking |
Catalog (controls)
↓ imports
Profile (selects + modifies controls)
↓ resolved profile catalog
Component Definition (how components implement controls)
↓ combined
System Security Plan (complete system documentation)
↓ assessed by
Assessment Plan → Assessment Results → POA&M
A profile can import from:
Each import selects specific controls and can modify parameters and add content.
All models share:
uuid - Unique identifiermetadata - Title, version, last-modified, oscal-version, roles, partiesback-matter - Resources, citations, attachments.json.yaml or .ymlTrestle uses dot-notation to address elements within models:
catalog.metadata - The metadata of a catalogcatalog.groups.*.controls.* - All controls in all groupscatalog.groups.0.controls.3 - Specific control (0-indexed)Rules:
* wildcard for arrays (quote on *nix shells)catalog.controls.control = catalog.groups.controls.control| Operation | Command | Description |
|---|---|---|
| Create | trestle create -t <type> -o <name> | Create bare-bones sample model |
| Import | trestle import -f <file> -o <name> | Import existing OSCAL file |
| Split | trestle split -f <file> -e <elements> | Decompose into sub-files |
| Merge | trestle merge -e <elements> | Reassemble split files |
| Describe | trestle describe -f <file> -e <element> | Inspect model structure |
| Validate | trestle validate -f <file> or -t <type> -n <name> or -a | Check model integrity |
| Assemble | trestle assemble <type> -n <name> | Combine split parts to dist/ |
| Replicate | trestle replicate <type> -n <name> -o <new> | Copy/rename model |
Each OSCAL model type has a primary owner persona responsible for authoring and maintaining it:
| Model Type | Primary Persona | Trestle Commands | Notes |
|---|---|---|---|
| Catalog | Regulators | catalog-generate, catalog-assemble | Source of truth for controls |
| Profile | Compliance Officers / CISO | profile-generate, profile-assemble | Tailored baselines with org guidance |
| Component Definition (Service) | Control Providers (vendors) | csv-to-oscal-cd, component-generate/assemble | Maps controls to product rules |
| Component Definition (Validation) | Control Assessors (PVP vendors) | csv-to-oscal-cd (with Check_Id) | Maps rules to automated checks |
| System Security Plan | System Owners / CIO | ssp-generate, ssp-assemble | Combines profile + compdefs |
| Assessment Plan | Assessors / CISO | create, split, merge | Defines assessment scope |
| Assessment Results | Assessors / PVP tools | xccdf-result-to-oscal-ar, tanium-result-to-oscal-ar | Scan findings |
| POA&M | System Owners | create, split, merge | Remediation tracking |
In real organizations, one person may fill multiple persona roles. The ownership mapping is logical (separation of duties), not necessarily physical (one person per artifact).
The component definition plays a unique bridging role in the OSCAL model chain. It connects regulatory controls (governance layer) to automated assessment (technical layer) through two distinct component types:
Service components declare which technology-specific rules implement a regulation control:
rule-account-types) --> Parameter (e.g., timeout=15min)csv-to-oscal-cd with Component_Type=Service)component-generate / component-assemble)Validation components declare which PVP checks validate a rule:
rule-account-types) --> Check_Id (e.g., test_github.GitHubOrgs.test_members_is_not_empty)csv-to-oscal-cd with Component_Type=Validation and Check_Id column)Together, the two layers create the full compliance automation chain:
Regulation Control (NIST AC-2)
--> Service Rule (rule-account-types)
--> Validation Check (test_github.GitHubOrgs.test_members)
--> Assessment Result (pass/fail)
--> Control Posture (satisfied/not-satisfied)
This traceability enables automated posture computation: given PVP results, map backward through component definitions to determine control-level compliance status.
For full pipeline details, see the trestle-compliance-pipeline skill.