Advisory OS — Architecture Handoff v2

What This Document Is

Complete inventory of systems, projects, and tools that exist across Kathryn's Advisory OS practice. This was produced through an interview session after the original handoff significantly underestimated scope. Search past chats for "Crulliance," "engagement SOP," and "working architecture" for the full build history on the active client engagement.

The problem this solves: Kathryn is building faster than she can organize. Version control is the biggest pain point. There is no single frame that shows where everything lives, how projects relate, and where new work goes. The weekly cycle with clients compounds the mess if this isn't sorted. She needs a working architecture — not perfect, functional — that handles current state and evolves.

The Three Layers (Confirmed)

Layer 1 — Methodology

Client-agnostic. How she works with any client. The constraint-to-solution cycle, diagnostic tools, document types, production standards. This is her IP. Process doesn't change by client — inputs and outputs do.

Layer 2 — Solution Library

Two categories:

1. Pre-built solutions (729 white-labeled packets): Fully packaged with six-piece anatomy (START-HERE, process-agent, process-consultant, context, golden example, quality checklist). Ready to adapt to a client's context and brand. When a constraint matches, she pulls the packet and adapts rather than building from scratch.
2. Custom solutions (built from client work): Like the Accounting Manager OS being built with Ruben. These start as one-off constraint solves and get packaged after they're proven through live testing. These grow the library beyond the 729.

Clients own their instance of SOPs, templates, and tools. They don't own the IP/patterns behind them. Solution library packaging is advisor-only.

Layer 3 — Client Instance

Everything dialed in to a specific client. Their reference data, brand kit (mini brand kit maintained on advisor side), team roster, constraints, their versions of every document. Layer 1 methodology produces these. Layer 2 solutions accelerate them. Client owns the deliverables. Everything gets the client's branding.

Complete Project & System Inventory

Client Delivery Systems

Kathryn's Business Systems

Internal Business Tools

Assets & Libraries

Active Client: Ruben Cruz / Crulliance

Client Details

• $1,500/month, 6-month commitment, signed Feb 9
• Goals: 40 new clients in 2026, 100% new client retention, 95% existing retention
• Wants to sell the firm in 1-3 years
• Team: ~10 people. Pooja Garg (Accounting Manager, India/IST), Sarah + Anas (bookkeepers, 20-25 clients each), Jheanifer (onboarding, 24hr/week), Patty (2-3 clients), Sariah (CSC only — NOT escalation), Krisha (EA), Kevin Garcia (CPA Advisor), Ashwin (tax), Nick (BD/Sales)
• Tools: Financial Cents, QuickBooks Online, Liscio, Google Sheets (month-end workbook)

Brand

Crulliance light theme: #f8f7f4 background, #122640 navy, #C4A44D gold, #3d7a5f green. Cormorant Garamond + Inter.

Current State

• Active constraint: Accounting Manager OS (C1+C2 co-primary)
• Next in matrix: C3+C4 (Solve Together), C5 (Founder Snapshot)
• February close = first live test (starts March 1)
• Pooja hasn't run a single close yet — SOP V3 is her guide
• Weekly check-ins with Pooja: 5 weeks starting Feb 19, Thursdays 1pm ET

Built Deliverables

• Client master plan (living, updated through Feb 13)
• Project plan (Accounting Manager OS)
• Client blueprint (Accounting Manager OS)
• SOP V3 (month-end close, 15 steps, three-phase continuous cycle)
• Engagement SOP (Kathryn's weekly rhythm for this client)
• Client reference data
• 5 skills: crulliance-brand, crulliance-sop, crulliance-project-plan, crulliance-blueprint, crulliance-master-plan

Locked Conventions

Terminology: Recurring (🔁), Escalating (📈, not "Compounding"), Same Root Cause (📦, not "Cluster"), Solve Together (↔️, not "Synergy"), Upstream (⬆️), Downstream (⬇️)

Engagement owner colors: Gold (#C4A44D) = Pooja, Steel blue (#6a9fb5) = Kathryn, Warm copper (#c4785e) = Ruben, Stone (#8a8680) = Team

Quote handling: Keep close to what was said, clean up transcription garble, never fabricate, ask if unclear.

File naming: lowercase-hyphens, client name first, mon-yyyy for deliverables, yyyy-mm-dd for daily files, no version numbers.

Automated Workflow

Session recorded on Otter → download transcript → date-stamp → drop in raw transcripts folder → Relay agent grabs it automatically → produces:

1. Client recap email (in Kathryn's voice — action items, next meeting agenda)
2. JSON file that seeds the constraint priority matrix

Constraint brief arrives separately from client (Friday, via their ChatGPT constraint identifier → manual copy/paste to Kathryn).

Weekly Cadence (Ruben)

• Friday: Constraint brief arrives from Ruben
• Monday: Session with Ruben. Recorded on Otter. After: transcript → Relay → recap + JSON. Then: brief + transcript + JSON → matrix update → master plan update.
• Tuesday–Wednesday: Build deliverables for active constraint. Deploy to Pooja.
• Thursday: Check-in with Pooja (1pm ET / 11:30pm IST)
• Ongoing: One thought leadership piece per week for own business

Architecture Decisions (Made February 14, 2026)

These were decided in the discovery session. They are not proposals — they are the plan.

Two-Tier Project Structure

Tier 1 — Agnostic Projects (no client branding) These work the same regardless of client. Advisory OS branding. Methodology instructions. Golden examples of the document type, not a specific client's version.

• Constraint Priority Matrix — takes any client's brief + transcript + JSON → produces matrix
• New Client Setup — initial build-out: brand kit creation, reference data, first deployment plan
• Methodology Refinement — where you improve how master plans, SOPs, blueprints work in general before pushing updates to Tier 2 projects

Tier 2 — Client Instance Projects (branded, client-specific) Duplicated per client. Each contains: that client's brand kit, reference data, project-specific instructions, golden examples, and the relevant skill files.

For Ruben/Crulliance:

• Client Master Plan (Ruben)
• Project Plan (Ruben)
• Client Blueprint (Ruben)
• SOP / Build (Ruben)

New client = duplicate the Tier 2 structure, load their specific files.

Assembly Line Workflow

Chats move between projects. You can remove a chat from one project and move it into another. The chat retains its conversation history and outputs. When it lands in the new project, tell it to review the project instructions and knowledge files and apply them.

Weekly Ruben cycle:

1. Start in Constraint Priority Matrix (Tier 1) → constraint brief + transcript + JSON → matrix output
2. Move chat → Client Master Plan (Ruben) → matrix output updates master plan
3. Move chat → Project Plan (Ruben) → updates project plan
4. Move chat → Client Blueprint (Ruben) → updates blueprint
5. Move chat → SOP / Build (Ruben) → produces deliverables

Each project is scoped to do one thing well. This solves the "instructions trying to do too much" problem.

Constraint on the assembly line: Long conversations may need a fresh output pulled into the next project rather than moving the whole chat. Plan for both paths.

What Goes in Every Project

Each Claude Project has three types of content:

Instructions (project instructions field) — What the project follows every time. The rules, the workflow, "when you get X input, do Y." Scoped to ONE job per project.

Skills (knowledge files) — Reusable how-to packages. Standard anatomy: SKILL.md + supporting files. The project instructions reference the skill; the skill teaches the methodology. Example: crulliance-master-plan/SKILL.md is a skill loaded into the Client Master Plan (Ruben) project.

Knowledge files (everything else) — Golden examples, brand kit, client reference data, context documents, terminology. The project's reference library.

For a Tier 2 project (e.g., Client Master Plan — Ruben), the contents are:

• Instructions: how to process matrix updates, quality rules, linking rules
• Skills: crulliance-master-plan/SKILL.md
• Knowledge: golden example, client reference data (team, tools, proper nouns), brand kit, constraint terminology

For a Tier 1 project (e.g., Constraint Priority Matrix), the contents are:

• Instructions: how to process any client's inputs into a matrix
• Skills: matrix methodology skill (if formalized)
• Knowledge: golden examples (client-agnostic or anonymized), Advisory OS brand defaults

Corrections to Inventory (from this session)

• Proposals → straddles My Business (prospects) and Client Delivery (extending engagements)
• Front Offer Page Builder → used for own business AND clients (Linda example)
• Website Evaluation Tool → NOT external. Chained agent workflow Kathryn owns. Entry point for authority website work.
• Top of Funnel → full weekly campaign production pipeline with 9 outputs (idea extraction, thought leadership piece, 2 micro-tools, social content, DMs, email, briefing video, fallback version, evergreen version)
• Email list → ~280 subscribers (not 670+), needs cleanup of GetSales-enriched inactive contacts
• Missing from original inventory: Build Agent/Deployment System, Client Brand Kit (Mini), Client Reference Data, LinkedIn automation pipeline (Lead Shark + GetSales)
• Visibility corrections: Master plan = shared in session (not handed over). Project plan = advisor only (client never sees). Blueprint = client receives. SOP = team-facing.

Status Labels (Simplified)

• Active — using it regularly, it works
• Evolving — actively iterating, not stabilized
• Complete — could hand to someone else and they could run it (only Case Study qualifies today)
• Needs Work — has known issues blocking you

Future Target: Claude Code / Cowork

Current architecture is designed for Claude Projects with the assembly line workflow. When pieces become repeatable and stable, they move to Claude Code or Cowork for automation. The project instructions written today become the spec for what gets automated. Architecture doesn't change — execution method does.

What Needs to Happen

The Core Problem

Everything listed above exists and mostly works. But there's no architecture holding it together. Projects were built as needed, iterated rapidly, and now the version control and organizational overhead is compounding. The weekly client cycle makes this worse every week it goes unsorted.

What "Sorted" Looks Like

1. Tier 1 and Tier 2 projects set up with correct instructions, skills, and knowledge files
2. Assembly line tested with one full Ruben weekly cycle
3. Version control solved — current version of every file has a known location
4. A way to see the full system without holding it in her head (System Index — built, editable)
5. The ability to onboard a new client by duplicating Tier 2 structure and loading their files
6. The ability to add new projects/solutions without breaking the structure

What's NOT the Problem

• Quality of outputs (production-grade across the board)
• The methodology itself (constraint-to-solution cycle is proven)
• Missing pieces (most of the system exists)
• Client results (Ruben engagement is delivering)

Constraints on the Solution

• Must be functional NOW, not after everything is perfected
• Must handle current weekly cycle without adding overhead
• Must evolve as projects get refined
• Current environment: Claude Projects with assembly line (chat moves between projects)
• Future target: Claude Code / Cowork for repeatable pieces
• Architecture needs to work across both environments
• Some things will always be discovered after the fact — the frame needs to absorb new additions

Documents Referenced in Past Chats

Search past chats for these to pull full context:

• "Crulliance" — all client delivery work, skills, branding, SOP
• "engagement SOP" — Kathryn's weekly rhythm document
• "working architecture" — three-layer model, folder structure draft
• "constraint priority matrix" — diagnostic methodology
• "month-end close" — SOP V3, team roster, process details
• "master plan alignment" — systematic corrections across 15 passes

Files Currently in Outputs (from past sessions)

• client-master-plan-ruben-cruz.html
• ruben-project-plan-accounting-mgr-os-feb-2026.html
• ruben-blueprint-accounting-mgr-os-feb-2026.html
• ruben-sop-month-end-close-v3-feb-2026.html
• kathryn-sop-advisory-os-engagement-ruben-feb-2026.html
• advisory-os-working-architecture.html (draft — needs visual fixes and scope update)
• crulliance-brand/SKILL.md + supporting files
• crulliance-sop/SKILL.md + golden example
• crulliance-project-plan/SKILL.md + golden example
• crulliance-blueprint/SKILL.md + golden example
• crulliance-master-plan/SKILL.md + golden example

Opening Message for Next Chat

"Search my past chats for 'Crulliance,' 'engagement SOP,' and 'working architecture' for build history. I'm uploading a comprehensive handoff document and an editable system index. Here's what's been decided:

I have a two-tier project architecture. Tier 1 is agnostic (methodology, works for any client). Tier 2 is per-client (branded, with their reference data and skills). Chats move between projects as an assembly line — matrix project → master plan project → project plan → blueprint → SOP/build. Each project has focused instructions, relevant skills, and knowledge files.

I need you to help me define what goes into each project — the instructions, skills, and knowledge files — starting with the Ruben/Crulliance assembly line so I can run his weekly cycle through it. Start by reading the handoff, then tell me what you see and what's missing before we build anything."