Specification: the work before the prompt

The most useful work often happens before the prompt. It is the work of deciding what you want the system to do, what information it should use, and how you will recognize a result worth using.

I think of that work as specification. It gives the model, the prompt and the evaluation a shared job to serve.

Decide what the system should know and do

A specification describes the task before committing to an implementation. It names the relevant context, the intended user, the permitted actions and the conditions under which the system should stop.

The model you choose should fit that task. The context you provide and the prompt you write should express the same decisions.

This is my approach to specifying an AI system: define the task, operating boundary, evidence and tests before relying on its output.

Keep the specification when the implementation changes

A prompt is one way of expressing a task to a particular model. A specification records what the task actually requires.

That distinction gives you something stable to evaluate when you change models, prompts or retrieval methods. The implementation can change while the expected outcome remains explicit.

For an operator assistant, the requirement might be to answer from approved procedures, identify the relevant source page and stop when the source does not support an answer. Those requirements are useful regardless of which implementation you test.

Put process before technology

At the start of an AI project, I want the team to name the work, the owner and the evidence that will count as success. The same discipline is useful for a small task in a chat window.

If you are asking for a summary, specify its audience, the documents it may use and what must remain visible. If you are asking for a recommendation, specify the decision, the constraints and who makes the final call.

Specify the task in four lines

Before your next piece of AI work, write four short lines:

• Know: What context, inputs and constraints does the system need? Name them and identify the approved sources.
• Do: What is the actual job, and what is explicitly out of scope?
• Good: What would a result you could use look like? Give a concrete example or an acceptance test.
• Edges: Where should the system stop, what should it leave out, and when should it ask a person rather than proceed?

These lines give you a starting specification. For consequential work, develop them into a fuller set of permissions, failure cases and tests before deployment.

Apply it to a manufacturing assistant

Know: The current approved procedures for one department, with document versions and access permissions.

Do: Answer an operator's question and identify the passage supporting the answer.

Good: The answer is supported by the current procedure, the citation is usable, and representative operator questions meet the agreed acceptance criteria.

Edges: Stop when information is missing, permissions do not allow access, or conflicting documents require an authorized person to decide.

This is an illustrative specification, not a substitute for a plant's safety procedures. The team still needs to define the actual scope, approvals and tests for its equipment and workflow.

Keep judgment visible

The specification records choices about what matters, what is acceptable and who is accountable. Those choices deserve the same attention as the model and interface.

For a source-grounded assistant in one manufacturing department, explore AI Tech Magic. For an independent pre-production review of an AI agent, see Launch Gate.

Virginia Kalesic is the founder of AI Tech Magic. She builds source-grounded assistants for manufacturers and reviews AI systems before production.