Content Engine: Direction & Decisions

Date: 2026-06-19 · Owner: Rachel (build) + Roman (brand/source) · Status: aligning after Roman's clean-repo proposal

This document exists because the machine got built before the message got pinned down. It states what this engine is for, who it talks to, what's decided, where it's still fuzzy, and the path forward, so we stop building in the dark.

1. North star: what this engine is for

Build trust and an audience among operators and builders, by showing the honest reality of building AI-powered products, so that when those people want something built, RomanLogic is the obvious name.

It is audience-and-trust first, inbound second. It is not a direct-response lead machine and it is not a place to be clever. The conversion is slow: people watch you ship honestly for weeks, then they reach out. The honesty is the strategy, not a tone choice.

Critical separation (this is half the confusion): the website pipeline in this workspace targets US construction trades with cold demo sites. This content engine targets operators/builders into AI: a completely different audience, different motion, different channels. They share a codebase and a person (Rachel), nothing else. When in doubt: trades = pipeline/cold outreach; builders-into-AI = content engine.

2. The system at a glance

Three separate motions. Only the first is "buildlog."

Source architecture (Roman's proposal, agreed in principle):

construction-website-pipeline ──┐
                                ├─► romanlogic-content-source ──► buildlog ──► FB + IG drafts
RomanMk2 ───────────────────────┘   (clean, sanitised,           (mines ONLY
                                     PII-free middle repo)         the clean repo)

The middle repo is a published-interface / blast-radius firewall: buildlog structurally cannot see client names, financials, or lead PII, because it only ever reads already-sanitised entries. Confidentiality runs in three gates: (1) extract-only, never dump-and-scrub; (2) automated check: client-name denylist + secret scan + an AI pass for fuzzy cases; (3) Rachel's human review gate at the end, draft-only.

3. Who it's for

Audience: operators and builders, people who run businesses or build products and are into AI and shipping things. Technically literate or technically curious. Tired of hype.

Explicitly NOT: trades/contractors (that's the pipeline's audience), and not "AI gurus" or people chasing a follower-count dopamine hit.

What they feel before they follow: "Finally, someone showing what this actually looks like, including the parts that break, instead of selling me a course."

4. The message and the brand image

The image: the honest builder who actually ships. Shows real work, including what breaks. Strips the AI noise. No guru hype, no "10x your life," no fake overnight wins.

The differentiator is honesty. Everyone in this space is performing success; the whole edge is being the person who shows the messy middle and the failures (with Roman's sign-off on anything that's a genuine bad result). If a post could have come from any AI-hype account, it's wrong.

Voice: RomanLogic "we." First-person-plural, plain, specific, a little dry. No emoji-spam, no hooks that overpromise.

5. Content pillars (the four post types)

These are the recurring formats. They map to a series library buildlog already supports (docs/buildlog/series.yaml); see §7, it currently needs re-pointing.

Failure gate: anything that's a failure or a bad result must clear Roman before it posts. "Permission + proof" is the pillar most likely to brush against this, and also the highest-trust one, so it gets the tightest gate. Mechanically this is a hard HOLD on the review board, never an auto-queue.

6. Decisions locked

• ✅ Clean-repo middle layer (romanlogic-content-source): agreed.
• ✅ Channel split: buildlog = FB + IG; content-engine = LinkedIn + Roman's YouTube.
• ✅ HumAIn academy exits buildlog; Rachel runs it separately.
• ✅ Draft-only, always, behind Rachel's review gate. Nothing auto-posts.
• ✅ Every post has an image; use Roman's brand-locked, PII-safe generator (he wires it in).
• ✅ Cadence target: 1 post/day on Instagram and Facebook.
• ✅ Deploy key on the new clean repo (not construction-website-pipeline).
• ✅ Subdomain buildlog.romanlogic.com held; run on Rachel's domain until proven.

7. Where to tighten up (suggestions)

1. The series library still reflects the dead two-brand model. series.yaml is entirely brand: humain (cold-calls-in-the-wild, work timelapses, etc.). Under the new split those are Rachel's separate motion. Action: rebuild series.yaml around the four RomanLogic FB/IG pillars; move the HumAIn entries out to wherever Rachel's own motion lives.

1. Settle push-vs-pull on extraction (the one open architecture question). Does each side run its own extractor into the clean repo (recommended: no cross-workspace read access), or does Roman's content-engine reach into Rachel's repo too? This decides what Rachel builds vs what Roman wires. Owner: Roman + Rachel, before any source-layer rebuild.

1. Lock the clean-entry schema as a contract: date, title, body, tags, and a safetopost_unattended flag. It's basically buildlog's existing RawEvent shape; promoting it to the repo boundary lets content-engine and buildlog evolve independently.

1. Pin the conversion path. We've said "audience first, inbound second", but what's the actual call-to-action when someone is ready? A link? A DM? A waitlist? Without this, great content has nowhere to land. Decide the one CTA the content quietly points to.

1. Roman's voice samples are still outstanding. Generation quality on the RomanLogic "we" voice depends on having real samples to ground against (the buildlog content-quality work showed thin input = weak drafts). Action: Roman provides 3–5 sample posts in his voice.

1. Is 2 posts/day/forever realistic on draft-only review? That's 14 drafts/week for Rachel to review. Suggest starting at 3–4 posts/week per channel, proving quality and the review rhythm, then ramping to daily once it's earning its keep. Tie the ramp to the "until it's proven" gate Roman already set on the subdomain.

8. How to move forward

Sequenced, smallest-real-step first:

1. Roman + Rachel: settle push-vs-pull extraction (§7.2) and the CTA (§7.4). Blocks the source-layer rebuild.
2. Roman: stand up romanlogic-content-source, set its deploy key, drop 3–5 voice samples (§7.5).
3. Rachel: rebuild series.yaml around the four RomanLogic pillars; retire the HumAIn entries (§7.1). No dependency, can start now.
4. Rachel: spec + plan the source-layer swap: buildlog's four readers become one clean-repo reader against the agreed schema (§7.3). Waits on step 1–2.
5. Roman: wire in the brand-locked image generator.
6. Soft launch at 3–4 posts/week/channel, draft-only, review the rhythm for ~2 weeks, then decide on the daily ramp.

When the push-vs-pull question and the repo exist, the next artifact is a proper design spec for the source-layer swap (brainstorm → spec → plan). This document is the strategy layer above that.