Skip to content
GradWorkbench

Chapter 11 · Every screen, part by part

Settings

Five tabs. Only two of them will ever need your attention twice.

TabWhat it controls
Account & SecuritySign-in, password, sessions
Research AccessWhich assistants may write into this workspace, and what each may do
Research BatchesHow much research runs, how often, how much you review, and who is worth researching
Model RoutingWhich model does which job
Writing RulesThe writing rules every outreach draft and document must pass

Your applicant profile is not here — it lives under Profile.

Research Batches — the limits#

1 — Research batches enabled. Nothing runs until this is on and saved. It is off by default deliberately: research costs money, and the first thing anybody does with a new workspace is import several thousand professors.

2 — The four numbers.

SettingWhat it doesWhy the default is low
Professors per batchHow many one run coversSmall batches let you look at the output before spending more
Max batches per weekThe ceilingA mistake costs one batch, not a month
Time limit per professorWhen to give up on one personA single hard-to-research professor cannot eat the whole run
Max retriesHow many times to retry a failureStops a broken faculty page becoming an infinite loop

3 — How much do you review? Three choices:

  • Everything, before it publishes — every finding waits for you in Review.
  • Only conflicts and warnings — clean findings publish themselves; anything contested waits.
  • Nothing, publish once checked — findings publish as soon as they pass their source check.

Findings are always checked against their sources first, whichever you pick. This setting only decides whether you sign off as well.

4 — Save configuration. Nothing takes effect until this is pressed.

Research Batches — who is worth researching#

1 — Which kinds of appointment are worth researching? Fourteen checkboxes, each with a sentence explaining what that kind of post actually is — because these words are used inconsistently across institutions and the differences matter. Ticked by default: the ones that normally supervise doctoral students, plus Not established yet. Unticked by default: adjunct, affiliate, visiting, lecturer, instructor, postdoc, emeritus, staff.

Read the two paragraphs under the grid; they are the important part.

  • This is a default, not a filter. Any individual professor can be switched on or off from their row or their page, and that choice wins over this.
  • It matters because imported labels are unreliable. A roster carries whatever the staff directory it was scraped from happened to say, and real tenure-track faculty regularly arrive labelled affiliate or adjunct. Treating that as final would quietly drop people worth writing to.
  • Leave Not established yet ticked. Working out somebody's actual appointment from their actual faculty page is a large part of what the research does. Unticking it means skipping everybody nobody has looked at yet — which, on a fresh workspace, is everybody.

2 — Which seniorities are worth researching? The same idea for rank: assistant, associate, professor, distinguished chair, and not established yet. All ticked by default.

Both sets are applied together, and both are overridden by a per-professor choice. The full rule, including the order it resolves in, is in §3.2a.

3 — Allow scheduled auto-start. Off by default. When on, batches begin on their own schedule instead of waiting for you to press Run this batch.

Model Routing#

Which model handles which job. The defaults route cheap models to mechanical work — tidying links, normalising a title — and the strongest ones to match analysis, where the failure mode is not an error but a fluent paragraph with the honest mismatches quietly missing.

Override any of them. The cost of getting this wrong is asymmetric: a cheap model on link tidying saves money with no downside, a cheap model on match analysis produces something that reads well and is not true.

Writing Rules#

Three tabs. The Email template is the shape an outreach email takes, and it applies to email only. The Humanizer is the rule about how everything here is written, and it is not email-only: outreach drafts, statements of purpose, research proposals, cover letters and the rest are all checked against it. Anything a professor or an admissions committee reads goes through it before you ever see it.

Per-field rules is the third: your own additions for one field at a time, on top of the base. Each field shows what is already checked for it, so you can see what you do not need to write. A field with no rules of your own is a normal state, not an unfinished one.

This is also the source of one specific error: "No active humanization_instructions policy document" means an assistant tried to write a draft and these are not set up yet.

Research Access#

Its own chapter, because connecting an assistant is the one setup step with real steps in it: chapter 10, and the reference for this screen.


← Analytics · Every screen, part by part