reflection 9 min read

The method can be public

11 September 2026


I have been writing publicly about Editorial Intelligence for a while, and I keep noticing the same slightly uncomfortable thing: the more useful the system becomes, the more of it I seem to explain.

I have written about using GitHub as a save point, about routing work between different models and tools, about building editorial memory, about making work recoverable, and about the moments when the system becomes too complicated and needs to be simplified. I am not really using the website to advertise a hidden methodology sitting somewhere behind it.

Most of the usable method is visible.

That used to make me wonder whether I was giving too much away. If somebody can see how the system works, what stops them copying it?

I increasingly think that is the wrong question.

This is not literally open source

I am tempted to describe this as open-source knowledge work, but that is not quite right.

Open source has a specific meaning. Software is released under terms that allow people to inspect it, reuse it, modify it and redistribute it. Editorial Intelligence is not that. The website is public, but the repositories also contain working context, unfinished material and things that should not be public. My day job includes employer, customer and colleague information that obviously has boundaries around it.

So this is not radical transparency either. I do not think good knowledge work requires publishing every note, every source document or every intermediate thought.

The useful distinction is between the method and the inputs.

I can make the method legible without making confidential work public. I can explain how I preserve context without exposing the context itself. I can show how I use a second model without publishing the material it was asked to review.

What I am becoming comfortable with is something closer to open-by-default method.

The system can be visible. The judgement exercised inside it remains mine.

The old instinct is to hide the machinery

A lot of professional knowledge still gets packaged as if value comes partly from concealment.

Consultancies create proprietary frameworks. Agencies name processes. Experts expose enough of their method to demonstrate that there is a method, then keep the rest behind the engagement.

There is a sensible commercial argument for doing that. If a repeatable process is the product, publishing the process can make it easier for somebody to reproduce what you sell.

I do not think that argument disappears in AI-assisted work. Some methods genuinely are valuable intellectual property. Some businesses depend on implementation knowledge that would be foolish to publish casually.

But AI changes the economics of the easier-to-copy parts.

A prompt can be copied. A template can be copied. A workflow diagram can be copied. A model-selection rule can be copied. A neat framework can be reconstructed from the public output, or generated from scratch by somebody asking a capable model to solve a similar problem.

If those things are the whole advantage, the advantage is already fragile.

Trying to protect them more aggressively may not make them much more defensible.

I have been publishing the machinery anyway

Editorial Intelligence has gradually become less like a portfolio and more like a public working environment.

When I wrote Prompting is becoming routing, I did not just publish the cleaner idea that different work should go to different systems. I added the failed implementation too: the version where routing created so much branch and handoff overhead that the process became more complicated than the article it was supposed to improve.

When I wrote about giving AI work a save point, the useful thing was not a polished productivity trick. It was the mundane problem underneath it: I move between projects, tools and models, and I need the work to remain recoverable when the conversation ends.

I have also shown how two different models can work from the same persisted record and still produce different kinds of challenge in How we work with Asavin. None of that requires a secret second version of Editorial Intelligence to make it useful. In fact, if the public version of the method only worked because the important part had been withheld, I would trust it less.

The framework is not the work

Imagine somebody copied the visible system tomorrow.

They set up the same repository structure. They used save points. They created a router. They added an evidence register. They persisted decisions. They used one model to develop an argument and another to challenge it.

Would they now be doing the same work?

No.

The framework mostly tells you where judgement has to happen. It does not contain the judgement.

A save point is useful because somebody has to decide what matters enough to save and what can safely disappear. An evidence register depends on somebody recognising what counts as useful evidence rather than merely collecting more material. A routing system still needs somebody to decide whether a task deserves escalation or whether the correct decision is to stop routing and do the work.

Even the simplest parts depend on context. Two people can use the same prompt against two different bodies of evidence and produce work of very different value.

That is why I have become less interested in prompts as durable intellectual property. The prompt matters, but it is operating one level down from the more important questions: what does the system already know, what evidence is available, what has happened before, and does the person using it know how to judge the result?

The visible framework can be copied. The accumulated ability to use it cannot be transferred quite so easily.

Context compounds

This is where the idea connects most strongly to Context is capital.

A blank knowledge system is not particularly valuable. A knowledge system that contains months of decisions, failed approaches, previous arguments, evidence, recurring questions and corrections is different.

The structure might be identical. The starting position is not.

The same is true of AI-assisted work. A clever prompt given to an empty model has to reconstruct the world every time. The same instruction operating against accumulated, maintained context begins further ahead.

That does not mean more context is automatically better. Bad memory can compound too. Old decisions can become baggage. Weak assumptions can be preserved and mistaken for truth.

The advantage comes from maintained context: information that can be corrected, challenged, connected and discarded when it stops being useful.

This is one reason I care about GitHub as more than storage. The point is not that I have lots of Markdown files. The point is that yesterday’s work can change tomorrow’s decision.

You can copy the folder structure. You cannot copy the history that made the contents useful.

Public explanation is also a test

There is another reason I am becoming less protective of the method.

Publishing it improves it.

A workflow can feel completely sensible while I am using it and obviously ridiculous once I try to explain it to a cold reader. A framework can look sophisticated until I discover that I have invented three loops describing essentially the same thing. A process can acquire extra stages simply because AI makes producing process cheap.

Writing publicly creates pressure to answer basic questions.

Why does this step exist? What problem is it solving? Did it improve the work? Would I recommend somebody else do it? What would happen if I removed it?

The routing experiment is a good example. I could have treated the overcomplicated first version as an implementation mistake and quietly replaced it. Publishing the failure made the correction part of the argument: a router that creates more cognitive overhead than it removes is badly designed.

That means the public layer is not only distribution. It is part of the development environment.

An idea has to survive being made legible.

There is a real counterargument

There is an easy version of this argument that says secrecy no longer matters and everybody should build in public.

I do not believe that.

If a consultancy has spent years developing a proprietary dataset, a validated diagnostic or specialised implementation knowledge, making it public may genuinely destroy part of the commercial value. If a method is easy to reproduce and clients mainly pay for access to that method, transparency can accelerate commoditisation rather than create advantage.

There is also a more practical problem. Showing everything can become performance. Once “working in public” becomes part of the brand, people can start publishing the appearance of process instead of doing the work.

And some work simply should not travel. Employer information, customer evidence, private conversations, unpublished research and other people’s intellectual property are not raw material for a personal transparency experiment.

So the principle cannot be “publish everything”. It is narrower than that: do not manufacture secrecy around the method simply because secrecy makes expertise look scarcer.

Protect what genuinely needs protection. Be careful with the inputs. But ask whether hiding a framework actually creates advantage, or merely prevents the framework from being tested.

The moat moves

If AI keeps making templates, prompts, frameworks and workflow patterns easier to reproduce, professional advantage has to move somewhere else.

I think more of it moves into judgement, context, evidence, access, taste and application.

Can you recognise a meaningful signal inside a messy project? Can you tell whether a customer quote is evidence or decoration? Can you notice that a proposed article already exists in another form? Can you connect three apparently separate pieces of work without forcing them into one theory? Can you abandon a clever system when a simpler one works better?

Those decisions accumulate.

They also leave evidence. A body of work shows whether the judgement was useful repeatedly, not whether somebody managed to produce an impressive diagram once.

That is a much stronger source of confidence than obscurity.

The method can be public

I used to think that explaining more of Editorial Intelligence meant gradually giving away the interesting parts.

I now think I had the scarce part and the visible part mixed up.

The visible method matters. It gives the work structure, makes decisions more repeatable and helps context survive. But its value comes from use. It gets stronger because it is applied to real work, corrected when it fails, and filled with context that compounds over time.

Someone can copy the workflow without copying the experience that shaped it. They can copy the prompt without copying the evidence behind it. They can copy the framework without inheriting the judgement needed to know when not to use it.

So I am becoming much less worried about showing the machinery. The method can be public; the advantage comes from practising it.

Topics

editorial-intelligenceknowledge-systemsthought-leadershipai-workflowseditorial-operationsportable-intelligence

What to explore next

See how the ideas in this Working Note connect to the frameworks, diagnostics and workflows in Editorial Intelligence OS.

Explore the EI OS →

Keep in touch with Editorial Intelligence

Occasional updates on new research, findings and ways to take part.

No spam. Unsubscribe in one click.

Your address is used only to send these updates. Read the privacy policy.