Skip to main content

Architecture Decision Records

Executive Summary​

This document contains the Architecture Decision Records (ADRs) for the Phoenix Rooivalk Counter-Drone Defense System. These records document key architectural decisions, rationale, and consequences to ensure consistent decision-making and knowledge preservation.

ADR 0001: Chain Selection for On-Chain Anchoring (Solana vs Others)​

Date: 2025-09-24
Status: Accepted (pilot on Solana)

Context​

We need a Layer 1 anchoring target for tamper-evident hashes of mission evidence. Criteria include security, latency, cost, resilience, interoperability, and operational fit for contested environments.

Options Considered​

  • Ethereum (L1): High security but high fees and slow finality
  • Solana (L1): High throughput with low latency and low fees
  • Avalanche (L1/Subnets): Good performance with subnet capabilities
  • Polkadot (Relay + Parachains): Interoperability focus with complex architecture
  • Bitcoin (L1): Highest security but slow and expensive

Decision​

Adopt Solana as the initial pilot chain for anchoring evidence digests.

Rationale​

  • Low-Latency Finality: High throughput supports near-real-time anchoring for dynamic operations
  • Low Fees: Enable frequent anchoring without prohibitive cost
  • Mature Memo Program: Simple, contract-free anchoring path
  • Ecosystem Tooling: Sufficient tooling for pilot implementation (solana-py/solders)
  • Performance: 3,000-4,500 TPS with sub-2-second finality
  • Cost Efficiency: $0.00025 per transaction

Consequences​

  • Resilience Monitoring: Must monitor resilience during high network load
  • Retry/Backoff: Add retry/backoff and outbox batching for reliability
  • Compliance Anchoring: May implement periodic Ethereum anchoring for compliance/archival
  • Classified Deployments: Subnet/private chain options (e.g., Avalanche) for classified deployments

Implementation​

  • Solana Anchor: Implementation using Solana Anchor framework
  • Blockchain Handler: API specifications for blockchain integration
  • Operations: Solana on-chain anchoring pilot implementation

ADR 0002: Solana Memo vs Smart Contract Approach​

Date: 2025-09-24
Status: Accepted (Memo approach)

Context​

Need to decide between using Solana's Memo program for simple data anchoring versus deploying custom smart contracts for evidence anchoring.

Options Considered​

  • Memo Program: Simple, built-in program for data anchoring
  • Smart Contracts: Custom smart contracts with complex logic
  • Hybrid Approach: Combination of both approaches

Decision​

Use Solana Memo program for initial implementation with option to upgrade to smart contracts.

Rationale​

  • Simplicity: Memo program provides simple, reliable data anchoring
  • Cost Efficiency: Lower transaction costs with Memo program
  • Speed: Faster transaction processing with Memo program
  • Flexibility: Easy to upgrade to smart contracts if needed
  • Compliance: Sufficient for legal admissibility requirements

Consequences​

  • Limited Logic: Memo program has limited programmability
  • Upgrade Path: Clear upgrade path to smart contracts if needed
  • Cost Savings: Significant cost savings with Memo approach
  • Implementation Speed: Faster implementation with Memo program

ADR 0003: SAE Level 4 Autonomy Adoption Strategy​

Date: 2025-09-24
Status: Accepted (SAE Level 4 autonomy)

Context​

Need to determine the level of autonomy for the counter-drone system, balancing operational effectiveness with safety and compliance requirements.

Options Considered​

  • SAE Level 4 Autonomy: High automation within a defined Operational Design Domain (ODD); capable of performing all driving tasks without human intervention while inside the ODD, but may require fallback or limited operation outside it.
  • SAE Level 3 Autonomy: Conditional automation with human fallback
  • SAE Level 2 Autonomy: Partial automation with human monitoring
  • SAE Level 1 Autonomy: Driver assistance with human control
  • Hybrid Approach: Different autonomy levels for different scenarios

Decision​

Implement SAE Level 4 autonomy with comprehensive safety and compliance frameworks.

Rationale​

  • Operational Effectiveness: SAE Level 4 autonomy provides maximum operational effectiveness
  • Response Time: Sub-200ms response time requires autonomous operation
  • GPS-Denied Environments: Autonomous operation essential for GPS-denied environments
  • Safety Framework: Comprehensive safety framework ensures safe operation
  • Compliance: Full compliance with DoD Directive 3000.09
  • Industry Standard: SAE J3016 standard provides clear autonomy level definitions

Consequences​

  • Safety Requirements: Comprehensive safety framework required
  • Compliance: Full compliance with autonomous weapons policies
  • Testing: Extensive testing and validation required
  • Documentation: Comprehensive documentation of safety measures
  • SAE J3016 Compliance: Must adhere to SAE J3016 standard definitions
  • Industry Alignment: Aligns with automotive and aerospace autonomy standards

ADR 0004: Layered Strategy (L1/L2/L3)​

Date: 2025-09-24
Status: Accepted (Layered approach)

Context​

Need to determine the blockchain architecture strategy, considering Layer 1, Layer 2, and Layer 3 solutions for different use cases and requirements.

Options Considered​

  • L1 Only: Single Layer 1 solution
  • L2 Solutions: Layer 2 solutions for scaling
  • L3 Solutions: Layer 3 solutions for specific use cases
  • Layered Approach: Combination of L1/L2/L3 solutions

Decision​

Implement layered strategy with L1 anchoring, L2 scaling, and L3 applications.

Rationale​

  • Scalability: L2 solutions provide scalability for high-volume operations
  • Cost Efficiency: L2 solutions reduce transaction costs
  • Flexibility: L3 solutions provide flexibility for specific use cases
  • Security: L1 provides security and finality
  • Performance: L2 provides performance and throughput

Consequences​

  • Complexity: Increased complexity with layered approach
  • Integration: Complex integration between layers
  • Maintenance: Increased maintenance requirements
  • Performance: Improved performance and scalability

ADR 0005: Sensor Integration Architecture​

Date: 2025-09-24
Status: Accepted (Multi-sensor fusion)

Context​

Need to determine the sensor integration architecture for multi-modal threat detection and classification.

Options Considered​

  • Single Sensor: Single sensor type for detection
  • Multi-Sensor: Multiple sensor types for detection
  • Sensor Fusion: Advanced sensor fusion for detection
  • Hybrid Approach: Combination of approaches

Decision​

Implement multi-sensor fusion architecture with advanced sensor integration.

Rationale​

  • Accuracy: Multi-sensor fusion improves detection accuracy
  • Robustness: Multiple sensors provide robustness and redundancy
  • False Positive Reduction: Multi-sensor validation reduces false positives
  • Environmental Adaptation: Better performance across diverse environments

Consequences​

  • Complexity: Increased complexity with multi-sensor integration
  • Calibration: Complex sensor calibration and synchronization
  • Processing: Increased processing requirements
  • Performance: Improved detection performance and accuracy

ADR 0006: AI/ML Architecture​

Date: 2025-09-24
Status: Accepted (Edge AI with cloud backup)

Context​

Need to determine the AI/ML architecture for threat detection, classification, and response.

Options Considered​

  • Edge AI Only: All AI processing at edge
  • Cloud AI Only: All AI processing in cloud
  • Hybrid Approach: Edge AI with cloud backup
  • Distributed AI: Distributed AI across multiple nodes

Decision​

Implement edge AI with cloud backup and distributed learning capabilities.

Rationale​

  • Latency: Edge AI provides low-latency processing
  • Autonomy: Edge AI enables autonomous operation
  • Scalability: Cloud backup provides scalability
  • Learning: Distributed learning improves performance

Consequences​

  • Complexity: Increased complexity with hybrid approach
  • Integration: Complex integration between edge and cloud
  • Data Management: Complex data management requirements
  • Performance: Improved performance and capabilities

ADR 0007: Security Architecture​

Date: 2025-09-24
Status: Accepted (Zero-trust security)

Context​

Need to determine the security architecture for the counter-drone system, considering threats, vulnerabilities, and compliance requirements.

Options Considered​

  • Traditional Security: Traditional security approaches
  • Zero-Trust Security: Zero-trust security model
  • Defense in Depth: Multiple layers of security
  • Hybrid Approach: Combination of security approaches

Decision​

Implement zero-trust security architecture with defense in depth.

Rationale​

  • Threat Landscape: Zero-trust addresses modern threat landscape
  • Compliance: Meets compliance requirements
  • Security: Provides comprehensive security coverage
  • Flexibility: Adaptable to changing threats

Consequences​

  • Complexity: Increased complexity with zero-trust
  • Implementation: Complex implementation requirements
  • Maintenance: Increased maintenance requirements
  • Security: Improved security posture

ADR 0008: Compliance Architecture​

Date: 2025-09-24
Status: Accepted (Comprehensive compliance)

Context​

Need to determine the compliance architecture for regulatory requirements, including ITAR, DoD, and international standards.

Options Considered​

  • Basic Compliance: Basic compliance requirements
  • Comprehensive Compliance: Comprehensive compliance framework
  • Automated Compliance: Automated compliance monitoring
  • Hybrid Approach: Combination of compliance approaches

Decision​

Implement comprehensive compliance architecture with automated monitoring.

Rationale​

  • Regulatory Requirements: Meets all regulatory requirements
  • Risk Mitigation: Reduces compliance risks
  • Automation: Automated compliance monitoring
  • Documentation: Comprehensive compliance documentation

Consequences​

  • Complexity: Increased complexity with comprehensive compliance
  • Cost: Increased compliance costs
  • Maintenance: Increased maintenance requirements
  • Compliance: Improved compliance posture

ADR 0009: Integration Architecture​

Date: 2025-09-24
Status: Accepted (API-first integration)

Context​

Need to determine the integration architecture for third-party systems, cloud platforms, and external services.

Options Considered​

  • Custom Integration: Custom integration approaches
  • API-First Integration: API-first integration approach
  • Middleware Integration: Middleware-based integration
  • Hybrid Approach: Combination of integration approaches

Decision​

Implement API-first integration architecture with comprehensive API support.

Rationale​

  • Flexibility: API-first provides flexibility and scalability
  • Standardization: Standardized integration approaches
  • Compatibility: Better compatibility with existing systems
  • Maintenance: Easier maintenance and updates

Consequences​

  • Complexity: Increased complexity with API-first approach
  • Development: Increased development requirements
  • Documentation: Comprehensive API documentation required
  • Integration: Improved integration capabilities

ADR 0010: Performance Architecture​

Date: 2025-09-24
Status: Accepted (High-performance architecture)

Context​

Need to determine the performance architecture for the counter-drone system, considering latency, throughput, and scalability requirements.

Options Considered​

  • Standard Performance: Standard performance requirements
  • High Performance: High-performance requirements
  • Scalable Performance: Scalable performance architecture
  • Hybrid Approach: Combination of performance approaches

Decision​

Implement high-performance architecture with scalable performance capabilities.

Rationale​

  • Operational Requirements: Meets operational performance requirements
  • Competitive Advantage: Provides competitive performance advantages
  • Scalability: Scalable performance architecture
  • Future-Proofing: Future-proof performance architecture

Consequences​

  • Complexity: Increased complexity with high-performance architecture
  • Cost: Increased development and implementation costs
  • Maintenance: Increased maintenance requirements
  • Performance: Improved performance and capabilities

Conclusion​

The Architecture Decision Records provide a comprehensive record of key architectural decisions for the Phoenix Rooivalk system. These decisions ensure consistent architecture, knowledge preservation, and informed decision-making throughout the system development and deployment.

Key architectural decisions include:

  • Blockchain: Solana for evidence anchoring with layered architecture
  • Autonomy: SAE Level 4 autonomy with comprehensive safety frameworks
  • Sensors: Multi-sensor fusion for improved detection accuracy
  • AI/ML: Edge AI with cloud backup and distributed learning
  • Security: Zero-trust security with defense in depth
  • Compliance: Comprehensive compliance with automated monitoring
  • Integration: API-first integration with comprehensive support
  • Performance: High-performance architecture with scalability

These decisions provide the foundation for a robust, scalable, and effective counter-drone defense system that meets all operational, regulatory, and performance requirements.

This document contains confidential architectural information. Distribution is restricted to authorized personnel only. © 2025 Phoenix Rooivalk. All rights reserved.