Blueprints & Treasure Maps

Two complementary systems for documenting the journey and guiding others.

The Distinction

Treasure Maps (Simple Business Plans)

  • Purpose: Guide others to success
  • Audience: Anyone who wants to follow
  • Format: Step-by-step instructions
  • Style: “Do this, then that”

Blueprints (Journey Documentation)

  • Purpose: Show WHY we chose what we chose
  • Audience: Reference material, future developers
  • Format: Historical narrative with decision points
  • Style: “We tried this → it failed → here’s why → we did this instead”

Blueprint Architecture

                    BLUEPRINT FORMAT
┌─────────────────────────────────────────────────┐
│                                                 │
│  START → Decision → [SUCCESS PATH]              │
│            │                                    │
│            └─→ [⚠️ DEAD END] → (click: why?)    │
│                     │                           │
│                     └─→ "Only used Jarvis for   │
│                         Lovable.dev. The        │
│                         blizzard fix took 3     │
│                         weeks. Star Chamber     │
│                         would have fixed it     │
│                         in <1 hour."            │
│                                                 │
│  → Next Decision → ...                          │
│                                                 │
└─────────────────────────────────────────────────┘

Dead-End Markers

Visual Indicator

<div class="dead-end-marker">
  ⚠️ DEAD END
  <span class="tooltip">Click to learn why</span>
</div>

Content Structure

When clicked, shows:

  1. What we tried
  2. Why it seemed like a good idea
  3. What went wrong
  4. Time/resources lost
  5. What we did instead
  6. Reference links to documentation

Example Blueprint: MimicTrunk Development

Path Taken

Decision: How to develop UI?
├── [⚠️ DEAD END] Lovable.dev only (Jarvis)
│   └── "Blizzard fix: 3 weeks of back-and-forth"
│   └── "21 conversations, 400+ messages"
│   └── "Still not working properly"
│
└── [✓ SUCCESS] Star Chamber + GitHub Bridge
    └── "Same fix: 45 minutes"
    └── "Now using Lovable as MimicTrunk"
    └── "All changes go through Star Chamber first"

The Blizzard Story (Documented)

Referenced in blueprint:

  • Problem: Mobile hamburger menu breaking
  • Duration: 3 weeks
  • Messages: 400+
  • Resolution attempts: 21
  • Final fix time with Star Chamber: <1 hour

Lesson: External AI tools are sandboxes, not production. Use them to prototype, use Star Chamber to implement.

Treasure Map Format

Simple Business Plan Template

# [Project Name] Treasure Map

## Destination
What you'll achieve: [clear outcome]

## Prerequisites
- [ ] Requirement 1
- [ ] Requirement 2

## The Path

### Step 1: [Action]
- Do this specific thing
- Expected result
- ⚠️ Don't go this way: [dead-end link]

### Step 2: [Action]
...

## Resources Needed
- Time: X hours
- Cost: Y credits/marks
- Skills: [list]

## Success Indicators
How you'll know you're done

Integration Points

With Cephas

  • Blueprints stored in Cephas under /journey/
  • Treasure maps stored under /guides/
  • Cross-linked via innovation numbers

With MimicTrunk

  • Failed experiments documented as dead-ends
  • Successful patterns become treasure maps
  • GitHub history provides raw data

With SENTINEL

  • Auto-detects when journey docs need updating
  • Flags when codebase diverges from documented path
  • Suggests new dead-end markers

With Upekrithen

  • Founder sees all blueprints
  • Can add private annotations
  • Can mark experimental paths

Hugo Implementation

Site Structure

blueprints-hugo/
├── content/
│   ├── blueprints/          # Journey documentation
│   │   ├── mimictrunk.md
│   │   ├── harper-system.md
│   │   └── yggdrasil.md
│   │
│   ├── treasure-maps/       # Simple business plans
│   │   ├── start-business.md
│   │   ├── join-node.md
│   │   └── earn-medallion.md
│   │
│   └── dead-ends/           # Detailed failure docs
│       ├── lovable-only.md
│       ├── manual-deployment.md
│       └── centralized-qa.md
│
├── layouts/
│   ├── shortcodes/
│   │   ├── dead-end.html    # ⚠️ DEAD END marker
│   │   ├── success-path.html
│   │   └── decision-tree.html
│   │
│   └── partials/
│       ├── journey-nav.html
│       └── related-failures.html
│
└── static/
    └── js/
        └── dead-end-tooltip.js

Shortcode: Dead-End Marker

{{/* layouts/shortcodes/dead-end.html */}}
<div class="dead-end-marker" data-detail-id="{{ .Get "id" }}">
  <span class="icon">⚠️</span>
  <span class="label">DEAD END</span>
  <span class="summary">{{ .Get "summary" }}</span>
  <div class="detail-panel hidden">
    {{ .Inner }}
  </div>
</div>

Usage in Blueprint

We needed to fix the mobile menu.




  Using only Lovable.dev
  

    
What we tried: Relying entirely on Jarvis (Lovable AI)
Duration: 3 weeks
Messages: 400+
Result: Still broken


Lesson: External AI tools need oversight. Use Star Chamber.


  





Instead, we created the Star Chamber approach.

Patented Mechanism References

When a Blueprint references a patented innovation:

We use the [Harper Review Protocol](/innovations/956) because...

→ Links to innovation page
→ Shows patent claim numbers
→ Explains why this approach was chosen

KISS 3-Tier Implementation

Quick View

  • Just the path: Start → Step 1 → Step 2 → Done
  • Dead ends shown as ⚠️ icons only

Standard View

  • Full steps with brief explanations
  • Dead end summaries visible
  • Key decision points highlighted

Deep View

  • Complete historical narrative
  • Full dead-end documentation
  • All reference links
  • Time/cost data
  • Alternative paths considered
SystemRelationship
CephasStores treasure maps publicly
UpekrithenStores blueprints privately
MimicTrunkSource of experimental data
SENTINELMonitors for drift
GRAFTINGImplements successful paths

Recent Blueprint: Shadow Marks System (Feb 2026)

Path Taken

Decision: How to incentivize recipe contributions?
├── [⚠️ DEAD END] Immediate rewards
│   └── "No quality filter — anyone posts anything"
│   └── "No commitment mechanism"
│   └── "Cold start unsolved"
│
└── [✓ SUCCESS] Shadow Marks + Vesting
    └── "Speculative rewards crystallize through validation"
    └── "Teaches vesting through cooking metaphor"
    └── "Equal opportunity: same tier = same reward"
    └── "Escape velocity → permanent IP protection"

Innovation References

  • #1218: Shadow Marks — Speculative reputation tokens
  • #1219: Category-based Recipe Bounties
  • #1220: Vesting Through Community Validation
  • #1221: Shadow Mark Decay Schedule
  • #1222: Escape Velocity IP Protection
  • #1223: Recipe Fork Attribution & Royalty Split
  • #1224: Makers vs Tasters Incentive Ratio
  • #1225: Early Taster Reward Tiers
  • #1226: Recipe IP Ledger Hash
  • #1227: Equal Opportunity Bounty

Key Learnings

  1. Vesting metaphor works: “Seeds need sunlight to grow” resonates
  2. Equal opportunity prevents race conditions: Everyone in same tier gets same reward
  3. Escape velocity creates permanence: 100 votes = IP Ledger protection forever
  4. Fork attribution preserves lineage: 80/20 split respects original creators

Educational Content (Canonical)

What is Vesting?

Think of Shadow Marks like seeds you plant. They need sunlight (community votes) to grow into real plants (real Marks). Without sunlight, they wither. But once they’re grown, they’re yours forever.

Your recipe “Water Salt” earned 50 Shadow Marks for being a French Elegant Dinner. If 10 people vote for it, those 50 become 50 real MARKS — permanently yours.

But if nobody votes for “Water Salt”… well, it withers. 🥀

Recent Blueprint: Root Return Navigation (Feb 2026)

Path Taken

Decision: How to navigate expandable card content?
├── [⚠️ DEAD END] Traditional breadcrumbs
│   └── "Takes up vertical space"
│   └── "Clutters the interface"
│   └── "Not intuitive on flip cards"
│
├── [⚠️ DEAD END] Back buttons only
│   └── "No way to explore forward"
│   └── "Forces return to menu repeatedly"
│   └── "Increases clicks"
│
└── [✓ SUCCESS] Root Return Chevron Pattern
    └── "Left chevron = always back to root overview"
    └── "Right chevron = advance to next item"
    └── "Visible by default (light green)"
    └── "Darkens on hover for affordance"
    └── "Universal pattern across all expandable cards"

Key Learnings

  1. Consistency over cleverness: Same pattern everywhere builds muscle memory
  2. Visibility matters: Light green background makes chevrons discoverable
  3. Escape hatch always available: Left chevron is always “back to safety”
  4. Forward exploration encouraged: Right chevron invites sequential discovery

Applied To

  • Main Card: “How Cost + 20% Works” topic navigation
  • Main Card: Initiative detail navigation within topics
  • Not Charity Card: Initiative dropdown expanded views
  • (Future) All expandable card content

Recent Blueprint: Initiative/Project Split (Feb 2026)

Path Taken

Decision: How to present 22 different ventures?
├── [⚠️ DEAD END] Grid of 22 buttons
│   └── "Overwhelming"
│   └── "No hierarchy"
│   └── "Equal visual weight for unequal maturity"
│
└── [✓ SUCCESS] Two dropdown categories
    └── "INITIATIVES (16) = Active operational businesses"
    └── "PROJECTS (6) = Developmental/experimental"
    └── "Vertical single-column layout"
    └── "3 visible rows with scroll"

Key Learnings

  1. Maturity distinction matters: Members understand some things are operational, others experimental
  2. Single-column improves scanning: Eyes track vertically better than grid
  3. Scroll containers manage density: Show enough to invite, hide enough to avoid overwhelm
  4. Width prevents wrapping: minWidth: 200px ensures initiative names display cleanly

Projects List (Experimental)

  1. Farmer/Warrior
  2. Healer/Assassin
  3. WarHorse
  4. Pneumatic Palm Tree
  5. HexIsle
  6. Water Table

Example Blueprint: HIVI & Sponsorship Cascade Economics

Decision: How to price platform services across currencies?

Decision: Cross-border pricing mechanism?
├── [⚠️ DEAD END] Fixed USD pricing
│   └── "Excludes weak-currency economies"
│   └── "Creates unfair participation barriers"
│
├── [⚠️ DEAD END] Dynamic currency conversion
│   └── "Continuous coupling to external volatility"
│   └── "External collapse affects internal economy"
│
└── [✓ SUCCESS] HIVI + Three-Gear Differential
    └── "One-way valve: capture external value, then decouple"
    └── "Ratchet: value can only increase"
    └── "Three gears absorb currency disparities"

Decision: How to frame locked-value service units?

Decision: Joule/Cloth Pouch marketing?
├── [⚠️ DEAD END] "Value protection" framing
│   └── "Sounds like investment product"
│   └── "SEC Howey concerns"
│
├── [⚠️ DEAD END] "Inflation hedge" framing
│   └── "Implies financial return expectation"
│   └── "Fails 'no profit expectation' test"
│
└── [✓ SUCCESS] Forever Stamp framing
    └── "Same service later that you would get now"
    └── "USPS analogy universally understood"
    └── "Prepaid access, not investment"
    └── "Clear non-security positioning"

Decision: How to enable community seeding?

Decision: Sponsorship mechanism?
├── [⚠️ DEAD END] One-time sponsorship only
│   └── "Limited cascade effect"
│   └── "No resurgence mechanism"
│
└── [✓ SUCCESS] Sponsorship Cascade
    └── "25 Credit minimum to sponsor anyone"
    └── "Recipients can split and add up to 5K more"
    └── "5K Sponsor badge for community seeders"
    └── "$10M cap resets and reopens at same terms"
    └── "Perpetual opportunity cycles"

Key Learnings

  1. Forever Stamp framing is legally critical: Avoids investment-like language
  2. One-way valve prevents external coupling: Internal economy survives external collapse
  3. Cascade enables exponential reach: One 5K sponsor → 45,500+ potential members
  4. HIVI is infrastructure, not investment: “How we price services” not “what you invest in”

Status: Live on lianabanyan.com

Last Updated: 2026-02-21

“The treasure map shows where to go. The blueprint shows why.”