HFA Response — Maxine Commercial Handbook Addendum

HFA's technical and operational read on the Addendum

Section-by-section response to Sarita's Handbook v1.1. This document is HFA's formal input before the main Handbook is updated.

The system principle holds — HFA fully endorses it

"Content engine first. Automation second. Conductor approval always."

Every HFA workflow in the Maxine system is built around this. Nothing publishes without Sarita's approval gate. The automation moves content from Maxine to Notion and from Notion to platforms — it does not decide, select, or approve anything.

Section 1 — Content Engine Library Doctrine

HFA read: Aligned. Notion stores and retrieves. n8n connects Maxine's output to Notion and connects Notion's approved assets to publishing destinations. The library never becomes the campaign brain — Maxine owns that. HFA's workflows will write to and read from these libraries with full field discipline, using the exact field structure Sarita defines.

Section 2 — Domain-Specific Library Pattern

HFA read: Clean architecture. Two libraries is the right call — the fields differ enough between music campaign and traditional campaign work that a single library would become unmanageable. HFA will build both Notion databases with the exact fields from the Addendum, plus add a Campaign Mode field that maps to Maxine's 11 modes. This is the link between Section 2 and Section 6.

Section 3 — Publishing Queue Decision Rule

HFA recommendation: Do not build the queue yet. The content library publishing fields handle single-platform, manual, or simple scheduled posts. Build the Publishing Queue as a separate Supabase operations table only when one asset needs to go to multiple platforms on different dates with different versions. Trigger condition: when the Lowcountry Jazz Festival campaign requires Facebook + Instagram + Email simultaneously with platform-specific versions. Until then — library fields are sufficient.

Section 4 — JSON Routing Contract Rule

HFA read: This is HFA's direct implementation territory. n8n reads the content_domain field from Maxine's output JSON and routes to the correct Notion library. HFA proposes extending the JSON beyond the two-field example in the Addendum to include campaign mode, status, platform targets, and approval flag. See Tab 04 for the full JSON schema proposal. The rule that JSON records but does not decide is core to everything HFA builds here — the cognition boundary holds.

Section 5 — Joint Client Orchestration

HFA read: All four TBDs can be answered now. See Tab 05 for the full ownership JSON with HFA's positions on each. Short version: client relationship owner is determined at intake by who originated the relationship. Database owner is split — Notion structure is AI Aunties' domain, Supabase operations is HFA's. Publishing operator is HFA for automated multi-platform delivery, Conductor for manual single posts. Orchestration owner is HFA as Mode 1 (Auntie Workflow Extension), with Conductor approval always as the non-negotiable gate.

Section 6 — Campaign Mode Routing

HFA can solve this in n8n. Before Maxine runs, an intake workflow reads the brief, identifies intent signals, and presents the correct mode options when intent is ambiguous — surfacing the exact question Sarita wrote: "Do you want a quick ticket-push post, a deeper cultural story post, or a story-led ticket movement post?" This is a pre-Auntie routing workflow (Category 1 in the scope architecture) that HFA builds as part of the intake bundle. See Workflow 01 in Tab 02.

Section 7 — Evidence to Preserve from Testing

HFA recommendation: The rejection patterns (AI-ism drift, campaign-copy patterns) should be logged to Supabase — not just stored in Notion. Supabase allows queryable pattern analysis over time. A weekly summary workflow pulls the most common rejection patterns and sends them to Sarita as a brief, enabling systematic improvement of Maxine's taste pack. See Workflow 05 in Tab 02.

The one thing HFA wants to flag before Sarita updates the main Handbook

The Addendum defines Campaign Mode as a product requirement for commercial deployment (Section 6). This needs to be a Notion field in both libraries — so every output is tagged with its mode. This allows Sarita to filter the library by mode, build pattern reports, and eventually build a mode-specific performance view. HFA is proposing this as a required field, not optional.

7 n8n workflow proposals for the Maxine system

Organized by category from the scope architecture. Every workflow respects the cognition boundary: Maxine thinks, n8n routes and executes. Conductor approves before anything publishes.

WORKFLOW 01 · CAT 1 — INPUT

Campaign Brief Intake → Mode Router → Maxine

Cat 1 · Input Solves Section 6 mode routing

Client submits a campaign brief → n8n reads intent → routes to correct mode → retrieves relevant library context → fires Maxine with mode + context pre-loaded

Flow

📋 Brief submitted (form / Telegram)

→

Intent parsed

→

Mode ambiguous?

→

Presenter: mode options to user

→

content_domain set

→

Relevant library context pulled

→

🧠 Maxine fires with brief + mode + context

n8n nodes

Trigger

Webhook / Telegram node

Receives campaign brief from form or Telegram message

Parse

IF / Switch node

Reads intent keywords: "ticket," "story," "cultural," "partnership," etc.

Clarify

Telegram response node

If ambiguous: sends Maxine's mode question to user. Waits for selection.

Enrich

Notion query node

Pulls relevant prior campaigns, source documents, and rejected patterns from correct library

Execute

HTTP Request (GPT API)

Fires Maxine with: brief + confirmed mode + content_domain + library context

Cognition boundary

n8n identifies the mode type from keywords and presents options. Maxine decides what to do with the mode and how to produce the output. n8n does not select the mode — it confirms the user's selection and routes accordingly.

WORKFLOW 02 · CAT 2 — OUTPUT

Maxine Output → Content Domain Router → Correct Library

Cat 2 · Output Core routing workflow

Maxine produces output → JSON content_domain read → routed to correct library with all fields populated → Conductor notified for approval → nothing moves without approval

Flow

🧠 Maxine output received (webhook)

→

content_domain read from JSON

→

music_campaign or traditional?

→

Correct library fields populated

→

Notion entry created · Status: Pending Approval

→

🎯 Conductor notified

n8n nodes

Receive

Webhook trigger

Fires when Maxine produces output from GPT API

Route

Switch node (content_domain)

Reads content_domain field → routes to music or traditional path

Write

Notion node (correct library)

Creates new database entry with all fields — Status: Pending Approval, Ready to Publish: false

Log

Supabase node

Appends session record to model registry with campaign_mode, domain, and session_id

Notify

Telegram / email node

Sends Sarita a notification: "New Maxine output ready for review in [library] — [Asset Title]"

Hard gate — this workflow cannot be bypassed

The Notion entry is created with Status: Pending Approval and Ready to Publish: FALSE. Nothing in the publishing workflow (Workflow 04) fires until Sarita changes Ready to Publish to TRUE. The Conductor approval is not a step — it is a hard gate built into the database field logic.

WORKFLOW 03 · CAT 1 — INPUT

Source Dossier Builder

Cat 1 · Input Solves Anthony Hamilton pattern from Section 7

Research documents provided (URLs, PDFs, articles) → n8n aggregates and structures → consolidated dossier filed to library → Maxine triggered in Source Dossier / Campaign Prep mode

Flow

📎 Research sources submitted

→

n8n aggregates: URLs fetched, PDFs extracted

→

Structures as dossier format

→

Filed to Music Library as Source Document

→

🧠 Maxine triggered: Source Dossier mode

Trigger

Form / Telegram node

Receives list of sources (URLs, PDFs) for a specific artist or festival

Fetch

HTTP Request + Extract From File

Fetches URLs and extracts text from PDFs

Structure

Code node

Formats all source text into structured dossier input for Maxine

File

Notion node

Creates Source Document entry in Music Campaign Library with all sources referenced

Execute

HTTP Request (GPT API)

Fires Maxine in Source Dossier / Campaign Prep mode with structured source input

WORKFLOW 04 · CAT 2 — OUTPUT + DELIVERY

Conductor Approval → Publishing Gate

Cat 2 · Output Conductor approval → single or multi-platform

Sarita marks "Ready to Publish" TRUE → n8n fires → reads platform + date → routes to manual notification or automated publishing → write-back to Notion

Flow

Sarita marks Ready to Publish: TRUE

→

Notion trigger fires

→

Single platform or multi?

→

Single: notification to Conductor with content

→

Multi: parallel publishing paths (Phase 2)

→

Write-back: Published Date + Link + Status: Published

Trigger

Notion database trigger

Fires when "Ready to Publish" checkbox is set to TRUE

Check

IF node (platform count)

Reads platform field — single entry = manual notification; multiple = queue (Phase 2)

Notify

Telegram node

Single platform: sends content to Conductor with copy-ready format and post instructions

Write-back

Notion node

Updates Notion record: Status → Published, Published Date → now, Published Link → URL

Log

Supabase node

Appends to campaign performance log: domain, mode, platform, dates

Phase 1 vs Phase 2

Phase 1: single-platform path routes a notification to Conductor with formatted content. Conductor posts manually or approves automation. Phase 2: when multi-platform volume requires it, the Publishing Queue (Supabase) handles parallel platform delivery with retry tracking.

WORKFLOW 05 · CAT 3/4 — BRAIN + GOVERNANCE

AI-ism Rejection Pattern Logger + Weekly Brief

Cat 3 · Brain Cat 4 · Governance Solves AI-ism rejection evidence from Section 7

Conductor rejects output or Lux review fails → rejection captured with full context → logged to Supabase → weekly pattern brief to Sarita for taste pack improvement

Flow

Conductor rejects OR Lux fails QA

→

Rejection captured: content, reason, mode, domain

→

Supabase rejection log appended

→

Notion Status → Rejected

→

⏰ Weekly: patterns summarized → brief to Sarita

Trigger A

Notion trigger (rejection)

Fires when Conductor marks Status = "Rejected" with Conductor Notes

Trigger B

Lux QA webhook

Fires when Lux review cycle reaches max iterations without pass

Log

Supabase node

Appends: rejected content snippet, reason, campaign_mode, content_domain, date, conductor_notes

Weekly brief

Schedule trigger + GPT summarize

Every Monday: queries last 7 days of rejections, GPT identifies top 3 drift patterns, sends brief to Sarita

WORKFLOW 06 · CAT 2 — OUTPUT

Campaign Calendar Sequencer

Cat 2 · Output Maxine Campaign Calendar mode

Maxine produces a campaign calendar in Calendar/Sequencing mode → n8n parses the calendar structure → creates one Notion library entry per asset → sets scheduled dates → Conductor 24hr reminder before each

🧠 Maxine: Campaign Calendar output

→

Parse calendar structure

→

Create Notion entry per asset

→

Platform + Date + Mode set per entry

→

⏰ 24hr reminder to Conductor before each

Receive

Webhook trigger

Maxine's calendar output received as structured JSON

Parse

Code node

Splits calendar into individual asset items with date, platform, mode, and copy

Create

Notion node (loop)

Creates one library entry per asset with Scheduled Date, Status: Pending Approval

Remind

Schedule trigger

24 hours before each Scheduled Date: sends Conductor a reminder with asset preview

WORKFLOW 07 · CAT 5 — PHASE 2 ONLY

Multi-Platform Publishing Queue

Cat 5 · Downstream Build only when volume requires

When one asset must go to multiple platforms on different dates with different versions — Supabase Publishing Queue handles parallel paths, retry tracking, and status write-back

Trigger condition (do not build until this is true)

One Maxine asset must go to Facebook + Instagram + Email on different dates

Multiple platform-specific versions of the same asset exist

Volume requires retry tracking (failed posts need to re-queue)

Published links need to differ per platform and write back separately

Conductor approves + platforms > 1

→

Supabase Publishing Queue row created

→

Parallel paths spawned per platform

→

Platform-specific format adapted

→

Status write-back per platform

→

Notion record updated with all published links

Notion Content Engine Library Architecture

HFA builds both databases in Notion with full field structure. The field schemas follow Sarita's Addendum exactly with additions noted. The "Ready to Publish" checkbox is the HFA automation trigger — nothing fires without it.

HFA additions to Sarita's field list (marked with ★)

Campaign Mode field (maps to Maxine's 11 modes), content_domain field (for JSON routing), Session ID (for model registry linking), and Lux Review Status (for QA loop integration). All other fields are exactly as defined in the Addendum.

Music Campaign Library — Notion Database

Field Name	Type	Options / Notes	HFA Automation Role
Asset Title	Title	Required — primary identifier	Used in Conductor notification
Festival Name	Select	Lowcountry Jazz Festival, other	Routes source dossier builder
Campaign Name	Text	Maxine-generated or user-entered	JSON routing field
Artist Name	Select	Anthony Hamilton, Keiko Matsui, other	Dossier builder trigger
Story Title	Text	Story-led content identifier	—
Asset Type	Select	Post, Email, Carousel, Ticket Push, Story Post, Visual Direction, Source Dossier, Email Sequence	Publishing path routing
★ Campaign Mode	Select	All 11 Maxine modes: Deep Cultural Storytelling, Ticket Push, Story-Led Ticket Movement, Source Dossier, Visual Direction, Campaign Calendar, Email Sequence, Carousel, Audience Segment, Traditional Campaign, Partnership Campaign	Mode routing + pattern analysis
★ content_domain	Select	music_campaign, traditional_campaign	JSON routing field — set by WF 02
Content / Copy	Rich Text	Maxine's full output — never altered by n8n	Read-only by automation
Source Document	Files / URL	Research materials, dossiers, briefs	Dossier builder writes here
Created Date	Date (auto)	Auto-set on creation	Auto-populated
Status	Select	Draft → Pending Approval → Approved → Scheduled → Published → Rejected	WF 02 sets Pending. WF 04 sets Published. WF 05 sets Rejected.
Conductor Notes	Text	Sarita's review notes	WF 05 captures on rejection
Platform	Multi-select	Instagram, Facebook, Email, LinkedIn, Twitter	WF 04 reads to route publishing
Scheduled Date	Date	When to publish	WF 06 sets per calendar entry. WF 04 triggers at time.
Published Date	Date	Auto-set by WF 04 write-back	Written by WF 04
Published Link	URL	Live post URL	Written by WF 04
Ready to Publish	Checkbox	Conductor sets TRUE — THIS IS THE GATE	WF 04 trigger — nothing fires until TRUE
★ Session ID	Text	Links to Supabase model registry	WF 02 populates for cross-system tracking
★ Lux Review Status	Select	Not reviewed, Passed, Failed, Escalated	QA loop integration (future)

Traditional Campaign Library — Notion Database

Field Name	Type	Options / Notes	HFA Automation Role
Asset Title	Title	Required — primary identifier	Used in Conductor notification
Campaign Name	Text	e.g. "AI Aunties + HFA Launch"	JSON routing field
Client / Brand Name	Select	AI Aunties, HFA, joint, client names	Orchestration ownership routing
Subject / Offer	Text	What the campaign is about	—
Asset Type	Select	LinkedIn Post, Email, Carousel, Campaign Strategy, Partnership Content, Offer Campaign, Civic Campaign	Publishing path routing
★ Campaign Mode	Select	Traditional Campaign Strategy, Partnership Campaign, Email Sequence, Carousel Campaign, Audience Segment Campaign, Founder-Led, Service Launch	Mode routing + pattern analysis
★ content_domain	Select	traditional_campaign	JSON routing field
Content / Copy	Rich Text	Maxine's full output — never altered	Read-only by automation
Source Document	Files / URL	Briefs, strategy docs, research	—
Created Date	Date (auto)	Auto-set	Auto-populated
Status	Select	Draft → Pending Approval → Approved → Scheduled → Published → Rejected	Same gates as Music library
Conductor Notes	Text	Sarita's review notes	WF 05 captures on rejection
Platform	Multi-select	LinkedIn, Email, Instagram, Facebook, Twitter	Publishing path routing
Scheduled Date	Date	When to publish	WF 06 sets. WF 04 triggers.
Published Date	Date	Auto-set by WF 04	Written by WF 04
Published Link	URL	Live post URL	Written by WF 04
Ready to Publish	Checkbox	Conductor sets TRUE — THE GATE	WF 04 trigger
★ Session ID	Text	Links to Supabase model registry	WF 02 populates

JSON Routing Implementation

HFA extends Sarita's two-field JSON schema into a full routing contract. The extended schema gives n8n everything it needs to route, file, log, and gate — while preserving Maxine's content verbatim.

Full Maxine output routing JSON (HFA proposal)

{
  // AI Aunties defines these — n8n reads them
  "content_domain": "music_campaign",          // Routes to correct Notion library
  "campaign_mode": "deep_cultural_storytelling",  // Maxine's active mode — required
  "auntie": "maxine",
  "asset_type": "story_post",

  // HFA writes these during routing
  "routing_destination": "maxine_music_campaign_library",
  "session_id": "mx_20260618_001",                // Links to Supabase model registry
  "status": "pending_approval",
  "ready_to_publish": false,                  // Hard gate — never true on creation

  // Campaign context (from WF 01 intake)
  "campaign_name": "Anthony Hamilton — Festival Campaign",
  "artist_name": "Anthony Hamilton",
  "festival_name": "Lowcountry Jazz Festival",

  // Publishing targets (Conductor sets platform)
  "platform_targets": ["instagram", "facebook"],
  "scheduled_date": "2026-06-25",

  // Cognition boundary confirmation
  "requires_conductor_approval": true,
  "content_alteration_by_workflow": false  // n8n never changes Maxine's content
}

The ownership JSON — HFA's complete answer to Section 5 TBDs

{
  "ownership": {
    "campaign_strategy_owner": "AI Aunties",
    "content_owner": "AI Aunties (Maxine produces, Conductor approves)",
    "auntie_cognition_owner": "AI Aunties",
    "story_selection_owner": "AI Aunties",
    "language_quality_owner": "AI Aunties",
    "final_approval_owner": "Sarita Myers / Conductor — always",

    // HFA owns the execution layer
    "workflow_build_owner": "Human First Automations",
    "automation_reliability_owner": "Human First Automations",
    "publishing_mechanics_owner": "Human First Automations (automated) | Conductor (manual)",
    "orchestration_owner": "Human First Automations (Mode 1 — Auntie Workflow Extension)",

    // TBDs now answered
    "client_relationship_owner": "Lead brand who originated the relationship — determined at engagement intake",
    "database_owner": {
      "notion_structure": "AI Aunties governs field schema",
      "notion_integration": "Human First Automations builds n8n connection",
      "supabase_operations": "Human First Automations — publishing ops, rejection log, session data"
    }
  }
}

Content domain routing table (n8n IF/Switch logic)

content_domain value	n8n routes to	Notion database	Library context pulled
`"music_campaign"`	Music Campaign path	Maxine Music Campaign Library	Prior music campaigns, source dossiers, artist history
`"traditional_campaign"`	Traditional Campaign path	Maxine Traditional Campaign Library	Prior brand campaigns, partnership history, service launches
`null` or missing	Intake WF 01 re-triggered	—	Mode question sent to user for clarification

HFA's answers to the Section 5 TBDs

These are HFA's definitive operational positions. Sarita should review these before updating the main Commercial Handbook. Any position marked ⚠️ should be discussed before it is codified.

client_relationship_owner

Was: TBD

HFA answer: The brand who originated the client relationship. Determined at engagement intake and recorded in the engagement scope document. If AI Aunties sourced the client (festival, cultural org, NPO, founder), AI Aunties owns the client relationship. If HFA sourced the client (solopreneur, small business, workflow subscription), HFA owns it. For joint engagements where both brands are co-named, the lead varies by what the client primarily bought.

Implementation: add "client_relationship_owner" field to the engagement intake form. Value locked at deal start. Cannot be changed without both founders agreeing.

database_owner

Was: TBD

HFA answer: Split ownership. Notion field schema and library structure is governed by AI Aunties — Sarita defines what fields exist and what they mean. HFA builds the n8n connections that write to and read from those databases. Supabase is HFA's domain — publishing operations, rejection log, session data, model registry, and performance tracking live in Supabase, built and owned by HFA. Neither party modifies the other's database layer without discussion.

publishing_operator

Was: Human First Automations or client, depending on scope

HFA answer: Two clear tiers.

Tier 1 — Manual: Single platform, Conductor posts directly. HFA workflow sends a notification with copy-ready formatted content. No automation beyond the notification.

Tier 2 — Automated (Phase 2): Multi-platform, scheduled, with version adaptation. HFA builds and operates the publishing pipeline. Conductor approval remains the hard gate — automation only fires after "Ready to Publish" is TRUE.

The Addendum's decision rule (library publishing fields now, separate queue when volume requires) stays intact.

orchestration_owner

Was: TBD

HFA answer: Human First Automations — Mode 1 (Auntie Workflow Extension). HFA owns the orchestration of all n8n workflows in this system: intake routing, output routing, library filing, approval gating, publishing mechanics, rejection logging, and calendar sequencing. This is governed by the AI Aunties Commercial Build & Deployment Handbook. AI Aunties owns the Conductor role — the decision point that every automated workflow must pause at before any content moves to publication.

⚠️ Discussion point: For joint client engagements where HFA has an independent relationship with the client, the orchestration boundary should be clarified in writing. HFA Mode 2 (downstream) vs. Mode 1 (inside AIA scope) may overlap on some joint engagements. This should be addressed before first joint commercial Maxine deployment.

Maxine evidence table — HFA's read on Section 7 lessons

Evidence	System Lesson	HFA Implication
Anthony Hamilton dossier consolidation	Maxine can ingest messy research	Source Dossier Builder (WF 03) handles multi-source aggregation automatically
Anthony ticket-push test	Maxine needs mode routing when user asks for sales movement	WF 01 mode router presents clarifying question before firing Maxine
Keiko Matsui story-pillar test	Maxine can identify culturally sensitive story pillars	Campaign Mode field captures this in library — enables pattern analysis over time
HFA campaign package	Maxine works beyond music/festival	Traditional Campaign Library handles this domain — same architecture, different fields
AI-ism rejection patterns	Taste Pack and rejection gates must include drift patterns	WF 05 logs all rejections to Supabase with context. Weekly brief surfaces top 3 patterns.

Build phase recommendation

Three phases. Phase 1 is what HFA can build now. Phase 2 is triggered by volume. Phase 3 is joint client commercial scale.

Phase 1 — Build now

Content Engine Foundation

Everything Maxine needs to move from testing to commercial deployment. Both libraries. All routing. Conductor gate. Rejection logging.

Two Notion databases: Music Campaign Library + Traditional Campaign Library with all field structures including HFA additions

WF 01 — Campaign Brief Intake + Mode Router: Solves the Section 6 mode routing requirement before commercial deployment

WF 02 — Maxine Output → Domain Router → Library: Core routing workflow. content_domain field routes to correct library. Conductor notified.

WF 03 — Source Dossier Builder: Solves the Anthony Hamilton aggregation lesson. Multi-source research → structured dossier → Maxine

WF 04 — Conductor Approval Gate: Notion trigger on "Ready to Publish" → content notification → write-back. Single-platform path only.

WF 05 — Rejection Pattern Logger: Conductor rejection or Lux fail → Supabase log → weekly pattern brief to Sarita

Estimated build: 2–3 sessions. Prerequisite: Notion library databases created by Sarita with agreed field schema. HFA connects to them via n8n Notion API.

Phase 2 — Build when volume requires

Campaign Calendar + Multi-Platform Publishing

Triggered when a single asset needs to go to multiple platforms, or when campaign volume requires a true publishing operations layer.

WF 06 — Campaign Calendar Sequencer: Maxine calendar output → one Notion entry per asset → 24hr Conductor reminders

WF 07 — Multi-Platform Publishing Queue: Supabase queue, parallel platform paths, retry tracking, write-back per platform

Platform-specific adapters: Caption length, image ratio, hashtag strategy per platform — n8n applies formatting rules without altering Maxine's content

Performance log: Published date, platform, engagement write-back to Supabase for campaign pattern analysis

Trigger: when Lowcountry Jazz Festival campaign requires Facebook + Instagram + Email on different dates with platform-specific versions.

Phase 3 — Joint client commercial scale

Joint Client Orchestration + Revenue Tracking

Triggered when the partnership has active joint clients and needs formal orchestration, ownership tracking, and revenue split automation.

Joint engagement intake workflow: Captures client_relationship_owner at intake, routes to correct brand for billing

Revenue split enforcement: Integrates with HFA's CFO agent (Stripe metadata) to enforce agreed split per engagement

Cross-brand orchestration log: Tracks which workflows belong to which brand for governance compliance

Lux QA integration with Maxine libraries: Full Maxine/Lux review cycle connected to Notion library status fields

Prerequisite: revenue split formally agreed and signed. Joint client orchestration rule added to main Commercial Handbook.

The immediate action for both founders

Sarita creates the two Notion databases with the agreed field schema from Tab 03. HFA gets API access to both databases. HFA builds Phase 1 workflows (WF 01–05). After first Maxine commercial deployment completes, Sarita updates the main Commercial Handbook with the five items from Section 8 of the Addendum. Phase 2 and 3 build after the system is live and producing.