Calamus WeavR

The pipeline

What happens to one post.

Twenty-five statuses and thirty-three legal transitions, enforced by a database trigger, not by convention. An engine cannot force a status, so nothing moves off the path below.

1. 01

   Planned

   Trend signals and prior visual research feed a plan. A person approves the plan itself before a single brief is written.

2. 02

   Briefed

   The brief pins a brand snapshot, prompt versions and seed, so any output can be reproduced later from the same inputs.

3. 03

   Generated

   Generation is conditioned on the catalogue photograph. A product-visible brief without a base photo is rejected by the schema, not by a reviewer.

4. 04

   Checked

   Automated checks score the weave against a rubric and measure it structurally against the real product before a person sees it. Below the floor it stops, and a weave failure never auto-retries: retrying spends money reproducing the same mistake.

5. 05

   Approved

   The deliberate stop. A person decides in Telegram or Notion and the first decision wins; the other surface reconciles. No decision six hours before the slot and the piece expires into a digest.

6. 06

   Published and verified

   Scheduled, posted, then checked again forty-five minutes later with the permalink stored. Anything that needs pulling goes through a correction path, not a delete.

Five layers, seventeen engines.

Engines are stateless, and every one reads a pinned brand snapshot instead of the latest commit, so an output is reproducible from its inputs months later.

• Grounding

  Photography is processed once into the references every later stage is measured against. Alongside it, a library of visual research that must clear a threshold before it can influence a plan.

• Orchestration

  Where a plan becomes briefs, briefs become pieces, and pieces become the variants and copy each surface needs. Every stage reads the same pinned snapshot, so two runs a month apart are comparable.

• Quality and approval

  Automated checks score a piece against the real product before a person ever sees it. Approval then runs on two surfaces at once — a fast lane and an audit lane — over one shared decision, and the first decision wins.

• Publishing and integrity

  Scheduling, verification that what went out is what was approved, and a path that watches the response afterwards. Correction and takedown exist because published is not the same as finished.

• Learning

  Specified and deliberately not built. They read metrics that do not exist until the system has published.

Powered by

No single vendor holds the pipeline.

Orchestration, reasoning and record-keeping are deliberately separate. Any one of them can be swapped without rewriting the others.

• n8nOrchestration

  Runs the schedules and the hand-offs between stages. When a piece stalls, the order of work is something you can open and read.

• ClaudeReasoning and copy

  Reads the research, drafts the captions and the long-form, and scores a draft against the brand’s rubric before a person sees it.

• SupabaseSystem of record

  Holds every piece and every decision. The rules about what may follow what live in the database itself, so no service can skip a step.

• GCPCompute and storage

  Each stage runs as its own isolated job. Generated assets and backups sit in versioned storage, so an old run can still be reproduced.

• TelegramApproval, fast lane

  A preview and two buttons. Most approvals happen here, because the decision takes seconds on a phone.

• NotionApproval, audit lane

  The same decisions with reason codes and a calendar attached. Both lanes write to one shared decision, and the first one wins.

• ShopifyBlog publishing

  Long-form publishes into the same storefront the products sell from.