# Goals

The WorkDash analysis workflow is designed to operate as a fully self-contained, privacy-preserving communication analytics engine optimized for a home-lab environment. The primary objective is to ingest, process, and derive actionable insights from real-world email and Microsoft Teams messages while guaranteeing that no raw private content ever leaves the local network boundary. The system must balance three competing demands: high-fidelity personal utility for the owner, rigorous privacy enforcement, and the ability to produce externally shareable benchmark reports that demonstrate system capability without compromising data sovereignty.

**Core Objectives:**
1. **Zero-Exfiltration Architecture:** All data ingestion, storage, model inference, and reporting generation occur on-premises. Network egress is restricted to essential package updates and explicitly approved synthetic data exports. No raw messages, embeddings, or metadata are transmitted to cloud APIs.
2. **Fine-Grained Local Classification:** Leverage a locally hosted language model to perform multi-dimensional tagging (urgency, sentiment, actionability, sensitivity, topic clustering) with high precision. The classifier must adapt to the owner's communication patterns, project nomenclature, and workflow preferences without external fine-tuning services.
3. **Dual-Plane Reporting:** Maintain a high-fidelity private dashboard for the owner that preserves context, PII, and raw message excerpts, while simultaneously generating a sanitized, benchmark-ready reporting plane that uses deterministic redaction and synthetic data generation. Both planes must remain structurally aligned to ensure metric consistency.
4. **Benchmark-Ready Output:** Produce reproducible, statistically valid reports that can be shared with external communities, research groups, or open-source benchmarking initiatives. These reports must demonstrate classification accuracy, redaction efficacy, and system throughput while containing zero identifiable information.
5. **Human-in-the-Loop Calibration:** Provide intuitive override mechanisms, audit trails, and feedback loops that allow the owner to correct misclassifications, adjust sensitivity thresholds, and continuously improve the local model through on-device reinforcement learning or prompt refinement.
6. **Resource-Aware Home-Lab Optimization:** Design the pipeline to run efficiently on consumer-grade hardware (e.g., RTX 3060/4070, 32GB RAM, NVMe storage) using quantized models, batch processing, and lightweight orchestration. The system must be resilient to power interruptions, network fluctuations, and storage constraints typical of home environments.

The workflow is structured as a modular data pipeline: ingestion → normalization → local classification → dual-plane transformation → metric aggregation → human review → export. Each stage enforces strict data boundaries, ensuring that privacy controls are baked into the architecture rather than applied as an afterthought.

# Data That Must Stay Local

Data sovereignty is the foundational constraint of this workflow. The following categories of information are classified as strictly local and must never traverse the home-lab network boundary, regardless of processing stage or export intent:

**1. Raw Communication Content:**
- Full email bodies (HTML, plain text, multipart)
- Teams chat messages, channel posts, and direct messages
- Thread context, reply chains, and conversation metadata
- Embedded links, inline images, and OLE objects
- Voice message transcripts and meeting chat logs

**2. Identifiable Metadata:**
- Sender/recipient email addresses and display names
- Internal usernames, employee IDs, or directory aliases
- Timestamps with sub-minute precision (to prevent correlation attacks)
- Routing headers, X-OriginatorInfo, and server hop data
- Calendar event titles, locations, and attendee lists

**3. Project & Organizational Context:**
- Internal project codenames, ticket IDs (Jira, GitHub, Linear)
- Department names, team structures, and reporting lines
- Confidential business logic, financial figures, or strategic plans
- Vendor contracts, NDAs, or legal correspondence
- Personal notes, drafts, or out-of-office messages

**4. Model Artifacts & Processing Logs:**
- Raw embeddings, attention maps, or token-level activations
- Inference logs containing prompt inputs or intermediate reasoning traces
- Fine-tuning datasets, LoRA adapters, or gradient snapshots
- Redaction mapping tables that could reverse-anonymize outputs
- Audit logs linking user actions to specific message IDs

**Storage & Isolation Architecture:**
All local data resides on an encrypted volume (LUKS2 or BitLocker with AES-256-XTS) mounted on a dedicated analysis partition. The ingestion layer uses read-only IMAP/Exchange and Microsoft Graph API connectors running in isolated Docker containers with no outbound network rules. Data is normalized into a local PostgreSQL database with row-level security and column-level encryption for high-sensitivity fields. Ephemeral processing containers handle classification and redaction, with memory scrubbing and secure deletion policies enforced via `shred` and `dm-crypt` wipe routines. Network isolation is maintained through a dedicated VLAN, firewall rules blocking all egress except whitelisted package repositories, and Tailscale/ZeroTier for secure remote administration. Backup routines use encrypted tarballs stored on offline drives, with rotation policies ensuring no single backup contains more than 30 days of raw data.

# Local Classification

The classification engine is the analytical core of WorkDash, responsible for transforming unstructured communication into structured, actionable insights. It operates entirely on-premises using a quantized large language model optimized for low-latency inference and high precision on fine-grained tagging tasks.

**Model Selection & Deployment:**
The primary classifier uses a 7B-8B parameter model (e.g., Llama-3-Instruct or Mistral-7B) quantized to Q4_K_M or Q5_K_S format via GGUF or AWQ. This balances accuracy with home-lab hardware constraints, enabling ~15-25 tokens/sec inference on consumer GPUs. The model is deployed via llama.cpp or vLLM in a containerized environment with CPU/GPU fallback routing. For latency-critical tasks, a smaller DeBERTa-v3 or RoBERTa classifier handles binary/multi-label routing, while the LLM handles complex semantic tagging.

**Classification Taxonomy:**
The model outputs a structured JSON payload containing the following dimensions:
- **Urgency:** Low, Medium, High, Critical (based on temporal cues, explicit deadlines, and escalation language)
- **Sentiment:** Negative, Neutral, Positive, Mixed (with confidence scores and emotional valence)
- **Actionability:** None, Review, Respond, Delegate, Archive (determines downstream routing)
- **Sensitivity:** Public, Internal, Confidential, Restricted (drives redaction intensity)
- **Topic/Project:** Auto-generated tags mapped to owner-defined project lexicon
- **Thread Context:** Parent message ID, reply depth, conversation state (open/closed/escalated)

**Inference Pipeline:**
1. **Preprocessing:** Messages are chunked into 2048-token windows with overlap to preserve context. HTML is stripped, URLs are normalized, and attachments are hashed for reference.
2. **Prompt Templating:** System prompts enforce strict JSON schema output, few-shot examples from synthetic data, and explicit instructions to avoid hallucination. Prompts are cached and version-controlled.
3. **Local Inference:** Batched requests are routed through the model with temperature=0.1 for deterministic tagging. Confidence thresholds (e.g., >0.85) trigger automatic routing; lower scores flag for human review.
4. **Validation & Fallback:** Output is validated against Pydantic schemas. Invalid JSON triggers retry with adjusted temperature or fallback to rule-based heuristics (regex, keyword matching, header parsing).
5. **Adaptation:** Low-confidence or overridden predictions are logged to a local feedback dataset. Periodic LoRA fine-tuning (every 30 days) updates the model using on-device DPO or SFT, ensuring continuous alignment with the owner's communication style.

**Fine-Grained Detail Handling:**
The classifier is explicitly trained to detect nuanced signals: implicit deadlines ("by EOD"), soft requests ("when you get a chance"), emotional subtext, cross-project dependencies, and action item extraction. It maintains a local knowledge graph of recurring contacts, project aliases, and historical resolution patterns to improve contextual accuracy. All classification artifacts remain local, with only aggregate statistics and synthetic examples exported for benchmarking.

# Redaction Strategy

Redaction is the critical bridge between private utility and public benchmarking. The strategy employs a multi-stage, defense-in-depth approach to strip identifiable information while preserving semantic structure, statistical distributions, and analytical utility.

**Stage 1: Rule-Based Extraction**
Deterministic regex patterns target high-confidence PII:
- Email addresses, phone numbers, IP addresses, MAC addresses
- Credit card numbers, SSNs, passport IDs, internal ticket formats
- File paths, URLs with query parameters, API keys
Output: Replaced with structured placeholders (`[EMAIL]`, `[PHONE]`, `[URL]`, `[TICKET]`).

**Stage 2: NER & Context-Aware Masking**
A local spaCy pipeline or transformer-based NER model identifies:
- Person names, titles, departments
- Organization names, product names, locations
- Dates, times, monetary values, percentages
Context windows (±3 tokens) are analyzed to determine if the entity is critical to meaning. If so, it is replaced with a consistent anonymized token (`[PERSON_01]`, `[ORG_ALPHA]`, `[DATE_Q3]`). Deterministic hashing (SHA-256 truncated) ensures the same entity maps to the same placeholder across all documents, preserving relational integrity for benchmarking.

**Stage 3: LLM-Assisted Semantic Preservation**
For complex sentences where direct replacement breaks grammar or meaning, a local LLM performs controlled paraphrasing:
- Maintains original length, punctuation, and syntactic structure
- Replaces sensitive clauses with generic equivalents ("discussed budget" → "reviewed financial parameters")
- Outputs are validated against a sensitivity classifier to ensure no residual PII
- Confidence thresholds require human approval for low-scoring transformations

**Stage 4: Differential Privacy & Noise Injection**
For aggregate metrics destined for public reports, calibrated Laplace or Gaussian noise is added to counts and percentages. This prevents membership inference attacks while preserving statistical validity. Noise magnitude is tuned to achieve ε=1.0 privacy guarantee for datasets >1000 records.

**Validation & Auditing:**
- Automated PII scanners run post-redaction with strict zero-tolerance thresholds
- Entropy analysis detects anomalous token distributions that may indicate leakage
- Redaction mapping tables are encrypted and stored offline, never exported
- All transformations are logged with version hashes for reproducibility

The redaction pipeline produces two outputs: a full-fidelity private view for the owner, and a sanitized publishable view that retains structural and statistical properties for benchmarking. Both views share the same underlying classification labels, ensuring metric consistency across planes.

# Synthetic Test Generation

Synthetic data generation enables safe benchmarking, model testing, and community sharing without compromising privacy. The system creates realistic communication artifacts that mirror the statistical and structural properties of real data while containing zero identifiable information.

**Generation Architecture:**
1. **Schema Definition:** Templates define message structure (headers, body, attachments, thread depth, metadata). Schemas are version-controlled and aligned with IMAP/Graph API standards.
2. **Distribution Modeling:** Real data is analyzed to extract distributions for:
   - Message length, attachment frequency, thread depth
   - Sentiment ratios, urgency distribution, topic clustering
   - Temporal patterns (peak hours, day-of-week trends)
   - Classification label frequencies and confidence distributions
3. **LLM-Based Synthesis:** A local model generates content using constrained decoding:
   - System prompts enforce schema compliance, distribution matching, and PII exclusion
   - Few-shot examples use previously validated synthetic data
   - Temperature=0.7 balances creativity with structural fidelity
   - Output is filtered through a sensitivity classifier and PII scanner
4. **Template-Augmented Generation:** For high-volume or low-variability messages, template engines inject randomized but realistic content:
   - "Please review the attached [DOCUMENT_TYPE] by [DATE_PLACEHOLDER]"
   - "Following up on our discussion regarding [PROJECT_PLACEHOLDER]"
   - Placeholders are populated from a curated vocabulary list with no real-world references
5. **Validation Pipeline:**
   - Statistical tests (KS, chi-square) compare synthetic vs real distributions
   - Similarity checks (cosine embedding, n-gram overlap) ensure <0.05 similarity to real corpus
   - Human review samples 10% of generated data for plausibility and utility
   - Failed batches are regenerated with adjusted constraints

**Use Cases:**
- Benchmark classification accuracy, latency, and memory usage
- Test redaction pipeline robustness and edge-case handling
- Stress-test reporting plane formatting and metric aggregation
- Share with external communities for reproducibility and comparison
- Train auxiliary models (sentiment analyzers, action extractors) without privacy risk

Synthetic data is stored in a separate encrypted volume, versioned, and exported only after passing all validation gates. It never interacts with raw data pipelines, ensuring strict isolation.

# Metrics To Keep

The reporting plane tracks operational, analytical, and privacy metrics to ensure system health, utility, and benchmark readiness. All metrics are computed locally, aggregated, and exported in sanitized form.

**Operational Metrics:**
- Inference latency (p50, p95, p99) per message
- Throughput (messages/sec) and batch processing efficiency
- GPU/CPU utilization, memory footprint, VRAM allocation
- Error rates, fallback triggers, and retry counts
- Storage utilization, backup success rate, encryption overhead

**Analytical Metrics:**
- Message volume over time (daily/weekly/monthly trends)
- Response time distribution (owner reply latency)
- Sentiment trend analysis and emotional valence shifts
- Topic clustering stability and drift detection
- Action completion rate and priority accuracy
- Classification F1, precision, recall per label
- Redaction success rate and semantic preservation score

**Privacy & Security Metrics:**
- PII leakage score (post-redaction scanner results)
- Synthetic data fidelity score (distribution match, similarity threshold)
- Audit log completeness and override frequency
- Model drift detection (KL divergence between training and inference distributions)
- Encryption verification status and backup integrity checks

**Benchmarking Metrics:**
- Cross-dataset classification accuracy (real vs synthetic)
- Redaction pipeline throughput and validation pass rate
- Human review efficiency (time per override, correction rate)
- System uptime, fault tolerance, and recovery time
- Resource efficiency (tokens/sec/Watt, memory/message ratio)

Metrics are aggregated using rolling windows, smoothed to prevent outlier distortion, and exported as CSV/JSON with deterministic hashing for reproducibility. Raw data never leaves the local environment; only aggregates and synthetic examples are shared. The owner dashboard provides real-time visualization, threshold alerts, and historical trend analysis to support continuous optimization.

# Human Review

Human oversight ensures accuracy, trust, and continuous improvement. The review workflow is integrated into the pipeline as a gated, auditable process that balances automation with owner control.

**Dashboard Interface:**
A local web UI (Streamlit/Gradio) provides:
- Message queue with low-confidence classifications
- Side-by-side view of raw text, model tags, and redacted output
- Override controls for urgency, sentiment, actionability, and sensitivity
- Bulk approval/rejection for batch processing
- Metric visualization and trend analysis

**Review Workflow:**
1. **Flagging:** Messages with confidence <0.85, conflicting tags, or high sensitivity are routed to the review queue.
2. **Triage:** Owner reviews context, adjusts labels, and approves redaction transformations. Overrides are logged with timestamps and rationale.
3. **Feedback Loop:** Corrections are added to a local dataset for periodic model fine-tuning. Prompt templates are updated based on recurring errors.
4. **Calibration:** Weekly review sessions adjust thresholds, refine taxonomy, and validate synthetic data quality. Model adapters are retrained using on-device DPO/SFT.
5. **Audit Trail:** All human interventions are recorded in an immutable log with cryptographic hashing. Access is restricted to the owner via local authentication.

**Efficiency Optimizations:**
- Smart sorting prioritizes high-impact messages (critical urgency, high sensitivity)
- Template overrides allow bulk label adjustments for recurring patterns
- Confidence calibration reduces review volume over time as model improves
- Automated suggestions reduce manual effort by 60-70%

Human review is not a bottleneck but a calibration mechanism. The system is designed to minimize intervention while maximizing accuracy, ensuring the owner retains full control over privacy boundaries and analytical utility.

# Failure Modes

Despite rigorous design, several failure modes must be anticipated and mitigated:

**1. Over-Redaction:**
- *Symptom:* Loss of semantic meaning, unusable reports, broken syntax
- *Mitigation:* Context-aware masking, LLM-assisted paraphrasing, human review for low-confidence transformations, adaptive thresholds based on message type
- *Monitoring:* Semantic preservation score, human override rate, report utility feedback

**2. Under-Redaction:**
- *Symptom:* PII leakage, benchmark contamination, privacy breach
- *Mitigation:* Multi-stage NER, regex fallback, entropy analysis, strict validation gates, zero-tolerance PII scanners
- *Monitoring:* Post-redaction leakage score, similarity checks against real corpus, audit log alerts

**3. Model Drift:**
- *Symptom:* Classification accuracy degradation, label misalignment, increased review volume
- *Mitigation:* Continuous local fine-tuning, periodic re-evaluation, synthetic data refresh, prompt versioning
- *Monitoring:* KL divergence tracking, F1 score trends, confidence distribution shifts

**4. Prompt Injection:**
- *Symptom:* Malicious messages bypass safety, extract system prompts, or trigger unintended behavior
- *Mitigation:* Input sanitization, system prompt hardening, sandboxed inference, strict JSON schema validation
- *Monitoring:* Anomaly detection in token distributions, fallback trigger rates, security audit logs

**5. Storage Breach:**
- *Symptom:* Local data compromised, encryption bypassed, backup exposed
- *Mitigation:* Full-disk encryption, network isolation, secure deletion, offline backups, air-gapped archives
- *Monitoring:* Integrity checks, access logs, encryption verification, backup rotation audits

**6. Synthetic Leakage:**
- *Symptom:* Generated data mirrors real content, distribution mismatch, benchmark invalidation
- *Mitigation:* Strict generation constraints, similarity checks, differential privacy, human validation
- *Monitoring:* Fidelity score, statistical test results, community feedback, reproducibility checks

Each failure mode has defined detection thresholds, automated alerts, and manual intervention protocols. The system is designed to fail securely, defaulting to conservative redaction, human review, and local isolation when anomalies are detected.

# Example Private Summary

**Internal WorkDash Report | Owner View | 2024-06-15**
**Classification Engine:** Llama-3-8B-Q4_K_M | **Confidence Threshold:** 0.85 | **Redaction Status:** Full Fidelity

**Message ID:** MSG-2024-0615-0842
**Sender:** sarah.chen@internalcorp.com
**Recipient:** owner@homelab.local
**Timestamp:** 2024-06-15T08:42:11Z
**Thread Depth:** 3 | **Attachments:** budget_Q3_draft.xlsx (2.4MB)

**Raw Excerpt:**
"Hey, following up on our sync yesterday regarding Project Nebula. The finance team flagged the Q3 budget allocation for the API migration sprint. We need your sign-off by EOD Friday or the vendor contract with DataFlow Inc. will auto-renew at 15% higher. Can you review the attached draft and let me know if we should reallocate from the marketing reserve? Also, Mark from DevOps mentioned the staging environment is unstable, which might delay the UAT phase. Let me know how you want to proceed."

**Local Classification:**
- Urgency: High (explicit deadline, financial impact)
- Sentiment: Neutral (professional, task-oriented)
- Actionability: Respond/Delegate (requires sign-off, coordination)
- Sensitivity: Confidential (budget, vendor contract, internal project)
- Topic/Project: Project Nebula, API Migration, Q3 Budget
- Thread Context: Parent MSG-2024-0614-1630, Reply Depth 2

**Owner Insights:**
- Deadline: Friday EOD (72 hours)
- Financial Risk: 15% auto-renewal if unsigned
- Dependencies: DevOps staging environment, marketing reserve reallocation
- Recommended Action: Review budget draft, coordinate with Mark, sign vendor contract
- Priority Routing: High-priority queue, calendar reminder set, draft response template generated

**Redaction Status:** None (Private View)
**Audit Log:** Classification confidence 0.92, no overrides, stored in encrypted local DB

# Example Publishable Summary

**WorkDash Benchmark Report | Public View | 2024-06-15**
**Classification Engine:** Llama-3-8B-Q4_K_M | **Confidence Threshold:** 0.85 | **Redaction Status:** Sanitized/Synthetic

**Message ID:** SYN-2024-0615-0842
**Sender:** [EMAIL_01]
**Recipient:** [EMAIL_02]
**Timestamp:** [DATE_2024_Q2]
**Thread Depth:** 3 | **Attachments:** [DOCUMENT_TYPE] (2.4MB)

**Redacted Excerpt:**
"Following up on our recent discussion regarding [PROJECT_ALPHA]. The finance team flagged the Q3 budget allocation for the [TECHNICAL_INITIATIVE] sprint. We need your sign-off by [DEADLINE_PLACEHOLDER] or the vendor contract with [VENDOR_PLACEHOLDER] will auto-renew at a higher rate. Can you review the attached draft and let me know if we should reallocate from the [DEPARTMENT_PLACEHOLDER] reserve? Also, [PERSON_01] from [TEAM_PLACEHOLDER] mentioned the [ENVIRONMENT_PLACEHOLDER] is unstable, which might delay the [PHASE_PLACEHOLDER]. Let me know how you want to proceed."

**Local Classification:**
- Urgency: High
- Sentiment: Neutral
- Actionability: Respond/Delegate
- Sensitivity: Confidential
- Topic/Project: [PROJECT_ALPHA], [TECHNICAL_INITIATIVE], Q3 Budget
- Thread Context: Parent SYN-2024-0614-1630, Reply Depth 2

**Benchmark Metrics:**
- Classification Confidence: 0.92
- Redaction Success Rate: 100%
- Semantic Preservation Score: 0.94
- PII Leakage Score: 0.00
- Synthetic Fidelity: Distribution match >0.98, similarity <0.03

**Aggregate Statistics (Rolling 30-Day):**
- Messages Processed: 1,247
- High Urgency: 18.3% | Neutral Sentiment: 64.1% | Actionable: 42.7%
- Avg Inference Latency: 142ms | Throughput: 8.2 msg/sec
- Human Review Rate: 6.4% | Override Accuracy: 91.2%
- Redaction Pipeline Pass Rate: 99.8%

**Export Format:** JSON/CSV | **Privacy Guarantee:** ε=1.0 differential privacy | **Reproducibility:** Deterministic hashing, versioned schemas

# Field-Level Keep/Drop/Redact Decisions

| Field | Decision | Rationale | Example Transformation |
|-------|----------|-----------|------------------------|
| Sender Email | Redact | Direct PII, enables contact tracing | sarah.chen@corp.com → [EMAIL_01] |
| Recipient List | Redact | Exposes communication graph | owner@lab.local, team@corp.com → [EMAIL_02], [EMAIL_03] |
| Message Body | Redact | Contains PII, project names, sensitive context | Raw text → Context-aware masked version |
| Timestamp (Exact) | Redact | Enables correlation attacks | 2024-06-15T08:42:11Z → [DATE_2024_Q2] |
| Project Code | Redact | Internal nomenclature, strategic info | Project Nebula → [PROJECT_ALPHA] |
| Attachment Filename | Redact | May contain versioning, author info | budget_Q3_draft.xlsx → [DOCUMENT_TYPE] |
| Sentiment Score | Keep | Aggregate metric, no PII | 0.62 Neutral → 0.62 Neutral |
| Urgency Tag | Keep | Classification label, safe for benchmarking | High → High |
| Internal Jira Link | Drop | Direct access to internal systems | https://jira.corp.com/NEB-442 → [TICKET_PLACEHOLDER] |
| Vendor Name | Redact | Commercial sensitivity, contract info | DataFlow Inc. → [VENDOR_PLACEHOLDER] |
| Team/Department | Redact | Organizational structure exposure | DevOps → [TEAM_PLACEHOLDER] |
| Action Items | Redact | May contain deadlines, assignees | "Sign by Friday" → "Sign by [DEADLINE_PLACEHOLDER]" |
| Classification Confidence | Keep | Model performance metric, no PII | 0.92 → 0.92 |
| Thread Parent ID | Redact | Internal message graph | MSG-2024-0614-1630 → SYN-2024-0614-1630 |
| Owner Notes | Drop | Highly personal, unstructured PII | "Call back after lunch" → [NOTE_PLACEHOLDER] |
| Encryption Hash | Keep | Integrity verification, no PII | SHA256:a1b2c3... → SHA256:a1b2c3... |
| Inference Latency | Keep | Operational metric, safe | 142ms → 142ms |
| Redaction Mapping Table | Drop | Reverse-anonymization risk | Stored offline, never exported |
| Synthetic Generation Seed | Keep | Reproducibility, no PII | seed=48291 → seed=48291 |

This table governs all data transformations within the WorkDash pipeline. Fields marked "Keep" are safe for both private and publishable views. Fields marked "Redact" undergo deterministic anonymization or semantic masking. Fields marked "Drop" are excluded from export entirely to prevent indirect leakage. All decisions are enforced by automated validation gates, with human review available for edge cases. The pipeline ensures that privacy controls are consistent, auditable, and aligned with benchmarking requirements.