Mycelia Present · rendered 2026-05-26T18:22:24.745Z · source: ../convivium/clients/emerson_fry/EF_PRODUCTION_TOOLS_BUILD_PROPOSAL_v0.1.md

EF Production Tools — Build Proposal v0.1

Filed: 2026-05-26 by Mycelia Triggered by: Billy's "GO TIME" directive 2026-05-26 — Keep brand+marketing story as deck lead. Add Ryan's three production-workflow tools (image selection + retouching + dev/print-swap) as amplification of low-hanging fruit we take on now, not as a pivot. Press in, build the tools, deep proposals required. For: Billy first; Faber as primary builder; Lumen + Mercator + Praetor as coordinated support; Polaris (StarNetwork science officer) for cross-network knowledge transfer. Status: v0.1 spec — Faber-actionable build scope. Billy approves direction → Faber starts immediately.

1. The frame (corrected from prior pivot mistake)

Earlier today I drafted EF_RYAN_3_CONCRETE_ASKS_PLAN_v0.1 proposing we lead the deck with Ryan's three operational asks. That was the wrong read. Billy's correction:

"I want to still build the larger marketing and brand story I just want to add the production workflow tools and narrative as part of the story not lead with them just amplify them as large low hanging fruit we can take on now."

Correct frame: The brand + marketing story still leads the deck. The three production tools are additive amplification — Day-1 deliverable capabilities we ship in parallel with the brand-system work. They cover Ryan's stated black-and-white asks; they don't replace the broader value-creation thesis.

This is also a structural alignment: the production tools + the marketing system both run on the same Gemini-multimodal substrate. The same agent doing the brand-coherent founder-voice emails ALSO does the image culling, the retouching, the print-swap. Different surfaces; same architecture.

Billy's other directives:

2. What RedStar already has (substrate we adapt — don't reinvent)

/Users/bpk_2025_laptop/Documents/DDG_ImageEditTool/ contains RedStar (the Star Studio image-edit tool, Pixura-branded). Reading the existing implementation:

Current RedStar capabilities:

Where RedStar's pattern directly applies to EF:

Where RedStar's pattern doesn't apply (we build new):

Polaris commune ask: Polaris (StarNetwork science officer) likely has deeper context on RedStar's architecture choices + Gemini optimization patterns + cost economics at scale. When this proposal is approved, I'd like to surface 3-5 specific questions for Polaris through Billy as facilitator. Putting those at end of this doc (§9).

3. Tool #1: Image Selection (Cull + Tag + Review)

What it does

Replaces the ~180-200 team days/year currently consumed by selection + tagging in Lightroom with a Gemini-powered web tool that does:

(a) Auto-tagging at delivery. Every image from a shoot gets analyzed by Gemini 2.5 Flash (vision) and tagged with:

Replaces ½ to 1 day of manual Lightroom tagging per shoot day with near-zero-touch processing at delivery.

(b) First-cut auto-scoring. Each image scored on Ryan's documented criteria:

Reduces 2,500 → ~250-400 candidates per shoot day in under an hour (auto-pass), surfacing the top candidates for human review.

(c) Brand-aware final cut. Score the working set on:

Surfaces top 10-12 per product matching Ryan's documented target. Human approves.

(d) Shared review interface. Replaces Lightroom's per-user-ratings limitation:

(e) Task queue per team member. Replaces the no-task-queue gap. Each user's "what needs your action" view, with notifications when new shoot batches arrive or items get routed to them.

(f) Cross-product image discovery. Tag-based search across folders eliminates the Lightroom-dependency for finding cross-product images. Database-backed; products tagged on multiple images appear in queries for any of them.

Designer-knobs philosophy

Simple-first surface, progressive disclosure:

| Default user (Emerson / Ryan / approving editor) | Click "Review my queue" → see top auto-cut + approve in bulk OR drill into individual images | | Power user (senior photo editor / retoucher) | Same default, plus: adjust per-criterion scoring weights ("emphasize character over composition this season"); over-ride auto-tags; reorder by any criterion | | Custom workflow (advanced) | Build per-shoot scoring profiles ("Holiday lookbook needs higher character + lower product-isolation than Spring Revival"); pin reference images that auto-train the scoring for THIS shoot |

UX target: a non-technical user (Emerson, e.g.) can review + approve a 2,500-image shoot in 30-45 min vs. 4 days. A power user can dial in custom scoring profiles for specific shoot types.

Technical architecture

Stack: Next.js (matches Faber's existing EF platform stack) + Gemini 2.5 Flash for vision/scoring + GCS for image storage + Cloud SQL (or D1 if smaller scale) for image metadata + tag index + review state.

Image input: bulk upload from Dropbox (Ryan's current transit layer — we maintain that pattern) OR direct upload from Lightroom export OR webhook from camera-tethered shoot.

Scoring API call structure (per RedStar pattern but using Gemini for VISION not generation):

// Per image: single Gemini API call w/ structured-output JSON schema
{
  model: 'gemini-2.5-flash',  // vision-capable, not image-gen
  contents: [{
    parts: [
      { inline_data: { mime_type: 'image/jpeg', data: <base64> } },
      { text: SCORING_PROMPT }  // includes EF criteria + brand DNA context
    ]
  }],
  generationConfig: {
    response_mime_type: 'application/json',
    response_schema: SCORING_SCHEMA
  }
}

SCORING_PROMPT is the brand-DNA-aware prompt that knows:

Cost economics: $0.0001-0.0005 per image score (Flash, not Flash Image — cheaper). 2,500 images per shoot × 40 shoots/year = 100,000 calls × $0.0003 avg = **$30/year in scoring API cost**. Negligible.

Performance: Gemini Flash latency ~1-2 sec per call. 2,500 images can score in 40-80 minutes wall-clock (or faster with parallelization). The 4-days-of-selection bottleneck collapses to the human-review phase only.

Phase 1 deliverable (Day 30 post-sign)

Phase 2 (Day 60+)

Phase 3 (Y2+)

Demo for Thursday call

Walk through:

  1. Bulk-upload of a sample shoot (~50-100 images we pull from emersonfry.com public photography)
  2. Auto-tags applied in real-time (visible per-image)
  3. First-cut auto-score with the top candidates surfaced
  4. Shared review UI w/ approve/reject/flag actions
  5. Cross-product image discovery search

Concrete, touchable, working. Ryan sees the workflow he documented being addressed.

4. Tool #2: Photo Retouching + Print-Swap (Gemini Nano Banana — gemini-2.5-flash-image)

What it does

Two related capabilities running on the same Gemini 2.5 Flash Image API (the "Nano Banana" — Billy's term — i.e., the multimodal image generation/edit model):

(a) Brand-aware photo retouching.

(b) Print-swap pipeline. (The "Development Use — Print Mockups" pain Ryan explicitly called out — current results "mixed").

Designer-knobs philosophy (progressive disclosure)

Default user (Emerson / approving editor):

Power user (designer / retoucher):

Custom workflow (advanced):

Technical architecture

Stack: Same Next.js platform as the Selection tool. Same Gemini API endpoint but using gemini-2.5-flash-image-preview (the Nano Banana, image generation/edit model).

Retouching API call (per RedStar pattern):

{
  model: 'gemini-2.5-flash-image-preview',
  contents: [{
    parts: [
      { text: RETOUCH_PROMPT },  // brand-DNA-aware retouching instructions
      { inline_data: { mime_type: 'image/jpeg', data: <base64> } }  // source image
    ]
  }],
  generationConfig: {
    temperature: 0.4,  // lower temp for retouching (consistency over creativity)
    maxOutputTokens: 1290  // per image SynthID watermarking
  }
}

RETOUCH_PROMPT examples:

Print-swap API call uses the multimodal capability — two input images (source product image + reference print), prompt specifying the swap operation. Gemini 2.5 Flash Image supports this via the parts array with multiple inline_data entries.

Cost economics: $0.039 per generated image. For a shoot of 250 final selects × $0.039 = $10/shoot in retouching API cost. Plus print-swap on demand ($0.04 per variant). Even at heavy use (20 print variations per product × 200 products = 4,000 swaps/season) = ~$160/season. Negligible.

SynthID watermarking is built into Gemini 2.5 Flash Image — every generated image carries the watermark, which is the appropriate disclosure mechanism for AI-modified imagery.

Phase 1 deliverable (Day 30 post-sign)

Phase 2 (Day 60+)

Phase 3 (Y2+)

Demo for Thursday call

Walk through:

  1. Take a real EF product photo (Santiago 4 maxi or similar)
  2. Apply brand preset retouching → before/after visible
  3. Print-swap: same photo, swap from current print to a different EF print → side-by-side
  4. Show the designer-knob layer briefly ("here's what a power user can adjust")
  5. Note: SynthID watermark on output for AI-disclosure discipline

Concrete; Ryan sees the print-swap problem he explicitly raised solved in real-time.

5. How the two tools slot into EF's existing workflow

Workflow step (per Ryan's PDF) Today With Tapt tools
1. Shoot Photographer Unchanged
2. Delivery → Dropbox Photographer Unchanged (Dropbox stays the transit layer; we read from it)
3. Organization Manual folders w/ inconsistent naming Auto-organized by metadata + tags (folder structure preserved for back-compat)
4. Tagging (½-1 day per shoot day) Manual in Lightroom AUTO at delivery — Tapt Selection tool
5. First Cut (Lightroom) Manual selection AUTO score + human approval — Tapt Selection tool
6. Final Cut (Lightroom) Manual selection AUTO score + human approval — Tapt Selection tool
7. Ratings (per-user) Lightroom (not shared) Shared across team in Tapt review UI
8. Export DNGs → Dropbox Lightroom Same; Tapt writes selects to existing Dropbox folder structure
9. Post-Production (Photoshop) Manual retouching Tapt Retouching tool handles routine; Photoshop reserved for gold-grade hero shots
10. Folder structure Static, duplication issues Tapt database-backed cross-product indexing solves duplication; folder structure preserved for archive
11. Distribution (Shopify / NuOrder) Manual upload Tapt one-click publish to Shopify + NuOrder
Dev Use — Print Mockups Manual Photoshop ("results mixed") Tapt Print-Swap pipeline — production-grade reliable

Lightroom + Photoshop stay in the workflow for gold-grade work. Tapt tools handle the 80% of routine work that consumes the team's time. Dropbox remains as the asset archive. Net: the team's time shifts from selection/tagging/retouching to higher-value brand + merchandising work.

6. Google stack — APIs, deployment, key rotation

APIs we use:

Key rotation pattern (per Billy's directive):

Phase API key source When
1. Initial dev + prototyping Macy's Gemini API (Star Studio production-tested key, has rate limits + cost visibility) Now — 1-2 days
2. Pre-Ryan-demo build Billy's personal Gemini account Until Ryan signs
3. Post-sign EF live Ryan's Gemini account (EF's GCP project, EF's billing) Day 1 post-sign onward

Rotation mechanics: API key as environment variable in the deploy; swap the env var on each phase transition; no code change required. Faber implements once, the pattern works for all three phases.

Why this pattern is right:

7. Build plan — Faber's work, sequenced

Sprint 1 (now → Wed EOD pre-Thu reveal):

Goal: working demo of BOTH tools, real images, suitable for the Thursday call. Doesn't have to be production-grade; has to be live + touchable.

Pre-call checklist: both tools at /admin/selection + /admin/retouching are reachable, demo data is loaded, the flows complete in under 30 sec each.

Sprint 2 (post-Thu — Week 1-2 if Ryan signs):

Sprint 3+ (Day 30 → Day 90):

What Faber needs from Polaris

Polaris likely has direct experience with:

Specific Polaris questions in §9 below.

8. Restructure of agent work (post-this-proposal)

Agent Pre-Thu work Post-Thu work (if Ryan signs)
Mycelia (me) Spec finalization w/ Billy feedback. Deck integration (NEW slides showing the tools as Day-1 amplification, NOT replacement of brand story). Polaris-comm coordination. Day 1 onboarding + EF Brand Architecture audit application + ongoing curation.
Faber Sprint 1 build (Selection + Retouching tools w/ working demos). Smoke test. Sprint 2-3 (production grade, integration, designer-knob layer). Plus Remy coherence-check middleware per existing spec.
Lumen (1) Deck integration check — does the new tools-amplification framing land cleanly within the existing brand-architecture narrative? (2) Audit Macy's-side Polaris findings for relevant patterns. Pricing + positioning work for the tools as Day-1 capabilities (the "ops savings clear the engagement spend" math). Brand-deep-dive service productization.
Mercator Tier-0 deck audit still standing (Slide 18 cost numbers, 55% GM, attribution, Atelia naming). Plus pricing-frame check — does the tools-amplification change the pricing conversation structure? Engagement template productization (Brand-Architecture-Audit + Production-Tools-Suite as standalone client offerings). Wholesale-layer service line.
Praetor No change — NDA + likeness addendum + MSA skeleton all ready. Attorney-engagement brief kickoff when Billy says go.
Polaris (via Billy facilitation) Answer 5 questions in §9. Possibly share specific RedStar architecture diagrams or code snippets we can adapt. Available for cross-network consultation as build progresses.

Cadence: all agents at 270s constant-contact. Mycelia + Faber tightest loop during Sprint 1.

9. Polaris commune — questions for Polaris (via Billy)

Billy: when you have a moment to relay to Polaris, here are the specific questions where their RedStar/Macy's experience would short-cut Faber's build:

1. Gemini 2.5 Flash Image — print-swap reliability. The "Development Use — Print Mockups" workflow in EF's PDF says current results are "mixed." Has Polaris/RedStar found a reliable prompting pattern for "preserve everything except swap this layer/pattern" with Gemini 2.5 Flash Image? Any negative-prompt or instructional patterns that materially improve reliability? Any cases where the model fails consistently (model rotation, complex drape, transparent fabrics)?

2. Gemini Flash (vision) — structured-JSON-output reliability. For the Selection tool's auto-scoring, we're asking Gemini Flash to return structured JSON (criteria + scores + tags) per image. Has Polaris found Gemini Flash reliable at this scale, or do we need to validate + retry? What schema patterns work best?

3. Cost economics at production volume. EF would run ~100,000 image scores/year + ~5,000 retouching ops + ~4,000 print-swaps. Polaris's cost projections vs reality?

4. SynthID disclosure UX patterns. RedStar produces SynthID-watermarked output. What's the right way to disclose AI-modification to EF's downstream consumers (wholesale partners, customers if the image is published)? Visible badge? Metadata only? Per-image disclosure copy?

5. Multi-image input via inline_data parts — token cost. For print-swap (source image + reference print image both as inputs), what's the token cost vs single-image generation? Are there ways to reduce (low-resolution preprocessing, image compression) without quality loss?

Optional 6th: Any RedStar code patterns Polaris recommends we copy directly into Faber's EF platform (rather than rebuild from scratch)? Specific .js files in /Users/bpk_2025_laptop/Documents/DDG_ImageEditTool/RedStar/ that are the right reference implementations?

If Polaris can answer any subset, Faber's Sprint 1 build is materially faster + more reliable.

10. How this lands in the deck (additive amplification, not replacement)

The brand + marketing story stays as deck lead. We add three NEW slides as a coherent block, positioned BETWEEN current Slide 5 (Platform that thinks like your studio) and Slide 6 (Nine surfaces of your brand, already running). Sequence:

Net: 3 new slides between current 5 and 6. Total deck = 29 slides (was 26). Sequence preserves: brand-system as lead → operational tools as live-Day-1 amplification → broader platform tour → channel plan → media → cost.

The bridge line on Slide 5a: "You asked us about image selection, photo retouching, and dev-related print-swap. The agent that holds your brand at the level you've just seen ALSO handles those three — Day 1 of the engagement, not a future roadmap. Here's how each works."

That lands the tools-as-amplification framing without breaking the brand-narrative flow.

11. Pricing — does this change the structure?

No structural change. The pricing v0.8 architecture (bounded 24-month engagement, $10K setup, declining monthly, lift share, Y3 zero) holds.

One clarification to add to the talk-track:

Currently the pricing slides frame the $10K setup as covering "the platform you just walked through — software install, stack integration, brand DNA load, the first-round creative suite, the analytics feedback loop, onboarding, and a month of actual operation."

Add to that list: "+ the Selection tool live + the Retouching/Print-Swap tool live." Same dollar amount; the deliverable scope is now explicitly broader. The implicit value-per-dollar improves substantially because the operational-savings math (the ~$40-75K/year team time recovered) now clears the engagement spend on operations alone, with the brand-marketing value as upside.

Mercator picks up the talk-track refinement.

12. Open questions / asks for Billy

  1. Approve this proposal direction overall? (Tools as additive amplification, build now per Sprint 1 plan, RedStar substrate adaptation, Polaris commune sanctioned.) Yes/no/adjust.

  2. Polaris-comm logistics — do you relay the 5 questions in §9 to Polaris (you facilitate), OR do you want me to attempt a direct read of STAR.log + write something Polaris will see on their next session OR something else? My discipline default per CLAUDE.md is "you can read Star's network, but never write to it" — so direct two-way needs your facilitation.

  3. API-key handover — when do you want to switch from Macy's Gemini API to your personal account for the build? My recommendation: stay on Macy's API for Sprint 1 (today/Wed), switch to your personal account before Thursday demo (Wed PM) so the demo doesn't accidentally hit Macy's billing.

  4. Demo ambition for Thursday — both tools live with real EF images, OR live Selection + mocked Retouching with Phase-1-committed roadmap, OR live Retouching + mocked Selection? Faber's call on what's safely buildable; I lean "both live" if Faber says yes, "Retouching live + Selection mocked" otherwise (retouching is the higher-impact demo because of print-swap).

  5. Deck integration timing — approve the 3-new-slide insertion (Slide 5a / 5b / 5c) before Faber commits build effort, OR build first + integrate slides after? My lean: integrate slides now in parallel (low-cost; reversible).

— Mycelia, 2026-05-26 ~05:30 ET