Let Hermes investigate or follow your brief. Review three ads, their images, and a concise UK research report. Approve the whole pack and prepare the client email.
Illustrative counts. DECTA is a research example, not a signed client. The pilot ends at email preparation.
BuxUp's intended paying client is a specialist payment provider serving the UK, typically a smaller or mid-sized payment institution, electronic money institution, or acquirer that accepts legitimate businesses with complex or higher-risk payment needs. Its campaigns reach suitable business customers for a supported service. The provider's acceptance criteria matter before choosing an audience or claim.
Use decta.com as the first research demonstration. Do not imply DECTA hired BuxUp, approved the materials, or appointed a reviewer. A domain-only campaign can let Hermes identify an offering and suitable business audience. Specific user instructions narrow that task. The live pipeline must ground factual claims in the provider's actual sources.
There is one user: the owner/admin/developer. The client reviews exported materials by email outside the app. There are no teammate views, role assignments, client logins or client-review links in the pilot.
The home screen shows domain workspaces, campaigns, status counts, and New campaign. Keep Needs review, Email draft ready, Awaiting client response, Client approved, Rejected, and active/partial/API-error work visible. Status counts and rows share the same domain/status filters.
An email export is a draft, not proof of sending. The owner may optionally record external sending or a client response manually. A recorded client approval leaves the exact campaign complete in the app; it does not launch an ad. Running campaigns, traffic, leads and ad-platform results are later-version features, not populated pilot KPIs.
One owner. Three platform drafts. One campaign decision.
| Campaign / domain | Scope / mode | Status | Next action |
|---|
Example counts describe saved work. Preparing or downloading an email never sends it.
Every canonical domain gets its own profile, files, facts, brand context, campaign history and memory. New domains start fresh; existing domains reuse relevant information. Do not merge unrelated domains into a brand group automatically.
The owner can add, replace or remove source material and inspect its status. PDF, images, and Word documents are pilot inputs. A removed source leaves active retrieval and invalidates dependent facts; a filename must not disappear while its extracted contents remain silently searchable. History remains visible without automatic expiration unless explicitly removed.
The pilot does not force the user through repeated clarification questions. A domain is enough to begin provider/audience investigation. Missing prices, rates, eligibility details or offers should lead to supported general wording and explicit report notes, not invented facts.
If the user supplies information that conflicts with a website, preserve the requested direction and flag the conflict in the final report with sources and uncertainty. Do not silently convert a user claim into verified evidence. Reports distinguish user-provided, website-derived, inferred, conflicting and stale facts.
Findings do not stop preparation or impose a legal-signoff dialog before the agent returns a draft. Real API failures and unavailable images remain honest partial/error states; the instruction to continue never means fabricating successful output.
New campaign asks whether the domain is new or existing. New domains require the domain; saved domains supply it. Offering, audience, instructions and supporting files are optional. UK, English and all three platforms are fixed pilot settings shown to the owner.
Optional strategic modes are Lead generation, Traffic, and Affiliate marketing. A blank selection is allowed. These guide the objective and creative approach; the pilot does not collect leads, measure traffic, calculate payments, or assume a commercial affiliate agreement.
Every ad links back to the provider domain. Landing pages, click destinations beyond that default, and lead-capture forms are later work. No product-imposed cap is placed on saved clients, campaign counts or preparation spending; real service limits still produce visible errors.
A dedicated creative node writes platform-specific copy and strong, distinct image prompts. It follows website style, avoids people's faces, and uses a retrievable official logo rather than inventing a brand mark. Each platform gets one copy treatment and one distinct image.
| Platform | Pilot output |
|---|---|
| Business-focused headline/body/CTA plus its own image | |
| Visual-led headline/caption/CTA plus its own image | |
| TikTok | Hook/on-screen wording/caption/CTA plus its own vertical still image; no generated video |
The previews below are editorial composition examples for a fictional provider. Real generation must return actual image assets through the verified image API; a text response or a failed image call is not an image.
A short hook and on-screen message. A still or storyboard is the first creative, not a finished video.
Hermes retains the campaign’s source-backed offer, then adapts the copy and image brief to the placement. All variants return to the same campaign review.
Illustrative draft · awaiting review
A clear image, caption, and call to action. Review any wording inside the image alongside the caption.
Hermes retains the campaign’s source-backed offer, then adapts the copy and image brief to the placement. All variants return to the same campaign review.
Illustrative draft · awaiting review
A specific business problem and a supported capability, presented with a professional visual.
Hermes retains the campaign’s source-backed offer, then adapts the copy and image brief to the placement. All variants return to the same campaign review.
Illustrative draft · awaiting reviewUse the existing gravityyy-proxyyy gateway, the requested main route gemini-3.8-flash-tiered, and requested Gemini image alias gemini-3.1-flash-lite. Confirm actual route availability, grounded search, document reading, extraction, and image bytes with authenticated capability tests. Requested aliases are not proof of upstream capabilities.
The backend owns credentials and proxy calls. The browser receives stored copy, media and report records. Separate adapters normalise reasoning, citations, document content, image output, errors and usage. A partial output keeps usable work and explains what failed; provider rate limits must be shown to the owner.
The UK review node examines the actual three-platform copy and visual content. It identifies potentially relevant areas of UK law/regulatory material, provider restrictions and platform policies, with authoritative links, applicability, checked dates, specific issues, wording choices and remaining uncertainty.
Explain how the draft attempts to address an issue without declaring guaranteed compliance. Unsupported claims and conflicting facts remain visible. No finding imposes an automatic question gate; the owner and client reviewers can inspect the evidence with the exact materials.
The client-facing summary accompanies the email, following the latest preference in Q5. It asks for review/approval rather than promising legal assurance or claiming that sending an email transfers all responsibility. The FCA overview is a starting reference, not a universal finding for every payment-service advertisement.
The finished pack contains the chosen angle, optional strategy mode, three platform copies/images, a concise UK report, sources/gaps, versions, and whole-campaign review actions. Inspect images, copy text, open findings, and download available assets. Partial-image failures keep the useful copy and research visible.
Redo LinkedIn / Instagram / TikTok changes that platform's copy/image only, then refreshes affected report/email dependencies. No chat or free-text creative revision is required. Reject approach preserves that version and offers Rethink campaign, which restarts the strategy using saved research. One internal approval covers the full exact campaign version.
After approval, prepare an email containing the three ads/images and a concise research attachment. Copy/edit the subject/body, download the package or draft email, or select Redraft email. This changes email wording only. Sending, reading replies and publication are outside the pilot. Any later client decision is manually recorded, then the work sits complete.
United Kingdom · English · LinkedIn / Instagram / TikTok
Website style guides production creatives; avoid faces and use an available official logo. The editorial images here use a fictional placeholder brand and demonstrate composition only.
Redo one platform with a button, or reject the approach and select Rethink campaign. A new creative version requires a new whole-campaign approval.
CTA: Explore the provider website
No provider evidence in this example substantiates this universal promise. The sample revised copy avoids that wording. A real report links the exact source, relevant UK area and applicability; it does not assert that this example has broken a named law.
Areas considered, authoritative links and dates, exact flagged copy/image content, reasons a rule may apply, wording choices that address an issue, and remaining uncertainty. Provider restrictions and platform policies remain distinguishable.
Findings do not create an automatic preparation gate. The owner/client can inspect them with the exact campaign. No legal assurance or automatic transfer of responsibility is claimed.
DECTA is a public research example, not a signed client. Prototype copy and editorial images are placeholders. No real offer, reviewed legal applicability, or DECTA approval is asserted.
DECTA public website ↗ · FCA starting reference ↗
Campaign-specific verification date: not performed in this preview.
Owner sends externally. Downloading or redrafting never sends a message. Recipient is a reserved demonstration placeholder.
The example .eml includes sample copy, three editorial SVG images, and a concise report. Production packaging also supplies ZIP and extracted files; mail-client compose behavior varies.
Example actions affect this tab only. No external account is contacted.
Hermes loads domain-scoped context, chooses an offering/angle or follows the brief, writes copy/image prompts, requests media, prepares the UK report, stores artifacts, and assembles the email preview. No routine clarification conversation is required. The backend tracks durable steps, versions and partial failures.
A selective redo reuses saved context and untouched platform artifacts. Email redrafting never triggers research or changes approved advertisements. Actual API errors have finite recovery and transparent stop/partial states rather than an endless loop.
Hermes improves supported skills, prompts, modes, settings, workflow configuration and versioned system behavior automatically, runs checks, applies passing updates, and records what changed and why. There is no approval or activation queue for those updates.
The owner can reach a separate Hermes dashboard from BuxUp and return afterward. It shows applied/checking/failed/rolled-back changes, exact versions/diffs, evidence, checks and recovery history. In-app activity is sufficient for the pilot; external alert/digest preferences are future questions. Self-improvement does not send an email or approve/publish an advertisement.
Already applied. Here is what changed, why, and how it is performing.
Production opens a separate Hermes activity screen with the same single-owner access. Return to BuxUp dashboard ↗
Hermes decides and updates automatically. Reading an update never activates it.
Inspect scope, evidence, checks, active versions, notification delivery, and rollback.
Updates shown as Applied are already active in this example. Open an update to inspect its record.
Domain memory stores only that provider's relevant facts, brand context, sources and campaign history. UK knowledge stores dated public research and applicability. Global skills hold general improvements without private client content.
On a new campaign, check relevant changes such as offers, discounts, terms and features while reusing stable context. Ongoing background monitoring is deliberately unanswered and parked with Q27. Saved records do not automatically expire; evidence can still become stale and require a fresh check.
The product frontend shows dashboard, domain workspaces, packs, redos and email handoff. A single-owner backend enforces access and domain scope, stores records, queues work and calls Hermes/proxy services. Persistent files/media/email packages live in object storage; business/version records live in a durable database.
Email packaging exports a draft with attachment/version metadata. There is no mail-send, lead-capture, ad-account, analytics or payment integration in the pilot. Technical capability and persistence checks are part of the implementation work.
For the same domain, start from its saved provider profile, brand style, relevant prior campaigns, and sourced facts. A new offering or specific instruction narrows the work. Refresh information that matters rather than repeating unchanged discovery.
A platform redo creates a new pack snapshot and invalidates the prior approval/email. A rejected approach stays in history. An email-only redraft preserves the exact approved campaign. No previous approval transfers to changed advertisements.
The first pilot proves domain-only generation, three platform treatments, image-prompt writing, UK research reporting, scoped reuse, targeted redo, campaign-wide approval and a draft-to-email handoff. DECTA remains an example; no actual client approval or publishing outcome is assumed.
Later-version questions are saved separately: Q24 campaign results, Q25 changes after approval/live ads, Q27 recurring refresh, Canada and other countries, languages, campaign chat/editing, publishing/sending, lead/traffic/affiliate outcomes, teammates/client access, and video/creative expansion. Those are deliberate exclusions from the first implementation draft.
Updated 3 November 2026 from the answered product questionnaire. This is a plan and interactive design preview; publishing it does not implement a live backend or send any client email.
Frontend first. Backend second. Version 6 incorporates the owner's answers to all 32 product questions. This first implementation draft is ready for build planning; the later-version questions are parked separately. Updated 3 November 2026.
Pilot contract: one owner/admin; UK; English; a separate workspace per domain; flexible domain-only intake; LinkedIn, Instagram, and TikTok; one copy and one distinct image per platform; a source-linked UK research report; campaign-wide internal approval; and a ready-to-send client-review email. The pilot ends at email preparation.
Use decta.com as a research demonstration, never as a confirmed client, partner, campaign approver, or endorsed advertisement. Demonstration assets and email recipients are labelled examples. The current HF page remains a guide and interactive prototype, not a deployed live campaign agent.
Lead generation, Traffic, and Affiliate marketing are optional strategy hints. They do not add lead collection, click tracking, billing, commission tracking, or publishing to this first build. Canada, other countries, multiple languages, campaign chat, teammates, and live-ad operations are later scope.
The answered questionnaire is preserved locally. BuxUp_Pilot_Decisions.md records how answers map to this draft; BuxUp_Later_Version_Questions.md preserves Q24, Q25, Q27 and groups future questions. There is no new blocking product questionnaire.
Single-owner screens, domain intake, three ads, targeted redo and client-email handoff.
PART 02 / THE ENGINEBackend specifications ↗Scoped jobs, copy/image prompts, UK report, email packaging, learning and automatic updates.
Use React and TypeScript for the production interface. Organise by dashboard, domains/clients, campaign intake, finished pack, platform regeneration, email handoff, and a separate Hermes activity screen. Shared components cover buttons, labelled forms, dialogs, status badges, source inspection, file upload, error/partial states, and theme controls. This is an implementation choice, not a claim that the production application already exists.
| Component group | Concrete responsibility |
|---|---|
| App shell | One authenticated owner context, navigation, Light / Dark / System, and a link to Hermes dashboard |
| Campaign dashboard | Domain filter, current campaign/version, UK/English context, useful status counts and next action |
| Campaign form | New/existing domain, optional offering/audience/instructions/files/mode, with fixed pilot market/platforms |
| Finished pack | Exactly three platform treatments, their individual images, UK report, evidence, issues, and history |
| Redo controls | Redo LinkedIn, Redo Instagram, Redo TikTok, and Rethink campaign after rejection |
| Email handoff | Editable/copyable subject and body, attachments, Redraft email, and download package |
| Hermes activity | Separate dashboard showing automatic changes, why, checks, versions, notifications, and recovery |
Separate saved server records from local view state. Cache records by domain/campaign/version; form contents, tabs, and dialogs remain local. Preserve unsaved input on failed requests. Keep secrets and source-document contents out of browser preference storage. The API owns campaign state; the UI never invents successful research, an image, a sent email, or client approval.
The landing screen is Dashboard. Navigation covers Dashboard, Domains/Clients, Campaign details, Email draft, and Open Hermes dashboard. The sole signed-in owner can manage all domain workspaces. There are no colleague permission variants, assigned reviewers, client accounts, private client-review links, or team invitation flows in the pilot.
| Proposed route | What the owner sees |
|---|---|
| /dashboard | All pilot campaigns, domain/status filters, New campaign |
| /clients and /clients/:id | One canonical-domain workspace, saved profile, sources, files, history |
| /campaigns/:id | Stored brief, run progress, current pack, versions, and next action |
| /campaigns/:id/versions/:version | Exact copy/image/report snapshot and decision history |
| /campaigns/:id/email | Email preview, subject/body, attachment manifest, redraft and downloads |
| /hermes | Separate Hermes dashboard, reachable from BuxUp and with a return link |
Use the established cream/green light palette and forest dark palette. Theme switching preserves page, selected domain, input, and campaign context. On desktop use a sidebar; on phones stack controls and place wide tables in contained scrollers. Validate 390, 768, and 1440 pixel layouts. A single-user design still protects source files and stored records behind the owner session; the separate Hermes screen uses the same owner access.
Show New campaign, domain filter, status filter, campaign table/cards, and counts for Needs review, Email draft ready, Awaiting client response, Client approved, and Rejected. Researching, partial/API error, and cancelled work remain visible in the list. These are working-pilot states, not fictional advertising-performance metrics.
Rows identify domain/client, campaign name or agent-selected offering, strategy mode if chosen, version, current status, last activity, and next action. One campaign includes all three platform variants. No Running, ad spend, leads, impressions, clicks, or booked-call KPI is populated in this pilot. Those metrics are explicitly deferred.
Generating or downloading an email does not mark it sent. If the owner later chooses Record sent externally, store that manual statement separately from the actual package-creation event. An optional Record client approval action stores the owner's reference/note against the exact campaign version, then leaves the campaign at Client approved — pilot complete. No publication follows.
Counters and rows must use the same filter scope and persisted state. Empty/loading/error states are distinct. Repeated clicks or a refreshed page must not duplicate a client, run, or email export. Keep historical rejected and superseded versions inspectable.
A new domain is the only required business input. Existing domain selection supplies it automatically. UK, English, and all three platforms are fixed pilot defaults shown to the user, not mandatory choices they must repeat. The New campaign dialog supports a new domain or an existing saved domain.
| Input | Pilot behavior |
|---|---|
| Domain | Required for new client; validate and normalise; reuse an existing matching domain |
| Client/display name | Optional; agent may derive it from research |
| Offering, audience, goal, instructions | Optional. If supplied, constrain the task to that direction rather than advertising unrelated offerings |
| Strategic mode | Optional: Lead generation, Traffic, Affiliate marketing; blank is valid |
| Supporting material | Optional PDFs, images, Word documents, or text context |
| Market/language | Fixed United Kingdom / English |
| Platforms | Fixed LinkedIn + Instagram + TikTok |
Domain-only input instructs Hermes to investigate, select a supported offering and suitable business audience, explain the chosen angle, then produce the full pack. The optional modes guide objective, CTA, and tone; the model must not invent the provider's agreement to pay per lead/visit or an affiliate contract. The destination defaults to the provider domain. No landing-page generation or lead-capture setup is required.
Missing commercial facts do not trigger a clarification loop. The agent continues with source-supported general wording, omits unsupported specifics when possible, and records assumptions/gaps in the final report. When explicit user information conflicts with a website, preserve the requested direction and show the conflict, both sources, and uncertainty clearly rather than silently treating it as verified.
Every distinct canonical domain gets its own workspace. Case, scheme, trailing slash, and a basic www alias normalisation must not create duplicates; do not silently merge unrelated domains, regional brands, or subdomains into a parent company. The single owner can browse all spaces, but agent retrieval remains restricted to the selected domain.
Show profile, offerings, files/sources, learned preferences, campaigns, and history. Start new domains from fresh client context. Existing-domain campaigns reuse relevant saved facts, prior creative history, and brand context, while refreshing campaign-relevant offers, discounts, feature changes, expired terms, or conflicts. Ongoing background monitoring is deferred with Q27.
Follow the provider website's visual style; avoid people's faces. Retrieve the provider's official logo if accessible, retain its source, and use the actual asset where appropriate. If no usable logo is available, record that gap rather than fabricating a logo or claiming to have used one. The guide's editorial illustrations are placeholders, not real Gemini outputs or DECTA-branded ads.
Support PDF, PNG/JPEG images, and Word DOC/DOCX through verified extraction/conversion paths. Show selected, uploaded, extracting, ready, and failed states. Unsupported/encrypted/unreadable material gets a visible explanation; other usable context may still produce a partial pack. No artificial product-wide file/count cap is selected; real service/format limitations must be disclosed. Records remain visible with no automatic expiry. Explicit removal still invalidates active source retrieval and dependent facts.
The completed view contains the chosen offering/angle, strategy hint, UK/English scope, source context, one LinkedIn copy/image, one Instagram copy/image, one TikTok copy/image, and a concise UK-law research report. TikTok is a still creative with appropriate hook/caption, not a generated video. Allow text copying, image inspection/download, and version history.
| Action | Effect |
|---|---|
| Redo LinkedIn / Instagram / TikTok | Rework only that platform's copy and image using previous output, saved brief/research, and an instruction to improve/try a different treatment |
| Reject approach | Preserve rejected version and offer Rethink campaign; do not automatically run another campaign |
| Rethink campaign | Restart strategy/creative planning from stored provider research, then regenerate all three variants and review |
| Approve whole campaign | Approve all three platform artifacts and the reviewed pack snapshot together; unlock a send-ready email draft |
| Redraft email | Reword only subject/body using the unchanged approved pack; leave ad copy/images and research alone |
There is no chat box, free-text revision conversation, or direct creative editor in the pilot. A redo button supplies the regeneration instruction; the owner does not have to write feedback. A new platform treatment creates a new complete campaign snapshot with the other two platform versions preserved. Recheck the changed material against report evidence, invalidate earlier campaign approval, and mark earlier email packages superseded.
Research findings are visible information for the owner/client review. They do not stop generation or create mandatory clarification/acceptance dialogs. Never label the pack guaranteed compliant. Genuine failed tool/model calls can produce Partial/API error; retain available copy and research and identify missing images explicitly.
After internal campaign approval, the next action is Prepare client email. An email preview can be assembled during pack completion, but it is only send-ready for the internally approved exact version. Use recipient placeholders until the owner provides details; no real recipient or established DECTA relationship is assumed.
| Email component | Contents |
|---|---|
| Subject/body | Provider/campaign reference, brief explanation, request for the client's review and approval, clear artifact/version reference |
| Campaign attachments | All three platform copies and distinct images, with platform labels |
| Research attachment | Concise client-facing UK report: applicable areas considered, direct sources, potential issues, wording choices, and remaining uncertainty |
| Owner controls | Copy/edit subject/body, Redraft email, inspect attachments, download complete package and a draft email file |
Use the latest preference in Q5 to include that research summary. Exclude internal model traces, credentials, private system prompts, and unrelated records. The wording asks the client to review, comment, and approve; it does not promise legal assurance or state that an email automatically transfers all responsibility. Missing images and unresolved findings stay disclosed in any partial/draft package.
Pilot handoff is manual: no connected mailbox, automatic send, reply reading, recipient outreach, or ad-account action. A MIME .eml draft with attachments plus a ZIP export is a workable first handoff; support owner-edited subject/body without requiring a new model call. A copied/downloaded draft is not Sent. Optionally record external sending/client response manually; the approved record then sits in the app.
Hermes improvements appear on a separate dashboard reachable from BuxUp. Applied updates show why, exact changes, scope, checks, version, time, and recovery; checking/failed/rolled-back states remain inspectable. No pre-approval or activation action is added. In-app activity is sufficient; external notification channels/digests are parked for later.
Define loading, researching, generating, checking report, partial output, API/rate-limit failure, email ready, rejection, and client-response states. If an image fails, show available copy/research plus the precise missing-image state and retry action. A rate limit must say what stopped and which output was preserved. Avoid fake placeholders presented as completed generation.
Controls need labels, visible keyboard focus, accessible dialogs/tabs, readable contrast, and feedback for async actions. Keep platform selection stable while opening findings. Show which campaign version is approved or superseded. A Redraft email action never silently changes an advertisement, and a creative redo cannot keep an approval of the previous pack.
No user-selected client/campaign count limits or campaign-preparation spending cap is imposed. Provider capacity is finite; truthful errors and finite recovery prevent runaway retries. Preparation-time and revision-count targets are measurements to collect in the pilot, not automatic quality guarantees.
Verify domain-only submission, optional-mode omission/selection, explicit-brief adherence, fixed UK/English/three-platform outputs, partial-image delivery, targeted redo, rejection/rethink, whole-campaign approval, attachment freshness, email-only redraft, and independent theme/read-mode navigation. Do not require a real DECTA approval to validate a demonstration workflow.
Use a React/TypeScript frontend, Python FastAPI API, PostgreSQL business records, object storage for documents/media/packages, and durable queued workers. A dedicated Hermes adapter coordinates model/tool tasks. The public static HF guide can host documentation or a static frontend build; the actual API, workers, database and file persistence require runtime services.
Use a single authenticated owner rather than implementing organisations, teammate roles, client accounts, and reviewer invitations for the pilot. Authorise record/file access for that owner on every API/export action. Pass an explicit domain/client context into every task, extraction, retrieval, and artifact write. Owner visibility across clients does not permit agent context to mix private client material.
Keep proxy credentials, queue/database access, and object-storage signing on the server. Separate identity/session bootstrap, clients, sources, campaigns, runs, artifacts/reports, approval/email, and Hermes updates into clear service modules. No mailbox or ad-publishing integration is a dependency of the first release.
| Record | Minimum fields |
|---|---|
| Owner | Account/session identity and access state |
| Client/domain | Canonical domain, display name, profile, products, brand assets and their sources |
| Source/file | Domain, source/version ID, URL/object reference, extraction status, checked date, deletion state |
| Fact/context | Value, source, product/audience applicability, confirmed/inferred/conflicting/stale status |
| Campaign | Domain, optional instructions/mode, chosen offer/angle, UK/English, current state/version |
| Campaign version | Brief snapshot, context/source manifest, strategy, artifact versions, report version, configuration snapshot |
| Artifact | Platform, copy, image prompt, image asset/status, version, requested/resolved model and source references |
| UK report | Exact artifacts, law/policy area, sources/check dates, applicability, issue, mitigation, uncertainty |
| Decision | Owner internal approval or manually recorded client outcome, timestamp, exact campaign/manifest hash |
| Email/package | Campaign/version, subject/body revision, recipient placeholder or owner entry, attachment hashes, draft/export state |
| Job/step | Action type, inputs/output hashes, attempts, state, error, run context, usage when available |
| Memory/update | Client/geographic/global scope, evidence, version, applied/failed/rollback state, update record |
Versions are immutable. A platform redo builds a new campaign manifest that references unchanged artifacts for the other platforms. Never rewrite an old approved version or its attachments in place. Retain records without automatic expiry while honoring explicit source deletion/invalidation. All timestamps are timezone-aware and displayed in the user's locale.
| Proposed operation | Pilot contract |
|---|---|
| GET /session | Single owner identity and current access; no team-role editor |
| POST /clients; GET /clients | Canonical-domain identity, duplicate reuse, searchable workspace list |
| POST /campaigns | New/existing domain plus optional brief/mode/files; inject UK/English/all three platforms |
| POST /campaigns/{id}/runs | Start full preparation with an idempotency key; domain-only is valid |
| GET /dashboard; GET /campaigns | Consistent scoped counts/status rows without performance metrics |
| GET /runs/{id} and progress stream | Stored step states, partial outputs, precise API/error status, resumable event IDs |
| GET /campaigns/{id}/versions/{v}/pack | Exact three-platform copy/image/report/source/history snapshot |
| POST /campaigns/{id}/redo/{platform} | Targeted creative regeneration from a base version; no discovery-loop restart |
| POST /campaigns/{id}/reject; POST /campaigns/{id}/rethink | Record rejected approach, then a separate owner-triggered strategy restart |
| POST /campaigns/{id}/approve | Whole-campaign decision with expected current version/manifest hash |
| POST /campaigns/{id}/email; POST /emails/{id}/redraft | Assemble/redraft email from exact pack; redraft changes only email wording |
| PATCH /emails/{id}; GET /emails/{id}/package | Save owner-edited subject/body, return draft .eml/ZIP with manifest; never send |
| POST /campaigns/{id}/external-status | Optional manual sent/client-response record; no launch or reply automation |
| POST /sources; DELETE /sources/{id} | Upload/extract, replace/version, or invalidate source and dependencies |
| GET /hermes/updates; POST /hermes/updates/{id}/rollback | Separate activity, exact automatic changes, evidence and recovery |
All paths are planned contracts. Validate type/scope and duplicate submissions. Reject stale approval/email writes with a version conflict. Persist meaningful events such as pack.ready, artifact.failed, campaign.approved, email.draft_ready, agent_update.applied, and agent_update.rolled_back; no event named email.sent is emitted by an export.
A platform redo reruns step 4 for that platform, its image request, affected UK review, and pack/email dependency assembly. It reuses the other two artifacts and provider evidence. Rethink restarts at the strategy stage using saved research. Redraft email invokes only the email wording step. Expired/missing required input evidence can be refreshed narrowly, without blindly repeating all discovery.
Persist each step and its outputs, checkpoint after success, and resume safely after restart. Retry transient errors only a finite number of times; expose provider rate limits or persistent failures and preserve partial work. Do not use an infinite 'nothing should stop the agent' loop. That instruction means avoiding discretionary question/approval gates during preparation, not pretending a failed external service succeeded.
Keep the owner's requested reasoning route gemini-3.8-flash-tiered and image alias gemini-3.1-flash-lite configurable through the existing gravityyy-proxyyy gateway. Verify actual route availability, grounded search citations, PDF/image reading, Word extraction, and image bytes before declaring a capability live. Image-input support alone does not establish image generation; retain explicit unavailable states and resolved route information.
The creative node returns structured per-platform copy, visual rationale, image prompt, brand/source references, and output requirements. Keep the image asset separate from the official logo asset; use a verified placement/compositing step where necessary so the model does not invent a brand mark. Inspect visible image text as part of the review.
The UK node distinguishes applicable legislation/regulator material, platform policies, and provider acceptance rules. Each finding references the exact artifact version, source URL, checked date, relevant area, reasoning, proposed wording choice, and uncertainty. A citation is not evidence of universal applicability, and the email must not present automated research as complete legal clearance. Findings do not block draft assembly or make decisions for the client.
Use a scoped Hermes profile/session or an external scoped memory adapter per domain/job as appropriate; do not run concurrent private-memory writers into one shared Hermes home. Store durable business state in the application database. Tool and model traces stay redacted and separate from the user-facing summary.
New domains start without another client's private context. Existing-domain campaigns retrieve relevant facts, brand preferences, prior offers and artifacts, and recorded outcomes. Refresh changes that matter to the current brief, including new features/discounts and stale terms. No periodic background refresh schedule is selected; preserve Q27 for later.
Client memory remains private to that domain. UK geographic memory stores dated public evidence and applicability. Global memory contains generalized workflow improvements stripped of private client content. Each memory has evidence, scope, validity/status, version, and dependencies. Removing a source invalidates its active chunks and dependent claims rather than merely hiding a filename.
There is no chat-based preference editor in the pilot. Existing instructions and website style guide generation; selecting a redo records dissatisfaction with that treatment, not a new universal legal or brand rule. Detailed one-time versus lasting correction controls belong to the later chat/editing iteration.
Keep the agreed lifecycle: detect an improvement, prepare a versioned change with reason/evidence, run automatic checks, apply passing changes automatically, record/notify afterward, monitor and restore a compatible prior version on regression. No pre-approval queue is introduced.
Update handlers cover supported skills/prompts, modes, configuration, memory policies and versioned application changes through actual granted runtime/deployment access. Store exact diff, scope, previous/new versions, checks, timestamps, outcome, notification state, and rollback history. A missing capability is reported accurately; it is not fabricated or converted into approval for a nonexistent permission.
Each campaign run captures the active workflow/configuration version set; already approved packs remain immutable. The separate Hermes dashboard presents applied/checking/failed/rolled-back records and recovery actions. In-app records satisfy pilot notification needs; external email digests and channels are postponed.
Campaign generation, whole-pack approval, email revision, manual external response, and Hermes update state are separate records. Use transactions and durable outgoing events; deduplicate run requests, stage writes, and package exports. A failure after two successful images must not discard those images or recreate them on a narrow retry.
Generate .eml with a proper multipart MIME structure and correctly labelled attachments, plus a ZIP containing three copy files, available images, the client-facing report, and a manifest of versions, hashes, gaps and approvals. Validate filename/media types, attachment consistency, recipients/placeholders, and package freshness. Redrafting an email changes its subject/body version, not the approved campaign content. Do not claim every mail client will open a saved .eml as an editable compose window; provide copyable text and extracted attachments as the reliable fallback.
There are no product-imposed limits on saved clients/campaigns or campaign spending in this pilot. Actual API rate limits, storage/file constraints, retry counts and request timeouts still exist and must be visible. Report errors with safe messages, failing stage, preserved output, retryability and a correlation ID. Bounded technical recovery avoids indefinite or duplicate work; it is not a purchased campaign-count quota.
Protect owner access and server secrets, validate uploads, block private/internal network destinations in web fetches, and treat retrieved content as evidence rather than tool instructions. Keep backups, resumable jobs and restoration procedures. No automatic data expiry is selected; explicit removal remains possible. Publication, mail sending, analytics ingestion, earnings tracking, and recurring monitoring are outside the pilot.
| Phase | Work | Done when |
|---|---|---|
| 0 | Verify proxy reasoning/search/extraction/image capabilities and record unavailable states | One real output of each required supported capability or an explicit diagnosed gap |
| 1 | Single-owner session, domain records, files, persistence, dashboard and flexible intake | Domain-only creates one job; optional strategy mode remains optional; fixed UK/English/three platforms |
| 2 | New/existing-domain research, brand/logo source capture and selective refresh | New domains start fresh; repeat campaigns reuse relevant facts and inspect changes |
| 3 | Strategy + dedicated copy/image-prompt node + three image requests | One copy and one distinct image per platform, or a transparent partial result |
| 4 | UK review/report and pack assembly | Source-linked areas/issues/wording rationale visible; findings do not force a clarification gate |
| 5 | Targeted platform redo, reject/rethink, versions, campaign-wide approval | Rechecks invalidate stale approvals/emails while preserving other platform artifacts |
| 6 | Email preview, approved handoff, redraft, copy/edit/export, optional manual response | Exact pack attached; .eml/ZIP available; no send or publish occurs |
| 7 | Client/UK/global learning and separate Hermes update dashboard | Automatic changes apply and report without approval; recovery is inspectable |
| 8 | End-to-end DECTA research demonstration and recovery checks | Demonstration labels remain clear; evidence and outputs match the tested workflow |
Build frontend against typed contract fixtures, then connect services and workers. Do not represent editorial preview images or simulated tests as model outputs. Existing public guide modes, themes, and chapter links must continue to work when its specification is updated.
| Scenario | Expected behavior |
|---|---|
| New decta.com domain only | Demonstration-labelled UK/English brief chosen by agent; all three platforms prepared; no assumed DECTA relationship |
| Domain with a specific offering and mode | Instructions constrain strategy; optional mode influences objective without inventing a commercial agreement |
| Existing domain | Reuse relevant facts/history; investigate only needed changes rather than full repeated discovery |
| Normal completion | Three individual copies/images plus a concise UK report and email preview |
| Explicit information conflicts with a website | Continue; preserve direction and flag the exact conflict with evidence/uncertainty |
| UK report has unresolved issues | Findings remain visible; draft/email preparation continues; no compliance guarantee |
| One image fails or the API is rate limited | Preserve copy/research/successful images, explain failure, provide partial status and a retry path |
| Redo Instagram | Revise Instagram copy/image only, recheck report dependencies, new campaign snapshot; other two preserved |
| Reject + Rethink | Rejected record kept; strategy restarts from stored research after the separate user action |
| Internal approval | One decision covers the exact whole campaign and unlocks a send-ready email |
| Redraft/edit email | Subject/body updated; approved ad copy/images untouched; attachment manifest still exact |
| Export email | Draft .eml/ZIP with current files/report; no sent status, delivery claim, mail contact, or publication |
| Record client approval manually | Exact version recorded and left complete; no launch, Running metric, or further automatic pipeline |
| Hermes improvement | Separate activity screen, automatic checks/application, after-update record and recovery without approval |
| Later scope | No Canada, extra language, chat, client login, publishing, analytics, or recurring-monitoring dependency |
The owner's examples suggest reduced preparation time and fewer revision cycles as pilot success measures. Actual timing, research quality, image success, context reuse and user acceptance are measured after capability checks; no signed DECTA outcome or production performance is implied.
The first draft is sufficiently specified to start implementation planning. Live model capability, extraction quality and deployment persistence are engineering verification tasks. The email handoff interpretation is deliberately concrete: owner sends externally, concise report included, optional manual client-response record.
Deferred questions are grouped in BuxUp_Later_Version_Questions.md: explicitly preserved Q24 results, Q25 post-approval/live changes, Q27 recurring refresh; Canada/other countries; multiple languages; campaign chat/editing; sending/publishing; lead/traffic/affiliate outcomes; teammates/client access; later creative options.
Updated 3 November 2026. This is the agreed-scope implementation draft and design preview; the live agent backend is not implemented by publishing this document.
Animated flowcharts and recorded pilot screens. Subtitles included; no sound needed.
BuxUp prepares the evidence, the ads and the review pack. A human makes the decision.
Pause anytime. Drag the video timeline, use ±10 seconds, or jump to a chapter. Fullscreen is available in the player.
Recorded interface: isolated DECTA public demo. Your live client workspace is unchanged.
A domain starts the work. Files and a brief help narrow the offering.
The agent creates platform copy and images, then researches UK issues in the actual material.
The owner reviews the pack, approves it for handoff and sends the email externally.
Research supports your judgment. Inspect source relevance, applicability and unresolved questions. Client review is external; changes produce a new version for approval.
The pilot prepares drafts. It does not automatically send email, publish ads or provide legal clearance.