The Content Engine

The post you saw was not ContentPilot. It was social-engine queue item #14, published 18 Aug at 21:52 by a Windows scheduled task. ContentPilot's prompt already asked for short lines and blank lines — so the rules were fine and nothing enforced them.

I read Mansi Pachpute's WhatsApp message (16 Aug) and the brain KB. Her read is correct and it is the sharpest input you have on this.

She is right about the diagnosis. Your content was proving her point: post #14 said "practical operating layer" and named no outcome anyone could check. That is feature language with the features removed.

The line the engine now writes from

That second line is in the spec as a topic filter and an angle, never as copy. A mission statement bolted onto the end of every post is exactly the AI tell your own rules ban. It shows up in which story gets told, not in a closing slogan.

Where I think your plan is wrong

• Posting was never the bottleneck — the offer page is. Content builds recognition; it does not close. There is no page a practice owner can land on that states what you do, for whom, and what it costs. Every post currently ends in a conversation you have to have manually.
• You were paying attention to LinkedIn while Facebook and Instagram sat unused with working tokens. That is free distribution you already own.
• AI-industry posts were in the queue. The Penn RAIL item is the clearest example. Your buyer is a practice owner who does not care which lab released which framework. The spec now forbids it: every post starts from a problem they already feel.
• Mansi's 25–28k is not the gap. Her diagnosis is the valuable part and she has already given it to you for free in that message. The strategy and calendar she quoted for are what this engine now produces on a schedule. Spend nothing here.

Signals in, post out, and a gate at the two points where a bad post could escape.

One set of rules, two systems. social-engine does not re-implement any of it — it shells to ContentPilot's checker through engine/format_gate.py, so the two can never drift apart.

Every row below was tested with a live API call in this session, not read off a config file.

Correction to the brain KB: 06_GTM.md lists Meta as NEEDS_SETUP. It is not — the tokens have been working the whole time.

What feeds the calendar, what makes the assets, and honestly which of these are running versus available.

The old plan is deleted — 67 unposted items removed, backup kept at post_queue.backup-2026-08-19.json. This replaces it. Six formats, no AI-industry stories, every row traced to a signal.

Stored at backend/content/calendar_2026-08-19.json with the full brief, asset pipeline and signal for every row.

So you can judge the output rather than the plumbing.

A denial hits your clearinghouse at 9am. Nobody touches it for 19 days.

Not because your biller is slow. Because nothing told her it was the one to work first.

Here is what a small billing team is holding in their head at any moment:

- which of last week's 40 denials are CO-45 write-offs and which are real
- which payer's timely filing window closes this month
- which claims are sitting on a modifier 25 problem that will deny again on resubmission
- which patient's eligibility was never checked and will bounce the whole encounter

A hospital system solves this with twelve people and a workqueue tool. A four-provider clinic solves it with memory and a spreadsheet, and the memory loses.

So we built the workqueue instead of the headcount. Eligibility runs 48 hours before the visit. Claim status comes back off the X12 277 in about two seconds, not a 40-minute hold. Denials get tagged by CARC on arrival and ranked by dollars at risk against the filing deadline.

The practices that run this way do not collect more per claim. They just stop losing the ones that age out.

Pull your last month of denials and count how many were worked after day 14. That number is your real leak.

#rcm #medicalbilling

Five ways a clean-looking claim still dies.

Most practices can name two of them.

- CO-45: contractual adjustment. Not a denial. Writing these off as denials makes your denial rate look worse than it is.
- CO-197: no prior authorization. Dead on arrival, and the auth cannot be obtained after the fact.
- CO-18: duplicate. Usually your own system resubmitting, not the payer being difficult.
- PR-204: not covered under the plan. This is a patient conversation you should have had at scheduling.
- CO-29: past timely filing. The only one that is purely a process failure. It was always payable.

Four of these five are visible before the claim goes out. The fifth is visible on day 1 of the filing window.

Which of the five is your most common? Most practices guess wrong until they sort by CARC.

You asked for agents with their own channel, a kanban board, and Qwen improving them continuously. Here is what exists versus what I would have to build, stated plainly so you are not told something is done when it is not.

The content engine is the right first tenant for that board: it now produces a scored artifact every day, which is exactly the kind of measurable output an improvement loop needs. Building the board before there was anything to measure would have been the wrong order.

• LinkedIn company page. Add Community Management API to app 86otv8t3qbya23, confirm you are page admin, re-consent for w_organization_social, then hand me the organization ID. This is the only part of your original ask that code cannot solve.
• Say go on the calendar and day 1 posts today. The queue is empty by design — nothing ships until you release it.
• The offer page. Not content. A page a practice owner can land on that says what you do, for whom, and what it costs. Every post above currently ends in a manual conversation.