AlwaysLoud — AI Content Marketing Platform for SaaS

AI writers are good at the most dangerous sentence a marketing post can contain: a plausible claim about the customer's own product that the customer never made. "Storafleet supports over 50 providers" breaks no rule about style or numbers. The only test is whether they ever said it, so we built that check in code, with one model call inside.

Find, narrow, judge, decide

1. Find (code). The post is split into sentences, headings dropped, and a sentence is flagged only if it names the customer, speaks as them ("we", "our") or compares them with someone else. A sentence about how a technology works is not their liability.
2. Narrow (code). Each flagged sentence gets up to six candidates: the claims Discovery read off the customer's pages that share the most distinctive words with it, plus everything the customer told us directly. Discovery had read 1,475 sentences off Storafleet's pages, far too many to show a model at once.
3. Judge (one model call per post). For each sentence the model answers two questions: does it claim anything that could be wrong, and if so, which one candidate supports it.
4. Decide (code). A citation the model was not shown for that sentence is dropped. A sentence the model skipped counts as unsupported. A judge that cannot run marks the post unchecked, never passed.

What the first real run taught us

On a real Storafleet post, the first version held 11 sentences, and most were the writer declining to claim things ("we are not claiming that"). We split the judge's question in two. On the same post the gate then held none of the 15 risky sentences, cited evidence for two, and still caught both planted inventions: an ISO 27001 certification and a 99.99% uptime SLA. A third plant, "over fifty storage providers", passed correctly, because Storafleet says "50+" on four of its own pages.

A held post has no "publish anyway" button. The way out is "that's true, here's the proof", which saves a proof point that later posts can use too.

AlwaysLoud never logs into a customer's CMS. The customer drops a small receiver kit into their own backend, and AlwaysLoud sends each post to it as signed JSON with a publish time. The app stores the post, copies its images into its own storage and publishes it itself when the time comes.

One contract file for both sides

The contract is one plain CommonJS file with no dependencies, shared by our sender and every receiver. It holds the limits, error codes, HTML allowlist and signing scheme, and a server test fails if either side re-declares any of them.

Signing the raw bytes

Each request is signed with HMAC-SHA256 over the method, the path, a timestamp, a nonce and a SHA-256 hash of the exact request body. The kit mounts before the app's JSON parser; if the parser has already run, it answers KIT_MISCONFIGURED rather than verify re-serialised JSON. Timestamps more than five minutes out are refused, and a nonce is stored only after the signature checks out, so unsigned traffic cannot fill the nonce table. During a key rotation, two keys are accepted.

Images judged by their bytes

Images are downloaded only from allowed origins, with no redirects, a 15-second timeout and a 10 MB limit. The type comes from the file's first bytes (PNG, JPEG, WebP, GIF or AVIF), never from the Content-Type header, and SVG is refused because it can carry script.

Safe with several app instances

The kit's publisher runs every minute in every instance of the app. Publishing is a conditional update on the post's status, so two instances that tick at the same moment publish a post once. That case has its own test among the kit's 29.

For apps not on Node.js

A generated guide covers any language, and conformance.mjs, a single file for Node 18+ with nothing to install, sends real signed requests and prints PASS or FAIL with the fix for each rule. One check sends oddly spaced JSON, to catch receivers that verify parsed JSON instead of the raw body.

A feature video starts as a storyboard: a short brief (who is watching, what they want done, what they see at the end) and a strip of shots, each a real screen of the customer's app with one sentence of narration. Nothing renders until a person approves it, and approval waits while a story issue is open.

Timing comes from the voice

Narration is generated first. Each shot holds for its sentence plus the chosen pace, never less than the sentence plus one second, so no voice is cut off. The same timings drive the recording, the edit and the captions.

Narration on our own server

The default narrator is Kokoro, an open-weight 82-million-parameter speech model run on CPU through ONNX Runtime in a Python sidecar, with no per-sentence fee. Its ONNX build returns no word timings, so the sidecar estimates each word's share of the audio from its phonemes, accurate to about a tenth of a second on product sentences.

The render

Playwright records the app, and ffmpeg cuts each shot to H.264 once and reuses it in later renders. Shots are joined with the transitions the studio previews; captions are burned in with one libass pass. When licensed tracks are on file (none ship with the server), the music bed sits at a fixed level, is ducked under the voice by a sidechain compressor, and the mix is normalised once to −16 LUFS. Each render writes a master, a clip of up to 20 seconds, a poster and VTT and SRT captions, in 16:9, 9:16 or 1:1.

What real renders found

The first real Hindi and Tamil renders, in October 2026, failed: the server's ffmpeg had no libass or libfreetype, and the test suite used a fake renderer. We moved to a full static build; the render now checks what its ffmpeg can draw and reports what it skipped rather than failing. The same pass replaced a notched caption band in Devanagari with one box behind the whole line. After the fixes, a 42-second English master rendered in 50 seconds.

To film real screens, AlwaysLoud has to find them inside an app it has never seen, signed in as the customer, without changing anything. We modelled access on app-store review: the customer gives us a demo account with made-up data and no two-factor prompt. If the login page shows a captcha or asks for a code, the run stops and says so. It never tries to get past either.

The walk

Playwright opens a 1440×900 browser, signs in (the only form it ever submits) and walks the app breadth-first: up to 60 screens, four levels deep, 12 clicks and 45 seconds per screen. On each screen it records the title, the headings, every control by its accessible name and a screenshot. Links are always followed, because opening a page is reading. Buttons, tabs and menu items are followed only when the fence allows them.

The fence

The fence is a deny-list matched against accessible names: words for deleting, paying, reaching other people, changing access and committing anything (save, submit, import, export). It is cautious on purpose, so "Remove filter" is refused too. A false positive costs a screen; a false negative costs someone's data. Any button inside a form, or of type submit, is refused whatever it is called.

A vision model looks at each screenshot and suggests which controls are sections and which are worth opening. It can only reorder and prune. Advice to press a denied control changes nothing, and a test plants exactly that advice to prove it.

The first real run

On Storafleet's app, the first advised walk covered 19 screens and mapped 15 of 17 workspace sections, refusing 29 clicks along the way. It also pressed three buttons that start work, "Scan for duplicates", "Rescan all buckets" and "Test connection", because none was a deny word or sat inside a form. Nothing was damaged (a scan ran in the demo account), and the deny-list gained a "starts work" group: scan, run, sync, retry, connect and others.