Decisions

Decision Log

Format:

## [Date] Decision Title
**Context:** Why this came up
**Options considered:** What alternatives existed
**Decision:** What we chose
**Rationale:** Why
**Owner:** Who's responsible

2026-05-14 Adopt Reach / Robustness / Resonance as Guiding Grammar

Context: Reuben and Josh have been refining a three-priority framework (Reach, Robust, Resonance) over the past month through Apr 23, Apr 30, and May 14 1:1s. May 14 conversation also pivoted from a role-evolution discussion (Reuben felt lost in the doc) into a goal-scaffolding reframe. Need a shared grammar for next year’s GPS narrative and quarterly planning. Options considered: (1) Keep R/R/R as informal language only; (2) Adopt R/R/R as the guiding grammar for next year and use it to structure both retrospective and forward-looking work; (3) Use a different framework (e.g., the four-goal categories: Technical / Communication / Wellness / Time/PM). Decision: Option 2, with Option 3 as the sub-structure underneath. Reach / Robustness / Resonance becomes the operating language for the next year. Quarterly check-ins use the framework. The four goal categories nest inside it. Rationale: R/R/R captures the work’s outcomes more durably than activity-based language. Maps cleanly onto the partnership criteria filter (Reach · Revenue/Model Validation · Identity Shift). Josh prefers “Robustness” (full word) over “Robust.” Owner: Reuben (drafts retrospective and forward plan); Josh (sends sacrificial draft mid next week; reviews iterations)


2026-05-14 Two-Document GPS Deliverable Structure

Context: Josh and Reuben agreed the R/R/R framework needs two artifacts: one looking back (to anchor the language in concrete past examples) and one looking forward (to inform next year’s goals). Options considered: (1) Single combined doc (retrospective + plan); (2) Two separate docs, retrospective first then forward plan; (3) Forward plan only, skip retrospective. Decision: Option 2. Produce a retrospective GPS narrative first (reflective, paragraph-based, first-person, R/R/R lens), then a forward-looking plan for the next 12 months informed by the retrospective. Forward plan eventually shared with Joanna. Rationale: Retrospective anchors the R/R/R language in concrete examples before forward-planning. Two docs keep each focused. Voice: first-person reflective journaling, not analytical bullets. STAR/GPS-style prompts scaffold the writing. Owner: Reuben (drafts both); Josh (review + targeted rewrites on strong phrases)


2026-05-05 SoM Q-Centered Therapy: AS Won’t Run It, Will Co-Support

Context: Kristen Bassetti at SoM EdTech is shopping for partners on a $25M+ Q-Centered Therapy (trauma-informed intervention) project, ages 8-18, school context. Co-proposal from SoM EdTech just sent to Josh. Question: should AS take a project-management role? Options considered: (1) AS leads the project (not realistic — capacity); (2) decline entirely; (3) AS contributes targeted learning design and research-connector support, SoM EdTech runs PM. Decision: Option 3. SAL will not serve as project management lead. Will offer learning-design expertise for school-age audiences and connect to relevant research expertise if there’s headroom. SoM EdTech has the intake/PM capacity; AS has school context and research fluency. Rationale: Avoids overcommitting a 3-person team. Plays to AS’s distinct strength (school-side learning design + research connection) rather than competing on project management. Wed May 6 3pm Peter Nguyen CCT Sync is the next surface for this thread. Owner: Josh (shares co-proposal with SAL leadership), Reuben (brings to Peter Nguyen meeting)


2026-05-05 Flash Lab Partnership Funnel

Context: Flash Lab demand is increasing post-ISTE-blurb work and Lake Forest revisions. Inbound asks from multiple directions (Lane Las Vegas, prospective referrals via Christine, etc.). Options considered: (1) accept all asks while capacity holds; (2) flat triage criteria; (3) train-the-trainer first, direct facilitation only when strategic. Decision: Prefer train-the-trainer or strategic relationship-building. Filter inbound interest through partnership criteria: (1) genuine excitement about the core offering — not Stanford prestige or AI trendiness; (2) skin in the game (usually financial, other forms count); (3) [3rd criterion in source doc — pending recovery]. Rationale: Greg’s solo Tinkery Flash Lab on May 4 validated the train-the-trainer model. Direct facilitation only justifies the time cost when it builds a strategic relationship or tests a real prospect. Owner: Josh (filters inbound), Reuben (executes train-the-trainer + strategic facilitations)


2026-05-05 Learning Impact Exchange: Stay Invite-Only

Context: Pilot Learning Impact Exchange next Thursday — 15 registered, target 10-25, two guest speakers confirmed. Question: open it up or keep tight? Decision: Stay invite-only for now. Josh adds 2 people. Future iterations may use a waitlist approach. Rationale: Pilot — keep the room curated to learn what works before scaling. Owner: Josh


2026-04-27 Strategic Huddle: Add “Calibrate Capacity” + Touch-Level Tracking

Context: End-of-month wrap-up surfaced a recurring trend — different seed-grant teams need very different support intensities (Mystery Machine = sounding board; SofIA, CRISPRkit = hands-on). High/medium/low-touch language exists but isn’t formalized or revisited. Options considered: (1) informal monthly gut-check, (2) per-project label set at first meeting + revisited, (3) embed in existing Strategic Huddle cadence rather than adding a new ritual. Decision: Bake “Calibrate Capacity” into the Strategic Huddle agenda as the first bullet under Big Picture Reflection. Initial label set after first meeting with a seed-grant team; recategorize as the relationship evolves. Three driving questions for each Huddle: (1) has support level stayed consistent? (2) any high-touch ↔ low-touch shifts? (3) any upcoming changes that will affect overall capacity? Rationale: Existing high/medium/low-touch language was vague — adding a “team maturity / self-sufficiency” axis gives it teeth. Embedding in the quarterly huddle (rather than a new monthly ritual) keeps overhead low and pairs the calibration with the existing Cathy review. Joe framed it well: “support-o-meter.” Owner: Josh (sends May 12 invite + updates handbook), Reuben + Joe (bring per-project calibrations to the huddle)


2026-03-24 Health Coach Bot: Cloud Default + Version Tracking

Context: Health Coach Bot regroup with Priya, Marily, Michele. Discussed data architecture for IRB submission and how to track bot configuration changes for research analysis. Options considered: (1) Local-only storage for privacy, (2) Cloud-default with opt-out, (3) Hybrid per participant choice Decision: Cloud syncing as default for IRB submission. Local-only available as opt-out. Track bot iteration/version metadata tied to each conversation row. Rationale: Cloud-default simplifies the study design and enables richer data analysis. Version tracking is essential for understanding which bot configuration drove which outcomes. Firebase flagged as potential concern for health data — medical school alternatives to be explored. Owner: Reuben (technical), Marily/Priya (IRB)


2026-03-17 ISTE Partnership: Services Agreement, Not Google Funding

Context: Joseph had suggested exploring Google funding for Flash Lab distribution through ISTE. Separately, timeline question of whether to sign partnership before ISTE Live. Decision: Not pursuing Google funding angle. Going with a services agreement structure. Timeline is moving forward now that agreement structure is decided. Rationale: Services agreement is cleaner and more actionable than seeking external funding. Aligns with OTL guidance on WSA path. Owner: Reuben / Josh


2026-03-11 No OTL Web Disclosure — Services Agreement Path Instead

Context: OTL web disclosure was in “pending” status at otldisclosure.stanford.edu since early March. After the Mar 9 OTL meeting, the path forward is a Work-Service Agreement (WSA), not a formal IP license or invention disclosure. Decision: Drop the OTL web disclosure. It’s not applicable — Flash Lab is heading toward a services agreement, not an invention filing. Rationale: OTL confirmed the IP structure is open-source curriculum + proprietary trainer content, contracted via WSA. An invention disclosure is for patentable inventions or licensable IP, which doesn’t fit this model. Owner: Reuben / Josh


2026-03-09 Flash Lab IP: Two-Tier Open Source + Proprietary Trainer Model

Context: OTL meeting with Isabelle, Josh, Brooke, and David to discuss IP/licensing for ISTE partnership. Options considered: (1) License entire toolkit as IP, (2) Open-source everything and charge for services only, (3) Two-tier: open-source workshop materials + proprietary train-the-trainer content Decision: Pursue two-tier approach. Open-source the day-to-day Flash Lab curriculum (creators can do this per Stanford policy). Keep train-the-trainer materials proprietary and licensable. Contract will likely be a Work-Service Agreement, not formal IP license. Rationale: Simplifies the IP structure — the true value is in the training methodology, not the workshop content itself. YouCubed and Ed TPA precedents support this model. Gives Stanford leverage (proprietary TTT materials) while maximizing reach (open-source workshops). Avoids UBIC tax complications of licensing content directly. Owner: Reuben (copyright/terms, TTT materials), Brooke/OTL (contract structure with Geoff Cox)


2026-02-17 Flash Lab Positioning Strategy — Top of Funnel

Context: AS:DE strategy session (Joe on vacation). ISTE meeting in 8 days, need to clarify Flash Lab’s institutional position. Options considered: (1) Flash Lab as standalone PD offering, (2) Flash Lab as ISTE-exclusive, (3) Flash Lab as top-of-funnel for GSE ecosystem Decision: Pursue top-of-funnel positioning — Flash Lab feeds other programs (Challenge Success, youcubed, CSET/PLEX, PACE). Non-exclusive with ISTE (Isabelle’s direction). Respect PLEX’s role as PL face at Stanford. Rationale: Asking to stop something with momentum is a non-starter. But framing it as “every time we do our offering, [X] benefits” creates alignment rather than competition. Also a signaling mechanism for the Accelerator. Owner: Reuben (concretize plan by Thu Feb 19), Josh (institutional alignment) Open question: What numbers would contribute to vs. cannibalize other GSE programs?


2026-01-30 Scratch Folder Pattern for Sub-Agent Outputs

Context: Read an article about building an AI project manager with Claude Code. Their key breakthrough was having sub-agents write outputs to a shared temp folder instead of returning everything to the orchestrator, which solved context window issues.

Options considered:

  1. Keep current approach (all workflow steps inline in main session)
  2. Consolidate all skills into one “handbook” document
  3. Add scratch folder for intermediate outputs (their pattern)
  4. Full sub-agent architecture with Task tool

Decision: Implement scratch folder pattern as an optional enhancement. Create scratch/ directory for heavy workflows to write intermediate outputs. Sub-agents write detailed reports there; downstream agents read directly.

Rationale:

  • Low-risk addition (doesn’t break existing workflows)
  • Solves potential context issues as workflows get more complex
  • Provides transparency (can inspect intermediate outputs)
  • Aligns with proven pattern from production system
  • Git-ignored with auto-cleanup keeps it clean

Owner: Reuben (Claude assists)

Files updated:

  • Created scratch/README.md - documents the pattern
  • Updated CLAUDE.md - added scratch to directory structure + new section
  • Updated .gitignore - ignore scratch contents except README
  • Updated daily-prep/SKILL.md - added architecture note
  • Updated weekly-review/SKILL.md - added architecture note
  • Updated end-of-day/SKILL.md - added scratch cleanup step

Source: decisions.md