Design Review and Change Control

Document Control

Document ID	DHF-008
Version	1.0
Date	2026-03-22
Author	camt053 Engineering
Status	Released
ISO 13485 Clauses	7.3.4 (Design and Development Review), 7.3.9 (Design Changes)

1. Design Review Records

1.1 DR-001: Architecture Review

Review ID	DR-001
Date	2026-03-21
Phase	Phase 1 (Core XML Generation)
Scope	Module architecture, message-type dispatch strategy, data flow, exception hierarchy
Participants	Lead Engineer, Quality Assurance
Findings	(a) 14-package modular architecture provides clear separation of concerns. (b) Message-type dispatch via dictionary enables O(1) lookup and extensibility without modifying existing code. (c) Exception hierarchy with single base class supports catch-all handling at API and CLI boundaries.
Disposition	Approved. Architecture supports the camt.052/053/054 message family with a consistent pattern for adding future message types.
Action Items	None. Proceed to Phase 2.

1.2 DR-002: Security Review

Review ID	DR-002
Date	2026-03-21
Phase	Phase 6 (Security Hardening)
Scope	XXE prevention, path traversal protection, SQL input validation, log sanitization, template injection prevention, container security
Participants	Lead Engineer, Security Reviewer
Findings	(a) defusedxml completely disables XXE attack surface — verified by security-marked tests. (b) Path jail restricts file access to cwd, tempdir, and /var/tmp with realpath resolution. (c) Jinja2 autoescape=True prevents SSTI. (d) Log sanitization strips control characters before emission. (e) Docker runs as non-root user. (f) Bandit SAST reports zero findings.
Disposition	Approved. All OWASP Top 10 relevant attack vectors are mitigated with defense-in-depth controls.
Action Items	None. All security controls verified by automated tests.

1.3 DR-003: SWIFT Compliance Review

Review ID	DR-003
Date	2026-03-21
Phase	Phase 4 (SWIFT Compliance)
Scope	Charset validation (Z/z set), field length enforcement, transliteration, BIC/IBAN/LEI validation, message-type-specific features
Participants	Lead Engineer, Domain Expert
Findings	(a) BIC validation follows ISO 9362 format rules. (b) IBAN validation implements ISO 7064 mod-97-10 checksum. (c) LEI validation follows ISO 17442 format and check-digit rules. (d) Inbound camt.052/053/054 statements parse correctly across every ISO version (namespace-agnostic), and ISO return reason codes (e.g. AC04 Closed Account) drive entry filtering. (e) Reversing entries flip CdtDbtInd, set RvslInd=true, and carry the original references, reason, and counterparty.
Disposition	Approved. Parsing, reason filtering, and reversal generation meet ISO 20022 message standards.
Action Items	None. Conformance tests verify behaviour against the official ISO business samples.

1.4 DR-004: API and Interface Review

Review ID	DR-004
Date	2026-03-21
Phase	Phase 5 (Interface Layer)
Scope	Python API (services facade), CLI (Click), REST API (FastAPI), MCP server, LSP server
Participants	Lead Engineer, Quality Assurance
Findings	(a) A single services facade exposes parse_statement(), list_entries(), filter_entries(), build_reversal(), and generate_reversal() and backs every interface. (b) CLI provides parse, entries, reverse, message-types, reasons, and validate-id commands with proper exit codes. (c) REST API exposes synchronous parse/entries/reverse/validate endpoints plus a health check. (d) Pydantic models enforce request/response validation at the API boundary.
Disposition	Approved. All interfaces share one facade and provide appropriate access to core functionality with proper input validation.
Action Items	None. Interface tests cover all endpoints and options.

2. Change Control Log

Design changes are tracked in CHANGELOG.md using Keep a Changelog format. The following table summarizes changes relevant to the DHF:

Version	Date	Summary
0.0.1	2026-03-21	Initial release. Parse camt.052/053/054 (namespace-agnostic, every ISO version) and generate validated camt.053.001.14 reversing entries. Reason-code filtering (ISO return reason codes). Jinja2 template engine with official-XSD validation. Single services facade backing the Python API, CLI, REST API, MCP, and LSP servers. FastAPI REST API. Click CLI. BIC, IBAN, and LEI validators. JSON schema validation. defusedxml XXE-safe parsing. Path traversal protection. Security hardening. 99%+ coverage including the official ISO business samples. Cross-platform CI.

3. Design Change Process

All design changes follow this procedure:

3.1 Change Request

1. Change is proposed via GitHub Issue or Pull Request

2. Change request includes: description, rationale, affected components, risk assessment

3.2 Impact Analysis

1. Identify affected modules, tests, and documentation

2. Review requirements traceability (DHF-007) for impacted requirements

3. Review risk register (DHF-005) for new or modified risks

4. Determine if change requires design review

3.3 Implementation

1. Create feature branch from main

2. Implement change following coding standards (ruff, black, mypy strict)

3. Add or update tests to maintain >= 99% branch coverage

4. Update documentation if affected

3.4 Verification

1. All pre-commit hooks pass (13 hooks)

2. Full CI pipeline passes (test, lint, security, smoke jobs)

3. Branch coverage >= 99% maintained

4. Bandit SAST reports zero findings

5. Gold master tests pass (if XML generation affected)

3.5 Review and Approval

1. Pull request reviewed by at least one team member

2. Design review conducted if change affects architecture, security, or compliance (DR record created)

3. Change merged via signed commit

3.6 Post-Change Activities

1. Update CHANGELOG.md with change summary

2. Update DHF documents if requirements, architecture, risks, or traceability are affected

3. Tag release if change is included in a version release