Logos
Logos is the source of truth for team structure, organizational identity, repositories, and access boundaries across GCP, GitHub, and Datadog.
- Resource Hierarchy: GCP folder structure with environment-scoped folders for sandbox, non-production, and production
- Identity & Access: Google Identity groups and centralized user management
- Team Topology: GitHub teams and repositories, Datadog teams, and branch protection
- SaaS Governance: GitHub and Datadog organization-level settings and policies
All downstream platform teams consume Logos data through Arche core helpers.
Repositories
- pt-logos: OpenTofu configuration for GCP folder hierarchy, Google Identity groups, GitHub teams and repositories, and Datadog teams
AI Context
- pt-ai-context: Platform-level Copilot instructions applying universally to all
pt-*repositories - pt-logos-ai-context: Team-level Copilot instructions for
pt-logos-*repositories
Context
Logos feeds team and identity data into all downstream platform teams. See team dependencies.
Glossary
| Term | Meaning in this context |
|---|---|
| Branch protection | A GitHub policy enforcing review and status check requirements on a repository |
| Environment (GCP) | A GCP folder scoping a deployment tier: sandbox, non-production, or production — Logos creates one folder per tier under each team folder |
| Environment (GitHub) | A GitHub Actions deployment environment attached to a repository, with reviewer teams and branch protection policies that gate workflow runs |
| Folder | A GCP resource container that scopes IAM and billing within an environment |
| Identity group | A Google Workspace group that grants role-based access to GCP resources |
| Membership | The assignment of a user to an identity group or GitHub team |
| Organization (Datadog) | The Datadog org that owns all monitors, teams, dashboards, and observability settings |
| Organization (GCP) | The top-level GCP resource container that owns all folders, projects, and IAM policies |
| Organization (GitHub) | The GitHub org that owns all repositories, teams, and Actions settings |
| Repository | A GitHub repository registered to a team and managed as code in Logos |
| Team | An ownership unit — one GitHub team, one GCP folder, one Datadog team, provisioned together from a single definition |
Downstream Interfaces
| Output | Via | Description |
|---|---|---|
teams | data.terraform_remote_state.logos → module.core_helpers | Team data map — folder IDs, identity groups, GitHub repositories, project flags, and platform-managed project config |
Team Topologies
Cognitive Load
Logos spans four domains across three SaaS providers — all driven from a single OpenTofu configuration. The cross-provider synchronization (GitHub + GCP + Datadog from one tfvars change) is the primary source of inherent complexity.
| Working Domains | High Intrinsic Domains |
|---|---|
| 🟠 4 / 4 | 🟢 0 / 3 |
Cognitive load by domain:
| Domain | Intrinsic | Extraneous Reduced By | Germane Expertise |
|---|---|---|---|
| Resource Hierarchy | 🟡 Medium | IaC, no manual ops | GCP org & folder design |
| Identity & Access | 🟡 Medium | IaC, no manual ops | Identity federation |
| Team Topology | 🟡 Medium | One tfvars → three providers | Cross-provider team modeling |
| SaaS Governance | 🟢 Low | Stable config, rarely changes | Org compliance policy |
Capacity: 0 high-complexity domains (Team Topologies guideline: 2–3); team members hold 4 active domains — at the ~4 working-knowledge limit.
Extraneous load is minimized by:
- Everything is code — no manual GCP console, GitHub UI, or Datadog UI operations
- A single tfvars edit propagates to all three providers in one deployment
- Called workflows provide OpenTofu deployment pipelines — no CI/CD to build or maintain
Germane load is built through:
- Multi-provider governance patterns and how org-wide policy propagates downstream
- Modeling teams with explicit ownership boundaries and dependency relationships
- Reasoning about how changes in Logos ripple through Corpus and Pneuma
Team Capacity
- Headcount: 1 platform engineer
- Scale signal: Stable — organizational structure is established; workload is routine maintenance