Nexus

Proof case

Autonomous content infrastructure

A pipeline that researches, writes, gates, optimises, illustrates and publishes without a person in the loop — built, run and paid for by us, so that our first reference is one we can be fully candid about.

Pipeline stages
7
Articles published
43
Manual steps per publication
0
Servers
1

Architecture

Seven stages, one direction.

Each stage hands a finished artefact to the next and refuses to pass anything it cannot validate. A stage that fails stops its own work item, not the pipeline.

  1. Keyword selection

    Candidate topics are drawn from a research store, filtered against everything already published, and locked so two runs can never claim the same subject.

  2. Subject gate

    A guard rejects topics outside the site's declared subject boundary. Rejected items are quarantined with a reason rather than dropped, so the boundary itself can be reviewed.

  3. Drafting

    Generation runs against a provider pool with per-provider quota accounting. Exhaustion or rate limiting moves the work to the next provider instead of failing the run.

  4. Editorial checks

    Structure, length, heading hierarchy and internal consistency are validated before anything is considered publishable.

  5. On-page optimisation

    Titles, descriptions, slugs, headings and internal links are produced as part of the artefact rather than bolted on after publication.

  6. Media

    Illustration is generated, sized and uploaded to the media library, then attached to the post record.

  7. Publication and report

    The post is written to the live site, indexing signals are submitted, and the run reports what it published — and what it refused to.

Production history

What actually went wrong.

Three outages, each with a root cause worth publishing. This is the section most case studies leave out.

  • A silent stall from a casing mismatch

    Deduplication compared topics case-sensitively while the claim lock compared them case-insensitively. Every candidate looked new and every claim was rejected. The pipeline reported healthy runs and published nothing. Fixed by normalising both sides to one comparison.

  • Provider quota became the real ceiling

    With the stall cleared, output was immediately capped by free-tier daily limits and upstream rate limiting. The pipeline now accounts for quota per provider and degrades to the next one instead of retrying into a wall.

  • A process running last month's code

    The supervised process held a months-old snapshot of code and environment. On-disk fixes were never loaded, so corrections appeared to do nothing. Deployment now treats "the code on disk" and "the code that is running" as two different facts that must be reconciled explicitly.

  • A dry run that was not dry

    A shadow mode advertised as write-free still posted media to the production library, because the image path bypassed the guard. Guards are now asserted at the boundary that performs the write, not at the entry point that intends it.

Still open

Publishing is solved. Distribution is not.

The system reliably produces and publishes. What it has not yet produced is an audience: the archive is under-indexed, entry pages link poorly into the body of work, and search impressions have fallen rather than risen over the measurement window. We know this because the reporting is built to show it, and we publish it here for the same reason.

The engineering claim this case supports is narrow and specific: a multi-stage autonomous system can be built to run unattended on modest infrastructure, to fail loudly at the right boundary, and to keep an honest account of itself. That is the claim we are willing to make for client work as well — and the only one.

Have a system like this to build?

Describe what has to run without you, and what happens when it stops. You get a written assessment back: scope, price, and whether we are the right people for it.

hello@nexus.studio