Architectural Principles

Introduction

The vibeflow architecture is built on foundational principles that distinguish it from typical AI content tools. These aren’t arbitrary design choices—they’re deliberate constraints that enable:

Context quality over context quantity
Brand consistency at scale
Verifiable outputs (not AI slop)
Compounding value over time
Systems thinking (work ON the business, not IN it)

These principles are informed by:

The Phoenix Project (DevOps/systems thinking)
Domain-Driven Design (bounded contexts, clear boundaries)
Progressive disclosure (UX pattern applied to AI context)
Context architecture (the finite resource that defines quality)

This document explains why the architecture works the way it does.

Principle 1: Progressive Disclosure

What It Is

Progressive disclosure is the practice of loading only the context relevant to the current task, at the moment it’s needed—rather than front-loading all possible information. Origin: UX design pattern for managing complexity (don’t show all features at once) Applied to AI: Don’t load all strategy files into every conversation

The Core Problem

Token limits are finite. You can’t load your entire brand bible, all research, all frameworks into every conversation. But you also can’t work without guidance (that creates AI slop). The tension:

Load everything → Token overflow, degraded quality
Load nothing → AI slop, no brand consistency

Progressive disclosure resolves this tension.

How It Works

Instead of:

❌ Load all 50 strategy files into every conversation
   Result: Token limit hit, context truncated, quality degrades

Do this:

✅ Entry point files (STRATEGY.md, SKILL.md) act as tables of contents
   Agent reads entry point (500 lines)
   Entry point points to relevant detailed files
   Agent loads ONLY what's needed for current task
   Result: High-quality context, efficient token usage

Implementation in Vibeflow

1. Strategy Layer:

/strategy/STRATEGY.md                 ← Entry point (table of contents)
    ↓ points to
/strategy/voice/index.md              ← Universal voice guidelines
    ↓ points to (when needed)
/strategy/voice/extensions/twitter-post.md  ← Platform-specific details

Agent workflow:

Reads STRATEGY.md (navigation)
Identifies: “For voice, see /strategy/voice/index.md”
Loads voice/index.md (universal guidelines)
Sees: “For Twitter-specific, see extensions/twitter-post.md”
Loads extension ONLY if generating Twitter content

Result: 2-3 files loaded instead of 10+ 2. Skills Layer:

.claude/skills/conducting-market-research/SKILL.md  ← Entry point (< 500 lines)
    ↓ points to
competitive-analysis.md         ← Loaded ONLY when analyzing competitors
customer-interviews.md          ← Loaded ONLY when analyzing interviews
survey-design.md               ← Loaded ONLY when designing surveys

Agent workflow:

Loads SKILL.md (methodology overview)
Sees: “For competitive analysis, see competitive-analysis.md”
Loads detailed methodology ONLY when that step is needed

Result: Comprehensive guidance without overwhelming every conversation 3. Research Layer:

/research/customer-insight/RESEARCH.md   ← Entry point
    ↓ points to
/research/customer-insight/execution/2025-10-21/  ← Specific research run

Agent workflow:

Reads RESEARCH.md (which runs are available)
Identifies relevant run based on date or topic
Loads ONLY that execution’s findings

Result: Access to all research, load only what’s relevant

Design Rules

1. Entry points must be < 500 lines

This is a hard limit for performance
If approaching limit, split into separate files
Entry point acts as navigation, not comprehensive documentation

2. Use clear section headers pointing to files

## Voice Guidelines

For universal tone principles: See `/strategy/voice/index.md`
For platform-specific adaptations: See `/strategy/voice/extensions/`

3. Load details only when relevant

Don’t pre-load “just in case”
Load based on actual task requirements
Use entry points to navigate

Benefits

✅ Maximizes context quality

Every token used is relevant to the task
No wasted context on tangential information
Higher signal-to-noise ratio

✅ Scales better than flat files

Can have comprehensive strategy without token overflow
Add new platforms/content types without redesigning structure
System grows without degrading

✅ Agents navigate like humans

Read table of contents
Jump to relevant section
Load details as needed
Natural, efficient workflow

✅ Token efficiency

Typical content generation: 3-5 files instead of 20+
More room for actual content/analysis
Better quality outputs

Anti-Pattern: Flat Loading

DON’T do this:

Load all strategy files:
  voice/index.md
  voice/principles.md
  voice/vocabulary.md
  voice/extensions/twitter-post.md
  voice/extensions/linkedin-post.md
  voice/extensions/blog-post.md
  messaging/pillars.md
  messaging/value-propositions.md
  [... 20 more files]

Result: Token limit hit, quality degrades

DO this:

Load entry point:
  STRATEGY.md → "For voice, see voice/index.md"

Load universal:
  voice/index.md → "For Twitter-specific, see extensions/twitter-post.md"

Load specific:
  voice/extensions/twitter-post.md (ONLY if generating Twitter content)

Result: 2-3 files, high quality, efficient

Principle 2: One-Way Dependencies

What It Is

One-way dependencies means context flows downward only through the architectural layers. Lower layers cannot reference upper layers. The rule:

Layer 2 (Output Style) CAN reference → Layer 3 (Agents)
Layer 3 (Agents) CAN reference → Layer 4 (Skills)
Layer 4 (Skills) CAN reference → Layer 5 (Tools)

Layer 5 (Tools) CANNOT reference → Layer 4 (Skills)
Layer 4 (Skills) CANNOT reference → Layer 3 (Agents)
Layer 3 (Agents) CANNOT reference → Layer 2 (Output Style)

Direction of dependency:

Layer 1: Marketing Architect (Human)
    ↓ instructs
Layer 2: Operations Manager (Primary AI Agent)
    ↓ delegates to
Layer 3: Sub-agents
    ↓ use
Layer 4: Skills
    ↓ leverage
Layer 5: Tools

Dependencies flow DOWN only, never UP

Why This Matters

1. Prevents circular dependencies Without one-way constraint:

❌ Skill references Agent A
   Agent A references Skill B
   Skill B references Agent A
   → Circular dependency, infinite loop

With one-way constraint:

✅ Agent A references Skill 1 (downward)
   Skill 1 references Tool X (downward)
   No circular references possible

2. Enables independent evolution Example:

Change a Tool (Layer 5)
  ↓
Skills (Layer 4) need to update HOW they use the tool
  ↓
Agents (Layer 3) don't need to change (they just use skills)
  ↓
Output Style (Layer 2) doesn't need to change

If dependencies went both ways:

Change a Tool → Skills change → Agents change → Output Style changes
Ripple effects everywhere, fragile system

With one-way dependencies:

Change a Tool → Skills adapt (if interface changes) → Done
Impact is contained to adjacent layer

3. Manages context size Each layer only knows about layers below it: Sub-agent (Layer 3) knows:

✅ Which skills it has access to (Layer 4)
✅ Which tools skills use (Layer 5)
❌ Operations Manager behavior (Layer 2)
❌ Other sub-agents (also Layer 3)
❌ Marketing Architect goals (Layer 1)

Result: Isolated context, focused work, predictable behavior 4. Makes system navigable When debugging or understanding system:

Where does this content come from?
  → Check Content Writer (Layer 3)

What skills does Content Writer use?
  → Check agent definition (references skills in Layer 4)

How does that skill work?
  → Check skill file (references tools in Layer 5)

Clear path, always know where to look

Without one-way dependencies:

Where does this content come from?
  → Content Writer... but it references a skill that references another agent?
  → Skill references output style?
  → Confusing, hard to trace

Enforcement Mechanisms

1. Architectural rules (documented)

This principles document
Component documentation
Ownership guidelines

2. Code reviews (for infrastructure team)

New skills checked for upward references
Agent definitions validated
Output style reviewed

3. Validation tooling (future)

Automated checks for circular dependencies
Warnings when layers reference upward
Build-time validation

Anti-Pattern: Upward References

❌ DON’T: Skill referencing an agent

In conducting-market-research/SKILL.md:

"This skill should be used by the Brand Analyst agent"
← Upward reference from Layer 4 to Layer 3

✅ DO: Agent referencing skills

In .claude/agents/brand-analyst.md:

"This agent has access to:
  - Conducting Market Research (skill)
  - Analyzing Qualitative Data (skill)"
← Downward reference from Layer 3 to Layer 4

❌ DON’T: Tool referencing skill

In .mcp.json:

"Perplexity tool: Used by the Market Research skill"
← Upward reference from Layer 5 to Layer 4

✅ DO: Skill referencing tool

In conducting-market-research/SKILL.md:

"For web research, use Perplexity tool (mcp__perplexity__perplexity_research)"
← Downward reference from Layer 4 to Layer 5

Principle 3: Phoenix Project Influence

The vibeflow architecture applies principles from The Phoenix Project (a DevOps/systems thinking book) to marketing operations.

Core Phoenix Project Concepts

1. The Four Types of Work Every organization has four types of work:

Type	Definition	Vibeflow Example
Business Projects	Planned work that drives business value	Campaign planning, content creation, research projects
Internal Projects	Infrastructure improvements	Creating new skills, adding agents, improving architecture
Changes	Iterations from the first two categories	Updating messaging based on research, refining voice guidelines
Unplanned Work	Urgent requests, firefighting	Client asks for emergency blog post, competitor launches, crisis response

How vibeflow is conscious of this:

Meta commands enable internal projects (plan/implement for creating new capabilities)
PLAN.md and TODO.md show work being done (visibility across all four types)
Research domains track evolution (changes over time are preserved)
Temporal execution (can see what was unplanned vs. planned)

Why this matters: You can’t optimize what you can’t categorize. Knowing which type of work you’re doing helps you manage it appropriately. 2. Flow & Value Streams Phoenix Project principle: Work should flow smoothly from idea → plan → execution → delivery without bottlenecks or waste. How vibeflow implements this:

Value Stream 1: Research → Strategy → Content
  Input: Customer interviews (raw data)
    ↓ flows to
  Research execution (analysis)
    ↓ flows to
  Strategy files (research-backed claims)
    ↓ flows to
  Content generation (brand-consistent outputs)

  No bottlenecks, clear handoffs

Value Stream 2: Plan → Approve → Implement → Deliver
  Input: Marketing Architect request
    ↓ flows to
  PLAN.md creation (operations manager)
    ↓ flows to
  Approval gate (marketing architect)
    ↓ flows to
  Implementation (TODO.md tracking)
    ↓ flows to
  Deliverables

  Systematic flow, visible stages

Anti-pattern (bottlenecks):

❌ Research done but strategy never updated
   → Bottleneck: Research doesn't flow to strategy

❌ Strategy exists but content ignores it
   → Bottleneck: Strategy doesn't flow to content

3. Work Visibility (Make Work Visible) Phoenix Project principle: “You can’t manage what you can’t see.” How vibeflow implements this:

PLAN.md - Shows approach before work starts (visibility before execution)
TODO.md - Shows work in progress (visibility during execution)
Temporal execution - Shows research evolution (visibility over time)
Audit trails - Shows lineage (content → strategy → research, visibility of dependencies)
Git commits - Shows what changed when (visibility of history)

What becomes visible:

What work is planned (PLAN.md)
What work is in progress (TODO.md status)
What blockers exist (TODO.md blockers section)
What’s been completed (TODO.md completed tasks)
What research backs strategy (footnotes)
How markets are evolving (temporal research comparison)

Why invisibility is dangerous:

Invisible work = Unmanaged work
Unmanaged work = Chaos
Chaos = Thrashing, missed deadlines, poor quality

4. Limiting WIP (Work In Progress) Phoenix Project principle: “Finish work before starting new work.” Why unlimited WIP is bad:

Context switching → Efficiency loss
20 projects 50% done → Nothing delivered
No focus → Lower quality

How vibeflow encourages limiting WIP:

TODO.md best practice: One task marked “In Progress” at a time
Plan/implement pattern: Finish current plan before starting new
Date-stamped executions: Encourages completing research run before starting new
File structure: Prevents “20 half-finished projects” scattered chaos

Example:

✅ Good WIP management:
TODO.md shows:
  - [x] Completed task 1
  - [x] Completed task 2
  - [ ] IN PROGRESS: Task 3 (current focus)
  - [ ] PENDING: Task 4
  - [ ] PENDING: Task 5

Clear: One thing in progress, queue is visible

❌ Bad WIP management:
TODO.md shows:
  - [ ] IN PROGRESS: Task 1 (started yesterday)
  - [ ] IN PROGRESS: Task 2 (started this morning)
  - [ ] IN PROGRESS: Task 3 (just started)
  - [ ] PENDING: 10 more tasks

Chaos: Three things half-done, nothing shipping

5. Reducing Technical Debt (Marketing Debt) Phoenix Project principle: Technical debt accumulates when you take shortcuts, creating future work. For marketing, this becomes “marketing debt”:

Marketing Debt	What It Looks Like	Cost
Orphaned files	Research that’s lost, can’t find past work	Time wasted recreating existing work
Inconsistent outputs	Content doesn’t follow brand guidelines	Brand dilution, confusing messaging
Duplicate work	Can’t find if research already exists	Redundant effort
Broken references	Strategy claims with no backing	Unverifiable, weak positioning
Overwritten history	Lost insights from past research	Can’t see evolution

How vibeflow prevents marketing debt: 1. Everything has a place

Strategy → /strategy/
Research → /research/
Agents → .claude/agents/
Skills → .claude/skills/

No "random files in random places"

2. Temporal execution preserves history

Research runs:
  /execution/2025-10-20/
  /execution/2025-11-15/

Both preserved, nothing overwritten

3. Progressive disclosure creates navigation

Entry points (STRATEGY.md, RESEARCH.md, SKILL.md)
  → Always know where to start
  → No guessing where files are

4. Audit trails create accountability

Strategy → Research → Data
  Footnotes enforce this
  Can't make unsupported claims

Result: Marketing debt is prevented systematically, not by discipline alone.

Principle 4: Context Architecture Prevents AI Slop

The Fundamental Insight

Context is the finite resource that defines system capabilities. Most AI content tools fail because:

Generic AI + No Brand Context = AI Slop
  ↓
Result: "Innovative solutions leveraging cutting-edge technology"
(Could be any company, any product)

Vibeflow succeeds because:

Generic AI + Brand Context = Brand-Consistent Content
  ↓
Result: Specific claims, brand voice, research backing
(Sounds like YOUR company because it uses YOUR strategy)

What Is Context Architecture?

Context architecture is the systematic design of what information AI agents have access to, when they access it, and how it’s organized. Not just “prompts”—it’s infrastructure:

What files exist (strategy, research, frameworks)
How they’re organized (progressive disclosure)
What references what (one-way dependencies)
How it’s loaded (entry points, navigation)
What backs up what (audit trails)

How It Prevents AI Slop

AI slop happens when agents:

❌ Have no brand guidelines (generate generic language)
❌ Have no research backing (make unverifiable claims)
❌ Have no structural frameworks (use templates)
❌ Have no voice guidelines (sound like everyone else)

Brand-consistent content happens when agents:

✅ Load brand voice guidelines (specific tone, vocabulary)
✅ Reference research-backed claims (via strategy footnotes)
✅ Follow content frameworks (brand-specific structure)
✅ Use messaging pillars (strategic themes)

The difference is context:

Element	Without Context	With Context
Tone	Generic professional voice	YOUR brand voice (confident but approachable, etc.)
Claims	”Our innovative solution"	"8/10 customers abandon complex tools” (research-backed)
Structure	Generic template (intro → 3 points → conclusion)	YOUR framework (hook → insight → evidence)
Themes	Random topics	YOUR messaging pillars (simplicity, focus, etc.)

The Context Stack

Every piece of content inherits from this stack:

Layer 1: Voice Guidelines
  → How to say things (tone, vocabulary, style)

Layer 2: Messaging Framework
  → What to say (pillars, themes, positioning)

Layer 3: Research Backing
  → Why we can say it (customer data, market insights)

Layer 4: Content Frameworks
  → How to structure it (blog, email, social, etc.)

Layer 5: Platform Extensions
  → Platform-specific adaptations (Twitter vs. LinkedIn)

Agent generates content by traversing this stack:

Load voice → Load messaging → Load research reference → Load framework → Generate
  ↓
Result: Content that's YOUR brand, backed by YOUR research, following YOUR frameworks

Why This Scales

Traditional approach (doesn’t scale):

Human writes every piece of content
  → Bottleneck at human
  → Can't scale beyond human capacity
  → Quality varies by human skill

Vibeflow approach (scales):

Humans define strategy once
  → Agents generate content using that strategy
  → Scales to any volume
  → Quality is consistent (same strategy every time)

Key insight: You’re not outsourcing execution to AI. You’re encoding YOUR thinking into the architecture, and AI is the execution layer for your strategic decisions.

Principle 5: Temporal Execution

What It Is

Temporal execution means research runs are date-stamped rather than overwritten, preserving historical context and enabling comparison over time. Pattern:

/research/{domain}/execution/
├── /2025-10-20/    ← First run
├── /2025-11-15/    ← Second run
└── /2025-12-10/    ← Third run

Why This Matters

Markets change. Competitors evolve. Customer needs shift. Traditional approach (point-in-time):

Run research → Save to "Competitor Analysis.doc"
Run research again → Overwrite "Competitor Analysis.doc"
  ↓
Result: Lost historical context, can't see evolution

Vibeflow approach (temporal):

Run research → /execution/2025-10-20/
Run research again → /execution/2025-11-15/
  ↓
Result: Both preserved, can compare changes

What You Can Do With Temporal Data

1. Compare evolution

October: Competitor A positioned on "speed"
November: Competitor A now positioning on "simplicity"
  ↓
Insight: They're shifting toward our space (threat)

2. Validate trends

October: 3 competitors mention "AI"
November: 5 competitors mention "AI"
December: 8 competitors mention "AI"
  ↓
Insight: "AI" is accelerating as a category theme

3. See pattern emergence

October: Customer pain point: "Complex onboarding" (8/10)
November: Customer pain point: "Complex onboarding" (5/10)
  ↓
Insight: Our onboarding improvements are working

4. Inform strategic pivots

Q1 research: Market wants features
Q2 research: Market wants simplicity
Q3 research: Market wants integrations
  ↓
Strategy: Shift messaging based on market evolution

Temporal Patterns

1. Periodic comparison

Monthly: See trends
Quarterly: Strategic review
Annually: Long-term patterns

2. Event-driven

Competitor launch → New research run
Product release → Customer feedback analysis
Industry shift → Category landscape update

3. Iterative refinement

Run 1: 10 customer interviews
Run 2: 20 more interviews (validate patterns)
Run 3: Survey 200 customers (quantify)

Benefits

✅ Historical context preserved

Never lose insights
Can reference past research
See what’s changed

✅ Trend analysis enabled

Velocity (accelerating or slowing?)
Direction (toward us or away?)
Patterns (cyclical or linear?)

✅ Institutional memory

Knowledge compounds
New team members can see history
Context for current state

✅ Verifiable claims

Strategy can reference specific research run
Audit trail includes date
Claims have shelf life (can update when research is old)

Principle 6: Audit Trails & Verifiability

What It Is

Audit trails are explicit links from outputs back through strategy to research to raw data, making every claim verifiable. The chain:

Content (Output)
  ↓ uses
Strategy (Brand guidelines)
  ↓ references (footnote)
Research (Insights)
  ↓ analyzed from
Raw Data (Source material)

How It Works

Example: Content (blog post):

"Most productivity tools add complexity instead of removing it."

Strategy (/strategy/messaging/pillars.md):

Pillar: Simplicity Over Complexity

Our positioning: Most tools add complexity; we remove it.

Evidence: Customer research shows 8/10 users describe existing
tools as "adding complexity rather than reducing it."[^complexity-research]

[^complexity-research]: Customer research,
`/research/customer-insight/execution/2025-10-21/findings.md:42`

Research (/research/customer-insight/execution/2025-10-21/findings.md:42):

Pattern identified across interviews:
- 8 out of 10 customers used phrase "adds complexity"
- 6 out of 10 mentioned "more complicated than expected"
- Common theme: Tools promise simplicity, deliver configuration burden

Supporting quotes: See customer-005.md, customer-007.md, customer-009.md

Raw Data (/research/customer-insight/data/interviews/customer-005.md):

Q: What's your biggest frustration with productivity tools?

A: "Honestly? They make things MORE complicated. I just want to
get organized, but I end up spending hours configuring views,
learning shortcuts, watching tutorials. The tool becomes another
project to manage."

The Audit Trail

Following the chain:

Claim in content: "Most tools add complexity"
  ↓
Strategy reference: Simplicity pillar backed by research
  ↓
Research finding: 8/10 customers said this
  ↓
Raw data: Actual customer quote

Every step is verifiable, traceable

Why This Matters

1. Defensible positioning Without audit trail:

"Our tool is simpler"
  → Says who? Based on what?
  → Unverifiable, weak claim

With audit trail:

"Our tool is simpler"
  → Based on customer research (link)
  → 8/10 customers said competitors add complexity
  → Here are the actual quotes
  → Defensible, strong claim

2. Prevents AI slop AI slop happens when:

AI generates content with no grounding
  → "Our innovative solution leverages cutting-edge..."
  → No connection to reality

Audit trails prevent this:

AI must reference strategy
Strategy must reference research
Research must reference data
  → Can't make unsupported claims

3. Enables strategic iteration With audit trails, you can:

Update strategy when research changes
See which content references old research
Refresh claims based on new data
Know exactly what to update when market shifts

4. Creates accountability Every claim has a source:

Marketing claim
  ↓
Which strategy file?
  ↓
Which research finding?
  ↓
Which customer said this?

Clear accountability chain

Implementation

1. Footnote format in strategy:

[^footnote-name]: Context, `/research/domain/execution/date/file.md:line`

2. Reference in content:

Content generation agents load strategy
Strategy contains footnote
Agent can optionally load research for specific details
Content reflects research-backed claim

3. Git preserves history:

All strategy, research, content versioned
Can see when claims were added
Can see which research backed which strategy
Complete historical audit trail

Anti-Pattern: Claims Without Backing

❌ DON’T:

In /strategy/messaging/value-propositions.md:

"Customers love our simplicity."

[No footnote, no research reference]

✅ DO:

In /strategy/messaging/value-propositions.md:

"Customers choose us for simplicity over complexity—8 out of 10
users describe competitor tools as 'adding complexity' rather
than reducing it."[^complexity-research]

[^complexity-research]: Customer research,
`/research/customer-insight/execution/2025-10-21/findings.md:42`

How Principles Work Together

The Reinforcing System

These principles aren’t independent—they reinforce each other:

Progressive Disclosure
  ↓ enables
Loading relevant context efficiently
  ↓ which enables
Context architecture
  ↓ which prevents
AI slop
  ↓ and supports
Audit trails (can load research when referenced)
  ↓ which require
Temporal execution (research must exist to be referenced)
  ↓ which creates
Work visibility (Phoenix Project)
  ↓ which is enforced by
One-way dependencies (clear layers)

Example: Content Generation

All principles in action:

Progressive disclosure: Load only relevant strategy files (3-4 files, not 50)
One-way dependencies: Content Writer (Layer 3) uses skills (Layer 4) which reference tools (Layer 5)
Context architecture: Agent has voice, messaging, research context → prevents AI slop
Temporal execution: Strategy references latest research run
Audit trails: Content → strategy → research → data (all verifiable)
Phoenix Project: Work is visible (TODO.md), WIP is limited (one piece at a time)

Result: Brand-consistent content, efficiently generated, fully verifiable.

Success Criteria

You’re following principles correctly when: ✅ Entry points are < 500 lines (progressive disclosure) ✅ Layers reference downward only (one-way dependencies) ✅ PLAN.md and TODO.md make work visible (Phoenix Project) ✅ Research runs are date-stamped (temporal execution) ✅ Strategy footnotes reference research (audit trails) ✅ Content loads ≤5 files (progressive disclosure + context architecture) ✅ Outputs are indistinguishable from human brand work (context prevents AI slop) You’re violating principles when: ❌ Entry points exceed 500 lines (not progressive) ❌ Skills reference agents (upward dependency) ❌ Work happens without PLAN.md (not visible) ❌ Research overwrites previous runs (not temporal) ❌ Strategy makes claims without footnotes (no audit trail) ❌ Agents load 20+ files (not progressive) ❌ Content is generic/templated (context architecture failed)

Summary

The vibeflow architecture rests on six core principles:

Progressive Disclosure - Load only what’s needed, when it’s needed
One-Way Dependencies - Context flows downward through layers
Phoenix Project Influence - Make work visible, manage flow, limit WIP, reduce debt
Context Architecture - Context is the finite resource that prevents AI slop
Temporal Execution - Preserve history, enable comparison, see evolution
Audit Trails - Every claim is verifiable back to source data

These principles create a system that:

Scales brand consistency (context architecture)
Compounds value over time (temporal execution)
Prevents marketing debt (Phoenix Project)
Makes work manageable (progressive disclosure)
Keeps system navigable (one-way dependencies)
Ensures quality (audit trails)

This isn’t just “best practices”—it’s the foundation that makes vibeflow fundamentally different from AI content tools. You’re not renting AI writing capability. You’re building marketing infrastructure that improves over time.

Getting Started

The Five Layers

System Architecture

Workflows

Reference

​Architectural Principles

​Introduction

​Principle 1: Progressive Disclosure

​What It Is

​The Core Problem

​How It Works

​Implementation in Vibeflow

​Design Rules

​Benefits

​Anti-Pattern: Flat Loading

​Principle 2: One-Way Dependencies

​What It Is

​Why This Matters

​Enforcement Mechanisms

​Anti-Pattern: Upward References

​Principle 3: Phoenix Project Influence

​Core Phoenix Project Concepts

​Principle 4: Context Architecture Prevents AI Slop

​The Fundamental Insight

​What Is Context Architecture?

​How It Prevents AI Slop

​The Context Stack

​Why This Scales

​Principle 5: Temporal Execution

​What It Is

​Why This Matters

​What You Can Do With Temporal Data

​Temporal Patterns

​Benefits

​Principle 6: Audit Trails & Verifiability

​What It Is

​How It Works

​The Audit Trail

​Why This Matters

​Implementation

​Anti-Pattern: Claims Without Backing

​How Principles Work Together

​The Reinforcing System

​Example: Content Generation

​Success Criteria

​Summary

Architectural Principles

Introduction

Principle 1: Progressive Disclosure

What It Is

The Core Problem

How It Works

Implementation in Vibeflow

Design Rules

Benefits

Anti-Pattern: Flat Loading

Principle 2: One-Way Dependencies

What It Is

Why This Matters

Enforcement Mechanisms

Anti-Pattern: Upward References

Principle 3: Phoenix Project Influence

Core Phoenix Project Concepts

Principle 4: Context Architecture Prevents AI Slop

The Fundamental Insight

What Is Context Architecture?

How It Prevents AI Slop

The Context Stack

Why This Scales

Principle 5: Temporal Execution

What It Is

Why This Matters

What You Can Do With Temporal Data

Temporal Patterns

Benefits

Principle 6: Audit Trails & Verifiability

What It Is

How It Works

The Audit Trail

Why This Matters

Implementation

Anti-Pattern: Claims Without Backing

How Principles Work Together

The Reinforcing System

Example: Content Generation

Success Criteria

Summary