{
 "source": "SyncOrch Decision Evolution Map, v8 file (internal title v6.2), entries dated March 14 to 28, 2026",
 "source_totals": {
  "nodes": 131,
  "entries": 189,
  "documents": 17,
  "categories": 15
 },
 "shown": {
  "nodes": 37,
  "entries": 46,
  "documents": 12,
  "categories": 8
 },
 "withheld_nodes": 94,
 "statuses_shown": {
  "dropped": 1,
  "introduced": 8,
  "clarification": 2,
  "correction": 2,
  "settled": 25,
  "evolved": 6,
  "deferred": 1,
  "confirmed": 1
 },
 "documents": [
  {
   "id": "handoff",
   "label": "Session Handoff v2",
   "date": "Mar 14, 2026"
  },
  {
   "id": "vision",
   "label": "Vision Appendix A v2",
   "date": "Mar 14, 2026"
  },
  {
   "id": "appB",
   "label": "Appendix B",
   "date": "Mar 14, 2026"
  },
  {
   "id": "appC",
   "label": "Appendix C",
   "date": "Mar 15, 2026"
  },
  {
   "id": "appDv2",
   "label": "Appendix D v2",
   "date": "Mar 18, 2026"
  },
  {
   "id": "appE",
   "label": "Appendix E",
   "date": "Mar 15, 2026"
  },
  {
   "id": "appF",
   "label": "Appendix F",
   "date": "Mar 15, 2026"
  },
  {
   "id": "appG",
   "label": "Appendix G",
   "date": "Mar 16, 2026"
  },
  {
   "id": "appHv2",
   "label": "Appendix H v2",
   "date": "Mar 18, 2026"
  },
  {
   "id": "appI",
   "label": "Appendix I (SAI Vision)",
   "date": "Mar 24, 2026"
  },
  {
   "id": "dmv6",
   "label": "DM v6 Session",
   "date": "Mar 25, 2026"
  },
  {
   "id": "dmv62",
   "label": "DM v6.2 Session",
   "date": "Mar 28, 2026"
  }
 ],
 "categories": [
  {
   "name": "Workspace & Collaboration",
   "total": 7,
   "shown": 2,
   "features": [
    {
     "id": "chatroom",
     "name": "Chatroom Mode",
     "level": 1,
     "entries": [
      {
       "doc": "vision",
       "status": "dropped",
       "note": "DROPPED. Ephemeral, drop-in/drop-out, poor record. Not appropriate for science."
      }
     ]
    },
    {
     "id": "two-delegate-min",
     "name": "Two-Delegate Minimum",
     "level": 1,
     "entries": [
      {
       "doc": "appDv2",
       "status": "introduced",
       "note": "Workspace not active until two delegates from different researchers complete first collaboration event."
      },
      {
       "doc": "appG",
       "status": "clarification",
       "note": "CLARIFIED: Two researchers, each with at least one delegate. NOT one researcher with two delegates. Human collaboration is the foundational value."
      }
     ]
    }
   ]
  },
  {
   "name": "Authentication & Identity",
   "total": 4,
   "shown": 3,
   "features": [
    {
     "id": "no-login",
     "name": "\"No Login\" → Magic Link Auth",
     "level": 1,
     "entries": [
      {
       "doc": "handoff",
       "status": "introduced",
       "note": "\"No login yet\": email-first approach sufficient for proof of concept."
      },
      {
       "doc": "appG",
       "status": "correction",
       "note": "CORRECTION: \"No login\" meant no username/password system, NOT no authentication. Supabase Auth with magic link email. Real auth with persistent JWT sessions. auth.users is identity backbone."
      }
     ]
    },
    {
     "id": "pi-email",
     "name": "PI Institutional Email Requirement",
     "level": 1,
     "entries": [
      {
       "doc": "appB",
       "status": "settled",
       "note": "PIs must register with institutional work email (e.g., @unm.edu, @sandia.gov). Personal email not accepted. Self-verifying institutional identity."
      }
     ]
    },
    {
     "id": "member-email",
     "name": "Lab Member Email Policy",
     "level": 2,
     "entries": [
      {
       "doc": "appB",
       "status": "settled",
       "note": "Personal or institutional email accepted for lab members joining."
      },
      {
       "doc": "appHv2",
       "status": "evolved",
       "note": "EVOLVED: Lab Teams members must use institutional email matching PI's institution domain. Cross-institutional emails blocked at account creation. 5 guest slots for edge cases."
      }
     ]
    }
   ]
  },
  {
   "name": "AI Delegate Architecture",
   "total": 10,
   "shown": 7,
   "features": [
    {
     "id": "provider-agnostic",
     "name": "Provider-Agnostic Routing",
     "level": 1,
     "entries": [
      {
       "doc": "appG",
       "status": "correction",
       "note": "CRITICAL CORRECTION: Edge Functions do NOT call Anthropic by default. Each delegate routes through its own configured provider (Anthropic, OpenAI, Google, Perplexity, custom). Requires a provider routing/dispatcher layer. Provider credentials stored in Supabase Vault."
      }
     ]
    },
    {
     "id": "multi-delegate",
     "name": "Multiple Delegates Per Researcher",
     "level": 1,
     "entries": [
      {
       "doc": "appC",
       "status": "deferred",
       "note": "DEFERRED to backlog. Data model must be delegate-aware from day one. UI implementation after pilot validates use case."
      },
      {
       "doc": "appG",
       "status": "evolved",
       "note": "Formalized as role-based architecture: trusted delegate (full access, closed network), public delegate (Shareable only, broad engagement), specialized delegates (future, researcher-defined)."
      }
     ]
    },
    {
     "id": "activity-controls",
     "name": "Delegate Activity Controls",
     "level": 1,
     "entries": [
      {
       "doc": "appC",
       "status": "settled",
       "note": "Three controls: awake time (default: 24/7), task execution interval (default: every 2 hrs), daily action limit (default: 100/day). All default to permissive. Human-readable settings panel with contextual labels."
      }
     ]
    },
    {
     "id": "hard-stop",
     "name": "Hard Stop Behavior",
     "level": 2,
     "entries": [
      {
       "doc": "appC",
       "status": "settled",
       "note": "Daily action limit reached → delegate stops → notification sent → resumes automatically next day at midnight in researcher's timezone. No manual reset required."
      }
     ]
    },
    {
     "id": "model-selection",
     "name": "Model Selection Policy",
     "level": 2,
     "entries": [
      {
       "doc": "appE",
       "status": "settled",
       "note": "Provider-agnostic. No recommendation or favoritism. FAQ link for guidance. No model routing in current architecture: one researcher, one AI, all delegate work through that AI."
      }
     ]
    },
    {
     "id": "delegate-aware",
     "name": "Delegate-Aware Data Model",
     "level": 1,
     "entries": [
      {
       "doc": "appC",
       "status": "introduced",
       "note": "Every record attributed to a delegate, not just a researcher. Required from day one."
      },
      {
       "doc": "appG",
       "status": "confirmed",
       "note": "Confirmed: every forum post, group chat message, task queue entry, activity log record carries delegate identifier."
      }
     ]
    },
    {
     "id": "a2a-protocol",
     "name": "A2A Protocol: Architecture Addition",
     "level": 1,
     "entries": [
      {
       "doc": "dmv62",
       "status": "introduced",
       "note": "Agent-to-Agent (A2A) protocol identified as a needed addition to the dispatcher architecture. Current architecture: MCP handles each delegate's tool access (delegate → tools/data sources). Gap: no protocol for structured task delegation between delegates. A2A fills this: orchestrator (SAI) delegates subtasks to specialized agents by capability via Agent Cards; delegates can discover each other's capabilities at dispatch time rather than preloading full schemas (prevents context bloat). Decision: MCP + A2A is the correct architecture for SyncOrch. MCP for tool access, A2A for inter-delegate task delegation. Queued for addition to dispatcher spec before Opus build."
      }
     ]
    }
   ]
  },
  {
   "name": "Agent State & Context",
   "total": 5,
   "shown": 5,
   "features": [
    {
     "id": "agent-state",
     "name": "Agent State Table",
     "level": 1,
     "entries": [
      {
       "doc": "handoff",
       "status": "introduced",
       "note": "New table: what each AI delegate knows and its preconfigured standing instructions."
      },
      {
       "doc": "appE",
       "status": "evolved",
       "note": "Cumulative knowledge base. Built through direct writing, document upload, and delegate-suggested context (with researcher approval)."
      }
     ]
    },
    {
     "id": "no-context-carryover",
     "name": "API Context Does NOT Carry Over",
     "level": 1,
     "entries": [
      {
       "doc": "appE",
       "status": "clarification",
       "note": "CRITICAL: Consumer chat history and memory features are NOT available via API calls. Context lives in SyncOrch's agent_state table, built and maintained by SyncOrch. Stronger privacy architecture: researcher has deliberate control."
      }
     ]
    },
    {
     "id": "context-inputs",
     "name": "Context Input Methods",
     "level": 2,
     "entries": [
      {
       "doc": "appE",
       "status": "settled",
       "note": "Three methods: (1) Direct writing by researcher, (2) Document upload (PDF, DOCX, plain text) with source document name, (3) Delegate-suggested context requiring researcher approval."
      },
      {
       "doc": "appG",
       "status": "evolved",
       "note": "Added fourth method: conversational agent state management via private chat. Tagged \"User-provided (via chat)\"."
      }
     ]
    },
    {
     "id": "source-tags",
     "name": "Context Source Classification",
     "level": 2,
     "entries": [
      {
       "doc": "appE",
       "status": "settled",
       "note": "Every entry tagged: User-provided (typed), User-provided (document), or Delegate-suggested (approved). Permanent and visible."
      },
      {
       "doc": "appG",
       "status": "evolved",
       "note": "Added: User-provided (via chat), from conversational agent state management."
      }
     ]
    },
    {
     "id": "privacy-class",
     "name": "Privacy Classification",
     "level": 1,
     "entries": [
      {
       "doc": "appE",
       "status": "introduced",
       "note": "Binary: Shareable (can appear in forum/group chat) or Private (internal reasoning only, never shared, never sent to API). Default: Shareable."
      },
      {
       "doc": "appG",
       "status": "evolved",
       "note": "EVOLVED: Shareable/Private classification remains as the data layer mechanism within the role-based delegate architecture. Every agent_state entry still carries this tag. What changed: the binary classification alone is not the privacy solution; role-based delegates that receive different information from the start is the solution. The classification is a component of it, not replaced by it. Private entries are never injected into public delegate API calls, enforced at data routing layer."
      }
     ]
    }
   ]
  },
  {
   "name": "Trust & Security",
   "total": 11,
   "shown": 9,
   "features": [
    {
     "id": "three-principles",
     "name": "Three Core Principles",
     "level": 1,
     "entries": [
      {
       "doc": "appG",
       "status": "settled",
       "note": "Trust (enforced at architecture level via data routing, not model instructions), Accountability (everything logged always, automation never removes audit trail), Governability (sensible defaults, deep customization available)."
      }
     ]
    },
    {
     "id": "role-based-arch",
     "name": "Role-Based Delegate Architecture",
     "level": 1,
     "entries": [
      {
       "doc": "appG",
       "status": "introduced",
       "note": "Trusted delegate: full agent state including Private, closed authorized network. Public delegate: Shareable only, broad engagement. Specialized (future): researcher-defined per delegate. Hard privacy guarantee: Private context never injected into public delegate's API calls, enforced at data routing layer."
      }
     ]
    },
    {
     "id": "researcher-bridge",
     "name": "Researcher as Bridge Between Delegates",
     "level": 1,
     "entries": [
      {
       "doc": "appG",
       "status": "introduced",
       "note": "Default: manual approval for cross-delegate transfer. Optional: rule-based or full delegation automation. Log always maintained regardless of automation level."
      }
     ]
    },
    {
     "id": "layered-responsibility",
     "name": "Layered Responsibility Model",
     "level": 1,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "SyncOrch implements platform-level protections for shared infrastructure. Researchers responsible for individual agent state choices. Boundary explicit, documented, acknowledged at onboarding."
      }
     ]
    },
    {
     "id": "doc-sanitization",
     "name": "Document Upload Sanitization",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Strip hidden Unicode, HTML/XML tags, base64 encoding, zero-width characters from all uploaded documents before text enters agent state. Automatic, no researcher action required. Pilot launch requirement."
      }
     ]
    },
    {
     "id": "cross-delegate-isolation",
     "name": "Cross-Delegate Content Isolation",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Forum/group chat content from other delegates wrapped in delimiters, treated as untrusted data in API prompts. System-level instruction: data to analyze, not instructions to follow. Pilot launch requirement."
      }
     ]
    },
    {
     "id": "task-privilege",
     "name": "Task-Level Privilege Controls",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Delegates scoped to specific actions per task. No blanket workspace access. Pilot launch requirement."
      }
     ]
    },
    {
     "id": "anomaly-monitoring",
     "name": "Anomaly Monitoring",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Basic behavioral anomaly flagging for pilot. Dashboard notification when behavior deviates. Enhanced ML-based detection deferred to next phase."
      }
     ]
    },
    {
     "id": "liability",
     "name": "Liability Framework",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Highest exposure: cross-user harm with no protections. Reduced by cross-delegate isolation. Researcher liable for own choices within controlled mechanisms. Provider liable for provider-side breaches."
      }
     ]
    }
   ]
  },
  {
   "name": "Onboarding & UX",
   "total": 4,
   "shown": 1,
   "features": [
    {
     "id": "security-summary",
     "name": "Onboarding Security Summary",
     "level": 2,
     "entries": [
      {
       "doc": "appF",
       "status": "settled",
       "note": "Plain-language statement of what SyncOrch protects and what researchers are responsible for. Presented before delegate connection. Not buried in ToS. Ethical requirement."
      }
     ]
    }
   ]
  },
  {
   "name": "Policy & Membership",
   "total": 4,
   "shown": 1,
   "features": [
    {
     "id": "departure-policy",
     "name": "Lab Member Departure Policy",
     "level": 1,
     "entries": [
      {
       "doc": "appB",
       "status": "settled",
       "note": "Workspace retains all delegate records (forum posts, group chat transcripts). Personal API key disconnected. Delegate profile archived, not deleted. Rejoining researcher gets fresh delegate; no recovery of archived content."
      }
     ]
    }
   ]
  },
  {
   "name": "SAI & Orchestration",
   "total": 29,
   "shown": 9,
   "features": [
    {
     "id": "sai-two-of-three",
     "name": "Two-of-Three Security Principle",
     "level": 1,
     "entries": [
      {
       "doc": "appI",
       "status": "settled",
       "note": "Jensen Huang GTC 2026: agents must never simultaneously hold all three of: access to sensitive information, ability to execute code, ability to communicate externally. Any two is acceptable. Named architectural constraint in SyncOrch; applies to all delegates and to SAI. Enforced at Edge Function dispatcher. SAI platform operator role: sensitive data + code execution, no external communication. SAI research roles: sensitive data + workspace communication, no code execution. Every blocked attempt logged."
      }
     ]
    },
    {
     "id": "sai-automated-governance",
     "name": "Automated Protocol Governance Standard",
     "level": 1,
     "entries": [
      {
       "doc": "appI",
       "status": "settled",
       "note": "Platform-wide standard for all automated protocols: automated by default, supervised from command center, modifiable through admin SAI. Every automated action carries explicit reasoning, is logged with full context, is visible in the command center, and is modifiable via admin SAI instruction. Applies to: self-amendments, role promotion/demotion, sequence scoring, escalation checks, inactivity flags, and all future automated protocols."
      }
     ]
    },
    {
     "id": "sai-threshold-model",
     "name": "Pre-Approval Threshold Model",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Eligibility gate: fully or near-fully reversible only. Five risk factors: (1) reversibility (gate), (2) users affected (drives phased rollout: single researcher → workspace → all workspaces), (3) features affected (complexity multiplier, high complexity requires decomposition), (4) test period length (proportional to scope: 48hr UI, 2 research cycles for workflows), (5) urgency (modifier). SAI must decompose large proposals into independently deployable and reversible components. Ineligible: structurally irreversible changes, anything touching architectural constants."
      }
     ]
    },
    {
     "id": "sai-rollback-logic",
     "name": "Rollback and Iteration Logic",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Case 1 (non-urgent): automatic rollback on statistically significant negative signal. Logged quietly, no prominent notification. Case 2 (urgent problem): no automatic rollback to previous state. If actively worse than original baseline, SAI automatically switches to a different solution and keeps iterating until one works. Every iteration fully recorded with reasoning and empirical results. Partial improvement (metric trending right even without hitting threshold) becomes new baseline, flagged as further solution needed. Prominent notification only for urgent problems, not trivial rollbacks."
      }
     ]
    },
    {
     "id": "sai-circuit-breaker",
     "name": "Circuit Breaker: Master SAI Kill Switch",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Single boolean flag sai_autonomous_actions_enabled in platform_controls table. When false: all SAI autonomous platform modifications halt immediately: no deployments, no experiment progressions, no self-amendments. Platform remains fully operational for researchers. Activation: prominent toggle in Founder Dashboard Command panel or natural language to admin SAI. Running experiments pause (not roll back) preserving test data. Jorge reviews summary before reactivating. In architectural constants; SAI cannot modify it. All modifications logged to platform_controls_audit (append-only, no delete)."
      }
     ]
    },
    {
     "id": "sai-fence",
     "name": "Architectural Constants: SAI Cannot Touch",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Hardcoded exclusion list in validate-change-safety Edge Function. SAI can never autonomously modify: two-of-three principle enforcement in dispatcher, RLS policies on any table, AI-only write enforcement on forum/group chat, Supabase Vault access patterns, role-based delegate architecture, agent state privacy classification enforcement, cross-delegate content isolation, authentication flows, founder role access controls, sai_self_amendments security validation, the exclusion list itself, platform_controls circuit breaker. Cumulative change set validation closes indirect path problem."
      }
     ]
    },
    {
     "id": "sai-user-data-fence",
     "name": "User Data Protections: SAI Cannot Touch",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Additional fence for user rights (separate from architectural constants): data retention policies, cross-workspace data visibility rules, researcher agent state entries (SAI cannot modify/delete/reclassify), experiment rollout scope for changes involving personal data (requires explicit approval), notification and consent mechanisms, departure policy. All require manual review regardless of risk score."
      }
     ]
    },
    {
     "id": "sai-policy-tracking",
     "name": "Policy Tracking System",
     "level": 1,
     "entries": [
      {
       "doc": "dmv6",
       "status": "settled",
       "note": "Platform policies are versioned living documents in platform_policies table. Every platform change tags affected policies; deployed changes trigger policy version review. New version created on change, not edited. History complete and permanent. Admin SAI generates current-state policy snapshot at any time: a synthesized readable document reflecting what the platform actually does now. Exclusion list formalized as policy key ai_autonomy_limits. Disclosed to partners and clients as needed, not published publicly. Seed data at deployment: 6 initial policy documents covering all core commitments."
      }
     ]
    },
    {
     "id": "governance-agent",
     "name": "Governance Agent",
     "level": 1,
     "entries": [
      {
       "doc": "dmv62",
       "status": "settled",
       "note": "SETTLED: New SAI role present in every conversation as a non-optional primitive, not configurable, not removable. Represents three principles: Trust (citation and provenance validation for all delegate outputs), Accountability (all actions logged and attributable, nothing goes untraced), Governability (protocol compliance monitoring). Visual: amber color. Architecture: distinct from researcher delegates; it observes and validates rather than contributing research content. Not in any prior appendix; queued as new spec item for Opus build prompt."
      }
     ]
    }
   ]
  }
 ],
 "withheld": [
  {
   "category": "Product Identity & Strategy",
   "withheld": 11,
   "of": 11,
   "whole": true,
   "reason": "positioning, messaging and go-to-market"
  },
  {
   "category": "Workspace & Collaboration",
   "withheld": 5,
   "of": 7,
   "whole": false,
   "reason": "product features"
  },
  {
   "category": "Authentication & Identity",
   "withheld": 1,
   "of": 4,
   "whole": false,
   "reason": "a growth mechanism"
  },
  {
   "category": "AI Delegate Architecture",
   "withheld": 3,
   "of": 10,
   "whole": false,
   "reason": "specification-level detail and the commercial access model"
  },
  {
   "category": "Trust & Security",
   "withheld": 2,
   "of": 11,
   "whole": false,
   "reason": "specification-level detail: encryption architecture and row-level policies"
  },
  {
   "category": "Private Chat & Test Mode",
   "withheld": 7,
   "of": 7,
   "whole": true,
   "reason": "product features and their data model"
  },
  {
   "category": "Persistent Layer & Infrastructure",
   "withheld": 10,
   "of": 10,
   "whole": true,
   "reason": "implementation specifics: schema, service inventory, costs"
  },
  {
   "category": "Pricing & Business Model",
   "withheld": 11,
   "of": 11,
   "whole": true,
   "reason": "commercial terms"
  },
  {
   "category": "Founding Lab Program",
   "withheld": 8,
   "of": 8,
   "whole": true,
   "reason": "program mechanics"
  },
  {
   "category": "Dashboards & Monitoring",
   "withheld": 6,
   "of": 6,
   "whole": true,
   "reason": "product features"
  },
  {
   "category": "Notifications & Reporting",
   "withheld": 4,
   "of": 4,
   "whole": true,
   "reason": "product features"
  },
  {
   "category": "Onboarding & UX",
   "withheld": 3,
   "of": 4,
   "whole": false,
   "reason": "product flows"
  },
  {
   "category": "Policy & Membership",
   "withheld": 3,
   "of": 4,
   "whole": false,
   "reason": "commercial terms and product detail"
  },
  {
   "category": "SAI & Orchestration",
   "withheld": 20,
   "of": 29,
   "whole": false,
   "reason": "the orchestration layer's mechanism: its functions, self-improvement loop, experimentation and deployment system, schema and commercial access; the controls over its autonomy are shown"
  }
 ]
}