The strategy behind it was precise: use publication as the primary IP defense. Write it up first, it becomes prior art. Prior art places the specific disclosed approach in the public domain, limiting what anyone can later claim exclusive patent rights over. That trade, surrendering exclusive claims on a specific method in exchange for establishing it as prior art, is the right one for a system designed to produce on a cadence. The factory thesis only holds if the factory actually ships artifacts, not just builds them.
So I committed to publishing everything. Articles about orchestration patterns. Notes on how distributed agent systems fail. Pieces on the engineering decisions that make something work in production versus in a demo. All of it written to describe what the system does and why, not to expose the specific implementation details that give it its real value. For a while it felt clean.
Then I sat down to write about how the decision routing worked, specifically, the criteria the system uses to choose which oracle panel handles which class of judgment call. Good content. Defensively valuable. Clearly prior art.
But then I noticed I was about to describe the exact weighting logic. Not a high-level description. A real, operational one that would let someone reconstruct a significant chunk of proprietary decision infrastructure.
That is not prior art. That is a manual.
I stopped. I did not delete it. I did not publish it. I put it down and left it there, waiting for a principle I did not have yet.
Why Gut Feel Does Not Scale
I held the piece. Rewrote the technical section three times. Each draft landed in the same trap: either too vague to be worth publishing, or specific enough to be genuinely risky. The cycling was not random. It was the same two failure modes in rotation, and there was no third option visible from inside the loop. The piece sat. The pipeline backed up behind it. Other pieces, cleaner ones, finished and waited because this one had not moved. Something locked upstream stays locked.
The problem is that "don't publish secrets" sounds like a policy but is not. It is a platitude. Real publishing decisions almost never sit at the obvious extremes. They live in the gray zone, and gut feel in a gray zone is just anxiety with a deadline attached.
What broke the loop was not inspiration. It was frustration with the binary. The gate I had been applying was safe/unsafe, a coin flip on every edge case. Binary forces every edge case to land somewhere that does not fit. The right frame is not a gate but a spectrum with named zones, each with clear markers you can actually apply to a draft.
I landed on four zones. The taxonomy is not original. Tiered sensitivity classification appears in information governance, compliance, and IP risk management across any field that has had to process sensitive material at scale. What made it workable for this pipeline was one practical question that could run fast, without requiring a human judgment call on every draft: is this describing what the system does, or how it does it? That question draws the Framed-to-Gated line reliably enough to handle most cases.
Public captures what the system does at a level that establishes prior art without exposing construction. The observable behavior, the user-facing capability, the category of problem solved. Almost everything here can publish, and it should.
Framed covers something proprietary that can publish with the framing adjusted. Pull the implementation specifics, keep the capability description. The decision oracle architecture can publish as "a local panel that routes judgment calls by domain." The exact panel composition does not need to be in the piece. Same prior-art value, different exposure profile.
Gated is for material where the honest answer to one question is yes: could a direct competitor read this and replicate or directly counter the specific capability within six months? If yes, framing alone does not resolve it. These pieces do not publish now. They go back to the backlog with a condition: resurface when the category stops being differentiating, or when a defensive-publication reason outweighs the exposure. Not killed, just parked with a concrete trigger.
Never is hardcoded. Client identifiers. Internal team structures. Credential flows. Anything that reveals how the system exploits a specific integration surface. These do not cross the wall under any framing, no matter how the piece is positioned.
The what-versus-how question made classification fast in practice. A piece describing "a dual-oracle convergence loop that drives artifacts to a quality bar" is a what-level description. A piece describing the exact prompt structure, the confidence thresholds, the fallback logic when oracles diverge, that is how-level, a different zone entirely. Same topic, two different classification outcomes. The zones give you a place to land. The question gives you a direction to travel.
Three Gates, Not One
The classification does not run once at the end. It runs at three points in the pipeline.
Before drafting. The seed pitch for a piece goes through a zone check before any writing starts. If the pitch itself is Gated or Never, the piece does not start. No point drafting something that cannot ship.
After the first draft. This is where most of the real work happens. A good author agent writes to the capability, but it does not always know which details cross from Framed into Gated. Reading the draft with the rubric in hand, the check is specific: does this paragraph describe a capability, or does it describe a construction?
After humanization. The humanizer changes words and cadence, not intent, but paraphrase can sharpen a vague description into a specific one without meaning to. A final pass after humanization catches those slips before they reach the output queue.
Three points because classification is not static. A draft can gain specificity at any stage. The rubric runs at each handoff.
The Thing That Surprised Me
I expected the rubric to slow things down. Another gate, another reason for a piece to sit in review longer.
It did the opposite.
The slowness before the rubric came from gray-zone anxiety. Finish a piece, spend days uncertain whether something in there crossed a line. Or hold pieces back indefinitely because the uncertainty never resolved. Or water them down until they lost the point.
Once the zones existed, classification got fast. Most drafts are clearly Public or Framed within a single read. Gated material flags quickly. There is usually one paragraph that reads like a technical specification when everything around it reads like a concept description. Pull that paragraph, reframe or drop it, done.
The rubric did not add bureaucracy. It replaced ambiguity with a decision procedure. A decision procedure, even a lightweight one, is dramatically faster than ambiguity.
That original piece, the routing-criteria draft I could not publish and could not delete, finally found a path once the zones existed. Not because anything in the draft changed fundamentally. Because I could now see it clearly. The routing criteria are what-level content. The weighting logic is how-level. One published. The other stayed inside. Three rewrites that had gone nowhere became one rewrite with a named target. The piece shipped. The pipeline moved. The thing that had been sitting there for weeks was gone in an afternoon.
The IP firewall is not a fence. A fence keeps everything in or keeps everything out, neither of which works for a publishing strategy that needs to produce real output on a real cadence.
It is a filter. Different mesh sizes for different material. Most things pass through. Some things need reshaping to pass. A small set does not pass at all.
That is the design. Fences create bottlenecks. Filters maintain flow.