The Per-Line Audit: A 15-Minute Exercise for Any AI System

How to find the instructions your AI system no longer needs

---

Summary

Every AI system accumulates instructions over time. Some of those instructions made sense when they were written. Some still do. Many do not. The per-line audit is a fast, practical exercise for identifying which instructions are earning their place and which are costing you clarity, tokens, and results. It takes fifteen minutes. It works on any system prompt, from a personal assistant to a production agent.

Key Points

• AI system prompts accumulate procedural debt over time
• Each instruction falls into one of three categories: outcome specification, persistent constraint, or compensatory scaffolding
• Compensatory scaffolding is the subtraction target
• Removing unnecessary instructions often improves results rather than degrading them
• The audit is a repeatable exercise, not a one-time cleanup

---

Introduction

If you maintain an AI system, you have a system prompt. If you have a system prompt, it has grown.

This is normal. You wrote an instruction because the system did something wrong. You added a clarification because a user reported a confusing response. You specified a procedure because the output was inconsistent without it. Each addition solved a real problem at the time it was written.

The question is whether those problems still exist.

AI systems improve. The capabilities available to you today are not the capabilities you had when you wrote most of those instructions. But the instructions remain, and they carry costs that are easy to underestimate: longer context windows consumed by guidance the system no longer needs, procedural constraints that prevent the system from using its own judgment, and accumulated complexity that makes every future change harder.

The per-line audit is a way to find out what you can safely remove. It takes fifteen minutes. You can do it on any prompt you control.

The Three Categories

Every instruction in a system prompt does one of three things:

1. Outcome specification. It describes what the result should look like, what success means, or what the user needs. These are the instructions that tell the system what and why.

Examples: "Respond in the user's language." "Summarize the key findings in three bullet points." "The report should include both quantitative data and qualitative assessment."

2. Persistent constraint. It defines a boundary that should hold regardless of how capable the system becomes. These are business rules, safety requirements, and quality standards that exist because of the domain, not because of the model.

Examples: "Never disclose customer financial data." "Always cite the source when referencing published research." "Responses must comply with our accessibility guidelines."

3. Compensatory scaffolding. It tells the system how to do something because, at the time the instruction was written, the system could not figure out the right approach on its own.

Examples: "First classify the intent into one of 14 categories, then route to the appropriate handler." "Retrieve the top five knowledge base articles using hybrid search before generating a response." "Check your response for hallucinated URLs before returning it."

The first two categories are durable. They describe what you want and what you require. They survive capability improvements because they are about your goals and your constraints, not about the system's limitations.

The third category is your subtraction target.

A Quick Example

Here is a fragment from a system prompt, classified:

[O] Respond in the user's language. [C] Never disclose customer financial data. [S] First classify the user's intent into one of 14 categories. [S] Then retrieve the top 5 knowledge base articles using hybrid search. [S] Check your response for hallucinated URLs before returning it. [O] The customer should leave the interaction satisfied that their issue was resolved.

The two O lines and the C line stay. They describe what you want and what must not happen. The three S lines are candidates for removal. Try replacing them with nothing. If the system still classifies, retrieves, and avoids hallucinations without being told to, those instructions were overhead.

Running the Audit

Set aside fifteen minutes. Open your system prompt. Read it line by line. For each instruction, ask one question:

Is this here because the system needs it, or because I needed the system to need it?

Mark each line with its category: O (outcome), C (constraint), or S (scaffolding).

Do not remove anything yet. Just classify.

When you reach the end, count your marks. In most system prompts that have been maintained for more than a few months, the scaffolding category often accounts for a substantial portion of the total instructions. This is not a failure. It is the natural result of building on top of earlier capabilities.

The Subtraction Test

Now take the lines marked S. For each one, ask:

1. Is this procedure something the system could figure out on its own if I just specified the outcome? If the instruction says "first do X, then do Y, then do Z to achieve W," try replacing the entire sequence with "achieve W." Test whether the result is comparable or better.

2. Is this instruction compensating for a problem I have not seen recently? If you added a check for hallucinated URLs eighteen months ago and have not seen the problem since, it may no longer be necessary. Remove it. Test. Revert if the problem reappears.

3. Is this instruction duplicating something the system already does reliably? Many older prompts include instructions for capabilities that have become default behavior. Instructions to "be concise" or "use proper grammar" were useful in earlier generations. They are rarely necessary now.

For each scaffolding line, either remove it or convert it. Converting means rewriting a procedural instruction as an outcome specification. Instead of "first classify the intent, then retrieve articles, then generate a response," write "resolve the customer's issue using our knowledge base and policies."

What to Expect

Two things typically happen after a per-line audit.

First, the system prompt gets shorter. This is good for cost efficiency, but it is not the main benefit.

Second, the system's output often improves. Removing procedural scaffolding gives the system room to apply its own judgment about how to accomplish the outcome. In many cases, the system's own approach to achieving the outcome may be more effective than a fixed procedure written for an earlier capability level.

This is counterintuitive if you are accustomed to thinking of instructions as insurance. But instructions that constrain a capable system to a less capable system's workflow are not insurance. They are overhead.

Making It Repeatable

The per-line audit is not a one-time cleanup. It is a practice.

Run it whenever you update a system prompt. Run it when you adopt a new model version. Run it quarterly on production prompts. Each time, you will find instructions that were appropriate before and are no longer necessary.

Over time, you will develop an instinct for what belongs in a system prompt and what does not. Outcomes and constraints stay. Procedures leave, replaced by better organized context and clearer success criteria.

That instinct is the discipline.

Conclusion

Every instruction in your system prompt is either earning its place or consuming resources without delivering value. The per-line audit gives you a concrete, repeatable way to tell the difference.

The exercise is simple: classify each line as outcome, constraint, or scaffolding. Test removing the scaffolding. Keep what is necessary. Remove what is not.

If you find that a significant portion of your prompt is scaffolding, you are not alone. That is the natural result of building on capabilities that keep improving. The per-line audit is how you keep your system current with those improvements rather than locked to the version you designed for.

Fifteen minutes. One prompt. Start today.

---

The Exercise

Time required: 15 minutes

What you need: One system prompt you control (personal or production)

Steps:

1. Open the prompt. Read it line by line.
2. Mark each instruction: O (outcome), C (constraint), or S (scaffolding).
3. Count the marks. Note the ratio.
4. For each S line, ask: could I replace this with an outcome specification?
5. Remove or convert the S lines. Test the result.
6. Revert anything that degrades output. Keep everything else removed.

What to track: Before/after prompt length. Before/after output quality on your most common use cases.

---

This article is part of the Subtraction Discipline series on Adaptivearts.ai.

Next: The Subtraction Discipline - a complete framework for designing AI systems by removing what you do not need.