# Goals

The primary objective of this private WorkDash analysis workflow is to establish a privacy-preserving, locally executed pipeline that extracts meaningful productivity and communication insights from real email and Microsoft Teams data while guaranteeing that all raw private content never leaves the home lab environment. The workflow is designed to serve two distinct but complementary purposes: (1) providing the home lab owner with actionable, fine-grained analytics to optimize personal workflow, and (2) enabling the generation of public-facing benchmark reports that are strictly synthetic or redacted, ensuring zero exposure of sensitive information.

Key goals include:
- **Privacy-First Architecture**: Implement a zero-exfiltration design where WorkDash ingests data via local connectors, processes everything on-premises, and stores raw content in encrypted, access-controlled volumes. No network egress is permitted for raw or semi-structured data.
- **Fine-Grained Local Classification**: Deploy a quantized open-source language model capable of multi-dimensional classification (intent, urgency, sentiment, domain, actionability, stakeholder sensitivity) with structured JSON outputs. The model operates entirely offline, ensuring that semantic understanding never requires cloud inference.
- **Controlled Redaction & Synthetic Generation**: Develop a multi-layer redaction pipeline that preserves analytical utility while stripping or pseudonymizing personally identifiable information (PII), project identifiers, and contextual secrets. Complement this with a deterministic synthetic data generator that mirrors real data distributions for benchmarking and public reporting.
- **Owner Utility & Benchmarking Parity**: Ensure the reporting plane remains highly useful to the home lab owner by maintaining real metrics, trend analysis, and actionable recommendations in a local dashboard. Simultaneously, design the public output plane to be statistically representative and methodologically transparent, allowing external validation without compromising privacy.
- **Auditability & Continuous Improvement**: Establish clear retention policies, human-in-the-loop review workflows, and feedback mechanisms that allow the local model and redaction rules to evolve over time without violating privacy boundaries.

# Data That Must Stay Local

All raw communication data ingested by WorkDash must remain strictly local. This includes, but is not limited to:
- **Email Content**: Full message bodies, attachments (metadata only), headers, sender/recipient addresses, CC/BCC lists, and calendar invites.
- **Teams Messages**: Chat threads, channel posts, replies, reactions, file shares, meeting transcripts, and presence indicators.
- **Auxiliary Context**: Task lists, project boards, calendar events, device logs, network metadata, and local file system references tied to communication threads.

**Storage Architecture**:
- Raw data is persisted on encrypted block storage (e.g., LUKS or VeraCrypt) mounted read-write only by the WorkDash ingestion service.
- A dedicated local virtual machine or container runtime isolates the analysis pipeline from the host OS. Network interfaces are configured with strict egress filtering (iptables/nftables) allowing only outbound HTTPS for model updates or telemetry opt-ins, never for data transmission.
- Data is chunked into immutable, timestamped archives (e.g., Parquet or SQLite with WAL mode) to prevent accidental modification and enable point-in-time recovery.

**Security Controls**:
- AES-256-GCM encryption at rest with keys managed via a local hardware security module (HSM) or encrypted keyring (e.g., `pass` or `age`).
- Role-based access control (RBAC) restricts ingestion, classification, and export services to specific service accounts.
- Comprehensive audit logging records every access, classification run, redaction operation, and export event. Logs are stored locally and rotated monthly.
- Zero-knowledge ingestion: WorkDash connectors operate in a local-only mode, reading from exported PST/MSG files, local Teams cache dumps, or IMAP/POP3 with TLS termination at the network edge. No cloud sync, no third-party APIs, no telemetry exfiltration.

**Retention & Cleanup**:
- Raw content is retained for a configurable window (default: 90 days) before automated cryptographic erasure.
- Only derived artifacts (classification labels, aggregated metrics, redacted summaries) persist beyond the retention window.
- Backup strategies use encrypted, air-gapped storage media with strict access controls and periodic integrity verification.

# Local Classification

The classification engine is the analytical core of the workflow, responsible for transforming unstructured communication into structured, actionable signals. It operates entirely on-premises using a quantized open-source language model (e.g., Llama 3 8B, Mistral 7B, or Phi-3 Mini) served via Ollama, vLLM, or llama.cpp.

**Model Configuration**:
- Quantization: 4-bit or 8-bit GGUF/Q4_K_M for balanced performance and accuracy on consumer-grade hardware.
- Context Window: 8K–16K tokens, sufficient for full email threads or Teams channel excerpts.
- Inference Hardware: Dedicated GPU (e.g., RTX 4060/4070) or CPU with AVX-512 support, with batch processing enabled for throughput optimization.

**Fine-Grained Classification Schema**:
Each message or thread is classified across multiple orthogonal dimensions:
1. **Intent**: Decision, Question, Update, Request, Escalation, Social/Informal, Administrative.
2. **Urgency**: Low, Medium, High, Critical (based on temporal markers, explicit language, and follow-up patterns).
3. **Sentiment**: Positive, Neutral, Negative, Mixed, Anxious/Conflicted.
4. **Domain**: Technical, Operational, Financial, HR/Compliance, Personal, Cross-Functional.
5. **Actionability**: Requires Response, Requires Action, Informational, Archive-Only.
6. **Stakeholder Sensitivity**: Public, Internal, Confidential, Restricted (based on keyword density, recipient roles, and explicit flags).

**Prompt Engineering & Output Structure**:
- System prompts enforce strict JSON schema compliance, privacy boundaries, and confidence scoring.
- Few-shot examples are embedded locally to stabilize output format across model versions.
- Output includes: `classification`, `confidence_scores`, `reasoning_summary`, `pii_flags`, `redaction_recommendations`.

**Pipeline Workflow**:
1. **Ingestion & Chunking**: Raw messages are normalized, deduplicated, and split into logical units (thread, reply, attachment reference).
2. **Preprocessing**: Tokenization, stop-word removal (configurable), and context window alignment.
3. **Local Inference**: Batched requests to the quantized model with temperature=0.1 for deterministic outputs.
4. **Validation & Routing**: Outputs are validated against schema constraints. Low-confidence classifications (<0.75) or high-sensitivity flags are routed to human review.
5. **Storage**: Results are written to a local vector database (e.g., Chroma, Qdrant) or relational store (SQLite/PostgreSQL) with full indexing for dashboard queries.

**Continuous Improvement**:
- Human review corrections are stored locally and used to refine prompts or train lightweight LoRA adapters.
- Periodic evaluation against a held-out synthetic dataset ensures classification stability.
- Model updates are applied via versioned containers with rollback capability.

# Redaction Strategy

Redaction is the critical bridge between private analysis and public benchmarking. The strategy employs a multi-layered, context-aware approach to ensure that sensitive information is removed or pseudonymized while preserving analytical utility.

**Layer 1: Rule-Based PII Detection**
- Regex patterns for emails, phone numbers, IP addresses, MAC addresses, credit card formats, and government ID patterns.
- Custom dictionaries for known project codes, internal domain names, and frequently used aliases.
- Fast, deterministic, and applied first to catch obvious leaks.

**Layer 2: Semantic Entity Recognition**
- A lightweight local NER model (e.g., spaCy with custom training or a quantized LLM) identifies names, organizations, locations, dates, and monetary values.
- Contextual disambiguation prevents false positives (e.g., distinguishing "Apple" the company from "apple" the fruit).
- Outputs are mapped to redaction targets with confidence thresholds.

**Layer 3: Contextual Masking & Pseudonymization**
- Replaced entities are substituted with deterministic hashes or structured placeholders (e.g., `USER_0x7A3F`, `PROJ_ALPHA`, `DATE_2024-05-12`).
- Sentence structure, punctuation, and semantic flow are preserved to maintain readability for aggregate analysis.
- Cross-reference resolution ensures that repeated mentions of the same entity receive consistent pseudonyms within a given report.

**Verification & Quality Assurance**:
- Post-redaction scanning runs a secondary PII detector to catch missed entities.
- Statistical checks verify that redaction rates align with expected distributions.
- Human reviewers spot-check a random sample (5–10%) of redacted outputs before public release.

**Granularity Control**:
- Configurable redaction levels: `Light` (only explicit PII), `Medium` (PII + project codes + internal names), `Strict` (PII + pseudonyms + contextual masking).
- Level selection is tied to the output audience and benchmarking requirements.

**Audit Trail**:
- Every redaction operation logs the original field, applied rule, replacement value, and confidence score.
- Logs are stored locally and accessible for internal audits or dispute resolution.

# Synthetic Test Generation

Synthetic data generation ensures that public-facing benchmark reports are statistically representative while containing zero real private information. The pipeline is designed to be reproducible, auditable, and distribution-aligned.

**Generation Architecture**:
- **Template Engine**: Defines schemas for emails, Teams messages, calendar events, and task items with realistic structures (headers, threading, metadata).
- **LLM Augmentation**: A local model generates content under strict negative constraints (no real names, addresses, companies, or identifiable projects). Prompts enforce tone, domain, and intent diversity.
- **Distribution Matching**: Statistical parameters (volume, category frequencies, sentiment spread, response latency distributions) are calibrated to mirror historical local data without copying it.

**Edge Case Injection**:
- Rare but critical scenarios are deliberately generated: ambiguous requests, conflict escalation, urgent deadlines, cross-timezone coordination, and low-signal noise.
- These stress-test classification accuracy, redaction robustness, and metric aggregation logic.

**Validation Process**:
- **Statistical Tests**: Kolmogorov-Smirnov, chi-square, and Jensen-Shannon divergence verify distribution alignment between real and synthetic datasets.
- **Human Plausibility Review**: Domain experts or the home lab owner review a sample for realism and coherence.
- **Security Scanning**: Automated PII detectors confirm zero leakage of real identifiers.

**Usage in Benchmarking**:
- Synthetic datasets replace real data in public reports, CI/CD pipelines, and documentation examples.
- They enable reproducible experiments, model evaluation, and third-party validation without privacy risk.
- Versioned synthetic datasets are archived alongside methodology documentation for transparency.

# Metrics To Keep

The reporting plane retains metrics that are privacy-preserving, analytically valuable, and actionable for the home lab owner. All metrics are aggregated, normalized, or anonymized before any external exposure.

**Productivity & Workflow Metrics**:
- Message volume per channel/domain (daily/weekly/monthly)
- Average response latency (hours/minutes)
- Task completion rate vs. creation rate
- Meeting-to-action conversion ratio
- After-hours activity index (messages outside standard hours)

**Communication Pattern Metrics**:
- Channel usage distribution (email vs. Teams vs. calendar)
- Cross-functional collaboration index (unique sender-recipient pairs)
- Thread depth and reply chain length
- Attachment frequency and type distribution
- Sentiment trend over time (positive/neutral/negative ratio)

**Classification & Quality Metrics**:
- Classification confidence distribution (mean, median, percentile)
- Low-confidence flag rate
- Human review override rate
- Redaction accuracy rate (precision/recall against manual audit)
- PII detection false positive/negative rates

**Privacy & Compliance Metrics**:
- Data retention compliance score (% of raw data purged on schedule)
- Encryption key rotation status
- Audit log completeness rate
- Zero-exfiltration verification score

**Output Formatting**:
- Owner dashboard: Real-time metrics, trend lines, heatmaps, percentile rankings, and actionable recommendations.
- Public benchmark: Aggregate statistics, normalized scores, methodology descriptions, and synthetic examples. No raw text, no identifiable data, no unaggregated counts.

# Human Review

Human review is integrated as a safety net and continuous improvement mechanism, ensuring that automated classification and redaction meet quality standards without compromising privacy.

**Workflow Design**:
1. **Automated Triage**: WorkDash classifies all ingested content. Items flagged as low-confidence, high-sensitivity, or ambiguous are queued for review.
2. **Review Interface**: A local web application or CLI tool presents side-by-side views: raw content, classification output, redaction preview, and suggested actions.
3. **Decision Logging**: Reviewers approve, modify, or reject classifications/redactions. Changes are logged with timestamps, reviewer ID, and rationale.
4. **Feedback Integration**: Corrected labels are stored locally and used to refine prompts, adjust confidence thresholds, or train LoRA adapters.
5. **Escalation Path**: Persistent low-confidence items or conflicting classifications trigger a secondary review cycle or manual tagging.

**Operational Controls**:
- Review quotas and rotation schedules prevent fatigue and maintain consistency.
- Inter-rater reliability checks are performed monthly to calibrate reviewer alignment.
- Review data is never exported; it remains within the local audit system.

**Training & Governance**:
- Owner and any delegated reviewers receive training on privacy boundaries, redaction expectations, and metric interpretation.
- Governance policies define retention, access, and audit requirements. Regular privacy impact assessments are conducted.
- Review workflows are versioned and documented to ensure reproducibility.

# Failure Modes

Anticipating and mitigating failure modes is critical to maintaining privacy, accuracy, and system reliability.

**Model Hallucination**:
- *Risk*: Fabricated entities, incorrect classifications, or overconfident low-confidence outputs.
- *Mitigation*: Confidence thresholds, schema validation, fallback to rule-based classification, and human review routing.

**Over-Redaction**:
- *Risk*: Loss of analytical value, unreadable summaries, or distorted metrics.
- *Mitigation*: Context-aware redaction, adjustable sensitivity levels, post-redaction readability checks, and human validation.

**Under-Redaction**:
- *Risk*: PII leakage, compliance violations, or benchmark contamination.
- *Mitigation*: Multi-layer scanning, secondary verification, strict network egress policies, and automated pre-export checks.

**Performance Bottlenecks**:
- *Risk*: Slow inference, memory exhaustion, or ingestion delays on consumer hardware.
- *Mitigation*: Quantization, batch processing, GPU/CPU offloading, caching, and rate limiting. Asynchronous pipelines decouple ingestion from classification.

**Data Drift**:
- *Risk*: Changes in communication patterns degrade classification accuracy over time.
- *Mitigation*: Periodic re-evaluation, prompt updates, synthetic data refresh, and adaptive threshold tuning.

**Key Compromise**:
- *Risk*: Encryption keys exposed, leading to raw data decryption.
- *Mitigation*: Secure key storage (HSM/encrypted keyring), rotation policies, zero-knowledge design where possible, and strict access controls.

**Benchmark Contamination**:
- *Risk*: Real data accidentally included in public reports.
- *Mitigation*: Strict pipeline separation, automated pre-export validation, manual sign-off requirements, and versioned synthetic datasets.

**Network Misconfiguration**:
- *Risk*: Accidental egress of semi-structured data due to firewall rules or proxy misconfiguration.
- *Mitigation*: Default-deny egress policies, network segmentation, regular penetration testing, and automated traffic monitoring.

# Example Private Summary

*Note: This summary is generated exclusively for local use and must never be transmitted outside the home lab environment.*

**WorkDash Private Analysis Summary – Week 24**
**Period**: 2024-06-10 to 2024-06-16
**Data Sources**: Outlook (IMAP), Teams (Local Cache Export)
**Raw Records Processed**: 1,842 messages, 34 threads, 12 calendar events

**Key Findings**:
- Message volume increased by 18% compared to the previous week, driven primarily by cross-functional project updates in the #devops-automation channel.
- Average response latency dropped to 2.4 hours, a 12% improvement, indicating better async coordination.
- 63% of messages were classified as "Informational" or "Update", while 22% required actionable follow-up.
- Sentiment analysis shows a neutral-to-positive trend (68% neutral, 24% positive, 8% negative), with negative spikes correlating with deployment windows.

**Communication Patterns**:
- Email usage decreased by 15%, with migration to Teams channels accelerating.
- After-hours activity accounts for 14% of total messages, predominantly from the #incident-response channel.
- Thread depth averaged 4.2 replies, with 12% of threads exceeding 8 replies, indicating complex coordination needs.

**Action Items**:
- Review #devops-automation channel tagging conventions to reduce notification fatigue.
- Schedule a 30-minute sync for the #data-pipeline-refactor thread to resolve ambiguous action items.
- Archive 47 messages classified as "Archive-Only" to reduce inbox clutter.

**Privacy Note**: This summary contains real metrics, project codes, and internal channel references. It is stored locally in `~/workdash/private/summaries/week24.json` and encrypted at rest. No raw message content is included. Access is restricted to the home lab owner via RBAC.

# Example Publishable Summary

*Note: This summary is sanitized, aggregated, and generated for public benchmarking. All identifiers are pseudonymized or replaced with synthetic equivalents.*

**WorkDash Benchmark Report – Public Release v1.2**
**Methodology**: Local-only classification pipeline using quantized open-source LLM. Redaction applied via multi-layer PII detection and contextual masking. Synthetic test generation used for public examples.

**Overview**:
This report presents aggregate communication analytics derived from a privacy-preserving home lab workflow. All raw content remains local; public outputs use synthetic or redacted data to ensure zero exposure of sensitive information.

**Key Findings (Aggregate)**:
- Message volume distribution follows a log-normal pattern, with 70% of activity concentrated in 30% of active channels.
- Average response latency clusters around 2–3 hours, with 90th percentile exceeding 8 hours during peak coordination windows.
- Classification confidence averages 0.84, with low-confidence flags (<0.75) accounting for 11% of processed items.
- Redaction accuracy rate: 96.2% precision, 94.8% recall against manual audit samples.

**Synthetic Example (Redacted)**:
> **Subject**: [REDACTED] Pipeline Update – Phase 2
> **From**: USER_0x7A3F → USER_0xB2C1
> **Content**: Deployment scheduled for [DATE_REDACTED]. Please verify staging environment readiness. Action required by [TIME_REDACTED].
> **Classification**: Intent=Request, Urgency=High, Sentiment=Neutral, Actionability=Requires Action
> **Redaction Level**: Medium (PII + project codes masked)

**Benchmarking Insights**:
- Synthetic datasets maintain distribution alignment (KS p-value > 0.05) while containing zero real identifiers.
- Multi-layer redaction preserves 89% of semantic readability while eliminating 99.4% of PII tokens.
- Human review override rate: 7.3%, primarily for ambiguous intent and cross-domain requests.

**Limitations**:
- Metrics are aggregated and normalized; individual thread analysis is not available in public outputs.
- Synthetic data may not capture rare edge cases present in real workflows.
- Classification accuracy varies by domain and language complexity.

**Reproducibility**:
- Pipeline configuration, prompt templates, and synthetic generation scripts are versioned and available under a privacy-compliant license.
- Public reports are generated via automated CI/CD with mandatory redaction validation and manual sign-off.

# Table of Fields: Keep / Drop / Redact Decisions

| Field Name | Data Type | Decision | Rationale | Retention Policy | Output Audience |
|------------|-----------|----------|-----------|------------------|-----------------|
| Sender/Recipient Names | String | Redact | PII, direct identifier | Cryptographic erase after classification | Public: Pseudonymized / Owner: Local only |
| Email Addresses | String | Redact | PII, contact identifier | Cryptographic erase after classification | Public: Hashed / Owner: Local only |
| Phone Numbers | String | Redact | PII, direct identifier | Cryptographic erase after classification | Public: Masked / Owner: Local only |
| Subject Lines | String | Redact (Medium) | May contain project codes, urgency markers | Retain redacted version for metrics | Public: Redacted / Owner: Local only |
| Message Body | Text | Redact (Strict) | High PII density, context-sensitive | Raw erased; redacted text retained for analysis | Public: Synthetic/Redacted / Owner: Local only |
| Timestamps | DateTime | Keep | Temporal analysis, latency metrics | Retain for trend analysis | Public: Aggregated / Owner: Local only |
| Calendar Titles | String | Redact (Medium) | May contain project names, meeting types | Retain redacted version | Public: Redacted / Owner: Local only |
| Task Descriptions | Text | Redact (Medium) | May contain actionable PII, project details | Retain redacted version | Public: Redacted / Owner: Local only |
| File Names | String | Redact | May contain sensitive project identifiers | Cryptographic erase after metadata extraction | Public: Hashed / Owner: Local only |
| IP/Device IDs | String | Drop | Network telemetry, not analytical | Immediate drop | None |
| Sentiment Score | Float | Keep | Aggregate metric, non-identifiable | Retain for dashboard | Public: Aggregated / Owner: Local only |
| Classification Labels | String | Keep | Derived metadata, privacy-safe | Retain for audit & improvement | Public: Aggregated / Owner: Local only |
| Confidence Scores | Float | Keep | Quality metric, non-identifiable | Retain for model evaluation | Public: Aggregated / Owner: Local only |
| Action Items | Text | Redact (Medium) | May contain PII, deadlines, project codes | Retain redacted version | Public: Redacted / Owner: Local only |
| Project Codes | String | Redact | Internal identifier, sensitive context | Retain pseudonymized version | Public: Pseudonymized / Owner: Local only |
| Meeting Duration | Integer | Keep | Aggregate metric, non-identifiable | Retain for trend analysis | Public: Aggregated / Owner: Local only |
| Response Latency | Float | Keep | Productivity metric, non-identifiable | Retain for dashboard | Public: Aggregated / Owner: Local only |
| Channel/Thread ID | String | Drop | Internal routing identifier | Immediate drop | None |
| Attachment Metadata | JSON | Keep (Metadata only) | File type, size, count for analytics | Retain anonymized metadata | Public: Aggregated / Owner: Local only |
| Reaction/Emoji Data | String | Keep | Engagement metric, non-identifiable | Retain for trend analysis | Public: Aggregated / Owner: Local only |

This table ensures that every field is explicitly categorized according to privacy requirements, analytical utility, and output audience. Decisions are enforced at the pipeline level, with automated validation preventing unauthorized retention or export. The workflow remains fully operational for the home lab owner while guaranteeing that public benchmark outputs are strictly synthetic or redacted, preserving both utility and privacy.