The Ops manual.

Everything you build now has an altitude.

Your framework's most usable idea for both developer work AND business work is the 3 Levels of Learning — Tactics · Principles · Essence. Treat each of those as an altitude. Every product tier, every agent, every Claude session, every sales conversation gets tagged with an altitude. Once altitude is legible on everything, three problems solve themselves at once:

1. Pricing collapses into clarity. Tactics tier · Principles tier · Essence tier. No debate.
2. Delegation gets accurate. Tactics → AI / junior humans. Principles → senior operators + you. Essence → you only.
3. Claude sessions stop drifting. Every CLAUDE.md declares an altitude. Every session log records what altitude was walked. Drift becomes visible before it costs a week.

This doc gives you the altitude system, the mapping to your existing products, the Claude session standard, the agent-altitude registry, the sales overlay, the developer's "build to protect" protocol, and this week's specific actions.

Three altitudes. every artifact tagged.

Same three names your framework already uses. Now they're operational — attached to files, tiers, sessions, and price tags.

The tagging convention

Every artifact in your repos gets one of three tags in its frontmatter or first line: altitude: T, altitude: P, altitude: E. Once you can grep for altitude, you can audit — which files are tactics-only? Which agents claim essence-level output but produce tactics? That gap is where quality dies.

Your product tiers already map to the ladder.

You didn't build them this way on purpose — but they align cleanly. That's the framework confirming your instincts. Lock the mapping publicly.

How this changes the discovery call

Add one question to the discovery script: "Are you buying steps · a pattern · or the thing that only shows up when someone becomes the person doing it?" Their answer picks the tier — not you. This is your framework doing the qualifying.

How Claude sessions run from here forward.

Same discipline in every repo you touch — hooks-os, fbtrainer-tojcampaign, smallbusiness, subject-report, and any future client OS. The standard is the framework, applied to your dev practice.

CLAUDE.md template addition

# Operating altitude: E · essence-level
# Reason: this repo produces the voice/advocacy/character layer for Margin Hooks.
# Tactics + principles live in downstream systems; essence is authored here.

# Session altitude declaration (paste at top of every session prompt):
# "This session is operating at [T/P/E] · outcome: [one sentence]"

Session end-log convention

## Session · 2026-07-17

**Altitude walked:** P → E
**Outcome shipped:** framework page + implementation companion
**Culmination touched?** yes · the "framework IS continuity" thesis clicked
**Disruption + response:** browser screenshot timed out → switched to read_page, continued
**Handoff:** deploy tomorrow · lock the standard into hooks-os CLAUDE.md

Six moves. every altitude runs this loop.

Same six steps whether you're building an agent, closing a client, or launching a product. This is the daily-mode. Capture → Triage → Approve → Eval → Execute → Notify.

This loop is altitude-agnostic. A Tactics agent runs it in seconds. A Principles workflow runs it over a week. An Essence engagement (like a Trainer OS client's monthly tuning session) runs it over 12 months. Same six moves. Different clock.

Every agent gets an altitude tag.

The 6 AI Agent Levels are a technical architecture. Altitudes are what they produce. Both matter — but altitude is the one that tells you whether the agent is safely operating in-scope.

The audit rule

Once a quarter, grep every skill/agent for altitude tags. Any agent producing at a higher altitude than tagged is a risk. Any agent producing at a lower altitude than tagged is a delivery gap. Both get logged in improvements.md.

Every agent answers seven questions.

Fits on one page. Seven questions. If any answer is "we'll figure it out later," the agent is not trusted yet — no matter how good the output looks. Add this block to every SKILL.md's frontmatter.

Example · weekly-stats-cards spec

Guardrails vs Evals

Add this rule to improvements.md across all client OSes: every skill in skills/ has a 7-question spec block in its SKILL.md frontmatter. If it doesn't, it's not shippable — no matter how promising the demo.

Turn a human job into tested labor.

The gap between "AI could probably do this" and "this agent is tested labor" closes with one method. Shadow the human. Extract the spec. Build the eval set. Run against it before you sell it.

Why this changes the sales conversation

Once shadowed and evaluated, the agent stops being a promise and becomes a receipt. That's the difference between "vague automation" (which prospects have been burned by) and "tested labor" (which they'll actually pay for at the SaaS tier).

Where to shadow first · in order of ROI

1. Margin's Sunday stat sheet workflow — already spec'd, but the shadow set makes the eval set. 10 real weeks of pastes.
2. Kyron's Monday triage flow — the actual meta-workflow. Shadow yourself for 4 Mondays. The extracted spec becomes the Control Tower's next automation.
3. The advocacy call log entry — Margin logs post-call. Shadow him for 10 calls. Extract the spec. That's the Coordinate agent for CBH advocacy.

The prospect's altitude picks the tier.

Instead of guessing tier from budget or roster size, read altitude. Then let the tier follow. Fewer arguments, higher-quality clients.

Add to the walkthrough script

One line, delivered early: "There are three altitudes to what we do. Basic is the steps · Premium is the pattern · SaaS installs what makes it yours. Fifteen minutes from now you'll know which one is for you — not the other way around."

The developer's protocol.

Kyron's principle from the notes: utilize LLMs · build to protect yourself · developers don't always operate with integrity (Empire of AI, Karen Hao). Here's what that becomes in practice.

The framework is the continuity product.

You already named this in the notes. Here's how it operationalizes.

One layer per month for 12 months

This is the SaaS-tier promise made specific. Renewal happens because they can see which layer is next. Attrition happens when the layer they need doesn't get scheduled. Now it's on the calendar from day one.

Don't build empty data centers.

Kyron's data center model applied to TOJ: paying customers before infrastructure. Pain before product. Signed pilot before the next tier.

The 3 checks before building anything new

1. Is there a signed pilot funding this? If no — do not build. Sell it first. Even at a heavily discounted "pilot rate."
2. Is the pain real and named? "A trainer might want this" ≠ "Coach [Name] signed a pilot to solve this." Only the second counts.
3. Does this graduate into a productized asset after the pilot? If it's a one-off for one client, price accordingly and don't multiply it into the roadmap.

Distribution strategy · one niche + one workflow

Build around one niche and one workflow first. Then create content that shows: the pain · the agent fix · the measurable outcome. Not "we do AI for trainers" — instead "Coach Hooks was spending 3 hours a week on Sunday stat cards; now it takes 15 minutes and looks like this. Here's the before, the after, and the eval scores." That's distribution content that converts.

Run the business from your phone.

You operate between meetings, airports, and work sessions. Approvals happen on iPhone. Notifications drive attention. The operator's control surface is mobile-first — full building/coding stays desktop.

The 3 mobile-first surfaces to build (in order)

Tool candidates for v1

GoHighLevel mobile app already supports approvals, notifications, and pipeline movements — closest thing to a ready-to-use approval surface. Leftclick AI for iPhone-native workflow deployment. Custom lightweight PWA as the long-term answer once patterns lock in — served from the fbtrainer-tojcampaign repo, wraps the Approval Inbox + Capture + Trigger.

Recommendation for v1

Start with GHL mobile + iOS Shortcut for capture. Cost: near zero, already in your stack. Build the custom PWA at Month 6 once the workflows are known-good. Do not build the PWA first — that's an empty data center. See 07B.

What to do before Sunday.

Ten actions. Total time ~3 hours across the week. The compounding starts the second altitude tags + 7-question specs become grep-able across every repo — everything the operating brains do from that point forward is auditable, and everything you sell becomes tested labor instead of vague automation.