Build an AI editorial operating system with ChatGPT, Claude and GitHub

ChatGPT helps me think. Claude challenges and implements. GitHub remembers. I make the editorial decisions. This is the practical version: how to build the machinery rather than merely describe the idea.

My simpler guide explains how to build a portable intelligence repository in a weekend.

This is what happens next.

Once you have somewhere durable to store what you believe, what supports it, what you’re still uncertain about, what you’ve decided and what you’ve learned, you can start doing something more interesting than asking AI to search your notes.

You can build a workflow around them.

Mine currently involves ChatGPT, Claude and GitHub. But this is not really a guide to those three products. The models are replaceable. The repository should not be. And the person remains responsible for deciding what the system believes.

The architecture looks roughly like this:

Human observation and judgement
        ↓
Conversational AI
explore / interrogate / connect
        ↓
Durable repository
memory / provenance / state
        ↓
Second AI or repository-aware agent
challenge / compare / implement
        ↓
Human review
approve / reject / edit
        ↓
Publication or other action
        ↓
Learning
        ↓
back into the repository

If you want to build something similar, here is the nerdy version.

The lazy version: give this guide to your AI

Before we get into the architecture, there is a shortcut.

You can give this guide to a capable AI and ask it to use the guide as an implementation specification.

Do not ask it to copy my repository. Your work, evidence standards, security requirements and publishing outputs will be different.

Ask it to interview you first, then build the smallest useful system around your answers.

Use this bootstrap prompt:

I want to build the editorial operating system described in this guide.

Use the guide as the architecture, not as content to reproduce.

First, interview me only for information that materially changes the system:

- what kind of work this repository will support;
- what knowledge I already have;
- what outputs I produce;
- what sources count as evidence;
- what information is sensitive;
- what AI tools I use;
- whether you have repository access;
- what decisions must remain human;
- what my current priorities are.

Then:

1. propose the minimum viable repository structure;
2. create the root operating files;
3. create reusable templates;
4. define status and governance rules;
5. create a current-work mechanism;
6. define the conversational-AI workflow;
7. define the second-editor workflow;
8. create the review gate;
9. create the weekly maintenance routine;
10. explain what you deliberately did not build yet.

Do not create elaborate taxonomy unless my actual work requires it.

Prefer a small system I will use over a sophisticated one I won't.

Do not implement until you have shown me the proposed structure and I have approved it.

Once you approve the architecture, the next instruction can be as simple as:

Implement it.

If the AI has appropriate GitHub or filesystem access, it can create much of the structure directly. If it does not, it can generate the files for you to copy.

The important point is that this guide can function as both human-readable documentation and a machine-readable-enough specification.

That is itself part of the idea. A well-designed workflow should be legible to both the people operating it and the AI systems entering it.

First, understand what each layer is allowed to do

The biggest mistake would be connecting several AI tools to the same repository and assuming you have created a system.

You have not.

You have created several things with write access.

A useful system begins with responsibilities.

In mine, the rough separation is:

Layer	Main job	Should not own
Human	noticing, judgement, priorities, accountability	repetitive retrieval and implementation
Conversational AI	exploration, challenge, connecting ideas	canonical truth
Repository	durable memory and state	judgement
Repository-aware AI	cold review, implementation, corpus checks	final editorial authority
Publication layer	public expression	methodology source of truth
Learning layer	evidence from what happened	automatic promotion into doctrine

If one AI can create a framework, declare it canonical, publish it and then explain why its own decision was correct, you have not built an editorial system.

You have built an extremely articulate single point of failure.

Build the repository around epistemic differences

The five-file version in the weekend guide is enough to start.

For an operating system, I would expand it only when the work starts to justify the separation.

A reasonably mature version might look like this:

editorial-os/
│
├── README.md
├── AGENTS.md
├── NOW.md
├── CURRENT-WORK.md
├── CHANGELOG.md
│
├── beliefs/
│   ├── README.md
│   └── example-belief.md
│
├── evidence/
│   ├── README.md
│   ├── research/
│   ├── conversations/
│   ├── performance/
│   └── observations/
│
├── questions/
│   ├── README.md
│   └── open-questions.md
│
├── decisions/
│   ├── README.md
│   └── decision-log.md
│
├── learning/
│   ├── README.md
│   └── learning-log.md
│
├── frameworks/
│   ├── README.md
│   └── ...
│
├── workflows/
│   ├── README.md
│   └── ...
│
├── experiments/
│   ├── README.md
│   └── ...
│
├── publishing/
│   ├── ideas/
│   ├── drafts/
│   ├── scheduled/
│   └── published/
│
├── archive/
│
└── templates/
    ├── belief.md
    ├── evidence.md
    ├── decision.md
    ├── experiment.md
    └── publication.md

Do not copy that because it looks organised.

Use it because each directory represents a different epistemic state.

A piece of evidence is not the same thing as a belief. A belief is not a framework. A framework is not a question. A question is not an article idea. A published article is not automatically canonical knowledge.

If everything lives in one /notes folder, your AI has to infer those distinctions every time it reads the repository.

Eventually it will infer one wrongly.

Structure is a form of prompting.

The root files are the control plane

Most people obsess over folders.

I care more about the handful of files sitting at the root.

These tell humans and machines how the system works.

`README.md`

This explains what the repository is.

Keep it descriptive rather than instructional.

# Editorial operating system

This repository contains durable editorial knowledge.

Its purpose is to preserve evidence, working positions,
decisions, questions, frameworks, learning and publication
history independently of any individual AI model.

The repository is the system of record.

AI systems may read, challenge and propose changes to it.

Humans remain responsible for final editorial judgement.

An AI entering the repository cold should understand the purpose in thirty seconds.

A human joining the team should too.

`AGENTS.md`: the vendor-neutral operating contract

This is the file I would make canonical, and I’d use that exact name.

Not a model-specific instruction file, not a custom GPT, not whichever configuration format is fashionable this year — those can be adapters, covered below. AGENTS.md is already an emerging cross-tool convention rather than one vendor’s format: several coding agents, including the ones I use, look for it automatically. It’s what actually sits at the root of both repositories behind this site — the public one included, if you want to see the real file rather than take my word for the shape of it.

AGENTS.md contains the actual editorial contract.

# Editorial operating contract

## Purpose

This repository preserves durable editorial intelligence.

Treat it as accumulated organisational context, not as a pile
of source documents.

## Authority

Human editorial judgement is authoritative.

AI systems may:

- retrieve;
- compare;
- challenge;
- suggest;
- draft;
- classify;
- implement approved changes.

AI systems may not silently:

- promote a draft position to settled;
- overwrite contradictory evidence;
- delete unresolved questions;
- turn observations into canonical frameworks;
- publish material solely because another model approved it.

## Before creating anything

Check:

1. Does this already exist?
2. Does it extend an existing position?
3. Does it contradict anything?
4. What evidence supports it?
5. What evidence weakens it?
6. Is it a new idea or a new expression of an old idea?
7. Is someone already working on it?

Prefer:

extend → correct → merge → split → create

over automatically creating another asset.

## Status vocabulary

Draft:
Early or unresolved thinking.

Working:
Useful enough to operate from but open to revision.

Settled:
Has survived enough evidence and use that changing it requires
an explicit reason.

Deprecated:
Retained for history but no longer guides current work.

## Editorial principle

Do not optimise for output volume.

Optimise for stronger judgement across the corpus.

## Uncertainty

Preserve uncertainty explicitly.

If the evidence is insufficient, say so.

Do not resolve an open question merely to produce a complete answer.

## Publication

Published work remains part of the learning system.

When new evidence appears, consider whether to:

- extend;
- correct;
- merge;
- split;
- create.

Publication is a state, not the end of thinking.

That file is effectively the constitution.

Everything else should point back to it.

Use adapter files, not duplicated constitutions

Different agent environments have different ways of accepting repository instructions.

Do not make each one a separate rulebook.

You want something closer to:

AGENTS.md
   │
   ├── conversational AI context
   ├── agent instruction adapter
   └── repository-tool instruction adapter

An adapter might say:

# Agent instructions

Read AGENTS.md before substantial work.

Also read:

- NOW.md for current priorities;
- CURRENT-WORK.md before proposing new work;
- relevant directory README files before editing within them.

Do not duplicate canonical methodology into this file.

Where this file conflicts with AGENTS.md on editorial matters,
AGENTS.md is the source of truth.

Why?

Because duplicated instructions drift.

You change a governance rule in one model’s instructions and forget the other. Six weeks later one agent believes working means one thing while another believes it means something else.

The architecture should make disagreement visible, not manufacture it accidentally.

Give every substantial file a contract

The system becomes much easier for AI to use if files are not arbitrary blobs of prose.

A belief might look like:

---
type: belief
status: working
created: 2026-08-21
last_reviewed: 2026-08-21
owner: human
---

# AI increases the value of editorial judgement

## Position

As AI reduces the marginal cost of producing competent
business prose, more editorial value moves toward selecting
the argument, evidence, framing and decision rather than
typing sentences.

## Evidence

- Customer-story programme: discovery repeatedly created
  more difficulty than prose production.
- Multi-model editorial experiment.
- Increasing ability to produce and revise copy cheaply.

## Evidence against

- Some categories of writing still depend heavily on
  exceptional prose execution.
- No organisation-level study currently demonstrates the
  economic shift described above.

## Confidence

Moderate.

## What would change this position?

Evidence that prose production remains the dominant constraint
even where capable AI drafting is available.

## Related

- frameworks/editorial-intelligence.md
- questions/early-career-training.md
- evidence/customer-story-programme.md

That is significantly more useful than:

AI means judgement is important

The point is not markdown fetishism.

The point is explicit epistemology.

The system can see what the claim is, what supports it, what opposes it, how confident you are, what would falsify it and what else it touches.

That makes challenge possible.

Treat evidence as evidence, not as prose

An evidence record needs a different structure.

---
type: evidence
status: settled
source_type: first-hand-programme
observed: 2026-08-08
reliability: medium
---

# Customer-story programme: discovery was the recurring bottleneck

## Observation

Across the completed customer-story programme, selecting the
editorial spine repeatedly required more judgement than
generating prose once the spine had been established.

## Source

Fifteen completed customer-story workflows.

## What this supports

- Story discovery should be separated from drafting.
- Editorial value often sits upstream of prose production.

## What this does not prove

- That writing quality no longer matters.
- That the same pattern holds across all editorial formats.
- That AI caused the bottleneck to move.

## Related

- beliefs/ai-and-editorial-judgement.md
- workflows/customer-story-discovery.md

The What this does not prove section is particularly valuable.

AI systems are extremely good at extending implications. That is useful until an implication quietly becomes a claim.

Explicit boundaries give the system something to push against.

Keep open questions first-class

A normal content repository records answers.

A thinking system also records uncertainty.

---
type: question
status: working
opened: 2026-08-16
---

# Does multi-model editorial review improve judgement?

## Question

Does deliberately separating argument development and final
editorial challenge between different AI models produce
materially better editorial decisions?

## Why it matters

If yes, editorial separation of duties may be worth retaining
for substantial work.

If not, the process is unnecessary complexity.

## Current evidence

Positive:
- second-model review has identified duplicated arguments;
- second-model review has challenged unsupported claims;
- repository-aware review has caught structural problems.

Negative:
- many reviews produce stylistic rather than substantive disagreement;
- both models can inherit the same framing from the human;
- additional passes consume attention.

## Evidence required

Track at least ten substantial publications and classify
second-model interventions as:

- prevented error;
- improved argument;
- identified duplication;
- changed implementation;
- stylistic only;
- no material value.

## Decision threshold

Do not promote this into a settled operating principle until
there is repeated evidence that the second-model pass produces
material changes.

Now the AI can distinguish something I am exploring from something I believe.

That is a huge difference.

Track current work or your agents will duplicate each other

I nearly learned this lesson from a real failure, and the correction turned out to matter more than the original story.

Two AI-assisted sessions had produced strikingly similar work — same argument, same structure, same failure named — from the same accumulated context, apparently without either knowing the other existed. It looked like exactly the risk this section warns about: independent processes, same gap, same conclusion, no coordination.

It wasn’t that. Checked properly, one session’s draft had been pasted into the other as a starting point, so the outputs shared a source rather than a cause. A second apparent duplication had an equally mundane explanation: a stale local checkout that hadn’t fetched the other session’s commits. Neither event was evidence of anything about shared context.

The real lesson survived the correction, even though the anecdote didn’t: a repository tells you what exists. It does not automatically tell you what is in flight, or which of two similar-looking things in front of you actually has independent origin. If the near-miss above had been genuine independent convergence, nothing in the repository would have told either session the other was mid-task — and nothing would have told me the two outputs weren’t independent either, which is the more uncomfortable half of it. I believed the story for about a day before checking where the pasted draft had actually come from.

So add:

CURRENT-WORK.md

For example:

# Current work

## Active

### Multi-model editorial workflow guide

Owner: Asavin
Agent: ChatGPT
Started: 2026-08-21
Status: drafting

Goal:
Create advanced practical guide showing how to operate
ChatGPT + Claude + GitHub as an editorial system.

Likely files:
- publishing/drafts/ai-editorial-operating-system.md
- workflows/multi-model-editorial-workflow.md

Do not independently create another guide covering this same
argument while this work remains active.

### Portable Intelligence framework review

Owner: Asavin
Agent: Claude
Started: 2026-08-21
Status: reviewing

Goal:
Check whether recent workflow observations require a framework
update.

Do not modify the framework until review is complete.

Now the system answers both:

What do we know?

and:

What are we already doing about it?

That becomes much more important as you add agents.

Use `NOW.md` to stop the repository becoming your boss

A good knowledge system will generate more possible work than you can complete.

Mine does.

So the repository also needs a deliberately tiny priority layer.

# Now

Current priorities:

1. Validate Editorial Intelligence through real programmes.
2. Develop evidence for multi-model editorial review.
3. Improve practical implementation guidance.
4. Do not create new frameworks unless evidence requires one.

Not now:

- new product concepts;
- expanding taxonomy;
- speculative agent architecture;
- additional website sections without evidence.

Decision rule:

If proposed work does not advance a current priority,
capture it in the backlog instead of doing it.

Otherwise AI becomes a machine for turning every interesting connection into an assignment.

Use conversational AI for exploration, not premature production

Suppose I notice:

I’m increasingly spending less time physically writing and more time deciding what the work should say.

My first prompt should not be:

Write me a LinkedIn post about AI and editorial judgement.

That skips almost all of the valuable work.

A better starting prompt:

I keep noticing that AI is reducing the amount of time I
spend physically drafting business writing, while increasing
the amount of time I spend selecting arguments, challenging
claims, deciding what evidence matters and editing structure.

I don't want an article yet.

Interrogate the observation.

Help me determine:

- whether this is actually new;
- what mechanisms could explain it;
- the strongest counterarguments;
- what evidence I have versus what I'm assuming;
- whether it changes anything already in my editorial system;
- what questions remain unresolved.

Prefer disagreement over producing a neat thesis.

The final sentence matters.

Conversational AI tends to help a conversation converge. Sometimes you want divergence first.

Separate exploration from persistence

After twenty minutes of useful discussion, do not dump the transcript into GitHub.

The transcript is not the knowledge.

The transcript is the process that generated possible knowledge.

Run a persistence pass.

Review this conversation as an editorial knowledge capture.

Do not draft public content.

Identify only material that deserves to survive beyond
the conversation.

Return:

1. New observations
2. Evidence introduced
3. Existing beliefs strengthened
4. Existing beliefs weakened
5. Potential contradictions
6. New open questions
7. Decisions made
8. Ideas that are interesting but should remain backlog
9. Existing repository material that may need updating

For every proposed durable item, explain why it deserves
persistence.

Prefer updating an existing item to creating a new one.
Do not invent a framework simply because an idea sounds
framework-shaped.

This creates a boundary between thinking and memory.

You need that boundary.

Otherwise the repository gradually fills with conversational exhaust.

Do not let the conversational model decide what gets persisted

The persistence prompt produces proposals.

Not automatic writes.

For important changes, I want something like:

Proposed repository changes

UPDATE
beliefs/ai-and-editorial-judgement.md

Reason:
New observation strengthens the existing upstream-value claim.

ADD EVIDENCE
evidence/editorial-workflow-observation-2026-08-21.md

Reason:
First-hand operating observation with future validation value.

ADD QUESTION
questions/editorial-time-allocation.md

Reason:
We do not yet have evidence showing whether the time shift
is generalisable.

NO NEW FRAMEWORK

Reason:
Existing Editorial Intelligence and Portable Intelligence
structures already contain the relevant concepts.

Then the human can say:

Approve 1 and 3.
Reject 2: insufficiently distinct evidence.
Agree no framework.

That decision is editorial work.

Do not automate it away simply because you can.

Make the second model enter cold

This is where Claude currently comes in for me.

The second model should not receive:

ChatGPT and I have developed this excellent argument. Please improve it.

You have already contaminated the review.

Instead give it the repository state and the proposed change.

You are performing a second-editor review.

Do not assume the proposed argument is correct merely because
another AI-assisted process developed it.

Read:

- AGENTS.md
- NOW.md
- CURRENT-WORK.md
- the proposed draft
- directly related beliefs, evidence, frameworks and
  published material

Then answer:

1. What is genuinely new here?
2. What substantially duplicates existing work?
3. Which claims exceed the evidence?
4. What existing material contradicts it?
5. What important counterargument is missing?
6. Does the piece confuse observation with established methodology?
7. Should the system:
   - extend
   - correct
   - merge
   - split
   - create?
8. What changes should happen outside the draft if this
   argument is accepted?
9. What should definitely not be changed?

Do not rewrite the article until the editorial decision has
been made.

Agents love implementation.

Editorial systems sometimes need diagnosis first.

Record model disagreement instead of hiding it

Imagine ChatGPT says create a new article and Claude says merge it into an existing one.

The wrong response is:

Which AI is better?

The useful response is:

Why do they disagree?

Record it.

# Decision: AI editorial judgement argument

Date: 2026-08-21

## Proposal

Create a standalone article.

## ChatGPT position

Create.

Reason:
The workflow mechanism is sufficiently distinct to justify
a dedicated explanation.

## Claude position

Extend.

Reason:
The upstream-value argument already exists repeatedly across
the corpus and another standalone article risks duplication.

## Human decision

Create a practical workflow guide but do not create another
conceptual essay.

## Reason

The conceptual claim is not new.

The implementation detail is.

The new asset therefore needs to teach the mechanism rather
than restate the thesis.

## Consequence

- no new canonical framework;
- practical guide added;
- existing conceptual article linked;
- workflow evidence retained separately.

Six months later you will not have to reverse-engineer why two similar-looking ideas were treated differently.

Use Git like editorial version control, not developer cosplay

You do not need to become a software engineer to get value from Git.

The useful conceptual primitives are simple.

Commit

A recorded change with a reason.

Editorially:

What changed, and why?

Diff

The exact difference between two states.

Editorially:

What is the AI actually proposing to change?

Branch

A temporary alternate version.

Editorially:

Explore this without overwriting the accepted version.

Pull request

A reviewable proposal to change the shared source.

Editorially:

Here is the proposed change. Should it become part of the system?

History

The sequence of previous changes.

Editorially:

How did this position evolve?

That is why Git feels unexpectedly natural for editorial work.

It externalises questions editors already ask.

If you want the command-line version

You do not need this section to use the method.

But this is the nerdy guide.

A basic local workflow might be:

git clone <repository>
cd editorial-os

Before working:

git pull
git status

Create a branch for substantial work:

git checkout -b guide/ai-editorial-operating-system

Make the edits.

Then inspect them:

git diff

Stage only what you intend to change:

git add publishing/drafts/ai-editorial-operating-system.md
git add CURRENT-WORK.md

Review the staged change:

git diff --staged

Commit it with a reason:

git commit -m "Draft practical multi-model editorial workflow guide"

Then push:

git push -u origin guide/ai-editorial-operating-system

Create a pull request.

Now another model or a human editor can inspect the proposal without altering the accepted state.

The important bit is not the commands.

It is this:

proposal ≠ accepted truth

Git makes that distinction structural.

Write commits like decision records

Bad commit:

update files

Useful commit:

Separate discovery from drafting in customer-story workflow

Repeated story reviews show that most editorial disagreement
occurs while selecting the spine rather than during prose
production.

This change:

- adds explicit discovery stage;
- records generated brief as hypothesis, not truth;
- delays drafting until human spine approval;
- adds learning question for six-story validation set.

Now commit history itself becomes evidence about the evolution of the system.

A future AI can inspect not just what exists.

It can inspect why it exists.

Do not allow agents to silently mutate settled knowledge

Give settled material stronger write rules.

# Settled change policy

Before modifying any file with:

status: settled

the agent must provide:

1. current position;
2. proposed change;
3. evidence requiring the change;
4. downstream files affected;
5. whether this is:
   - correction;
   - qualification;
   - extension;
   - deprecation.

No settled position may be modified solely for style,
brevity or consistency if the edit could change meaning.

You can make the rule even simpler:

AI may suggest.
Human must promote.

Treat status as a state machine

Once the repository becomes larger, think of knowledge as moving through states.

capture
   │
   ▼
draft
   │
   ▼
working
   │
   ▼
settled
   │
   ├───────────────┐
   │               │
   ▼               ▼
revised        deprecated

Not everything has to travel all the way.

Some observations stay draft forever. Some questions get closed without becoming beliefs. Some working positions get disproved.

You can define transition rules.

Draft → working

Requires:

a clear claim;
some evidence;
known uncertainty;
enough usefulness to guide actual work.

Working → settled

Requires:

repeated evidence or application;
no unresolved contradiction serious enough to invalidate it;
explicit human promotion.

Settled → revised

Requires:

new evidence;
material contextual change;
contradiction discovered;
clearer mechanism.

Settled → deprecated

Requires:

replacement;
falsification;
loss of relevance.

That is governance.

You do not need a committee to have governance.

Make evidence provenance machine-readable

If your system becomes serious, add metadata.

---
type: evidence
status: settled

source:
  kind: customer-interview
  date: 2026-07-15
  participant: anonymised
  owner: human

provenance:
  source_file: interviews/embedded-services-roundtable.md
  verified: true
  permission: internal-analysis

supports:
  - beliefs/embedded-accounting-trust.md

contradicts: []

confidence: medium
---

Now an AI can do things like:

Show me all working beliefs supported only by low-confidence evidence.

Or:

Find settled positions whose newest evidence is more than twelve months old.

Or:

Which claims depend entirely on one customer interview?

That is where a knowledge repository starts becoming computational rather than merely searchable.

Build reusable diagnostics

Once structure is predictable, you can create recurring editorial queries.

Contradiction scan

Review all working and settled beliefs.

Identify pairs that appear to conflict.

For each:

- quote the relevant positions;
- classify the conflict as real, contextual or superficial;
- identify which evidence supports each side;
- recommend investigation, not automatic resolution.

Evidence debt scan

Find working beliefs with:

- no linked evidence;
- only one evidence item;
- only anecdotal evidence;
- evidence older than one year;
- unresolved contradictory evidence.

Rank by how much downstream work relies on the belief.

Duplication scan

Compare publishing/ideas and publishing/drafts against
published work.

Classify each proposed asset:

- genuinely new;
- extension;
- reframing;
- near-duplicate;
- uncertain.

Do not judge by headline similarity alone.
Compare underlying argument and mechanism.

Framework inflation scan

Review all frameworks created in the last 90 days.

For each ask:

- is this genuinely reusable?
- is it distinct from an existing framework?
- does evidence support it?
- has it been applied more than once?
- would a principle, workflow or note be a more accurate type?

Recommend demotion where appropriate.

AI loves frameworks nearly as much as consultants do.

Build editorial tests

Software has tests.

Editorial systems can too.

Not truth tests.

Consistency tests.

TEST: settled files have evidence
FAIL if:
type=belief AND status=settled AND evidence_links=0

TEST: deprecated files identify replacement
FAIL if:
status=deprecated AND replacement=null

TEST: published methodology exists in core
WARN if:
public article claims a canonical principle
that has no corresponding canonical repository entry

TEST: current work collision
WARN if:
two active tasks have substantial semantic overlap

TEST: orphan framework
WARN if:
framework has no evidence, applications or related workflow

You do not necessarily need code for these.

An AI agent can run them conversationally.

Once they are explicit, you can automate them later.

Separate methodology from publication

This is a particularly important architecture choice in Editorial Intelligence.

The website should not automatically become the source of truth simply because something was published.

I think in two layers:

CORE
methodology
evidence
principles
workflows
decisions

        ↓ informs

PUBLICATION
articles
field notes
framework explanations
social
guides

But learning also moves back:

PUBLIC RESPONSE
performance
criticism
new examples
corrections
reader questions

        ↓

CORE LEARNING

So the relationship is:

core → publication → evidence → core

Not:

AI → article → done

That is the compounding loop.

Use the five-way publishing decision

Whenever a new signal arrives, ask:

EXTEND
CORRECT
MERGE
SPLIT
CREATE

Example.

You notice:

Claude performs better than ChatGPT at a particular editing task.

Bad system:

NEW ARTICLE:
Why Claude is better than ChatGPT for editing

Better system asks whether this alters the existing multi-model argument.

Perhaps the answer is:

EXTEND

Existing position:
Different AI models can occupy different editorial roles.

New evidence:
Claude produced materially stronger cold-review challenges
across three substantial pieces.

Change:
Add as current evidence.

Do not convert into permanent vendor preference.

That is corpus-level judgement.

Do not make your models permanently role-shaped

Today I might use:

ChatGPT = thinking
Claude = second editor

It would be easy to turn that into doctrine.

Do not.

Store roles independently of vendors:

roles:
  exploratory_editor:
    current_tool: chatgpt

  repository_editor:
    current_tool: claude

  final_authority:
    current_tool: human

Then review periodically.

If another model becomes better at repository review, swap it.

The system survives.

That is Portable Intelligence.

A complete worked example

Let’s run the entire system.

Signal

I notice:

AI is making it possible for me to revisit and substantially update old articles rather than constantly create new ones.

Step 1: conversational exploration

I have an observation:

AI plus repository-aware tooling is making it much cheaper
for me to revisit old published work and integrate new
thinking into it.

Do not draft an article.

Interrogate whether this is:

- merely easier editing;
- a change in publishing economics;
- an editorial workflow change;
- something already covered by Editorial Intelligence.

Look for counterarguments and existing related concepts.

Possible conclusion:

The interesting idea is not cheap editing.

It is that reduced revision cost changes the default decision
from "publish another asset" toward "maintain a corpus".

Step 2: persistence analysis

What from this discussion deserves durable repository memory?

Possible output:

NEW OBSERVATION
Cheap revision may alter corpus-level editorial decisions.

EXTENDS
Knowledge-system argument.

POSSIBLE WORKFLOW
Before creating, choose extend/correct/merge/split/create.

QUESTION
Does continuous revision create maintenance churn?

NO NEW FRAMEWORK YET
Insufficient evidence.

Step 3: human approval

Approve the workflow experiment and open question.

Reject the new framework.

Step 4: repository update

Create:

workflows/continuous-publishing.md

Status:

emerging

Step 5: second-editor review

Review continuous-publishing.md against existing methodology.

Do not assume this deserves to be a workflow.

Find duplication, unsupported claims and conflicts.

The second editor might identify:

relationship to the existing Editorial Intelligence cycle;
risk of endless revision;
need for provenance;
distinction between sentence polishing and material development.

Step 6: human judgement

Decision:

Keep as emerging workflow.

Add explicit review test.

Do not promote to canonical.

Step 7: implementation

The repository-aware agent updates the workflow and relevant links.

Step 8: publication

A public article demonstrates the behaviour.

Step 9: real-world use

Several existing articles are later extended, corrected, merged or split.

Step 10: learning

The implementation becomes evidence for the workflow.

Something that began as:

Huh, updating old posts is easier now.

has travelled through:

observation
↓
interrogation
↓
working hypothesis
↓
workflow
↓
challenge
↓
implementation
↓
publication
↓
evidence
↓
methodology development

That is what I mean by an editorial operating system.

Build a review gate before publication

For substantial publication, I want a gate roughly like this:

[ ] Is the argument actually new?

[ ] Is there relevant existing work?

[ ] Have contradictory positions been checked?

[ ] Are major factual claims evidenced?

[ ] Does the language distinguish observation from proof?

[ ] Has another editorial perspective challenged it?

[ ] Has the human made the final decision?

[ ] Should this create or update anything in core?

[ ] Should another existing article be updated instead?

[ ] Is CURRENT-WORK clear?

[ ] Is provenance preserved?

[ ] Are relevant relationships linked?

The checklist should not become bureaucracy.

Use it where failure matters.

A minor social post does not need the same gate as a methodology change.

Give agents permission to say “do nothing”

This may be one of the most important instructions in the whole system.

AI agents are optimised around completion.

Give them a task and they want an output.

Editorial judgement often concludes:

Don't publish this.

Or:

Interesting, but capture only.

Or:

Already covered.

Or:

Evidence too weak.

Or:

Wait.

So explicitly include:

## Valid outcomes

A successful editorial task may conclude:

- create;
- update;
- merge;
- archive;
- defer;
- investigate;
- do nothing.

Producing no new public asset is a valid successful result.

Without that rule, your system will slowly optimise itself back into a content factory.

Protect yourself from AI certainty

Give the agent an uncertainty grammar.

OBSERVATION
Something seen or experienced.

HYPOTHESIS
Possible explanation.

EVIDENCE
Material supporting or challenging a claim.

WORKING POSITION
Current interpretation used provisionally.

SETTLED POSITION
Current canonical interpretation.

OPEN QUESTION
Important uncertainty requiring more evidence.

DECISION
Human choice made given current information.

Then tell it:

Never silently promote one category into another.

An observation does not become evidence merely because it is interesting.

Evidence does not automatically establish a position.

A working position is not a fact.

A decision is not proof.

That discipline matters more as the prose becomes more convincing.

Keep a graveyard

I like deleting clutter.

But some failures are valuable.

Maintain an archive for things that were considered and rejected.

archive/
  abandoned-frameworks/
  withdrawn-publications/
  superseded-workflows/
  failed-experiments/

Each should say why. The near-miss from a couple of sections back is the real entry from mine:

# Concurrent duplication in shared context

Status: withdrawn — the finding was false

## What was claimed

Two AI sessions, given the same accumulated context, converged
independently on near-identical output — evidence that shared
context causes concurrent duplication.

## What was actually true

One session's draft had been pasted into the other as a
starting point. The outputs shared a source, not a cause.
A second apparent duplication had an equally mundane
explanation: a stale local checkout.

## Why it's kept

The mechanism was plausible and the story compelling enough
that it got told, and believed, for about a day before anyone
checked where the pasted draft had actually come from. That
failure — not the mechanism — is the reusable lesson.

## What would make the underlying question real again

A second, independently verified instance. One unverified
anecdote is not evidence, however good the story is.

Notice what the entry is actually for. It isn’t there to preserve a finding — the finding was wrong. It’s there so that the next time a two-model coincidence looks too good a story to check, something in the repository has already paid for that mistake once.

Maintain the system like a garden, not a database

Eventually the repository gets messy.

That is normal.

Run periodic maintenance.

Weekly: active learning

Ask:

What happened this week that changes anything?

Monthly: working positions

Ask:

Which working positions became:

- stronger;
- weaker;
- contradicted;
- irrelevant;
- ready to settle?

Quarterly: architecture

Ask:

Which folders, frameworks and workflows exist because they
are useful?

Which exist because AI once suggested them?

Six-monthly: model independence

Ask:

If ChatGPT disappeared tomorrow, what would we lose?

If Claude disappeared tomorrow, what would we lose?

If GitHub disappeared tomorrow, could the knowledge be
exported and reconstructed elsewhere?

The ideal answer to the first two should mostly be:

an interface

Not:

our organisational memory

Security and permissions get serious quickly

A personal repository is easy.

Organisational use is not.

Do not casually give every model access to confidential interviews, unreleased financial data, personal information, commercially sensitive documents, customer records, internal strategy or legal material.

Your architecture needs permissions.

Conceptually:

public
internal
confidential
restricted

Agent access should follow the task.

The principle is:

least context required

not:

give the AI everything because context is good

More context can improve reasoning.

It can also increase exposure, confusion and cost.

Portable Intelligence still needs information governance.

Do not confuse repository size with intelligence

A ten-gigabyte repository is not necessarily better than a hundred useful markdown files.

The goal is not comprehensive storage.

It is usable accumulated context.

Bad:

47,000 meeting transcripts

Better:

raw transcripts
      ↓
verified evidence
      ↓
connected positions
      ↓
decisions
      ↓
learning

An archive contains information.

An editorial system creates relationships between information and judgement.

That is the difference.

The system should get harder to impress

A strange thing should happen as this works.

Early on:

Wow, AI found a connection!

Later:

Yes, but is the connection important?

Early on:

It generated a framework!

Later:

Why does this need to be a framework?

Early on:

Both models agree!

Later:

What independent evidence exists?

Early on:

We could publish five articles from this.

Later:

Should any of them exist?

That is maturity.

The AI does not necessarily become less impressive.

Your editorial threshold becomes higher.

The minimum viable advanced system

If everything above sounds ridiculous, good.

Do not implement all of it.

Start here:

README.md
AGENTS.md
NOW.md
CURRENT-WORK.md

beliefs/
evidence/
questions/
decisions/
learning/
publishing/

Then establish six rules:

1. Durable thinking leaves the chat.

2. Not everything said in chat deserves durability.

3. Search before creating.

4. The second model challenges rather than blesses.

5. Settled knowledge requires explicit human change.

6. Publication feeds learning back into the repository.

Run that for three months.

Only add architecture when a real failure demands it.

My own system grew because problems appeared, not because I designed the perfect ontology on day one.

That distinction matters.

A system built entirely in advance is mostly speculation.

A system built from failures contains evidence.

The workflow in one screen

If I had to reduce everything to one operating loop, it would be this:

1. HUMAN NOTICES
observation / problem / disagreement
        ↓
2. CONVERSATIONAL AI
interrogate / connect / challenge
DO NOT WRITE ARTICLE YET
        ↓
3. PERSISTENCE PASS
what deserves durable memory?
        ↓
4. HUMAN APPROVAL
approve / reject proposed knowledge changes
        ↓
5. REPOSITORY UPDATE
evidence / beliefs / questions / decisions
        ↓
6. SECOND EDITOR
read cold / find contradiction / duplication
        ↓
7. CORPUS DECISION
extend / correct / merge / split / create
        ↓
8. HUMAN JUDGEMENT
decides what survives
        ↓
9. IMPLEMENT / PUBLISH
agent executes approved change
        ↓
10. LEARN
what happened? what changed?
        ↓
REPOSITORY

It is a loop.

But the loop does something a blank chatbot cannot.

It accumulates.

The real asset is not the model

I use ChatGPT constantly.

I use Claude constantly.

GitHub has become unexpectedly central to how I think.

But I do not want Editorial Intelligence to depend permanently on any of them.

That would defeat the point.

The goal is to build a body of intelligence that models can enter.

Not knowledge trapped inside models.

That intelligence includes the obvious things: research, frameworks, published articles and decisions.

But it also includes the less glamorous material: things I rejected, things I got wrong, questions I could not answer, arguments I withdrew, frameworks I chose not to create, reasons I changed my mind and work somebody else is already doing.

Those things give future work shape.

Once enough of them accumulate, AI stops feeling like something you summon to generate an answer.

It starts operating inside a history.

That is when the workflow becomes interesting.

You are no longer asking:

What can Claude write for me?

Or:

What can ChatGPT generate?

You are asking:

Given everything we know, everything we’re uncertain about, everything we’ve already tried, everything currently in flight and everything we’ve learned — what should we do next?

And the most important answer the system can give you is sometimes:

Nothing.

Because the point of an editorial operating system is not to produce more.

It is to make better decisions about what deserves to exist.

The lazy version: give this guide to your AI

First, understand what each layer is allowed to do

Build the repository around epistemic differences

The root files are the control plane

README.md

AGENTS.md: the vendor-neutral operating contract

Use adapter files, not duplicated constitutions

Give every substantial file a contract

Treat evidence as evidence, not as prose

Keep open questions first-class

Track current work or your agents will duplicate each other

Use NOW.md to stop the repository becoming your boss

Use conversational AI for exploration, not premature production

Separate exploration from persistence

Do not let the conversational model decide what gets persisted

Make the second model enter cold

Record model disagreement instead of hiding it

Use Git like editorial version control, not developer cosplay

Commit

Diff

Branch

Pull request

History

If you want the command-line version

Write commits like decision records

Do not allow agents to silently mutate settled knowledge

Treat status as a state machine

Draft → working

Working → settled

Settled → revised

Settled → deprecated

Make evidence provenance machine-readable

Build reusable diagnostics

Contradiction scan

Evidence debt scan

Duplication scan

Framework inflation scan

Build editorial tests

Separate methodology from publication

Use the five-way publishing decision

Do not make your models permanently role-shaped

A complete worked example

Signal

Step 1: conversational exploration

Step 2: persistence analysis

Step 3: human approval

Step 4: repository update

Step 5: second-editor review

Step 6: human judgement

Step 7: implementation

Step 8: publication

Step 9: real-world use

Step 10: learning

Build a review gate before publication

Give agents permission to say “do nothing”

Protect yourself from AI certainty

Keep a graveyard

Maintain the system like a garden, not a database

Weekly: active learning

Monthly: working positions

Quarterly: architecture

Six-monthly: model independence

Security and permissions get serious quickly

Do not confuse repository size with intelligence

The system should get harder to impress

The minimum viable advanced system

The workflow in one screen

The real asset is not the model

`README.md`

`AGENTS.md`: the vendor-neutral operating contract

Use `NOW.md` to stop the repository becoming your boss