Technical Principles

Architectural Requirements for Complicity Auditing

Data IsolationLocal-First Persistence

Introduction: Architectural Consistency

A platform designed to audit moral responsibility must be structurally consistent with its own methodology. Systemic complicity cannot be examined using infrastructure that is itself complicit in the extraction and centralization of user data. This document records the technical decisions made to maintain the integrity of the 4 Guilts diagnostic.

The Problem: Complicit Infrastructure

Standard web application architectures often facilitate collective irresponsibility:

  • Centralized data harvesting for behavioral analytics.
  • Engagement-maximizing patterns that prioritize retention over reflection.
  • Privacy treated as a legal disclosure rather than a physical constraint.
  • Architectures optimized for data extraction rather than user autonomy.

The storage of an individual's complicity audit on a centralized server would be a fundamental failure of project integrity. A different protocol is utilized here.

The Solution: Local-First Architecture

Development Decisions

  • Local storage: Data is isolated to the user's specific hardware.
  • Zero tracking: Monitoring of user behavior or inputs is inactive.
  • Offline capability: The audit functions without network connectivity.
  • Functionality-first: Notifications and retention-based features are omitted.

Core Constraints

  • Absence of centralized databases for user data.
  • Anonymous usage by default.
  • Transparent scoring logic.
  • Minimal resource footprint.

Implementation Details

Data Isolation Protocol

Every technical decision reflects the requirement for user autonomy:

// Data handling methodology
const dataIsolation = {
  boundary: "The user's device",
  implementation: "IndexedDB for local persistence",
  result: "User data is physically inaccessible to the server"
}

Privacy as a Constraint

Privacy protection is a baseline requirement of the system:

// System settings
const defaultSettings = {
  dataStorage: 'local-only',
  serverSync: 'disabled',
  thirdPartyAnalytics: 'none',
  tracking: 'inactive'
}

System Validation

Verification of project consistency across multiple dimensions:

User Autonomy

Isolated data storage as a baseline safeguard.

Operational Equity

Optimization for performance on lower-specification hardware.

Resource Efficiency

Minimal load times and energy usage.

Methodological Rigor

Adherence to the Jaspers framework.

Verification

Technical Observations

  • • Privacy-by-design improves performance by eliminating third-party scripts.
  • • Transparent scoring builds user confidence in diagnostic findings.
  • • Local-first storage ensures the audit is persistent regardless of server status.
  • • Minimal dependencies reduce the potential attack surface.

User Experience Realities

  • • Transparency > Engagement: Clarity is prioritized over manipulation.
  • • Anonymity = Honesty: Data isolation facilitates unsparing self-examination.
  • • Accessibility: The tool remains functional in low-connectivity environments.
  • • Focus: A zero-tracking environment supports the serious nature of the audit.

Execute the Audit

Proceed to the diagnostic under the data isolation protocol.

Conclusion: Integrity in Design

This application serves as a proof of concept that technology can support individual autonomy and systemic truth-telling without participating in data extraction.

"Technical integrity requires building without tracking."

Technical principles for operational integrity.

A methodology for auditing complicity cannot be built on a foundation of extraction.