Ugrás a tartalomhoz
← Back to the journal

Content Studio inside out — what we learned about making a publisher pipeline reliable

After six months we explain how Content Studio works inside: target, generator, eval as a gate, and persona ingestion as the hardest piece.

Content Studio inside out

Nortinia Content Studio is not a CMS. It is a pipeline: in goes a target (a concrete audience + brand voice + topic focus), out comes a publishable article. Six months after stabilising it, we want to write down what we got wrong first, and what we now leave alone.

The four stages

  1. target — a NestJS service-backed entity stored in Postgres under FORCE RLS. A target carries 30+ fields: persona, tone, banned phrases, mandatory CTAs, keywords, cadence. The target is the knowledge. Everything else is one read away from it.
  2. generator — a BullMQ job that, given a target, calls the right model via Nortinia Engine. One generator produces one article per run. We do not retry mid-generation: if it errors, we drop the partial output and re-run the whole job with clean input.
  3. eval — a strict gate, not a hint. Six dimensions: topical relevance, tone match, factuality, banned terms, length floor, CTA presence. The threshold is tenant-tunable but defaults to 0.78 across the board. If it fails, back to the generator — three iterations max.
  4. publish — a POST to the receiving storefront's /api/blog/publish route. Idempotent (by articleId), bearer-token auth, payload is one CmsArticle JSON.

Why the eval is a gate, not a hint

For the first six weeks we ran eval as advisory only. Editors saw the scores, the generator always published. Six weeks in, 312 articles were live and 47 of them had a tone that matched no brand on Earth. One angry customer call later we decided: from now on, eval is a gate. Fail it, no publish. Period.

Articles dropped after three iterations land in the manual review queue 19% of the time. The other 81% are deleted. That hurts, but it is cheaper than retroactively pulling them down.

Approval mode: auto vs. manual

Every tenant picks: auto-publish on eval pass, or queue for human review. Of our 14 design partners:

  • 9 tenants auto — 3-5 articles a week, no human in the loop, everybody happy
  • 5 tenants manual — regulated industries (healthcare, financial advisory) where compliance overrides everything

The lesson: there is no single right default. Our SaaS pattern now is: new tenants start in manual mode, and after 20 articles passing eval we offer them auto.

The hardest part: persona ingestion

When a new target lands, somebody has to describe the audience. We assumed this was a form-fill task. Then we realised 70% of tenants cannot articulate who they write for. "SMBs" is not a persona. "Decision-makers aged 35-55" is not a persona either.

What we now do: the tenant uploads 3-5 of their existing materials (article, brochure, LinkedIn post). The engine extracts tone markers, recurring themes, and returns a suggested persona. The tenant edits it. 78% of suggestions ship unchanged. That single UX call was the most important thing we did in the Studio's life.

What we did not build (and why)

  • Real-time co-editing — three tenants asked for it. None would have used it daily. Did not build.
  • In-house image generator inside articles — Nortinia Engine's /illustrate endpoint already handles that, we do not duplicate.
  • A/B tests on published articles — interesting, but too early. 14 tenants, ~40 articles a week: not enough volume for significant tests.

Numbers after six months

  • 2,847 articles published
  • 67% first-iteration eval pass rate
  • 12-minute average end-to-end pipeline time (target read → publish HTTP 200)
  • 0.31 USD average model cost per article (mixed GPT-5 usage)

The pipeline is more stable today than we dared hope six months ago. Next phase: deeper multilingual support. We are HU/EN now; DE and SK ship next quarter.

Let's talk about your project

Tell us what you are building — we will figure out how to help.