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. Human approval remains the normal main-feed authority; a separately started live First-1,000 mission can receive a bounded Original/Quote/Thread approval grant with stored verification provenance.
• Proof: the current Node.js/SQLite system combines source snapshots, relationship profiles/events, growth-next opportunities, writing strategy, explicit approval/delegation state, verified Clearcote browser publication, measurements, experiments, and learned rules.
• Current phase: publishing is one lane inside a First-1,000 network-growth system whose routing, hooks, momentum assumptions, and outcome learning are treated as adaptive experiments rather than platform laws.

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.

In the normal main-feed path, authority appears only after explicit human review and approval. The separate live First-1,000 mission can receive a bounded grant to approve Original, Quote, and Thread items for that mission, with the grant and verification provenance persisted rather than inferred from the draft.

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.

First-1,000 mode made the assumptions inspectable

A small account has a cold-start problem: a mature relationship-heavy strategy can reject the exact fresh conversations needed to create relationship history in the first place.

The current bootstrap mode makes that tradeoff explicit. growth-next reads last-known-good X Latest and X Momentum state, joins opportunity scores and source shape, then asks the operator to inspect the exact live source in the authenticated browser before taking action. Freshness, momentum, conversation crowding, hook structure, and borrowed distribution remain empirical variables.

That distinction matters to me. “This threshold helped during a small-account experiment” is a useful local rule. “This is how the X algorithm works” would be an unsupported claim.

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 the active approval/delegation contract. 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. That older run also exposed ambiguous responses in the then-current GraphQL transport.

The current publisher has since moved to the authenticated Clearcote browser UI. It verifies the rendered result and resulting tweet identity before reconciling local publication state, and it does not blindly replay failed, partial, or unknown browser actions.

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

Delegated automation still needs a visible boundary

Main-feed publishing now uses a dedicated authenticated Clearcote browser profile. That keeps the current human-reviewed and First-1,000 mission paths grounded in the rendered X UI, but it does not turn browser automation into an official platform API.

There is 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. Clearcote browser publication 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 the normal main-feed path or explicitly starts a bounded live mission.
4. Writing strategy and the writer produce a draft under deterministic gates.
5. Normal work receives human approval; a live First-1,000 mission may exercise only its persisted Original/Quote/Thread grant.
6. Browser publication verifies the rendered remote result before local reconciliation.
7. Reply automation operates only inside its separate consent, policy, and transport contract.
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.