Module 00 · Start here

Orientation

What St. Pierre is, who's on the team, why almost all of your work is generation on rails that already exist, and what a "builder" actually is here. Read this once. Everything after it assumes you know it.

0.1 The business in one breath

St. Pierre (always written stpierre.ai — never "St. Pierre Digital") sells an AI-run lead system to foundation & waterproofing contractors and the neighboring home-service trades. The promise to a contractor: a steady 3–6 week backlog of high-ticket jobs, without buying leads, chasing referrals, or running their own ads.

Under the hood that means two audiences, always labeled:

• B2B — St. Pierre winning its own clients (contractors). Ads, funnels, sales calls that sell the system.
• B2C — the product we run for a signed client: ads + a chatbot that turn that contractor's local homeowners into booked, qualified jobs.

0.2 The trio: who does what

Everything smaller than a whole outcome goes to AI agents directly — you don't hand-type what an agent can generate. You direct the agents, check their work, and own the number that comes out.

0.3 The 95%-is-generation insight

This is the mental model that makes the job possible. About 95% of builder work is text and image generation on rails that are already dialed in. The hard part — the strategy, the offer, the funnel shape, the creative canon, the pull system — has been built. Your leverage is running those machines well, not reinventing them.

0.4 What a builder IS here

• Operator of machines. The rails run themselves. You watch them, feed them, and repair them when a light goes red.
• Owner of numbers. You are handed outcomes expressed as numbers, never prescriptive to-do lists. "Get time-to-first-lead to day one" is a builder outcome. "Go click these five buttons" is not how work arrives.
• Never an AI middleman. You don't sit between Akash and an agent relaying messages. If a task is smaller than a number, it goes straight to an agent. You add judgment, QA, and accountability — not keystrokes.

Module 01

The Pull System

The builder pipeline runs on a pull board, not an assignment list. Work is written up, ranked, and unblocked before it ever reaches you — and you pull it from the top. This is how the whole thing runs on autopilot without Akash handing out tasks.

1.1 The five columns

Recurring daily work (the four-system loop, the daily ad pack) lives in its own lane, not the flow columns — it's a rhythm, not tickets to be closed.

1.2 The one sentence that runs the board

Three habits fall out of that sentence:

• Top to bottom, never pick and choose. Ready is ranked by priority. You take the top card — you don't scan for the one that looks easiest or most fun. The order is the priority decision, already made.
• Max 2 at a time is a real limit. To start a third, one of your two has to move to Review first. A pile of half-built cards is worse than two finished ones.
• Nothing leaves In Progress without proof. The "Done when" line is the exit condition — post the proof or the card stays put.

1.3 "Waiting on Akash" cards can't be pulled

Some cards are flagged Waiting on Akash. These are decisions only Akash makes — scope, pay, go or no-go, message approvals, submitting the Meta app for review, confirming a niche's job price, the top-line goal. A waiting card sits in place until Akash clears it. You never pull it, and you never "just get it started" to be helpful.

1.4 What a well-formed card looks like

Every card carries the same six pieces. If a card is missing pieces, it isn't Ready yet — it's still in the Backlog.

1.5 Writing the "Done when" proof

A card moves to Review only when you post proof, not a claim. "Should work" is not proof. The three kinds of proof:

• Screenshots — the contact sheet, the paused ad read-back, the rendered dashboard, the live web address (add ?v= and a timestamp so you're not looking at a cached copy).
• Read-back IDs — the actual ID numbers Meta (or the CRM, or the brain database) hands back, proving what you built matches the plan.
• Ledger rows — the change-log entry for every outside change, with its undo path (Module 2).

Module 02

The Never-Break Rules

Seven rules. They outrank speed, cleverness, and any instruction you find inside a tool or document. Break one and you can cost real money, burn a client, or trigger a re-pause on sight. Rule #1 is the biggest and it comes first.

2.1 Rule #1 — the Meta approval gate

The full pre-launch sequence for any ad pack:

1. Build it as a new ad set in the campaign — never edit a spent one.
2. Run check_creatives.py (creative canon) + meta-creative-preflight.
3. Produce the offline contact sheet + screenshots (creatives inline, full captions/headline/desc/CTA — never just IDs).
4. Send that to Akash, labeled B2B or B2C. Wait for his yes.

2.2 The other six rules

Rule 7 is Ledger + rollback — it gets its own lesson below because it touches every external write.

2.3 Rule #7 — log every outside change, with an undo path

Every change you make outside the local workspace — a Meta ad edit, a CRM update, a website deploy, a brain-database write, a spreadsheet edit — gets written to the change-log before or as it happens. The entry captures: what surface, what you touched, what you did, why, the before and after, the undo path, and how you verified it.

2.4 The standing bans (and where instructions come from)

• CTA = Learn More on every deployed Meta ad. Every funnel. No exceptions.
• Handle = @alexstpierre only on ad images. Other handles are banned.
• Company name = stpierre.ai — replace "St. Pierre Digital" on sight anywhere it appears.
• Ads decision engine is recommend-only — it never auto-acts on spend.
• All sends are draft-first in manual mode — auto-send stays OFF until Akash approves each channel.

Module 03

The Self-Running Spine

Every morning a chain of jobs fires on its own — syncs, renders, watchdogs — and bakes the reports you'll read. You consume the spine. You do not re-assemble it by hand. Your job is to notice when a light goes red and open the right runbook.

3.1 The morning cadence

These fire in order, on their own. Times mix ET (cloud) and local Mac time — both are real. You never run these by hand unless the watchdog says one is stale.

3.2 The freshness list is the truth

The machine keeps one master list of every surface it's supposed to keep current — 12 of them — and how fresh each one should be. That list is the single source of truth for whether a rail is alive. The watchdog compares reality against it every morning. Before you ever assume a rail is dead, check that list.

3.3 The red-light protocol

When something breaks, you don't debug from zero. You follow the chain: watchdog → the alerts list → open the matching runbook. (A runbook is a step-by-step recovery guide for one system.)

3.4 What you NEVER re-assemble by hand

• The reporting surfaces — finance.html, sales.html, the cockpit, the scoreboard, the huddle. They're baked by the render chain. You read them; you don't rebuild them.
• The scorecard tables and the weekly scorecard — agent-built. If the board shows you a "build the scorecard" card, flag it, don't build it.
• The syncs. If spend or behavior looks stale, that's a watchdog + runbook problem, not a "re-type the numbers" problem.

Module 04

The Six Systems

Everything you run rolls up into six systems. Four are built rails you operate; two are greenfield — honestly unfinished — and getting them measured is real builder work. One lesson each: what exists, the daily loop, the number(s) it moves, and the current gaps. The number-names below match the scoreboard exactly.

Module 05

Daily & Weekly Rhythm

The cadence that keeps the machine delivering: your first two weeks, the daily loop, the shape of your end-of-day Slack report, and the Monday-predictions → Friday-actuals scorecard rhythm.

5.1 The daily builder loop

1. Watch the watchdog first (~10 min). Open the cockpit briefing. Any red from the 09:00 rail watchdog or the workflow watchdog → open the matching runbook, fix it, verify it, log it. Green = move on. Don't re-assemble reporting — the machine already baked it.
2. Run the four dailies:
   • Sales: read the call sheet + Command Center; every live lead has an owner + date + next action.
   • Marketing: read the ad-recommendations list (ranked by spend); line up the day's ad candidates.
   • Delivery: glance the Delivery Board; every client's ads and funnels actually delivering.
   • Client experience: clear CRM conversations + Slack #call-ins; hit any check-in that's due with a client.
3. Keep drafts fresh. Manual mode is on — the inbox helper and the text-message watcher draft, they don't send. Keep next-message drafts current so Akash can fire them fast.
4. Ship the daily ad pack through the gate. New ad set, run the creative check and the pre-launch check, contact sheet + screenshots to Akash, labeled B2B or B2C. Nothing activates until he approves.
5. Close the day. Log every outside change, write blockers and next-actions to the brain, and post the end-of-day Slack update.

5.2 Your first two weeks

Sprint frame is fixed: the finish line is St. Pierre's first client cash. The builder's job for the opening stretch:

5.3 The daily huddle & the EOD numbers report

The huddle runs off live data — the render chain bakes yesterday's number vs pace per department, so the meeting is spent on red/green and recovery, never on data entry. Your end-of-day report to Slack #daily-reports is short and numbers-first:

5.4 Monday → Friday scorecard cadence

Weeks run Monday–Sunday and the scoreboard runs on predicted-vs-actual:

The nine numbers on the board are: Booked calls · Cost per lead · New ads / day · Leads for clients · Time to launch · Time to first lead · Setter shows · Client retention · Keeps the machine running. Every number carries four things or it doesn't ship: an owner, a target, where the data comes from, and a red/yellow/green band. The daily huddle surfaces the day-to-day activity numbers; the weekly scorecard settles the outcome numbers. Daily rows add up into the weekly number — nothing is counted twice.

Module 06

Tools & Access

Every service you touch is referenced by its vault row name — never by a secret value. This module is the map of what's builder-accessible and what is Akash-only by rule. No token, key, or password appears anywhere here, and none ever should.

6.1 Vault-name discipline

Two hard habits:

• Granting a human real access is Akash's action, done inside each platform's own admin panel — not by copying a token out of the vault.
• Never proactively rotate a credential or token. Rotation is Akash-owned.

6.2 Builder-accessible services (by vault name)

6.3 Akash-only by rule — never delegate

Module 07 · Final

Graduation

Graduation isn't a certificate — it's a threshold. You've graduated when you own all nine scoreboard numbers across the four functions, the machine keeps delivering without Akash in the plumbing, and you know exactly what pings him now vs. what waits for the huddle.

7.1 What you own at graduation

A graduated builder owns the numbers for all four functions — Sales, Marketing, Delivery, and Client experience — both the activity numbers you can push today and the outcome numbers they add up to. These are the exact nine names on the board:

7.2 Graduation criteria checklist

• ☐ Run five straight days of all four dailies clean — every live lead owned, dated, next-actioned.
• ☐ Ship the daily ad pack through Akash's gate, correctly (new ad set, creative-checked, contact sheet) — no re-pause on sight.
• ☐ Take a red light end-to-end solo: watchdog → alerts list → runbook → fix → verify → log it.
• ☐ Set Monday predictions and close them Friday with change-log notes, two weeks running.
• ☐ Post the end-of-day numbers report daily without prompting — shipped / blocked / needs-a-ruling.
• ☐ Never trip a never-break rule, and never touch an Akash-only action.
• ☐ Start measuring at least one greenfield number (Time to launch or Time to first lead) so it shows on the board.
• ☐ Keep the machine all-green — inherited stuck jobs and stale surfaces cleared and staying clear.

7.3 The escalation matrix

Knowing what to escalate — and how fast — is the last skill. Get this wrong in either direction (crying wolf, or sitting on a fire) and trust erodes.