CREATIVE WORKFLOW SYSTEM

BENJICapture the image. Keep the context. Preserve the lineage.

We built Benji because image generation got fast enough that creation stopped being the bottleneck. The harder problem became preserving what made each image useful: the prompt, references, conversation context, project, variants, lineage, and a durable path back to the original work.

CREATION ISN'T THE SAME AS RETRIEVAL
30-second summaryCapture AI-generated image runs from ChatGPT, preserve creative provenance, back them up durably, and make the library searchable and shareable without breaking the creator's flow.
Core stack
Chrome MV3JavaScriptGoogle Apps ScriptGoogle DriveIndexedDBPlaywrightVitest
01 / Problem

Creative output was becoming disposable.

When image generation happens at high volume, the file is only half the asset. Without the prompt, source chat, references, variants, project assignment, and lineage, useful work quickly turns into a folder of orphaned images.

We wanted a workflow where an image could move from ChatGPT generation → saved run → durable backup → shared gallery without losing the evidence needed to understand or revisit it later.
DESIGN CONSTRAINTSaving had to feel lighter than organizing manually. The system could not ask the creator to become an archivist just to preserve good work.
01Generate in ChatGPT
02Capture Run + Variants
03Attach prompt + context
04Persist originals + metadata
05Index shared gallery
06Search, favorite, revisit
Actual Benji shared-library captureREAL PRODUCT EVIDENCE
Actual Benji shared gallery interface
The gallery is image-first, but each card points back to durable Run identity and creative provenance.click to inspect
02 / What we designed

The product is the workflow around the images.

Benji is not an image generator. It is the continuity layer around one. The important decisions were about identity, provenance, storage, retrieval, diagnostics, and how to keep all of that out of the creator's way.

01 / DATA MODEL

Runs, variants, references

One generation event becomes a Run, each output receives stable Variant identity, references stay linked, and project assignment can change without destroying original lineage.

02 / CAPTURE

Context travels with the asset

The image, generating prompt, source-chat evidence, references, notes, and detectable provider metadata are captured as one recreation package.

03 / STORAGE

Drive is the vault, not the UI

Canonical files remain durable while logical organization stays in application metadata. Search indexes and caches are rebuildable.

04 / OBSERVABILITY

Failures cannot disappear

Saves carry traceable timing and outcomes so slow, partial, retried, or failed captures can be diagnosed without asking a creator to reproduce the problem manually.

NAME ORIGIN: The name is a nod to the teammate whose high-volume creative work inspired the first use case. The product itself was designed around the broader shared workflow.
03 / Engineering decisions

Four choices shaped the system.

These are the decisions that made Benji more than a download button and a folder.

01

Model a generation as a Run, not a file.

DECISION → preserve the event around the image

A Run can contain multiple Variants, references, a source chat, prompt context, notes, and lineage. The image remains useful because its creation context survives with it.

TRADEOFF: richer metadata and identity management in exchange for reproducibility and continuity.
02

Keep logical organization separate from physical storage.

DECISION → stable vault, movable metadata

Projects can change without physically moving canonical assets. Drive provides durable storage while the gallery owns the creator-facing organization model.

TRADEOFF: catalog/index complexity in exchange for stable files and flexible organization.
03

Make diagnostics a first-class feature.

DECISION → trace behavior without browser surveillance

Benji records structured save behavior, retries, partial captures, parser drift, and timing, while explicitly avoiding arbitrary keystrokes, unrelated browsing, cookies, credentials, or tokens.

TRADEOFF: more engineering around traces and issue states in exchange for debuggability without burdening creators.
04

Live-update the gallery without moving the user.

DECISION → revision polling + anchored re-render

The shared gallery checks a tiny health endpoint, refreshes only when the catalog changes, preserves route/search/focus/scroll, dedupes by Run ID, and pauses polling while hidden.

TRADEOFF: careful client-state handling in exchange for a gallery that can stay open all day without reload churn.
CHATGPT
creative source

Generated images, prompt, source conversation, and references.

CHROME EXTENSION
capture + local reliability

Parser, queue, local persistence, issue handling, sync, status dock, and diagnostics.

RUN MODEL
stable identities

Project, Chat, Run, Variant, Reference, and future promoted-asset identity.

GOOGLE PERSISTENCE
durable vault

Originals and canonical metadata persist outside the browser.

CATALOG
rebuildable index

Logical organization and optimized previews derive from canonical records.

SHARED GALLERY
image-first retrieval

Projects, Recent, Favorites, Unassigned, detail views, metadata editing, and live sync.

Actual Benji Run detail interface
Run detail keeps the visible asset attached to its project, metadata, variants, references, and creation record.
Actual Benji diagnostics health interface
Diagnostics were designed as product infrastructure, not an afterthought: enough operational evidence to debug capture and sync without recording unrelated browser behavior.
04 / Evidence

It was tested like a workflow, not a demo.

Run 04 focused on a deceptively hard interaction: new creative work should appear in the shared gallery automatically while somebody is already browsing it, without losing their place or causing duplicate content.

Run 04 / live gallery sync

Update in place without disturbing the viewer.

The implementation used a 45-second health poll, catalog revision checks, selective shard refresh, Run-ID dedupe, viewport anchoring, hidden-tab suspension, and recovery from background failures.

visible tab ↓ health revision check ↓ change detected ↓ refresh changed catalog state ↓ anchor viewport / preserve search + route ↓ +N NEW RUNS · NO RELOAD
NEW RUN TESTS10 / 10 passed
UNIT SUITE140 / 140 passed across 12 files
FULL E2E + PERF117 / 117 passed
BUILDproduction extension build clean
LIVE DEPLOYexisting Apps Script deployment updated in place to version @8 after target and drift verification
LIVE SMOKEnew Run appeared automatically on the next poll with no reload
VIEWPORTmid-grid anchor preserved at 0 px delta during live metadata refresh
ROLLBACKprevious deployment version @7 retained as explicit rollback point
117 / 117full e2e + perf checks
140 / 140unit tests
45 svisible-tab revision poll
0 pxlive refresh anchor drift in production smoke
05 / Scope discipline

What Benji is, and what it isn't.

The product stayed deliberately focused on preserving and retrieving creative work rather than becoming a general browser monitor or an AI governance layer.

Built because the workflow needed it

Owned surface

ChatGPT image-generation capture
Run / Variant / Reference identity model
Prompt, chat, and lineage preservation
Local queue + retry/recovery behavior
Google Drive durable persistence
Shared image-first gallery
Structured diagnostics and self-checks
Live catalog synchronization
Explicitly not the product

Out of scope

General browser surveillance
Arbitrary keystroke or screen-recording capture
Credential, cookie, or token collection
Brand policing inside V1
A replacement for durable file storage
A generic legacy DAM migration
Creator-facing cost accounting
What this project demonstrates

Creative AI needs memory around the artifact.

Benji is a workflow-engineering project disguised as an image library. The useful part is not the gallery alone. It is the chain that keeps an AI-generated asset connected to the context that made it valuable, while remaining durable, searchable, diagnosable, and lightweight enough to use every day.