Recommendation is not publication authority

The simplest automated publishing system is one button: find something interesting, write a post, publish it.

I did not want that architecture.

Once a recommendation can silently become publication authority, research quality, relationship work, factual review, scheduling, measurement, and learning all become harder to inspect. The goal was automation that becomes more useful without making approval harder to explain.

In 30 seconds

• Problem: a single “agent” can blur observation, relationship state, recommendation, approval, and action into one status.
• Decision: persist those states separately and make explicit human approval the only path to main-feed publication authority; keep engagement automation on a separate delegated boundary.
• Proof: the current Node.js/SQLite system keeps source snapshots, relationship profiles/events, conversation opportunities, editorial recommendations, drafts, approval, queue state, measurements, experiments, and learned rules as separate records.
• Current phase: publishing is now one lane inside a broader network-growth system, and the live path has been exercised without turning early outcomes into causal claims.

Recommendation is not a command

The system reads current signals from X, GitHub Trending, Hacker News, and tracked conversations and stores source observations before editorial work begins.

An AI Editorial Director can cluster those sources and propose stories. Code still owns source truth and numeric ordering around those recommendations, and the human can select, override, dismiss, or add evidence before writing starts.

That distinction matters because a recommendation is a claim about what might be worth doing. It is not permission to do it.

The writer does not own approval either

Selected work moves through an explicit writing-strategy decision before the writer produces structured output and deterministic gates. Growth Focus, Writing Approach, evidence IDs, and claim scope make the reasoning inspectable, but none of them turn a passing draft into approved content.

Main-feed authority appears only after explicit human review and approval.

recommendation != selection
selection      != approval
approval       != transport
measurement    != causality

I keep those inequalities in mind because automation tends to erase them when every step is represented by the same “status” field.

Publishing became one lane of a network system

The system no longer treats publishing as the whole growth loop. It now keeps raw audience observations separate from strategic relationship_profiles and append-only relationship_events, derives relationship stages from observed interactions, and uses Engage Next to surface useful active conversations before comparable cold opportunities.

Reach, Follow, Conversation, and Relationship potential are also separate signals. A huge source can be useful to watch but weak to engage with; a smaller technical thread can be a much better opportunity if I have something concrete to contribute and the relationship can compound.

That changed the daily job from “what should I post?” to something closer to “what is worth researching, which conversation is worth entering, what owned work would strengthen that conversation, and which action has actually earned authority?”

Source truth and workflow history still answer different questions. To review is unresolved work. Bookmarks is reference state. Handled comes from actual publication or engagement history. Starting a draft does not silently bookmark a source, and an observed relationship event does not become publication approval.

The result is more data, but less ambiguity.

Measurement needed the same restraint

After publication, the system can capture the first available 15-minute, 1-hour, 6-hour, and 24-hour observations. It can compare declared experimental variants and preserve follower or engagement context.

What it should not do is turn every association into a causal lesson.

The experiment layer therefore carries assignment and attribution confidence. Learned-strategy rules move through their own lifecycle: evidence can create a suggested rule, but the suggestion has zero effect until a human accepts it. Accepted learning can tune future targeting or writing guidance without overriding hard gates, expiry, explicit routing, or main-feed approval. A later reversal can retire the rule without deleting the history that produced it.

The live pilot changed what I trusted

The first repaired live run was more useful as a systems test than as a growth result.

It exposed an authority conflict between rule-based routing and editorial selection, so the product now preserves the current rule recommendation and requires an explicit Use anyway reason when a human overrides an Ignore. The writing score was also renamed to Writing quality / structure because a 50-point rubric is not predicted engagement, virality, or follower growth.

One selected Quote was published and independently observed live. Early fixed-window measurements were weak, and I kept them weak: zero visible engagement in the first mature window is an observation, not a reason to retrofit a success story. The same run also exposed intermittent identity-less/no-post GraphQL responses, which are now treated as reconciliation problems rather than safe automatic retries.

That is the kind of feedback I want the product to preserve: a real run can invalidate a workflow assumption without granting the system permission to invent a better outcome.

Delegated automation still needs a visible boundary

Main-feed publishing still uses X’s internal web GraphQL interface rather than the official API. The code discovers the live operation ID and fails closed if the authenticated session cannot be validated, but a private interface can change without notice and automated use can carry account risk.

There is now also a persistent autonomous-reply operator. It is off by default, requires an explicit persisted Start grant, and can continuously evaluate independently eligible opportunities in dry-run mode. Live autonomous sending has a deliberately narrower contract: recipient opt-in, a clear opt-out path, recorded X approval for the AI-reply use case, remaining operator budget/health eligibility, an atomic claim, and an official X API write transport. The current private GraphQL publisher does not satisfy that last condition, so Live autonomous Start remains blocked.

Required media also stays blocked because there is no real attachment/upload path yet. The configurable continuous_scan AI profile remains separately inactive because no semantic background consumer owns that role; the autonomous-reply daemon is a different runtime owner.

Those are product constraints, not README footnotes.

Approval should be structural

A confirmation dialog at the end of an automated pipeline is weak control. So is claiming human oversight when the delegation boundary is not represented in the data model.

The useful pattern is to decide where human judgment changes authority and where bounded automation is allowed:

1. The recommendation layer proposes evidence-bounded options.
2. Relationship intelligence surfaces conversations that may be worth entering.
3. A human chooses what main-feed work is worth pursuing.
4. Writing strategy and the writer produce a draft under deterministic gates.
5. A human approves the actual main-feed artifact.
6. Automation schedules and transports only approved main-feed work.
7. Engagement automation operates only inside its separately granted and gated authority.
8. Measurements may suggest future rules.
9. A human decides whether those rules become active.

That is more complicated than “generate and post.” It is also much easier to explain which part of the system was allowed to do what, and why.