Corp-OS

What it is

Corp-OS is a Claude plugin. It is 23 skills that operate on a folder of markdown files on your own disk. The folder is the knowledge base. The skills are what put things into it, turn them into statements you can cite, get them back out with their provenance attached, and take things out again when they stop being true.

There is no database, no server, and no account. If every part of this disappeared tomorrow you would still have a folder of markdown you could read with cat in ten years, which is the only durability guarantee that has ever actually held.

The problem it is built around

Most personal knowledge systems are organized by subject: a folder per topic, a note per person. They only ever grow. Nothing in them ever expires. After a few months nobody trusts them enough to look, and the reason that happens is worth being precise about.

It is not that the notes are wrong. It is that you cannot tell which ones are. Every individual entry still looks reasonable. A pricing note from March reads exactly like a pricing note from last week, and the system has no opinion about which one you should believe. So you stop believing any of it, and the thing you built to save time becomes a place you visit to confirm what you already remembered.

The fix is not better note-taking. It is a system that knows when it is out of date and says so.

Five things that are not configurable

Almost everything about Corp-OS is declared rather than assumed. Layer names, label vocabularies, how long things stay fresh, how strict the review step is, even the organizing idea itself: all of it lives in a config file that every skill reads before it does anything, and all of it is meant to be changed.

Five properties are not, because everything else rests on them.

A day with it

Something gets said in a meeting. It goes into the raw layer, either pulled from a registered source or handed over directly, and it goes in as it was said rather than as a summary. Later you work the queue: each candidate becomes a proposal with its kind, its confidence, and a verbatim citation attached, and you confirm, decline, defer, or modify. Declines are kept, because the record of what you deliberately chose not to know is frequently the most useful thing in the file.

Then you get value back out. A question gets an answer with citations. A recurring brief says what moved, what needs a decision, and what went stale. A dashboard is a page you return to, built by a script that recounts what is actually on disk rather than by a model writing numbers into markup.

Once a month or so, you sweep. Claims past their window, claims never verified, contradictions, and assumptions that have quietly been promoted to facts.

What building it actually taught me

This is the part I would want to read.

Past a certain point, more instruction stops buying reliability

The redaction skill is supposed to write two files: the cleaned copy and a private log of exactly what was removed. Across five test runs it produced that log under four different names, and once not at all. The instruction to write it was present, concrete, explained, and had already been strengthened twice.

The retention-delete sequence was the same story. It held at 67% after two instruction passes, the second of which said never edit the original into a tombstone in as many words, and one run in three still did exactly that.

So the step stopped being something to remember. A script now writes both files together and refuses to write one without the other; another performs the delete sequence in the right order. With the script, that 67% became 8 out of 8.

The rule that came out of it, which I now apply everywhere:a step that has to happen every time, that nothing else will catch if it is skipped, belongs in code rather than in an instruction. Eleven scripts exist for that reason. None of them exercises judgment. That stays with the person.

A model that only ever confirms itself is not measuring anything

Corp-OS organizes work around jobs to be done, which is its best idea and is wrong for some people. It pays off when the same questions get re-asked and the same evidence re-gathered. It costs more than it returns when the work is mostly reference accumulation.

So the audit skill runs an actual test before recommending it: cluster the existing material into candidate jobs without looking at the subject taxonomy, then compare. If the clusters just reproduce the taxonomy that already exists, the material is subject-shaped, and the audit says to leave the jobs layer off. A model that cannot argue against its own best idea is not giving you information.

The tests found things that reading never would

There are three harnesses at three different costs, because a loop you can run in a minute is a loop you stay inside and a thirty-minute one is a loop you leave.

The first real conformance run found the intake skill doing four of its five required outputs, four runs out of four, with the fifth missing every time. It found a four-release-old contradiction where the spec said raw files are never edited while three skills instructed editing them, which nobody had noticed because it gets read in whichever direction you arrive from.

Then it found something worse about itself. Every conformance figure before v0.11.0 was void: the harness auto-approved file edits and nothing else, so not one shipped script had ever actually executed inside a test run. The file-level results were real, but what produced them was never measured, because a model told to run a script and blocked from doing so writes the result by hand. That cost six runs and three instruction passes chasing a failure that was the instrument the whole time.

The best one came last. A test written to check something else entirely found that the skill whose whole job is removing stale knowledge had never had a review gate, in any release, going back to the first. Three of four runs rewrote the derived layer with no proposal behind it, one of them across fourteen files. Nobody reading it had caught that, in any release. One run of a test did.

Publish what still fails

Every skill now has a conformance case, and the suite figure is 203 of 208 checks across 28 cases, one run each. The five that failed are on the record rather than reworded until they sound fixed. One was the harness asserting the wrong thing, reading the OS's own capture rule as a fabricated source, and that assertion was replaced. Four are real, in two skills: the guide skill opens a decision itself instead of handing it to the decision skill, a hand-off that passed two releases ago and has regressed since, undiagnosed; and recall dropped a load-bearing sensitive fact, which has scored one in four, then seven of seven, then this. That one is a rate, not a state, and it is the highest-stakes check in the suite, so it stays at the top of the backlog.

A wording pass meant to improve a hand-off once measured 0 out of 2 and got reverted, because prose that does not move the number is churn.

A test that has never been wrong about what it measures has not been looked at hard enough, so when an assertion turned out to be wrong about the skill rather than the other way around, it got corrected on the record with the evidence attached. That happened eight times.

Measure what a run costs, too

The same instinct applied to the bill. In a real session breakdown, 54% of tokens went to the per-turn prefix, the system prompt and every loaded tool schema re-sent on every turn, and reading files was under 9%. So the expensive things are turn count and what is loaded, not what a skill reads. Filing forty items moved from forty turns of arithmetic into one script. Measured against a real 852-claim OS rather than the fixture, the per-run pre-flight floor went from 9,508 to 5,501 tokens, and one generated index went from 14,943 to 244. The things that did not save money are written down next to the ones that did.

One field carrying three questions makes a specific thing invisible

Confidence started as a single value, and it was quietly answering three unrelated questions at once: how faithful is the recording, how many independent sources exist, and is this contested.

Measured in a real corpus: 599 of 836 entries sat one rung below the top because they were single-source summaries. Their full transcripts were still fetchable through the same connector that produced the summaries. One call. Zero had taken it, because a ceiling that is elective looked exactly like a ceiling that is permanent, so it got treated as permanent.

Splitting the medium out into its own field turned that into a sortable list of entries that are one call away from being stronger. Not a list of what is weak. A list of what is cheap to fix.

Sensitivity is two questions, and treating it as one made the system wrong

There is what must not leave, and there is whether the system can reason correctly without it. Those are different, and collapsing them into a single flag meant quarantining everything sensitive, which sounds safe and is not. When sensitive material is load-bearing, removing it from the working set does not produce a gap. It produces a confidently wrong answer with nothing in it to signal the omission.

Load-bearing sensitive material now stays where the system can see it, marked, and gets stripped at the boundary where things actually leave. That boundary is also the only place confidentiality was ever really enforced.

Anything stating a fact that is already true somewhere else will go stale

This project has caught that same defect five times: a file saying "both shipped scripts" three releases after there were four, a hard-coded version string that went stale within one release, a version recorded in six files with six different values, a layer counted wrong for five releases, and two README files stating a skill count that was four short.

So the reference page listing every skill is generated from the plugin at build time, and the build fails if it has drifted. The stated counts in the prose are checked against the directories on disk. The only thing declared by hand is the judgment a machine cannot derive, and the generator refuses to run until a person has supplied it.

Who it is wrong for

If your work is mostly reference accumulation, or is organized around long-lived subject areas that genuinely do not change, this will cost more than it returns and the audit will tell you so.

It assumes one operator. Sharing is an export event, not a mode: there is a step that produces a cleaned copy along with a private log of exactly what came out. That is deliberate, but it means this is not a team wiki and does not want to become one.

And the setup interrogation takes fifteen to twenty minutes. That is the deliverable as much as the folder is. A scaffold built without it produces a generic notebook that gets abandoned in a month, which is the thing this exists to avoid.

Try it

Install it as a Claude plugin:

/plugin marketplace add brentgann/corp-os
/plugin install corp-os@brentgann

Then ask for Corp-OS setup, or run /corp-os.

Updating has two halves, and doing the first does nothing to the second./plugin marketplace update brentgann replaces the skills. Asking forcorp-os-upgrade brings your own folder in line with them, because every Corp-OS carries its own copies of the shipped scripts so that it keeps working when the plugin is not loaded.

The source, the architecture record with every decision and its reasoning, and the eval results are all on GitHub. MIT licensed. The diagrams are also available as PDFs:architecture andskill map.

Corp-OS v0.27.0: 23 skills, 8 slash commands,18 scripts, 14 reference specs, 5 invariants. Routing accuracy 100% across 77 queries at 3 repeats. Conformance 203 of 208 checks across28 cases and 23 of 23 skills, one run each on 2026-09-10, so a baseline rather than a rate. Current as of September 2026.