Create a plain-text file named Modelfile, set FROM to a local base model, and add a SYSTEM instruction. Build a named variant with ollama create, then run the base and custom variants on the same prompts. Keep the source file so you can review and rebuild the configuration later.
Choose a base model and a specific goal
Identify a task that benefits from consistent instructions. Examples include answering in short paragraphs, extracting dates from notes, or acting as a terse practice interviewer. Write the goal in one sentence and decide how you will recognize a good answer. A useful goal identifies the output you need and what the model should do when required information is missing. Avoid adding several unrelated roles to a first experiment.
Run ollama list and record the exact base tag. Try a few representative prompts using the unmodified model first. Our local model setup guide covers installing and running a base model. If the base model struggles to understand a basic task, custom instructions may help you test clearer phrasing, but a different model can also be appropriate. Keep your model choice fixed for the first comparison so you can attribute differences to the configuration.
Write the first Modelfile
Create a plain-text file named Modelfile in a project directory you control. Put FROM followed by the exact model tag on the first line. Add SYSTEM followed by a quoted instruction. For example, a document assistant can be told to summarize the supplied passage in three sentences and indicate when a requested fact is absent. The Ollama Modelfile reference documents the syntax and other available directives. Use its multiline syntax if your instruction needs several lines.
For an initial test, keep the existing model template and change only the system instruction. Models can expect specific prompt delimiters, and replacing the template can introduce a second source of differences. Avoid putting a password, API credential, or customer data in this file. Anyone with access to the project configuration could read it. Use dummy examples for testing and keep the instructions short enough that a teammate can explain what they do.
Build and run the named variant
From the directory containing your file, run ollama create notes-helper -f Modelfile, replacing notes-helper with the name you want to use. Check the command output and confirm the resulting name appears in ollama list. Then run ollama run notes-helper and ask the same question you tried with the base model. Use a distinct name for an experimental version so you can keep using the original in other projects while testing.
If Ollama cannot find the file, check the current directory and filename. An editor may have saved it with a text extension you do not see in the file browser. If the base model name is wrong, copy the exact value from the installed list. Change one line and rerun the build when diagnosing a syntax error. Save the build output that identifies the relevant issue rather than changing both the tag and instruction at the same time.
Test that your instruction makes a real difference
Compare at least three prompts. Use one ordinary example, one ambiguous example, and one that asks for a fact the source does not contain. Check the actual content and format. A model can produce the requested number of sentences while making an unsupported claim. For an extraction task, compare against a known answer and note any invented value. Our local model benchmarking guide explains how to compare outputs under repeatable conditions.
If a response varies from run to run, repeat each prompt and compare the patterns across the base and custom version. Avoid treating a single satisfyingly phrased answer as evidence that the configuration is ready. Rewrite vague clauses into observable requirements. For example, ask the model to name the field it could not find, and test a sample where that field is deliberately absent. Review that output before adding more instructions. Keep examples that expose weaknesses as part of the project’s own tests.
Use the variant in an application
Set the model name in your application to the custom tag and send a known request. Our Ollama Chat API guide shows how to check that the intended endpoint and model handled it. Review whether the application also supplies its own system message or configuration. Test through the real client because its message history or other settings can change behavior. A successful command-line test does not cover every prompt the application sends.
A system instruction guides generation. It cannot serve as an access-control rule, and generated output still needs any validation your workflow requires. If a program expects structured fields, validate the actual values and reject invalid responses. The structured JSON guide explains how to combine a schema with output checks. Keep the application’s security checks in code and use the model configuration for the style and task behavior you can evaluate.
Keep the configuration reproducible
Save the Modelfile, the base tag and a few test prompts together. Record which version passed your checks. This gives you a way to rebuild after moving to another computer or to explain why a later edit changed the output. If you create several experimental names, identify which projects use each one before cleaning them up. Keep a copy of any custom input required to recreate the model.
When changing the base model, rerun the original checks before using the new variant. Two releases can interpret the same instruction differently. Save the old comparison and test a fresh example as well. If you distribute the Modelfile, check that the recipient can obtain the base model and understand the expected runtime. Include the build command and the exact variant name used in your examples.
Before relying on the variant, run a prompt with two overlapping facts and confirm the model can distinguish them. Keep that test outside the instruction itself so you can tell whether it has learned the desired behavior from the configuration.
A useful instruction for a meeting summary is to list only decisions that the text states explicitly, then put unresolved questions in a separate paragraph. Give both variants the same notes containing a proposal that nobody accepts. If the custom output lists the proposal as a decision, revise the wording or keep a human review step. Then try a second set of notes where a decision is actually made. Testing both outcomes helps you catch a rule that avoids false positives by omitting every decision. Record the accepted example and its expected answer alongside the failure case.
Frequently asked questions
Does a Modelfile fine-tune the model?
A SYSTEM instruction configures how the model is prompted. It does not train new weights.
Will my custom variant change the base model?
Use a separate name and keep the base tag available. Compare both variants explicitly.
Can a system instruction guarantee output?
Validate responses when your program depends on a format or fact. Run tests for missing and ambiguous input.
