Repository navigation
Guide Getting Started
Once a project is open, the screen is three panes: your papers on the left, the PDF in the middle, and the annotation form on the right, built from the project's schema.
- Pick a paper from the left list to load its PDF and its form.
- Read the PDF in the middle; its text is selectable, and Ctrl/Cmd+F searches within it.
- Fill in the form on the right. Repeatable fields (like Findings above) show + Add and a remove (×) control for each entry.
- Save via the Save menu, or Ctrl/Cmd+S. Save as… writes to a new location and re-derives every PDF reference so they keep resolving from there.
If the project is set up for screening instead of full annotation, this pane shows a title/abstract record and an Include/Exclude choice instead — see Screening. If it's set up for multiple reviewers, you'll be asked which seat you are before you can annotate anything — see Working with several reviewers.
The box above the paper list searches title, authors, DOI, abstract, the PDF's file name, and the paper's own id by default (the META trigger on the right edge of the box). Click that trigger to switch to TAGS, which searches the annotation content you've already recorded instead — useful for "which papers did I mark as X".
The search above matches A1-37 — part of a PDF's file name, not its title or authors — and still
finds the right paper. Searching by the paper's own id works the same way; both are useful once a
project has more papers than you can recognize by title alone.
Annotation-content search looks at your own current seat's answers, so in a multi-reviewer project it finds your work, not somebody else's.
Select any text in the PDF, then click the ⧉ button next to a field to insert exactly that selection into it. Numeric fields pull out the first number in the selection.
This is the fastest way to fill in most fields without retyping anything from the paper — select the sentence that supports a claim, click ⧉ next to Claim, done.
Select text in the PDF and a small color toolbar appears — pick a color to highlight the selection and open a note box for it right away, or press a to use the first color without reaching for the mouse. A selection that runs onto the next page becomes one continuous highlight instead of stopping at the page break; a running header or footer caught in that spillover is left out automatically, though selecting into one yourself still highlights it. Click any existing highlight later to reopen that box: change its color, edit or clear the note, or delete it. Press Escape, click elsewhere, or scroll the page to close the box without deleting anything.
Hovering a highlight or note (without clicking) shows its comment — or, for a highlight with no comment, the text it covers — plus any fields it's linked to, in a small tooltip, so you can check what a mark is without opening it. Ctrl/Cmd+scroll zooms the PDF in and out. Deleting a highlight or note that's linked to one or more fields asks you to confirm first, naming which fields would lose their evidence.
These highlights and notes are your own — in a multi-reviewer project, each reviewer (and Consolidation) sees only their own marks, just like annotation answers. They're saved with the project like everything else, but on their own file per paper per reviewer, so two people marking up the same PDF never conflict in git.
More annotation tools. The 📝 button in the PDF header opens a row of annotation tools below it:
- A post-it button for dropping a sticky note anywhere on the page — click the button, then click the spot in the PDF, and the note's comment box opens right away.
- ‹ › buttons to step through every highlight and note on the paper, in reading order, jumping straight to each one's exact spot on the page (not just the top of the page it's on).
- A 📤 button (enabled once you have at least one highlight or note) that exports the PDF with your marks burned in as real PDF annotation objects any PDF reader can show — for sharing outside SaiLoR. Choose to save it as a new file (the default) or overwrite the paper's own PDF in place; the app warns before the second option, since that file is shared with every other reviewer and overwriting it is likely to cause a git conflict.
Linking a highlight or note to a field. Next to every annotation field is a small 🔗 button —
click it to record why you picked this value. It opens a box showing what's already linked (or "No
links yet"); click + Link a highlight or note to fold out a scrollable list of the paper's other
highlights and notes, with a search box at the bottom if there are a lot of them. That list is sorted
with up to 3 highlights/notes you made this session first, most recent first (a little extra space
marks where that group ends), then everything else in reading order down the paper — a highlight
that's simply been in the file since a previous sitting is never pinned there, however new its own
timestamp looks. Clicking a highlight/note's own text — in
either list — jumps to it in the PDF so you can see which one it is, without closing the box or
changing anything; click Link to attach it — its button flips to × right there without the row
jumping anywhere, and it moves up into the linked list above the next time you open the box. The 🔗
button shows a count once you've linked one or more (🔗 2). A highlight or note can be linked to any
number of fields, and a field can have any number linked to it.
If you highlight or note something and then open a field's 🔗 box right away, that highlight/note links itself automatically — no need to find and click it. Typing the value into that same field first still counts as "right away" and links it too. Doing anything else first — editing a different field, adding or removing an entry, undoing, touching another mark — cancels the offer, and you pick it from the list by hand instead.
To remove a link, click its × — either in the field's own box, or by opening the highlight/note itself in the PDF, where its box lists every field it's linked to.
Each paper in the list carries a status dot on its left. In an ordinary (non-screening) project, it fills in proportionally as fields are completed:
- If the schema marks any fields required, the dot's denominator is those required fields only.
- If nothing is marked required, it's a fraction of all fields instead — better than nothing rather than staying permanently empty.
- Hover a dot (or check its accessible label) for the actual numbers: "3 of 12 fields filled".
The fill is always progress; the color says whose move it is:
| Dot | State | Meaning |
|---|---|---|
| empty | Not started | nothing filled in yet |
| amber slice | In progress | partly filled |
| solid amber | Ready to finish | every counted field is filled, but nobody has said it's done |
| solid green | Finished | you ticked Annotation finished and it still holds |
| red | Finished, required fields missing | ticked while a required field is empty — see below |
The dot always tracks your own seat: as a numbered reviewer it's your progress and your sign-off,
and in Consolidation it's the consolidated record's progress and your sign-off on it. Whether
every reviewer has answered a paper yet — the thing that decides if it's workable at all — is in that
dot's tooltip in the Consolidation seat, and counted in the line under "Papers" (… · 3/10 ready).
In a screening project the dot becomes the tri-state include/exclude/undecided marker described in
Screening instead.
A completely filled form is not the same as a finished paper, so SaiLoR does not decide that for you. The Annotation finished checkbox sits at the top of the annotation panel, under the paper's title, and is always there — tick it when you're done with the paper. Only then does its dot turn green.
Red means one specific thing: a field that had to be filled is empty on a paper you called
finished. "Had to be filled" is the schema's own required flag — the same rule
Validate uses — so the red dot and the Validate dialog can never disagree.
- If your schema marks nothing required, no paper ever turns red. An unanswered question is often the right record of a paper that doesn't address it, and ticking the box says so.
- A Yes/No field is never a hole. Unticking it records no, which is an answer — it can't turn a finished paper red even if the field is marked required. (Same reason Validate never reports a Yes/No field as missing.)
- Ticking early — before a required field is filled — is allowed rather than blocked. Sometimes a paper genuinely can't be filled in further; the app marks the disagreement instead of hiding it.
The mark is re-evaluated from the current data, live, as you type: it is not tied to saving. Empty a required field on a finished paper and it turns red at once; refill it and it goes green again. Nothing is ever silently un-ticked — the declaration is yours to withdraw by unticking the box.
The tick is yours alone: in a multi-reviewer project each reviewer — and Consolidation — has their own checkbox and their own green dot, saved in their own file. In the Consolidation seat the box reads Consolidation finished, since what you're signing off there is the reconciled record rather than your own extraction; it is stored with the consolidated result, and says nothing about whether the reviewers have all answered the paper.
If you'd rather not sign papers off by hand, put "finishCheckbox": false in the project file's
config. Papers then count as finished the moment their schema is fulfilled — all required fields
filled, or all fields where the schema requires nothing — and the checkbox disappears. Nothing can
be red in that mode (there is no declaration left to contradict the data), so the filter drops its
With issues option too.
The default is true. Ticks recorded before you turned it off stay in the file untouched, so
turning it back on picks up exactly where you left off.
Opening a project puts you on the first paper that isn't finished — including one showing red — rather than on paper 1, which on a review you've been working through is something you already signed off. If every paper is finished, it opens on the first one as before. Screening projects, and a multi-reviewer project where you haven't picked a seat yet, also open on the first paper: neither has a per-seat "finished" to go by.
The dropdown under the search box narrows the list to one of these buckets:
- Open — every paper you have not ticked as finished, whatever its dot shows: untouched, part-filled, and filled-but-not-yet-signed-off alike. Undo some annotations, or untick the box on a paper you had finished, and it comes back here.
- In progress — the papers you have actually started: those with at least one annotation recorded, still not signed off. This is Open minus the papers you have not touched yet, so it answers "what have I begun and not finished". (A paper whose only entry is a Yes/No answer counts as started even though its dot still reads empty — the fill ignores Yes/No fields.)
- Finished — ticked and still holding.
- With issues — ticked while a required field is empty (the red dots).
The five dot colors are unchanged; the filter is just coarser than they are, since "what still needs work" is the question you actually ask a list.
The line under "Papers" counts whichever bucket is selected, across the whole project regardless of
the search box: finished: 5/100. With no filter set it counts finished, the headline number.
Screening projects keep their own include/exclude/undecided filter instead. The Consolidation seat has
the same dropdown and the same counter as any other, plus a second number for how many papers every
reviewer has answered: finished: 5/100 · 82/100 ready.
Validate (in the toolbar) checks every annotated paper against the schema: required fields that are still empty, values of the wrong type, and enum values outside a dropdown's allowed choices.
Click a problem to jump straight to that field. Papers with no annotations at all are listed separately under Not annotated yet rather than reported field by field — an untouched paper would otherwise fail every required field at once and bury the problems that are actually worth looking at.
Note the reminder at the top of the dialog: a Yes/No field is never reported as missing, even if it's marked required — see Things to know.
Press F1 at any time for the full, current list for whichever screen you're on — it differs between the start screen, annotating, screening, and the project editor. The most common ones while annotating:
| Shortcut | Action |
|---|---|
| Ctrl/Cmd+O | Open a project file |
| Ctrl/Cmd+S | Save |
| Ctrl/Cmd+Shift+S | Save as… |
| Ctrl/Cmd+Z / Shift+Z | Undo / redo an annotation change |
| Ctrl/Cmd+F | Search within the PDF |
| Ctrl/Cmd+scroll | Zoom the PDF |
| a | Highlight the current PDF selection with the first color |
Alt+↓ / ]
|
Next paper |
Alt+↑ / [
|
Previous paper |
| F1 | Open help |