# The AI Operating System Starter Kit

From "Applied AI for Marketing Ops" (appliedaiformops.com) by Lily Luo. This is a pared-down version of the system I run for my own work: the facts, standards, boundaries, and checks that persist between sessions, so every draft starts from what I have already decided instead of from nothing.

**Two ways to use this file:**
- **By hand.** Read it top to bottom and build the level your tools allow. Levels 1 and 2 are plain documents and work in any chat window.
- **Give it to your agent.** Paste this whole file to your AI agent and say "set this up for me." The last section is instructions for the agent.

---

Most people improve their AI results by rewriting prompts. That works for a while and then stops, because the prompt is only one of four layers that produce the output, and it is the one that resets every time you close the window.

This kit builds the layers that persist. It is a pared-down version of the system I run for my own work, arranged so you can stop at whatever level your tools allow.

## The four levels

Start at level one. Move up only when the level below is actually being used.

**Level 1. One file.** A single document with your verified facts and your standards, pasted into whatever tool you already have. Works in any chat window. No permissions, no setup, no IT conversation.

**Level 2. A folder.** Facts, standards, boundaries, and a rulings log, kept as separate files so they can be maintained separately. Point a project, a knowledge base, or a connector at it.

**Level 3. Routing.** An index that decides which of those files load for which kind of work, so a drafting task pulls your voice rules and nothing else. Needs a tool that can read files on demand.

**Level 4. Checks and automation.** Rules that run before you see a draft, a gate before anything goes out, and reviews that run in their own lanes. Needs a tool you can configure.

## Which level can you reach

This depends on the tool, not on your skill.

| What you are using | Highest level available |
|---|---|
| An assistant inside email or documents | Level 1 |
| A chat tool with projects or connectors | Level 2 |
| A tool that reads a folder you control | Level 3 |
| An agent platform you can configure | Level 4 |

Levels 1 and 2 are where most of the gain is. Levels 3 and 4 compound it.

## The files

| File | Level | What it is |
|---|---|---|
| 01-facts.md | 1 | What is verifiably true, and how precisely to state it |
| 02-standards.md | 1 | How you work and how output should read |
| 03-boundaries.md | 2 | What never goes out, and what needs approval |
| 04-rulings-log.md | 2 | Corrections you have made often enough to write down |
| 05-routing.md | 3 | Which files load for which kind of work |
| 06-checks.md | 4 | What gets checked before you see it |
| advanced/automation.md | 4 | Hooks, gates, and review lanes |
| advanced/keeping-it-clean.md | all | The audit habit, and why context rots |
| example/worked-example.md | all | A filled-in version of levels 1 and 2 |

## The one rule that matters most

Every correction goes in the log once, and never gets re-explained. If you find yourself giving the same feedback twice, that is the signal. Write it down and let it apply to everything after.

---

## `01-facts.md` (Facts)

Verified information about you, your team, or your work. Everything an AI system states about you should trace back to a line in this file.

Write facts precisely enough that they cannot be restated in a way you would not claim. This is the failure mode people hit first: a fact that is technically true but loosely written, which the system then overstates.

Here is the problem in practice. "Wrote first Python code two years ago" is true, and it produces output describing you as a programmer. What was meant was "uses AI and coding tools to build software." Same fact, different claim, and nothing in the file said which one was intended.

---

### Identity

- Role and scope:
- Years of experience, and in what:
- Where based:
- What you want to be known for:
- What you do NOT want to be described as:

### Track record

For each item: what it was, what you did, what resulted, and how precisely the number can be stated.

| What | Your role in it | Outcome | How to state it |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |

### Numbers

Only numbers you can defend. Mark the ones that are approximate.

| Figure | Exact or approximate | Source | Last verified |
|---|---|---|---|
|  |  |  |  |

### Timeline

Dates matter, because a system will infer sequence and get it wrong.

| When | What happened |
|---|---|
|  |  |

### True but easy to overstate

The facts most likely to get inflated, with the correct framing next to each. This table prevents more bad output than any other part of the kit.

| The fact | How it must be framed |
|---|---|
|  |  |

### Not true, and worth saying so

Assumptions people or systems make about you that are wrong. Stating these explicitly stops them being repeated.

-

---

## `02-standards.md` (Standards)

How work should read and how it should be done. This is the layer that makes output sound like you or your team instead of like everyone else.

Split it in two, because the halves behave differently. Mechanical rules can be checked automatically. Judgment cannot, and pretending otherwise is how you get output that passes every rule and still sounds wrong.

---

### Mechanical rules

Things with a yes or no answer. These are the ones worth automating at level 4.

**Never use:**
-

**Always use:**
-

**Formatting:**
- Headings:
- Lists versus prose:
- Numbers and units:
- Links and citations:

**Banned words and phrases, with the reason:**

| Banned | Why |
|---|---|
|  |  |

### Judgment

Things you can describe but not test for. Write them anyway, because they steer output even when nothing can verify them.

- The test for any sentence:
- What good looks like:
- What trying too hard looks like:
- How much hedging is right:
- Register: who you are talking to, and how you would say it out loud:

### Examples

The most useful section, and the one most people skip. Two or three real before and after pairs teach more than a page of rules.

**Example 1**

Weaker version:

> 

Better version:

> 

Why:

**Example 2**

Weaker version:

> 

Better version:

> 

Why:

### What this file cannot do

Note the things you know you have not managed to write down. It is a useful reminder that the last edit is always yours.

-

---

## `03-boundaries.md` (Boundaries)

What must never appear in output, what needs approval first, and what is deliberately allowed. Boundaries are separate from facts on purpose, because something can be true and still not publishable.

Keep this file short and absolute. Ambiguity here is what produces contradictions later.

---

### Never appears

- Confidential or internal information:
- Named individuals:
- Financial figures:
- Client or customer names:
- Anything under agreement or policy:

### Needs approval before it goes out

| Type of content | Who approves | What they check |
|---|---|---|
|  |  |  |

### Deliberately allowed

State these explicitly. Without them a cautious system will strip things you actually want published, and you will not know why it happened.

| Allowed | Note |
|---|---|
|  |  |

### When two sources disagree

Name the winner in advance. This is the most valuable line in the file.

- If facts and boundaries conflict, boundaries win.
- If two documents state different versions of the same fact, the canonical source is:
- Who resolves a conflict this file does not cover:

### Posture

Not rules about content, but about how you position.

- Never claim:
- Never position as:
- Never compare against:

---

## `04-rulings-log.md` (Rulings log)

Corrections you have given often enough that they should apply automatically. This is the file that makes the system compound instead of resetting every morning.

The habit: when you correct AI output, ask whether the correction is one off or general. One off corrections just get made. General ones come here, dated, with the reason and your actual words where you have them.

Review this log whenever you update your standards file. Rulings that keep recurring should graduate into 02-standards.md as rules.

---

### Format

Copy this shape for each entry.

**Date and short name**

- What happened: the output that triggered it
- The correction: what it should have been
- The rule going forward: stated so it applies beyond this one case
- Scope: everything, or one channel, or one document type

---

### Log

**2026-00-00, example entry, replace me**

- What happened: the draft opened with a rhetorical question as a hook.
- The correction: opened with a specific thing that happened last week instead.
- The rule going forward: no rhetorical questions as openers. Start with something real.
- Scope: everything published.

---

### Real entries from my log

Replace these with your own. They are here so you can see what real entries look like, including the last one, which is a correction that did NOT become a rule.

**2026-07-11, em dashes**

- What happened: drafts kept using em dashes as the connector between clauses.
- The correction: "wherever there is an em dash, replace it... too many."
- The rule going forward: no em dashes. Commas or periods instead.
- Scope: everything, including chat replies.

**2026-08-12, consultant abstractions**

- What happened: a draft reply was full of slideware phrasing, abstract talk of axes and bottlenecks instead of the actual thing.
- The correction: "get rid of this and use plain speak."
- The rule going forward: name the actual thing plainly. If a sentence could sit on any consultant's slide, rewrite it with the specific system, decision, or number.
- Scope: everything.

**2026-07-11, one canonical number**

- What happened: a draft cited a different years-of-experience figure than the one I use everywhere else.
- The correction: "that's what i've been citing everywhere else."
- The rule going forward: every fact has one canonical number, stated in the facts file. Drafts use it or leave it out.
- Scope: everything published.

**2026-08-12, a rejected rule, kept as a reminder**

- What happened: after a "way too long" note on one draft, a standing rule was proposed: replies default short.
- The correction: rejected. "depends... on the content and what im replying to."
- The lesson: not every correction generalizes. Log the one-off, but only promote it to a rule when it holds across cases. That discipline is what keeps the log trustworthy.

> **Ask your AI:** paste your last three corrections into the format above and ask, "which of these are one-off fixes, and which should become standing rules?"

---

### Recurring misses

If the same correction shows up here more than twice, the system is not picking it up. Note it and find out why, because the fix is usually in routing rather than in the rule.

| Correction | Times repeated | Why it is not sticking |
|---|---|---|
|  |  |  |

---

## `05-routing.md` (Routing)

Level 3. This file tells a tool which of your files to load for which kind of work, instead of loading everything every time.

Two reasons it matters. Loading everything is expensive, and most of it is irrelevant to any given task. And a system handed ten files will weight them roughly evenly, which means your most important standards get diluted by things that do not apply.

Put this at the front of your folder, named whatever your tool looks for.

---

### Routing table

| If the work is about | Load |
|---|---|
| Anything written in my name | 02-standards.md, then 04-rulings-log.md |
| Anything factual about me or my work | 01-facts.md |
| Anything going outside the company | 03-boundaries.md, and run the checks |
| Internal drafts and working notes | 02-standards.md only |
| A specific project | that project file, plus facts |

### A grown example

My own table after two months of use, trimmed of the rows I keep private. Yours will start smaller and grow the same way, one row per kind of work you actually do.

| If the work is about | Load |
|---|---|
| Voice, tone, anything published in my name | standards file, then the rulings log |
| What can be public, and how I am positioned | boundaries file |
| Visual design, palette, typography | design file |
| A specific project | that project's file |
| Past decisions and why | decisions file, plus the rulings log |
| What is live right now, open loops | injected automatically at session start |
| Publishing anything outward | staging file first, then the publish gate |

Two things worth copying. Some rows exist in my real table that are not shown here, because those areas are private; private files get a row so the system knows they exist, and a rule that they never load automatically. And the last row is a gate, not a file: nothing outward-facing goes out without staging and an explicit yes.

> **Ask your AI:** "Here are the five kinds of work I do most weeks: [list them]. Draft my routing table, then tell me which file each row needs that I have not written yet."

### Standing rules

Rules that apply no matter what else is loaded. Keep this list very short, because everything here competes for attention with the actual task.

1. Every factual claim must come from the facts file. If something is missing, leave it out rather than filling the gap.
2. Boundaries are binding, not advisory.
3. When two sources disagree, say so rather than picking one silently.
4.

### Defaults

- Loaded on every task:
- Never loaded automatically:

### Adding a new area of work

1. Create the file.
2. Add a row to the routing table above.
3. Note inside the file what it is for and what it is not for.

---

## `06-checks.md` (Checks)

Level 4. What gets verified before you ever read a draft.

The point of a check is not to judge quality. It is to catch the things you have already decided, so your attention goes to the things you have not. A check that tries to score quality will rank your best work badly, because the parts that make work good are the parts you could not write down.

Keep machine results and your own read in separate columns. Never blend them into one number.

---

### Mechanical checks

Run automatically, before you read anything.

| Check | What it looks for | Blocks or warns |
|---|---|---|
| Banned phrases | Terms from 02-standards.md | Blocks |
| Formatting | Heading style, list style, units | Warns |
| Boundary scan | Anything from 03-boundaries.md | Blocks |
| Claim tracing | Facts not present in 01-facts.md | Blocks |

### Human review

What only you can assess. Writing these down makes review consistent instead of mood dependent.

- Does it sound like us:
- Is it specific where it matters:
- Is the most important thing first:
- Would I put my name on it:
- How much editing did it need, and where:

### The scorecard

| Draft | Mechanical result | Human read | Editing needed | Decision |
|---|---|---|---|---|
|  |  |  |  |  |

### Calibrating a check

A check is miscalibrated when it disagrees with you repeatedly.

- If it blocks things you would ship, the rule is too broad. Narrow it.
- If it passes things you reject, the rule is not measuring the thing you care about. Find what is.
- If one small violation swings the whole result, the weighting is wrong.

Log every calibration change in 04-rulings-log.md. A check is part of the system and drifts like everything else in it.

---

## `advanced/automation.md` (Automation)

Level 4, for tools you can configure. None of this changes the model. It changes what the model can reach, when it reaches it, and what has to pass before anything gets to you.

---

### What runs on its own

**On startup.** Load the current state before any work begins: what is live right now, what is open, what standing corrections apply. Without this, every session starts by asking you what is going on.

**Before you see a draft.** Run the mechanical checks from 06-checks.md. Fix what is fixable, and flag what is not, so your first read is about substance rather than about catching a banned phrase for the tenth time.

**Before anything leaves.** A gate. Nothing outward facing goes out without passing the boundary scan and getting an explicit yes from a person. Drafts never send themselves.

**At the end of a session.** Capture what was corrected. That capture is what feeds 04-rulings-log.md, and it is the difference between a system that learns and a folder of stale files.

### Review lanes

Run reviews as separate passes with separate jobs rather than one general "review this." A single reviewer asked to check everything checks nothing thoroughly.

| Lane | Question it answers | Blocks |
|---|---|---|
| Standards | Does this follow the written rules | Yes |
| Facts | Does every claim trace to a source | Yes |
| Boundaries | Is anything here not publishable | Yes |
| Read | Is this actually any good | Human only |

The first three can be automated. The fourth cannot, and should never be given a score that gets averaged with the others.

### A working check to start from

A real check is about thirty lines, not a platform. This one is a trimmed version of the linter I run on my own drafts: it scans a file for the mechanical rules you wrote in 02-standards.md and fails loudly with line numbers. Fill in BANNED with your own rules; the three shown match the worked example.

```js
// check.mjs  -  run with: node check.mjs <file>
// Each BANNED entry is [pattern, reason]. Take them from your 02-standards.md.
import { readFileSync } from "node:fs";

const BANNED = [
  [/\u2014/g, "em dash, use a comma or period"],
  [/\bleverag(e|ed|ing)\b/gi, "leverage as a verb"],
  [/\bbest in class\b/gi, "hype phrase"],
];

const file = process.argv[2];
const lines = readFileSync(file, "utf8").split("\n");
let hits = 0;
for (const [i, line] of lines.entries()) {
  for (const [pattern, reason] of BANNED) {
    pattern.lastIndex = 0;
    if (pattern.test(line)) {
      console.log(`line ${i + 1}: ${reason} -> ${line.trim().slice(0, 80)}`);
      hits++;
    }
  }
}
console.log(hits ? `FAIL ${file}, ${hits} hit(s)` : `PASS ${file}`);
process.exit(hits ? 1 : 0);
```

Where it runs depends on your tool. If your platform supports hooks, run it automatically after every draft write, and again at the gate before anything goes out. If it does not, run it by hand before you read a draft, which still moves the banned-phrase hunt off your first read.

> **Ask your AI:** paste this section and say, "take the never-use list from my 02-standards.md, turn each entry into the BANNED array, and set this up to run on every draft before I see it. Show me a failing example so I know it works."

### Permissions

Decide what the tool is not allowed to touch, and enforce it rather than requesting it.

- Folders that are off limits:
- Actions that always need confirmation:
- Anything that sends, publishes, or deletes:

### What not to automate

- Deciding whether something is worth publishing.
- Resolving a contradiction between two of your own sources. Surface it, do not let it be resolved silently.
- Anything where being wrong is expensive and being slow is cheap.

---

## `advanced/keeping-it-clean.md` (Keeping it clean)

Context does not stay accurate on its own. It accumulates, and accumulation is how it goes wrong.

Every file in your system was correct when you wrote it. Then the work changed, you added another fact, and at some point two entries began to disagree. Nothing announces this. You find out when the output is subtly wrong and you cannot work out why.

---

### The audit habit

Once a month, or after any significant change in the work, check for four things.

**Conflicts.** Two files stating incompatible versions of the same thing. These are the expensive ones, because a system will pick one silently and never tell you which.

**Staleness.** Facts with dates attached, numbers that have moved, roles that have changed, rules that were retired but never deleted.

**Drift.** Standards that describe how you used to work rather than how you work now.

**Bloat.** Files that grew past the point of being read. If a standards file is long enough that a person would skim it, a system effectively skims it too.

### Where conflicts come from

At an individual level, from adding without removing.

At a team level, from something harder. Your positioning document, your messaging document, your brand guidelines, and whatever was actually approved were written by different people at different times for different reasons. Some of them contradict each other right now, and nobody has had to reconcile them because no single person ever read all four at once. A system does read all four at once.

### The rule that prevents most of it

Every fact has one canonical home. If a number appears in three files, two of them are copies waiting to go stale. Reference the source instead of restating it.

### Signals something is wrong

- The same correction keeps coming back.
- Output is confidently wrong about something you thought you had documented.
- A check blocks something you would ship, or passes something you reject.
- You find yourself explaining context in the chat window that already exists in a file.

That last one is the clearest signal. If you are re-explaining, the routing is not working, or the file is not being read.

### Test it against real output

The only reliable way to find a bad rule is to run it against real work rather than a test case. I found a check in my own system that was enforcing a rule I had retired weeks earlier, and I only found it because it blocked something I knew was fine.

---

## `example/worked-example.md` (Worked example)

A filled-in version of levels 1 and 2 for a fictional revenue operations lead, so you can see the shape before you write your own. Everything here is invented.

---

### 01-facts.md, filled in

**Identity**

- Role and scope: leads revenue operations for a mid market B2B software company. Owns the CRM, the marketing automation platform, and reporting.
- Years of experience: eleven, all in B2B operations.
- What I want to be known for: fixing the systems underneath the numbers, not just reporting the numbers.
- What I do NOT want to be described as: a data analyst, or a Salesforce administrator.

**True but easy to overstate**

| The fact | How it must be framed |
|---|---|
| Ran a CRM migration | Led the migration. Did not build the integrations. Say "led," never "built." |
| Reduced reporting time by 70 percent | For one weekly executive report, not for reporting overall. Always name the report. |
| Manages a team of four | Three direct reports and one contractor. Say "a team of four including a contractor." |

**Not true, and worth saying so**

- I do not write production code. I build with low code tools and AI assistance.
- I do not own the sales forecast. I own the data it runs on.

---

### 02-standards.md, filled in

**Never use:** "leverage" as a verb, "best in class," "seamless," exclamation marks in anything external.

**Always use:** the specific system name rather than "the tool." Numbers with their timeframe attached.

**The test for any sentence:** would I say this out loud in a status meeting without feeling like I was presenting.

**Example**

Weaker version:

> We leveraged best in class automation to seamlessly streamline the lead handoff process, resulting in significant efficiency gains.

Better version:

> We moved lead routing from a manual queue into an automated one. Handoff time went from about two days to under an hour, measured over Q3.

Why: the second one names the system, the change, the number, and the period. The first could describe any project at any company.

---

### 03-boundaries.md, filled in

**Never appears:** customer names, revenue figures, anything from a board deck, the names of anyone on my team.

**Deliberately allowed:** my job title and employer, order of magnitude metrics such as "roughly a thousand records," the names of tools we use publicly.

**When two sources disagree:** boundaries win over facts. The canonical source for any metric is the reporting file, not the slide it was copied into.

---

### 04-rulings-log.md, filled in

**2026-03-11, name the timeframe**

- What happened: a draft said "reduced reporting time by 70 percent" with no period attached.
- The correction: added "for the weekly executive report, measured over Q3."
- The rule going forward: every percentage carries what it applied to and over what period.
- Scope: everything, internal and external.

**2026-04-02, no team names**

- What happened: a draft named a direct report in a public post.
- The correction: described the role instead.
- The rule going forward: never name anyone who reports to me in external content, even positively.
- Scope: anything published.

---

### What this bought

Before: every draft started from nothing, and the same three corrections went in every time.

After: drafts arrive with the timeframe already attached and no names in them. What is left to review is whether the thing is any good, which is the part that was always mine anyway.

---

## For your AI agent

If your user pasted this whole file and asked you to set it up, do this:

1. Create a folder named `ai-os` (or the name they choose) with this structure:

```
ai-os/
  05-routing.md      <- put this first in any tool that reads files in order
  01-facts.md
  02-standards.md
  03-boundaries.md
  04-rulings-log.md
  06-checks.md
  advanced/
    automation.md
    keeping-it-clean.md
  example/
    worked-example.md
```

2. Split each backtick-named file section above into its own file, keeping the templates blank. Do not fill them in from what you know or assume about the user. The sections marked as the author's real entries and real routing table are worked examples: keep them visible as reference, but the user's own log and table start empty.

3. Interview the user to fill in `01-facts.md` first, one section at a time. Push for precision: for every fact, ask how it must be framed so it cannot be overstated. Use the worked example as the model.

4. Then `02-standards.md`, starting from real before and after examples of their own writing.

5. Stop there. `03-boundaries.md` and beyond are for a second session, after levels 1 and 2 are actually in use.

6. If the user's tool supports startup instructions (a CLAUDE.md, a system prompt, project instructions), point it at `05-routing.md` and nothing else.