Skip to main content

Module 1: The Ecosystem

Before you touch any code, it helps to know the shape of the place you're joining: what the platform actually is, where its many repositories live, and how a given project decides what tooling and process it's expected to have. This module is a map, not a manual — later modules go deep on the pieces that matter most in your first weeks.

The platform, at a glance​

Wasteology's data platform is built from a small number of systems that talk to each other through shared PostgreSQL tables and blob storage — not a web of point-to-point API calls. Internally it's described as a Brain / Hands / Eyes / Interface model:

RoleWhat it does
BrainAn autonomous scanning/recommendation agent that watches codebases and pipelines and proposes work
HandsThe orchestration hub — executes implementations, dispatches agentic work, runs the CLI that ties everything together
EyesA read-only dashboard surfacing activity, recommendations, and pipeline status across the whole portfolio
InterfaceA web chat UI for interacting with an orchestrator agent directly

You don't need to memorize which system is which on day one. The important idea is the pattern: shared state in a database, not scattered direct calls, so any system can be down without silently breaking the others.

Where the repos live​

Wasteology's source lives primarily in an Azure DevOps (ADO) organization (with a smaller number of projects on GitHub, notably a multi-client pilot platform). Within the main ADO org, most day-to-day work happens inside one shared project holding many git repositories; a few engagements — most notably work involving external contractors — get their own isolated ADO project instead, scoped narrowly so an external party's access never spills into the shared project, other repos, or Azure itself.

A centralized project registry (manifest files, one per project) is what lets internal tooling answer questions like "what repos exist," "who owns this one," and "does it have a Prefect pipeline" without hardcoding that knowledge into every script. If you're ever unsure where a piece of functionality lives, that registry — and the lat.md/ of the orchestration repo itself — is the place to check before asking around.

The Claude Project Standard: tiers, at a high level​

Not every project needs the same tooling. Wasteology projects are classified into tiers, where each tier inherits everything from the tier above it and adds the commands, skills, and settings that its category of project actually needs. You'll meet this standard in almost every repo you touch, so it's worth knowing the shape even before Module 3 covers the git-specific piece of it in depth.

Tier 0 — Core (every project)
  └── Tier 1 — ADO-Managed (uses ADO git + PRs + work items)
        ├── Tier 2a — Python Service
        │     ├── Tier 3a — Docker/ACI
        │     │     └── Tier 4a — Prefect ETL (flows on ACI push pools)
        │     └── Tier 3b — Streamlit Dashboard
        └── Tier 2b — Data Transform (dbt Cloud CLI, no local server)
  • Tier 0 is universal: every project gets a baseline set of session commands (context priming, a health check, an end-of-session doc audit), a lat.md-authoring skill, and a minimal CLAUDE.md covering how to work in that repo.
  • Tier 1 adds the ADO git workflow — you'll cover this in Module 3.
  • Higher tiers layer on what a project's type needs: a Python service adds test/lint tooling, a container-deployed service adds build/deploy commands, and a Prefect ETL project adds flow-deployment tooling on top of that.

Wastey says

You won't be asked to memorize the tier tree. What's useful to internalize is the idea itself: a project's required tooling is derived from what kind of project it is, not copy-pasted ad hoc — so two Tier-1 ADO-managed projects push code to ADO the exact same way, even if one is a dashboard and the other is a data pipeline.

How to find where something lives​

When you're not sure where a piece of functionality or documentation lives:

  1. Check the project's CLAUDE.md first — every project has one, and it names the stack, the key lat.md concepts, and how to authenticate for git.
  2. Search that project's lat.md/ (Module 2 covers this in depth).
  3. If it's a cross-project question — "which repo owns X," "who's the owner of this project" — the orchestration repo's project registry is the source of truth, not memory or a wiki page that might be stale.

Hands-on lab​

You don't need special access for this — just a terminal.

  1. Pick any Wasteology repository you have access to (or ask your onboarding buddy which one to start with).
  2. Open its CLAUDE.md at the repo root and read the sections named "Before starting work," "Stack," and "Git and ADO Authentication." Note which tier's additions you can spot (a Prefect deployment command means Tier 4a; a dbt command means Tier 2b; and so on).
  3. Look for a lat.md/ directory in that repo. If it exists, open the file that looks like it documents the overall architecture and skim its headings — you're previewing what Module 2 teaches you to search properly.
  4. Note one thing you didn't know about this project before doing steps 1–3. That's the gap this module exists to close.

Explore the platform model​

Click each part of the platform to see what it does and how it talks to the others.

The Wasteology platform in four roles: Brain, Hands, Eyes, Interface.
The Wasteology platform in four roles: Brain, Hands, Eyes, Interface.
Brain / Hands / Eyes / InterfaceInteractive

Click any step to see what happens and who's responsible.

▸Why shared PostgreSQL tables and blob storage instead of point-to-point API calls between these four?

Knowledge check​

In the platform's Brain/Hands/Eyes/Interface model, how do the systems primarily communicate?
What is the relationship between tiers in the Claude Project Standard?
When you're unsure which repo owns a piece of functionality across the whole portfolio, what should you check?

Next up: Module 2 — Knowledge Graph (lat.md).