# EWD-DigiFlow Constitution ## Core Principles ### I. Extreme Cost-Efficiency Every component MUST prioritize affordability and accessibility: - Hardware components MUST be sourced from standard Amazon marketplace or equivalent mass-market suppliers - Exotic or specialized components requiring supplier relationships are PROHIBITED - Total bill of materials (BOM) cost MUST be documented and minimized - Design decisions MUST favor cheaper alternatives unless technical requirements absolutely prevent it - Component substitution guides MUST be provided when multiple compatible options exist **Rationale**: Enables hobbyists and small-scale makers to reproduce the project without requiring bulk purchasing, special accounts, or expensive tooling. Amazon availability ensures global accessibility and price transparency. ### II. 3D Printing Reproducibility All physical components MUST be designed for hobbyist-level 3D printing: - Printable parts MUST fit within 200mm × 200mm × 200mm build volume (standard Ender 3 size) - Designs MUST NOT require support structures exceeding 30% part volume - Models MUST be provided in STL format with print-ready orientation - Print settings MUST be documented: layer height, infill, material (PLA/PETG/ABS) - Assembly instructions MUST include photos or diagrams showing part orientation - Tolerances MUST account for ±0.2mm print variance - Post-processing MUST be limited to basic tools: knife, sandpaper, soldering iron **Rationale**: Ensures anyone with a basic FDM printer can manufacture parts without industrial equipment, specialized slicing knowledge, or expensive materials. Standard bed size constraint guarantees accessibility. ### III. Lightweight Design Physical design MUST prioritize minimal weight to ensure measurement accuracy: - Total device weight (excluding measured object) MUST be under 150 grams - Load-bearing structures MUST use infill patterns and wall thickness for strength, not mass - Component mounting MUST avoid unnecessary brackets or fasteners - Weight distribution MUST be documented and optimized to prevent measurement drift - Calibration procedure MUST account for self-weight offset - Scale or sensor placement MUST minimize impact on small surface measurements **Rationale**: Heavy measurement devices introduce errors when placed on lightweight objects or small surfaces. Minimal weight ensures the device doesn't influence what it measures, critical for precision applications. ### IV. Software Simplicity (Plug-and-Play) Software MUST operate without complex installation or ecosystem dependencies: - NO app store submissions or account creation required - NO cloud services or internet connectivity required for core functionality - Firmware MUST support direct USB programming (no proprietary tools) - Data output MUST use standard protocols: USB serial, CSV files, or simple HTTP endpoints - Configuration MUST use plain text files (JSON/YAML) or physical switches/buttons - Libraries MUST use permissive licenses (MIT, Apache 2.0, BSD) - Setup procedure MUST NOT exceed 3 steps: connect hardware, flash firmware, run **Rationale**: Eliminates friction for users unfamiliar with complex development environments. Avoids platform lock-in (iOS/Android gatekeeping), subscription models, and proprietary ecosystems. Users own and control their device completely. ## Hardware Design Requirements ### Component Selection - MUST provide Amazon ASIN or equivalent marketplace identifier for each component - MUST include at least 2 alternative suppliers/models for critical components - MUST document component specifications (voltage, current, communication protocol) - MUST verify component availability in US, EU, and Asia markets ### Assembly Standards - Fasteners MUST use metric sizes (M2, M3, M4) commonly available in assortment kits - Soldering MUST be limited to through-hole components where possible; SMD only if unavoidable - Cable lengths and connector types MUST be specified in BOM - Assembly time for experienced maker MUST NOT exceed 4 hours ### Testing & Validation - MUST provide calibration procedure using household reference objects - MUST document expected measurement accuracy and precision - MUST include troubleshooting guide for common assembly errors - MUST test with at least 3 different 3D printer brands/models before release ## Software Development Requirements ### Firmware - MUST target widely-available microcontroller platforms (ESP32, Arduino, RP2040) - MUST use Arduino framework or PlatformIO for maximum compatibility - MUST include pre-compiled binary for users without development environment - MUST document flashing procedure for Windows, macOS, and Linux ### Code Quality - MUST use descriptive variable names and comments for non-obvious logic - MUST avoid platform-specific extensions that limit portability - MUST keep total firmware size under 80% of target microcontroller flash capacity - MUST validate all sensor inputs and handle error conditions gracefully ### Data Interface - Serial output MUST use human-readable format (CSV or JSON lines) - MUST provide baud rate and data format in documentation - MUST include example Python/JavaScript code for reading data - Optional web interface MUST NOT require external dependencies or build steps ## Governance ### Amendment Procedure 1. Proposed changes MUST be documented with rationale 2. Impact analysis MUST verify alignment with all four core principles 3. Changes affecting BOM, weight, or software dependencies require version bump 4. Community feedback period (if applicable) MUST be at least 7 days for major changes ### Versioning Policy - **MAJOR**: Principle removal/redefinition, incompatible BOM changes, new tooling requirements - **MINOR**: New principle added, expanded component options, additional features - **PATCH**: Clarifications, documentation improvements, specification corrections ### Compliance Review - All design changes MUST pass constitution check before implementation - Pull requests MUST document which principles are affected and how compliance is maintained - Complexity that violates principles MUST be justified in writing and approved - Default answer to "should we add this feature?" is NO unless it serves core principles **Version**: 1.0.0 | **Ratified**: 2026-01-22 | **Last Amended**: 2026-01-22