# Configuration Management > Use when managing configuration of aircraft system requirements and design data per ARP4754A: identify configuration items (requirements, design data, verification data, analysis), create and version baselines, run change control (change request, impact analysis, minor vs major classification, approval, implementation, verification), check traceability closure (every requirement mapped to a design element and a verification method, every derived requirement sourced), and record change history. All logic is deterministic, offline stdlib. Trigger: configuration management, baseline, change control, change request, impact analysis, major change, minor change, safety critical requirement, certification data, interfaces, configuration item, change history, traceability closure. - Skill: `ashfordeou/configuration-management-3` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add ashfordeou/configuration-management-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/ashfordeou/configuration-management-3/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: Apache-2.0 - Author: ashfordeOU (https://skillmd.com/u/ashfordeou) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ashfordeou/configuration-management-3 --- # ARP4754A Configuration Management (systems-engineering-safety/arp4754a/configuration-management) Use when the task is configuration management of aircraft system requirements and design data per ARP4754A: identifying what must be placed under configuration control, freezing baselines, running change control with impact analysis and minor/major classification, checking traceability closure, and keeping a change history. ## Domain quick reference - Configuration items (CIs) per ARP4754A: system requirements, design data (architecture, interfaces), verification data (tests, results), and analysis (safety analysis, trade studies). Working notes and minutes are not CIs. - A baseline is a versioned snapshot of the CI set. All change activity is measured against the frozen baseline. - Change control sequence: change request -> impact analysis (which requirements, design elements, verification methods, and analyses are affected) -> classification -> approval -> implementation -> verification. Classification is MAJOR when the change touches safety-relevant requirements, interfaces, or certification data; otherwise MINOR. - Traceability closure: every requirement maps to at least one design element and one verification method; every derived requirement has a source. - Every change is recorded in the change history log (change id, description, classification, status, date, sequential record id). ## Workflow 1. Identify the configuration items in the development data set (identify_configuration_items): requirements, design, verification, analysis. Non-CI data is excluded. 2. Create the baseline (create_baseline): pass the item list with versions; the snapshot is sorted and frozen under a baseline id and version. Baseline version "1.0" is the start of change control. 3. On a proposed change, run impact analysis (change_impact_analysis): give the change request (id + affected item ids) and the trace map. The impact set is expanded through the trace map so a touched design element, test, or analysis pulls in its owning requirements. 4. Classify the change (classify_change): major when the impact set is safety-relevant or the change flags interfaces_changed or certification_data_changed; otherwise minor. 5. Approve, implement, and verify the change, then record it (record_change) in the change history log with its classification and status. 6. On a change to a derived requirement, confirm the source is updated; re-run check_traceability_closure before releasing a new baseline. ## Worked example Flight control system, baseline B-1 at version 1.0 contains REQ-101 (brake authority, safety critical), REQ-102 (derived from REQ-101), and design/test/analysis items. A change request CR-001 proposes updating REQ-101 braking limits. - identify_configuration_items puts REQ-101, REQ-102, DES-201, TEST-301, AN-401 under configuration management; meeting minutes are excluded. - create_baseline freezes the set as B-1 v1.0 (item_count 5). - change_impact_analysis(CR-001, trace_map) expands REQ-101 to DES-201, TEST-301, AN-401 and reports safety_relevant True because REQ-101 is safety critical. - classify_change returns "major". The change proceeds through approval, implementation, verification, and record_change appends record 1 to the history log. ## Verification checks - Every requirement has a non-empty design mapping and a non-empty verification mapping (check_traceability_closure closed True). - Every derived requirement has a source. - No change affecting safety-relevant requirements, interfaces, or certification data is categorized as minor. - Impact analysis lists every affected requirement, design element, verification method, and analysis before approval. - Every change has a history record with classification and status. ## Pitfalls - Placing working notes and minutes under configuration control: only requirements, design data, verification data and analysis are configuration items, and non-CI data is excluded from the baseline snapshot. - Freezing a baseline from an unsorted, unversioned item set: the snapshot is sorted and frozen under a baseline id and version, and version \"1.0\" is the start of change control - change activity has no meaning before the baseline exists. - Approving an impact analysis that lists only the directly touched item: the impact set is expanded through the trace map, so touching a design element, test, or analysis pulls in its owning requirements before classification. - Classifying a safety-relevant change as minor: classification is major when the impact set is safety-relevant or the change flags interfaces_changed or certification_data_changed, so a minor label on REQ-101-class impact is a process failure, not a judgment call. - Releasing a new baseline without re-running traceability closure: a change to a derived requirement must update its source, and closure must hold (every requirement mapped to design and verification, every derived requirement sourced) before release. - Skipping the history record: every change is appended to the change history log with its classification and status, and a change with no record cannot be audited against the frozen baseline. ## Behavior contract (gate 3) The logic is exercised by the contract test scripts/test_configuration_management.py against scripts/configuration_management_logic.py (stdlib unittest, offline, deterministic). Run: python3 scripts/test_configuration_management.py Contract asserts: a complete trace map passes closure; a requirement missing its verification mapping fails closure; a change to a safety-critical requirement classifies as major; invalid input raises ValueError. ## Compliance - Standards referenced, not reproduced: ARP4754A text is proprietary (SAE); this skill encodes CM process logic only (summary-only per standards-map.yaml). - Revision note: ARP4754B (2023) supersedes ARP4754A; this skill keys to ARP4754A as the certification-baseline revision (FAA AC 20-174 cites A); see standards-map.yaml arp4754a.revision_decision. - compliance: STANDARDS-REF, gated: false. ## Related skills - requirements-traceability: trace matrix closure across levels (complementary to the per-requirement closure check here). - derived-requirements: source discipline for derived requirements. - verification-planning: verification methods and data that must stay under configuration management. - development-assurance-levels: safety relevance of requirements that drives major-change classification.