Execution Model

How Theseus work is structured and tracked.

Workstreams

Ownership per workstream and component: Team & Roles.

Tracking hierarchy

All v1 work hangs off a single tracking Epic: every workstream, component, and pilot onboarding effort sits somewhere beneath it, so anything not represented there will not show up in program reporting.

    flowchart TD
    V1["Theseus V1"]
    V1 --> DX["Dev Experience"]
    V1 --> RP["Runtime Platforms"]
    V1 --> PA["Pilot Adoption"]
    V1 --> US["User Support"]
    PA --> AR["Artifact Registry"]
    PA --> GATE["GATE"]
    PA --> ORB["Orbit"]
  

Labels drive filtering and reporting across it:

Program

theseus-v1

Workstream

workstream::dev-experience workstream::runtime-platforms workstream::pilot-adoption workstream::user-support

Component

component::lab-bench component::labkit component::caproni component::common-template-copier component::common-ci-tasks component::runway component::fairway component::tube component::release-framework component::artifact-registry

Phase

phase::pilot phase::ga phase::theseus-post-v1

Due dates

Each epic’s due date field is being used to indicate the completion date of that work. Due dates reflect the current best estimate and will be updated as unknowns are resolved.

Known limits of this tracking model

Issues and epics linked in from other projects may not carry the full label set — check them directly rather than assuming a filtered view will catch them.

Meetings

Theseus Execution Weekly

When

Every Thursday

Who

All component DRIs

Purpose

Review progress against the v1 roadmap, risks, and any blockers

Core decisions and misalignments discussed in this meeting can be found in the change log.

Component syncs

Each component also runs its own sync. These are not on a shared schedule: ask the component’s DRI in Team & Roles for the details.

Channels

#theseus_execution_group is day-to-day execution coordination (private). General program updates: #proj_theseus.