OZM Legal & Architecture Summary: The "Legal FPGA"

Concept: Governance as Structural Determinism

The core philosophy of the OZM project's legal and security architecture is the "Legal FPGA". Just as an FPGA (Field-Programmable Gate Array) enforces logic through physical hardware connections rather than software instructions, our governance is enforced through structural determinism.

  • Rule by Structure, not Policy: We do not rely on users reading privacy policies or terms of service. We rely on a system architecture that physically prevents violations (e.g., no hard drives for user data, no internet connection for sensitive nodes).
  • Predictability: The system’s behavior regarding data is deterministic. It does not "decide" to process data; it is wired to process data in a specific, transient way.
  • Transparency: The constraints are visible and verifiable, much like an open hardware schematic.

Hardware Strategy: FPGA vs. SoC

We distinguish between two types of computing paradigms which mirror our legal approach:

  1. SoC (System on Chip) / Probabilistic:

    • Examples: Raspberry Pi 5 with Hailo, Jetson Orin, Modern CPUs/GPUs.
    • Role: Heavy lifting, AI inference, "thinking".
    • Nature: Probabilistic, complex, "black box" software stacks.
    • Legal Equivalent: A standard contract or EULA—flexible but prone to interpretation and "bugs".

  2. FPGA / Deterministic:

    • Examples: Lattice FPGAs, Microcontrollers (ESP32 in specific modes), Discrete Logic.
    • Role: Safety critical timing, LED bus control, hardware interlocks.
    • Nature: Deterministic, cycle-accurate, verifyable.
    • Legal Equivalent: A physical key or a circuit breaker—it works one way, every time.

Strategic Decision: We use SoCs (like the Pi 5) for their power, but we wrap them in a "Legal FPGA" framework—a deterministic environment that constrains their capabilities to ensure safety.

Three-Model Strategy

To accommodate different use cases while maintaining safety, we define three operational models:

1. Local Core (The "Waldmitte" Standard)

  • Operator: The local crew (e.g., OZM Hamburg).
  • Data: Strictly local. No cloud.
  • Identity: No consistent user accounts. "Session-based" identity only.
  • Connectivity: Air-gapped or strictly firewalled (VLAN).
  • Safety: Physical supervision by the crew.

2. Self-Host / Replication

  • Operator: The user (e.g., a school, a family, another collective).
  • Data: Controlled entirely by the user.
  • Identity: User's choice.
  • Connectivity: User's choice (Mesh, VPN, or Offline).
  • Safety: Responsibility shifts to the self-hosting operator. We provide the tools code, they provide the governance.

3. Online-Light (Optional/Special Case)

  • Operator: OZM (or trusted partner).
  • Data: Minimal, transient, strictly regulated.
  • Identity: Minimal necessary (e.g., invite codes).
  • Usage: For users without hardware (e.g., TTYD web interface).
  • Legal: Full GDPR compliance, "Betreiberverantwortung" (Operator Liability). strictly separated from the Local Core.

Child Protection Policies

Our architecture is designed fundamentally for child protection, adhering to the "Nullfeld" principle.

  • No Persistent Identities: We do not track "User X" over time. When a session ends, the data is gone.
  • No Private Channels: There are no Direct Messages (DMs) or hidden chat rooms. All interaction is public and visible within the physical or digital space of the installation. "Light is the best disinfectant."
  • Local-First: Data stays physically where the child is. It does not travel to a server in another country.
  • Reset Culture: The system is designed to be wiped/reset easily. Mistakes are not recorded forever.

Legal Compliance (GDPR)

  • Data Minimization: We collect only what is needed for the immediate interaction (e.g., a drawing, a temporary voice command).
  • Purpose Limitation: Data is used only for the art/interaction, never for tracking or advertising.
  • Storage Limitation: Data is deleted immediately after the interaction or session ends.
  • DSFA (Data Protection Impact Assessment): Given the "Local Core" architecture with no persistence and no special category data storage, a formal mandatory DSFA is likely not required, but we perform an internal Risk Assessment to ensure we meet our own ethical standards.