From Internal Engineering Notes to Public Writing

YunLab writing notes

I want to write this one honestly.

Recently I've been turning some internal engineering material from OpenClaw into articles that can live publicly on YunLab.ai. When I started, the natural assumption was: the internal material is already detailed — task, conclusion, retrospective, boundary, verification record. So I just delete the sensitive bits, rephrase the rest, and I have a public article, right?

Once I actually started, it wasn't that simple.

The biggest value of internal material is letting the next person, the next AI, the next session pick the work up. It aims for accuracy, completeness, traceability. Where the files are, how far this task has gotten, whether this judgment has evidence behind it, whether this capability is still just a local candidate — all of that has to be spelled out.

But a public article isn't read that way. When someone opens YunLab.ai, they're not picking up my local project, and they're not auditing my task directory. They're more likely just trying to understand: why am I building a personal AI system this way? What potholes did I hit? Which judgments could transfer to their own system?

My first attempt kept turning into an internal handoff

That was the first pothole.

I would write straight down the source material: here's a state file, there's a handoff, this module passed, that audit scored X, this directory has more outputs underneath. While writing, it all felt right — these things did genuinely happen.

But once the page rendered, the flavor was off. It didn't read like an article. It read like I'd pasted a photo of my workbench in public. Lots of information, but the reader couldn't get in. Worse, it exposed too much backstage in public view: paths, processes, capability boundaries, unfinished states, internal names, even working habits that should only stay with the local system.

That's when I realized public writing isn't "compressing" internal material. It first has to change the question.

Internal material asks: where is this task now, how do we continue. A public article asks: what experience is behind this, which parts of it are worth keeping.

Redaction only solves a small part

The second pothole was trusting "redaction" too much at first.

I used to feel that as long as I covered the tokens, accounts, paths and internal names, the content was safe. Later I realized that's only the lowest layer of safety. What's actually likely to go wrong isn't always a particular string — it's the state the article conveys.

For instance, a system that's only a local candidate can't be written as if it's already live and stable. A process that's only been run once can't be written as a mature method. An agent still being tuned for persona, permissions and memory can't be cherry-picked to look like it's already deliverable.

That kind of problem isn't fixed by redaction. It's fixed by honestly writing the boundary.

The public-safe I now mean isn't only "nothing leaked." It also includes "not overstated, not misleading, not treating the backstage as the result."

Now I ask first: what can this piece actually leave in public?

Now when I write an article from internal material, I pause before moving any content.

I ask one dumb question first: out of all this material, what can actually be left in public?

Sometimes the answer is a pothole — for example, why raw chat logs can't directly become a knowledge base. Sometimes the answer is a boundary — for example, an agent's role can't only describe personality; it also needs a work contract. Sometimes the answer is a method — for example, a personal AI system can't only aim for "running"; it also has to be verifiable, handed off, continued.

Once I find that public angle, the internal material becomes useful again. It's no longer the structure of the article. It's the evidence and memory behind me. I can use it to think clearly, without putting it on display.

I roughly sort content into three buckets now:

• Public-able: potholes I've hit, judgments I corrected, methods that can be reused, and honest impressions of personal AI systems.
• Needs abstraction: internal tasks, roles, audits, memory, workflows. I can talk principles, but I won't lay out the backstage detail as-is.
• Must stay local: keys, accounts, full prompts, real directories, unreviewed conclusions, private-relationship context, and any operational entry point that could be misused.

The taxonomy isn't complicated, but it saves me from a very common illusion: that an article is more "real" the closer it stays to the internal source. It isn't. The realness of a public article doesn't come from spreading out the backstage. It comes from describing the experience accurately.

So this isn't "desensitizing" — it's rewriting

These days I see it as a rewrite.

Internal material exists to let the system continue working. Public articles exist to be read by people. The first needs enough operational context. The second needs that context distilled into understandable experience. Both matter, but they can't be mixed.

That's also why I preview locally before I finish writing now. Just reading the Markdown makes "this is fine" too easy. Once the page opens, problems show up: does it sound like me, is the title trying too hard, are there too many cards, is the type fatiguing, did a sentence overstate some internal state.

If it reads like a manual, I rewrite. If it reads like an internal report, I rewrite. If it reads like an AI-curated "best practice," I rewrite harder. YunLab.ai isn't a company website I'm packaging. It's more like a public experimental record I'm keeping for myself. Articles here can have structure, but they can't lose the personal trace.