The Craftsperson's Tools: Who Owns the AI Governance Docs You Built?

A carpenter who works at a cabinet shop builds cabinets that belong to the shop. That’s the deal — your labor, their product. When the carpenter leaves, the cabinets stay.

But what about the jigs? The fixtures the carpenter built — perhaps on his own time — to make their work faster, more precise, more repeatable? The muscle memory of a particular saw angle, the eye for grain direction, the instinct for how this type of joint responds in humidity?

That’s never been a question. The cabinets are the shop’s. The skill is the carpenter’s. The jigs occupy a gray area that usually resolves in the carpenter’s favor — because a jig without the person who built it is just a piece of wood with holes in it. The knowledge of when and how to use it lives in the carpenter’s head.

That distinction has held for centuries. The rise of Agentic AI (LLMs) is breaking it.

The jig that works without you

The previous post in this series argued that your AI governance frameworks — the CLAUDE.md files, the decision-making heuristics, the prompt patterns, the architectural preferences you’ve encoded into documents — are cognitive property. Your reasoning process, externalized into a transferable format.

So what makes that different from every prior version of “I take my skills with me when I leave?”

The carpenter’s jig is inert without the carpenter. It’s a tool that amplifies existing skill — useless to someone who doesn’t already know the craft, and possibly cumbersome at best to another carpenter with their own methods. A governance document is not inert. Feed it to a fresh AI instance and you get a functional version of how you solve problems. Not perfect, but operational. The tool works without you in a way that a carpenter’s jig never could.

That changes the ownership math. When the skill only existed in your head, the boundary was simple: work product belongs to the employer, expertise belongs to you. Nobody could take your expertise because it wasn’t extractable.

Now it is.

It’s sitting in one or more markdown files. And the question of who owns that file matters a lot more than it did when the equivalent knowledge was locked inside your nervous system.

The account boundary

The ownership question has a surprisingly clean heuristic. Not your laptop. Not your office. Not your work hours. The account.

If you’re building governance frameworks on a corporate AI account — the company’s subscription, the company’s workspace, administered by the company’s IT department — the company has a reasonable claim on what’s built inside it. That’s the cabinet shop. Their tools, their subscription, their infrastructure. The work product and the meta-work product (the frameworks that produce it) both live under their roof.

If you’re building on your own account — your subscription, your money, your personal workspace — that’s your workshop. The projects you deliver might belong to your employer, but the system you built to produce them is yours. The same way a freelance carpenter owns their personal tool collection regardless of which shop they’re currently working in.

The same principle has governed trade work for generations: the employer owns the output, the craftsperson owns the tools. The new variable is that “tools” now includes documented reasoning processes that function without you.

The counterargument that doesn’t hold

There’s a predictable objection: “You wouldn’t have developed those patterns if you hadn’t needed to for this job.” The argument being that the cognitive infrastructure is a derivative of the employment, and therefore belongs to the employer.

By that logic, everything you learn at any job is company property. The architectural patterns you internalized. The debugging instinct you developed. The leadership style you refined under pressure. Nobody seriously believes that — and courts have consistently upheld the distinction between work product and professional skill, even when the skill was developed entirely on company time.

The principle hasn’t changed. You own your expertise. What’s changed is the evidence. Before AI governance documents, your expertise was implicit — hard to quantify, impossible to transfer wholesale. Now it’s explicit. It’s a repo. And explicit things are easier to claim ownership of, in both directions.

Where you build matters more than when you build

Most employment agreements have an IP assignment clause. The standard version says something like: anything you create using company resources, during company time, or related to company business belongs to the company. These clauses were written for code and patents. They weren’t written for the cognitive infrastructure that produces code.

(I’m not a lawyer, and none of this is legal advice. But the legal landscape here is worth understanding even if you never end up in a dispute.)

There’s a meaningful legal distinction between “I built this feature for the company’s product” (clearly theirs) and “I developed a methodology for how I approach all engineering problems, which I also used while building features for the company’s product” (much less clearly theirs). The former is work product. The latter is professional development — it just happens to exist in a series of files now instead of only in your head.

Some jurisdictions have already drawn a version of this line. California’s Labor Code §2870 says an employer can’t force assignment of inventions developed entirely on the employee’s own time without using the employer’s equipment, supplies, or trade secrets. Courts have gone further — in Whitewater West v. Alleshouse, the Federal Circuit struck down assignment clauses that reached beyond active employment, and California law prohibits employers from claiming inventions created after employment ends. Not every state has these protections, and your jurisdiction matters. But the principle is established: own time, own resources, own tools.

The practical implication is uncomfortable but important: where you build your cognitive infrastructure matters. Not when, and not whether you were “on the clock.” Whether the account, the subscription, and the workspace belong to you or to your employer.

A developer who builds their CLAUDE.md and governance frameworks on their personal Claude account, using their personal subscription, and then applies that methodology at work — that’s a craftsperson using their own tools on the client’s project. The projects belong to the client. The tools come home with the craftsperson.

A developer who builds their entire cognitive framework inside a corporate-administered AI workspace — that’s a murkier situation. And most people aren’t thinking about which one they’re in.

The intentionality tax

None of this is automatic. The default — building everything in whatever account is most convenient, usually the corporate one — puts your cognitive property inside someone else’s infrastructure. Not because they’re trying to take it, but because you didn’t think about where you were building.

The carpenter who shows up to a new shop with their own tools doesn’t have this problem. They know which tools are theirs. The tools traveled with them from the last shop. There’s no ambiguity.

I pay for my own AI subscriptions. I’ve never asked for reimbursement, and I’ve declined when it’s been offered. The cost is the boundary. If the company pays for the subscription, the company has a reasonable claim on what’s built inside it. Owning the account keeps the ownership question clean — and the annual cost of a Claude subscription is trivially small compared to the value of the cognitive infrastructure I’ve built inside it.

When I work on company-owned repositories, the governance files travel with me but they don’t live there. Core methodology — the CLAUDE.md, the architecture docs, the task management structures — lives in my own repos, on my own GitHub account. What lands in the company’s codebase is either untracked, loaded via symlink from my personal infrastructure, or an intentionally minimal version that lets the project function without exposing how I think. The full methodology stays in my workshop.

Custom tools get built on personal time, on personal accounts. Small bugfixes during work hours, sure — the same way a carpenter might sharpen a blade between cuts. But the jig itself gets designed and built at home.

That’s the intentionality tax. It’s a real cost — maintaining two contexts, paying for your own tools, thinking about where every file lives. Most people won’t pay it. But the alternative is discovering the ownership question after someone else has already answered it for you.

The work product stays. The operating system comes with you.

The boundary is the same one it’s always been, updated for a new medium. You leave the cabinets at the shop. You take the tools.

But the tools have changed.

They’re not just muscle memory and instinct anymore — they’re documented, structured, portable cognitive frameworks that work without you in the room. That makes them more valuable, more extractable, and more worth knowing about.

I’m not telling you to go set up a separate account tonight. I’m telling you to look at what you’ve already built and know where it lives. The governance documents, the prompt patterns, the architectural preferences you’ve encoded into files that make your AI work like you — where are those? On whose infrastructure? Under whose terms of service?

The answer might be fine. But it should be deliberate.

The next post in this series is about what happens when that awareness comes too late — when your documented cognitive patterns become something a company can copy, scale, and redeploy without you in the room.

---

This is part two of a four-post series on cognitive property. The next post explores what happens when the boundary isn’t respected.

Employment law & IP

Understanding the Work Made for Hire Doctrine — Venable LLP. How courts distinguish employer-owned works from the employee’s underlying skills and know-how.

IP Clauses in Employment Contracts and Assignments — Briffa Legal. Overview of standard IP assignment clause patterns and the “in course of employment” test.

Employee invention statutes & case law

California Labor Code §2870 — Employee inventions developed on own time, without employer resources, can’t be force-assigned.

Employment Law and Patent Law Collide — Hunton Andrews Kurth. Federal Circuit strikes down overly broad assignment clauses in Whitewater West v. Alleshouse (2020).

California Law: Former Employer Cannot Require Assignment — Manatt, Phelps & Phillips. CA prohibits employers from claiming post-employment inventions.