OLOS PRD v3.0 — Open Labs Operating System

00 — Quick Start

What this document is

OLOS is the software and automation layer that runs Open Labs. It handles registration, Pulse tracking, Pod and Project formation, proposal moderation, and Cycle archiving — so Facilitators spend their time on community, not administration.

This document covers the full operating model, from product vision through database schema. Use the jump links below to get to what's relevant for your role.

HQ / Product leads

Start with Vision & Design Principles, Core Concepts, and the Roadmap. Focus on the Key Flows for a full-system picture.

Developers

Start with Architecture, then Schema & Data Model, then Technical Standards. The Pulse Contract has critical system behavior.

Facilitators

Read Core Concepts, The Pulse Contract, and Key Flows A–C. Admin Hub covers your day-to-day dashboard.

The 6 primitives

Upskiller — a participant in Open Labs.
Local Lab — a chapter of The Upskilling Labs running its own Cycle(s).
Cycle — a 12-week active sprint within a 9-month campaign calendar.
Pod — a group investigating a shared problem (n ≥ 5 to activate).
Project — a team building a solution within a Pod (n 3–7).
Pulse — a weekly reflective journal submission. The atomic unit of the system.

The 3 core rules

Pulse every week to stay in. Miss a week: access is revoked until you catch up. See The Pulse Contract.
Problems before solutions. Proposals must describe a real friction or gap — not a product to be built.
Nothing is deleted; everything is archived. Every event, submission, and transition is preserved permanently.

01 — Vision

Vision & design principles

Open Labs is a radically accessible upskilling program: participants learn by doing — proposing real problems, forming collectives around them, and building experimental solutions together. The system provides a structured container (guidelines, the Upskillers Agreement, a shared timeline) and lets the community self-organize within it. OLOS has no opinion about what problems are worth solving or what solutions to build. It only asks: has the community chosen to pursue it?

Open Labs is the foundational layer of The Upskilling Labs. Themes, workshops, mentorship programs, and events produced by HQ are external to OLOS. The Cycle framework, Pods, Projects, and the Pulse aren't features of one program — they are the operating model everything else is built on.

Design principles

Self-organization over prescription. Anyone can propose any problem. Any proposal with community support becomes a Pod. The system enforces the rules of the game, not the outcomes.
Centralized data, federated delivery. OLOS is one platform, centrally operated by HQ. A Local Lab is a permissioned scope within the shared system — not a separate installation. All data lives in one place, governed by HQ.
Automation first. Every task that doesn't require human judgment — Group provisioning, Pulse reminders, lockouts, archive creation — is owned by the system. Facilitators focus on community and relationships.
Research-grade data practices. Pulse submissions are the primary longitudinal dataset of The Upskilling Labs. Every record is append-only, schema-versioned, and scoped to a Cycle. Nothing is deleted, ever.
Minimum viable governance. A new Facilitator should need only an orientation session and a clean dashboard to run their first Cycle.

02 — Core Concepts

Core concepts & terminology

People

Upskiller — a participant. Authenticates via Google OAuth; their verified Google ID is the system's primary key. Interacts with OLOS only through Email, Google Drive, and Google Groups. Max 3 active Pods; max 1 active Project at any time.
Local Lab Facilitator — the operator of a Local Lab chapter. Works exclusively through the Admin Hub. Sees only their chapter's data — enforced by Row Level Security, not application logic.
Pod Moderator — a Facilitator team member scoped to one or more Pods. Read-only access to Pod data; can override lockouts and add notes for their assigned Pods.
HQ Facilitator — global role. Cross-network visibility, provisioning authority, and access to chapter application review.

Work containers

Open Labs runs on a 9-month campaign calendar. Facilitators can manage up to three Cycles at once.

Pre-Cycle

Mo. 1–3

Problem proposals, Discovery, Voting, Pod Registration. Intake mode.

Active Cycle

Mo. 4–6

12-week sprint. Pods and Projects live. Pulse tracking active.

Post-Cycle

Mo. 7–9

Reflection, archiving, recommitment. No passive continuation.

Cycle — the 12-week active sprint. Every Pod, Project, and Pulse is scoped to a cycle_id.
Pod (Research Pod) — a group investigating a shared problem. Activates at n ≥ 5. Below 5: 14-day Recruitment Window before archiving.
Project (Project Team) — a group building a solution within a Pod. 3–7 members (hard cap). Below 3: same 14-day Recruitment Window.

Post-Cycle recommitment

Upskillers who wish to continue must actively re-earn their place during Months 7–9: re-propose, re-vote, re-register. Passive continuation is not permitted. Missing the Pod Registration window sets status to Inactive. All historical records are preserved.

03 — The Pulse Contract

The Pulse contract

The Pulse is the atomic unit of Open Labs — the single mechanism that generates participation, value exchange, and institutional data simultaneously. All Pulse logic is defined here; other sections reference this one rather than repeating it.

What it is

A weekly reflective journal — not a status report. Prompts help Upskillers make sense of what they're learning, surface blockers, and articulate what they're building toward. It is designed to be worthwhile on its own, independent of any compliance function.

What Upskillers get for doing it

Access to Open Labs membership benefits: Google Drive collaboration, Pod and Project participation, and full Cycle membership. The Labs provides infrastructure, facilitation, and community. Upskillers provide presence and reflection. The Pulse is the cost of that exchange.

The 7-day window

Day 1 Pulse submitted. 7-day clock resets.

Days 2–4 Open window. No action taken.

Day 5 Reminder email sent automatically.

Day 6 Final grace period.

Day 7 Lockout. Google Group and Drive access revoked.

First Pulse: Delivered by email the morning after registration. Starts the 7-day clock.
Clock source: last_pulse_at in the upskillers table. Resets on every submission.
Lockout: Status → Locked. Group and Drive access revoked via Admin SDK. Not a Cycle-specific action.
Restoration: Submit a makeup Pulse → status reverts to Active, access restored, clock resets.
Manual override: A Facilitator or Pod Moderator can unlock with a logged reason note.
Global rule: The 7-day window applies to all Active and Locked Upskillers regardless of Cycle. The Pulse is the cost of Labs membership, not Cycle-specific participation.

Lockout intent

Lockout is not a punishment. It is the consequence of the value exchange breaking down. The framing for Upskillers should always be: "your access pauses when you step away, and restores when you return."

As a research instrument

Every Pulse submission is written to raw_pulse_checks — the primary longitudinal dataset of The Upskilling Labs. This table is append-only, schema-frozen per Cycle version, and every row carries upskiller_id, cycle_id, pod_id, project_id, and pulse_form_version. No submission is ever modified or deleted.

04 — Key Flows

Key flows

Four flows cover the full system lifecycle. Implementation details are in the Architecture, Schema, and Standards sections.

A

Facilitator runs a Cycle

Trigger

HQ publishes a new Cycle in the Admin Hub Drafting Board.

Facilitator actions

Set Cycle dates and theme in the Drafting Board.
Review and stage each of the 6 stages before publishing.
Moderate problem proposals: Approve, Request Revision, or Reject.
Monitor Pulse health and Pod status throughout the Active Cycle.
Initiate the Cycle Archive at close.

System automates

Stage date recommendations from templates.
Discovery Layer updates with each Approved proposal.
Pitch Doc generation on Stage 2 publish.
Pod/Project provisioning (Groups, Drive folders) at threshold.
All Pulse reminders, lockouts, and makeups (Pulse Janitor).
Recruitment Window emails at Day 1/7/13/14.
Cycle archive snapshot and Drive folder creation.

Exit conditions

Cycle Archive complete. EMAIL_CYCLE_ARCHIVE_COMPLETE sent to Facilitator team.
Post-Cycle recommitment window opens.

B

Upskiller lifecycle

Trigger

Upskiller submits the registration form (Google-authenticated).

Upskiller actions

Complete first Pulse (email link, next morning).
Browse and vote on problem proposals (Stages 1–2).
Register for up to 3 Pods (Stage 3).
Propose or vote on solutions within their Pod(s) (Stages 4–5).
Register for a Project (Stage 6). Only 1 active Project at a time.
Submit weekly Pulse to maintain access. See Pulse Contract.
Re-propose and re-register during Post-Cycle recommitment.

System automates

Registration → raw_registrations → upskillers state table.
Add to chapter Google Group via Admin SDK.
EMAIL_WELCOME and EMAIL_FIRST_PULSE sent.
Pulse Janitor enforces 7-day window globally (see Pulse Contract).
Pod/Project cap validation on each registration attempt.

Exit conditions

Voluntary exit → status Inactive, access revoked, record preserved.
Missed recommitment → status Inactive. All historical data retained.

C

HQ onboards a Local Lab

Trigger

Prospective organizer submits the Local Lab application form (Google-authenticated).

HQ actions

Review application in Admin Hub (Module 6, HQ only).
Approve, request more information, or decline.

System automates on approval

Creates chapters record with new chapter_id.
Provisions a scoped Facilitator account — a permissioned view into the central OLOS platform, not a separate environment.
Creates chapter-level Google Group via Admin SDK.
Creates chapter Drive folder.
Sends EMAIL_CHAPTER_APPROVED with onboarding instructions.

Exit conditions

Facilitator can log into the Admin Hub and see their chapter's scope.
HQ can create a Cycle for the new chapter.

D

System maintenance

Recurring automations (n8n, scheduled)

Pulse Janitor (daily): Checks last_pulse_at across all Active/Locked Upskillers. Day 5 → reminder. Day 7 → lockout, access revoked. Makeup submission → auto-restore.
Recruitment Monitor (daily): Checks all Pods/Projects in Recruiting status. Sends Day 1/7/13 emails; archives on Day 14 if threshold not met.
Provisioning checks: All Group/Drive operations are idempotent — safe to re-trigger after failure.

Error handling

All n8n steps wrap API calls in error branches.
Failures logged to sys_audit_log with action_type: ERROR.
Critical failures (lockout, provisioning, archive) trigger SYSTEM_ALERT to Facilitator team via Resend.
Failed provisioning steps leave the system in its prior state, not a partial state.

Job queue

Batch provisioning jobs tracked in sys_job_queue with statuses PENDING / IN_PROGRESS / COMPLETE / FAILED.
All workflow JSON exported to GitHub repo for version control.

The 6-stage Cycle workflow

Each Cycle progresses through 6 stages. Every automated action is scoped to both chapter_id and cycle_id. No workflow executes without confirming both.

1

Problem Proposal Window

Google-authenticated Tally form. Submissions enter moderation queue as PENDING. Confirmation email sent. Discovery Layer begins populating with APPROVED proposals.

2

Problem Voting

Voting form draws from APPROVED proposals only. Pitch Doc auto-generated and shared with the chapter's Google Group. All Active Upskillers receive a voting invitation.

3

Pod Registration

Top-voted problems open for registration. At n ≥ 5: n8n provisions Google Group, Drive folder, and DB row automatically. 3-Pod membership cap enforced. Pod Moderator notified.

4

Solution Proposal Window

Scoped Tally form per Pod, gated by Google Group membership. Proposals describe an approach to the Pod's problem — not a pre-defined product.

5

Solution Voting

Internal to each Pod. Pod-scoped Tally form. Results surfaced in the Admin Hub.

6

Project Registration

At n ≥ 3: n8n provisions Group and Drive sub-folder. Hard cap at 7, enforced by DB constraint. 1-active-Project constraint validated at registration.

Proposal moderation

Problems before solutions

Proposals must describe a friction, gap, or challenge — not a product to build. "Build an AI tool that does X" should become "Professionals struggle with X because..." Facilitators guide proposers toward this framing via revision requests.

✓

Approve

Status → APPROVED. Appears in Discovery Layer immediately.

↩

Request revision

Facilitator adds a guidance note. Proposer receives EMAIL_PROPOSAL_REVISION. Resubmission returns to PENDING.

✕

Reject

Guideline violations or spam only. Rare. Mandatory Facilitator note. Logged in sys_audit_log.

Recruitment window (Pods & Projects)

Day	Action	Channel
Day 1	Status → Recruiting. Members and Pod Moderator notified.	Email
Day 7	Mid-window warning to members and Facilitator.	Email
Day 13	Final warning: 24 hours remaining.	Email
Day 14	If threshold not met: status → Archived. Group access revoked. Drive folder preserved. Audit log entry created.	Email + Audit log

05 — Architecture

Architecture

OLOS is a single system, centrally operated by The Upskilling Labs HQ. A Local Lab is a permissioned scope within this shared environment — not a separate installation, database, or deployment. Google Workspace handles identity and collaboration. Everything else runs in HQ's central stack.

Database

Supabase (PostgreSQL)

Single source of truth, HQ-owned. Row Level Security scopes each Local Lab Facilitator's view to their chapter at the query level.

Auth

Supabase Auth + Google OAuth

All users authenticate via Google. Verified Google ID is the primary key for every Upskiller record. No self-reported emails.

Automation

n8n (self-hosted)

All workflow logic: Pulse Janitor, provisioning, recruitment monitoring, archive generation. Workflows exported to GitHub as JSON.

Forms

Tally

Google-authenticated intake forms. Session identity pre-populates hidden fields. Webhooks write directly to Supabase.

Admin Frontend

Next.js on Vercel (HQ-operated)

One deployment. Local Lab Facilitators access a chapter-scoped view. HQ Facilitators have global access. RLS enforces the boundary.

Access Control

Google Groups (Admin SDK via n8n)

All Group operations automated. Provisioning, membership adds/removes, and archiving are n8n workflows — no manual Group management required.

Collaboration

Google Drive (Drive API via n8n)

Pod and Project folders provisioned automatically. The Upskiller-facing experience is entirely in Drive.

Email

Resend

Transactional email. 3,000/mo free tier. Every send logged to sys_email_log.

Discovery Layer

Next.js page

Live query from raw_problem_proposals (APPROVED, current Cycle). Browsable and filterable by Upskillers during Stages 1–2.

Admin Hub

The Admin Hub is the single interface for all Facilitators and Pod Moderators. It is centrally operated by HQ, deployed once on Vercel. Local Lab Facilitators log in and see only their chapter's data — scoped at the database layer by Row Level Security before any data reaches the application.

The top-level dashboard shows all active Cycles (up to 3 per chapter) as status cards: Cycle ID, Theme, current Stage, health indicators, and quick actions. HQ Facilitators see across all chapters.

Core modules (v1)

Cycles — Drafting Board

Set start date and theme. System recommends stage dates from templates. Override before committing. Guardrail: no stage may precede its predecessor.

Cycles — Stage Controller

Shows Stage N of 6 with status (LIVE / STAGING / UPCOMING). Stage transition generates assets in staging. Facilitator reviews and clicks Publish. Logged with actor and timestamp.

Proposals — Moderation Queue

All PENDING proposals for the active window. Approve, Request Revision, or Reject. Revision requests and rejections require a Moderator Note. All actions logged.

Members — Pulse Health Monitor

Visual list: ● Active · ● Locked · ● Inactive. Filterable by Cycle, Pod, Project. Manual override requires a reason and is logged.

Pods & Projects — Health Monitor

All Pods and Projects with status, member count, and threshold health. Facilitators can trigger Recruitment Windows or Archive actions manually. Pod Moderators see only assigned Pods.

Cycles — Archive Manager

Initiate a Cycle Archive at close. Shows archive status and link to completed archive.

HQ-only modules Later

Chapter Applications

Review queue for incoming Local Lab applications. Approve, request more info, or decline. Approval triggers automated chapter provisioning.

Cross-chapter analytics

Network-wide Pulse health, participation rates, Cycle completion stats, and longitudinal research exports across all chapters.

07 — Schema

Schema & data model

All data is centrally stored in one HQ-owned Supabase database. Every record belonging to a Local Lab carries both chapter_id and cycle_id as foreign keys. These are the primary governance mechanism — they determine which Local Lab Facilitator's scoped view a record appears in. No data is stored or managed locally by a chapter.

People & membership

Table	Type	Purpose & key fields
raw_registrations	Append-only	One row per registration. PK: `google_id` (verified OAuth). Never self-reported email.
upskillers	Mutable state	Current status per Upskiller: `active / locked / inactive`, `last_pulse_at`, `active_pod_count`, `active_project_id`.
memberships	Mutable state	Pod and Project membership per Upskiller per Cycle. Enforces caps.
chapters	Mutable state	One row per Local Lab. `chapter_id`, name, region, `facilitator_id`, status.

Work containers

Table	Type	Purpose & key fields
pods	Mutable state	Status: `forming / active / recruiting / archived`. Tracks `member_count` and `recruitment_window_start`.
projects	Mutable state	Same status model as Pods. FK to parent Pod.

Signals (append-only intake)

raw_pulse_checks

upskiller_idFK. Verified Google ID of submitting Upskiller.

chapter_id / cycle_idScoping keys. Required on every row.

pod_id / project_idActive affiliations at time of submission (nullable).

submitted_atTimestamp. Pulse Janitor reads this to evaluate lockout eligibility.

pulse_form_versionSchema version. Required for cross-Cycle longitudinal analysis.

[reflective_prompts]Journaling responses. Schema frozen per form version.

raw_problem_proposals

proposer_idFK to google_id.

chapter_id / cycle_idScoping keys.

moderation_statusPENDING / APPROVED / REVISION_REQUESTED / REJECTED

moderator_notesFacilitator feedback. Included in revision email to proposer.

form_versionSchema version at submission.

System tables

Table	Purpose
sys_cycle_control	One row per active Cycle per chapter. Stage, committed dates, Pulse form version, deployment version.
sys_audit_log	Append-only. Every consequential action: lockouts, overrides, provisioning, Publish clicks, archives. actor_id, action_type, target_id, notes, created_at.
sys_email_log	Append-only. Every outbound email: recipient, template_id, trigger_event, status, sent_at.
sys_job_queue	Batch provisioning resilience. PENDING / IN_PROGRESS / COMPLETE / FAILED.
sys_templates	Default stage scheduling offsets and email template content.

08 — Standards & Communications

Technical standards & communications

Four guarantees

Idempotent provisioning. All Group and Drive operations check for existing resources before creating. Safe to re-trigger after any failure.
RLS is the only access control. Application code does not filter data by chapter. Supabase RLS enforces every Local Lab Facilitator's scope at the query level, using the chapter_id claim from their JWT. HQ roles carry a global claim.
Append-only logs and archives. sys_audit_log, sys_email_log, and all raw intake tables are never modified or deleted. Cycle Archives are frozen snapshots — read-only after creation.
Error logging + SYSTEM_ALERT. All n8n steps wrap API calls in error branches. Failures log to sys_audit_log. Critical failures (lockout, provisioning, archive) trigger SYSTEM_ALERT to the Facilitator team. Failed provisioning leaves the system in its prior state.

Multi-Cycle isolation

Every n8n workflow and every DB query confirms chapter_id and cycle_id at runtime by reading from sys_cycle_control. No workflow acts on data without both keys confirmed.

Email templates

All transactional email is sent via Resend, triggered by n8n. Every send is logged in sys_email_log. Failures trigger SYSTEM_ALERT.

EMAIL_WELCOMENew registration confirmed → Upskiller

EMAIL_FIRST_PULSEMorning after registration. Starts the 7-day clock. → Upskiller

EMAIL_PULSE_REMINDERDay 5 of window, no submission yet → Upskiller

EMAIL_LOCKOUTDay 7 lockout triggered → Upskiller

EMAIL_LOCKOUT_OVERRIDEFacilitator or Moderator manual unlock → Upskiller

EMAIL_PROPOSAL_CONFIRMProblem proposal received → Proposer

EMAIL_PROPOSAL_APPROVEDProposal approved → Proposer

EMAIL_PROPOSAL_REVISIONRevision requested, includes Moderator Note → Proposer

EMAIL_PROPOSAL_REJECTEDProposal rejected, includes Moderator Note → Proposer

EMAIL_VOTING_INVITEStage 2 published → All Active Upskillers in Cycle

EMAIL_POD_ACTIVATEDPod hits n ≥ 5 → Members + Pod Moderator

EMAIL_RECRUIT_DAY1Pod/Project drops below threshold → Members + Moderator

EMAIL_RECRUIT_DAY7Day 7 of Recruitment Window → Members + Moderator

EMAIL_RECRUIT_DAY13Day 13 — final 24hr warning → Members + Facilitator

EMAIL_ARCHIVEDDay 14 archive triggered → All former members

EMAIL_PROJECT_ACTIVATEDProject hits n ≥ 3 → Project members

EMAIL_RECOMMITMENT_OPENPost-Cycle begins → All Upskillers from prior Cycle

EMAIL_CYCLE_ARCHIVE_COMPLETECycle archive complete → Facilitator team

EMAIL_CHAPTER_APPROVEDHQ approves Local Lab application → Applicant

09 — Roadmap

Roadmap & MVP scope

MVP scope

One chapter. Up to 2 concurrent Cycles. Basic Pulse enforcement, Pod/Project formation, proposal moderation, and simple Cycle archive. Everything else is a later phase.

Phase 1 — Database & intake Current focus

✓Supabase schema: all tables, foreign keys, RLS policies.

✓Supabase Auth with Google OAuth.

○Tally registration form (Google-authenticated) → webhook → raw_registrations.

○sync_upskillers() n8n workflow: raw_registrations → upskillers state table.

○Identity Bridge: new registration → chapter Google Group via Admin SDK.

○First Pulse n8n workflow: morning-after trigger → EMAIL_FIRST_PULSE.

○Tally Pulse Check form with hidden session fields (upskiller_id, cycle_id, pod_id, project_id, form_version).

Phase 2 — Logic Engine Next

○Pulse Janitor: daily trigger, Day 5 reminder, Day 7 lockout, makeup detection.

○Recruitment Window Monitor: daily trigger, Day 1/7/13/14 protocol.

○Pod provisioning: n ≥ 5 → Google Group + Drive folder + DB update (idempotent).

○Project provisioning: n ≥ 3, hard cap at 7.

○sys_job_queue pattern for provisioning resilience.

Phase 3 — Forms, assets & Discovery Layer Upcoming

○Discovery Layer: Next.js page, live query from approved proposals, browsable + filterable.

○Pitch Doc generator: n8n → Google Doc from approved proposals on Stage 2 trigger.

○Tally forms for Proposal, Solution Proposal, Voting — session pre-populated, webhooks → Supabase.

○Cycle Archive workflow: snapshot scoped records, create Drive folder.

Phase 4 — Admin Hub Upcoming

○Next.js Admin Hub with Google OAuth. Supabase RLS enforces chapter scoping automatically.

○Build 6 v1 modules: Dashboard, Drafting Board, Stage Controller, Moderation Queue, Pulse Health Monitor, Pod/Project Monitor, Archive Manager.

○Pod Moderator scoped view.

○Deploy to Vercel. Configure production Supabase.

Phase 5 — Testing & launch Upcoming

○Mock Cycle end-to-end through all 6 stages with test Google accounts.

○Pulse Janitor: validate reminder, lockout, makeup, restore.

○RLS isolation: run two mock chapters simultaneously, confirm no data bleed.

○Google Groups automation: validate all provisioning, membership, and revocation flows.

○Facilitator and Pod Moderator UAT.

Later phases — deferred scope Deferred

→Local Lab application review UI in Admin Hub (Chapter Applications module).

→Cross-chapter analytics and HQ research exports.

→Rich job queue semantics (retry policies, dead-letter handling).

→Multi-chapter scale testing and network-wide operations.

→3 concurrent Cycles per chapter (start with 1–2).