Part 1: Conceptual Architecture

Go to The FX Demo Root

Part 1 defines the conceptual foundation of the Financial Systems Archetype. It identifies the major architectural concepts, stakeholder concerns, runtime planes, evidence concepts, sovereignty and residency concerns, and classification structures that guide the rest of the document set. Part 1 focuses on meaning rather than technology, platform selection, or deployment design. It establishes the stable vocabulary and conceptual relationships that later parts refine into logical, profile, and implementation-specific forms.

* Foreword

• Introduction
• 1. Scope
• 2. Relationship to Part 0
• 3. Traceability to Parent and Source Architectures

  • 3.1 Traceability to SIP-RA
  • 3.2 Alignment with FDIS-RA
  • 3.3 Coverage of the Original FX Demo Reference Architecture
  • 3.4 Traceability Position
• 4. Conceptual Architecture Principles

  • 4.1 Separation of Concerns
  • 4.2 Platform Independence
  • 4.3 Classification Before Implementation
  • 4.4 Logical Meaning Before Physical Realisation
  • 4.5 Traceability
  • 4.6 Evidence Orientation
  • 4.7 Governance of Meaning
• 5. Archetype Classification Model

  • 5.1 Overview
  • 5.2 Ecosphere
  • 5.3 Ecosystem
  • 5.4 Domain
  • 5.5 Classification Path
  • 5.6 Classification Values and Runtime Identifiers
  • 5.7 Classification and Governance
• 6. Financial Systems Classification

  • 6.1 Overview
  • 6.2 Finance Ecosphere
  • 6.3 Monetary Ecosystem
  • 6.4 Foreign Exchange Domain
  • 6.5 Classification Inheritance for FX Profiles
  • 6.6 Future Financial Classifications
  • 6.7 Classification Governance
• 7. Core Conceptual Elements

  • 7.1 Overview
  • 7.2 Node
  • 7.3 Node Identity
  • 7.4 Node Role
  • 7.5 Runtime Plane
  • 7.6 Communication Endpoint
  • 7.7 Data Structure Definition
  • 7.8 Data Structure Instance
  • 7.9 Evidence
  • 7.10 Traceability
• 8. Conceptual Runtime Plane Model

  • 8.1 Overview
  • 8.2 Control Plane
  • 8.3 Data Plane
  • 8.4 Health and Observability Plane
  • 8.5 Policy and Release Plane
  • 8.6 Audit and Provenance Plane
  • 8.7 Cross-Plane Relationships
• 9. Separation of Concerns Model

  • 9.1 Overview
  • 9.2 Data
  • 9.3 Structure
  • 9.4 Semantics
  • 9.5 Interpretation
  • 9.6 Governance and Authority
  • 9.7 Traceability and Evidence
  • 9.8 Cross-Concern Relationships
• 10. Conceptual Traceability Model

  • 10.1 Overview
  • 10.2 Traceability Across Layers
  • 10.3 Conceptual Element to Logical Element / PIM
  • 10.4 Logical Element / PIM to Implementation Artefact / PSM
  • 10.5 Implementation Artefact / PSM to Deployment Artefact
  • 10.6 Deployment Artefact to Evidence
  • 10.7 Bidirectional Review and Impact Analysis
  • 10.8 Traceability Boundaries
• 11. Conceptual Rules and Constraints

  • 11.1 Overview
  • 11.2 Conceptual Elements Remain Distinct
  • 11.3 Conceptual Architecture Does Not Prescribe Realisation Mechanisms
  • 11.4 Classification Values Do Not Define Runtime Boundaries
  • 11.5 Runtime Planes Remain Conceptual Classifications
  • 11.6 Implementation Mappings Do Not Redefine Concepts
  • 11.7 Deployment Artefacts Do Not Redefine Implementation Artefacts
  • 11.8 Evidence Supports Claims
  • 11.9 Traceability Preserves Layering
  • 11.10 Local Profiles Must Preserve Parent Meaning
  • 11.11 Conceptual Constraints Summary
• 12. Relationship to the Logical Architecture / PIM

  • 12.1 Overview
  • 12.2 Conceptual Elements Become Logical Elements
  • 12.3 Logical Architecture Preserves Conceptual Meaning
  • 12.4 Logical Architecture Remains Platform Independent
  • 12.5 Logical Architecture Supports Domain Profiles
  • 12.6 Logical Architecture Provides the Basis for Implementation Profiles
  • 12.7 Traceability from Part 1 to Part 2
  • 12.8 Boundary Between Part 1 and Part 2
• 13. Conceptual Requirements

  • 13.1 Overview
  • 13.2 Conceptual Separation Requirements
  • 13.3 Classification Requirements
  • 13.4 Core Conceptual Element Requirements
  • 13.5 Runtime Plane Requirements
  • 13.6 Separation of Concerns Requirements
  • 13.7 Traceability Requirements
  • 13.8 Evidence Requirements
  • 13.9 Relationship to Logical Architecture / PIM Requirements
  • 13.10 Profile and Layering Requirements

This document should be maintained as a set of linked wiki pages rather than a single monolithic page. Each major section should have its own stable URI so it can be referenced from other wiki pages, exported documents, presentations, AI-assisted tools, and semantic models.

Do not rename pages once they have been cited externally unless a redirect or move plan is in place.