Project Settings¶
The settings that apply to every run in the project, and when it is worth changing them.
There is one thing to know before the detail: almost all of these settings are chosen in a single place, the form you fill in before the Export file is uploaded. Once the Project holds a file, that form is replaced by the Project Home Page and most of the settings become a record of what you chose rather than something you can still change. Labels are the exception - those you can change whenever you like.
So it is worth reading this page before you create the Project, not after.
Model¶
SLIM does its work by asking an AI model to read your export, reason about it and write the results. The Model you pick decides the highest model that is used, and therefore how much capability is brought to the work, how long it takes and what it costs.
The skills may use lower capability models for simple tasks, but will never exceed the selected model for the most complex tasks.
You do not need to know anything about the models themselves to choose one. The picker lists each by name with a short note of its relative cost and speed alongside, so the comparison you need is on the screen. The list changes as new models become available, and the recommended default is already selected. For a first Project, leave it alone.
Two things about the choice are worth understanding.
It applies to the whole Project. Every Stage works to the model you picked here, and so does the work the agent delegates to itself along the way. That is what makes the choice a ceiling rather than a starting point: nothing in the run reaches above it.
It is pinned. A Project keeps the model you chose, recorded as an exact version rather than a name that moves. When a newer model is released, nothing about your Project changes: it does not quietly upgrade. This is deliberate. If you need to explain a result months later, or run the same work again and expect the same shape of answer, the model that produced it is still available to ask for.
The consequence of pinning is that the choice cannot be revised. Nothing on the Project Home Page or on any Stage Page lets you change the model after the Project has been created. If a Project needs a different one, create a new Project.
There is one exception: Replacing the export returns both the model and the effort level to their defaults, exactly as it does with Migration Mode, and it does so without asking. If you had chosen anything other than the defaults, check the Agent Model & Effort panel after replacing an export - see Uploading an Export.
You can always see which model a Project is using. The Project Home Page carries an Agent Model & Effort panel that names it and says Set when the project was created, and each Stage Page repeats it next to the run button as Using the model and effort level. On a Stage Page that is information about the run, not a control.
Effort¶
Reasoning Effort is a separate control from the model, set on the same card, and it answers a different question: not which model does the work, but how hard it thinks before acting.
It is a slider with five stops. On screen they are written in lower case, and they read:
Level |
Suited to |
|---|---|
low |
Quick lookups, classification, high-volume jobs |
medium |
Solid answers, moderate savings |
high |
Complex reasoning, hard analysis, most real work - the recommended default |
xhigh |
Long-running work and deep search |
max |
The ceiling, with no attempt to economize |
Drag the slider, or click a level, and the line beneath it describes what that level suits. The slider starts on high, which is the right choice for most migrations.
Higher effort costs more and takes longer, and earns that on complex integrations - the ones with tangled branching, unusual transformations or a lot of interdependence. Lower effort is faster and cheaper. Dropping to low is a perfectly reasonable thing to do on a learning Project where the point is to see the shape of the process rather than to get a production-quality result.
As with the model, one level applies to the entire Project. There is no way to run one Stage harder than another, and the level shown beside a Stage’s run button reports what that Stage will use rather than offering to change it.
Execution mode¶
Migration Mode decides whether SLIM runs the Stages one after another on its own, or stops after each one and waits for you.
Automatic runs all stages end-to-end. It is preselected and marked Recommended.
Step-by-Step runs one stage at a time, and you decide what to run next and when.
Which to choose depends on how much you want to read and adjust along the way, and that decision is worth a little thought - see Choosing an Execution Mode.
For the setting itself, two practical notes. It sits on the upload form, so it is chosen before the export goes in. And if you later replace the export, the mode returns to Automatic whatever you had chosen originally, which is described in Uploading an Export.
Diagnostic logging¶
Diagnostic Logging saves a detailed record of every run to a logs folder in the Project Tree: what the agent was asked to do, what it actually did, which files and supporting documents it drew on, and how long it took and what it cost. It is off by default. The switch is labeled Enable diagnostic logging.
Turn it on while you are learning. It costs you nothing in the quality of the output, and it changes what you can do when something looks wrong: you can follow how a run unfolded rather than guessing, you have something concrete to attach when you ask for help, and you can compare two runs to see what your change to the instructions actually did.
If you are ever unsure whether a Project has it, look at the Project Tree. No logs folder means it was not enabled.
Like the other settings on the form, this one is chosen at creation. Unlike the model and effort, it can be changed afterwards by an administrator, and only for the Project as a whole. Replacing the export leaves it as it was.
Labels¶
Labels are the one setting you can change at any time, and the only one that is not really about how the Project runs.
A label is a tag you attach to a Project so you can find it again. On the Project Home Page the Project’s labels appear as small chips: type into + add label and press Enter to make a new one, or use the chevron beside it to pick one you have used before. The small cross on a chip removes it.
What they are for is filtering. The control at the top of the Header Bar reads All projects until you choose a label, at which point the Project List shows only the Projects carrying it. On a screen with dozens of Projects, that is the difference between scrolling and finding.
Two things to know before you invest in a scheme:
Labels are private to you. Your colleagues do not see the ones you apply, and you do not see theirs. Choose them to suit the way you work rather than as a shared taxonomy - and if the team needs a shared convention, put it in the Project Name instead.
Labels grant no access. Attaching one does not change who can open a Project. That is decided by its Team.
Settings an administrator manages¶
A few things that affect your Project are not on any page you see, and are not meant to be.
Where the work actually runs is one of them. It is settled by how SLIM was set up for your organization, applies to everything in it, and there is nothing for you to choose.
Others are ordinary settings that simply move out of reach once a Project exists. An administrator can turn Diagnostic Logging on or off for an existing Project, move a Project to a different Team if it was created against the wrong one, and release a Project that has become stuck. If you need any of those, ask, and give them the Project Name and the Team - see Getting Help and When a Project Is Busy.
The model and the effort level are the exception to all of this. They are fixed when the Project is created, on purpose, and the reliable way to run the same export with different ones is a new Project.