3.6.2 Adjudication Data Storage

Adjudication uses two folders inside the project folder. Keeping them separate means regular annotation files stay clean and standard, while the adjudication working state lives on its own.

Folder	Contains	Purpose
saved/	<annotation> elements only, with no adjudication bookkeeping	Regular annotations from each annotator
adjudication/	<annotation> elements (the adjudicated result, each carrying its adjudication status) plus <adjudicating> elements (items still needing review)	Adjudication working state and gold standard

The adjudication/ folder is written only when you save while in adjudication mode. This is why eHOST prompts you to save before leaving adjudication mode (see 3.6 Adjudication Mode).

What gets written

Every annotation is written at most once, either as an <annotation> or as an <adjudicating> element — never as both. Two rules decide which:

• It becomes an <annotation> if it was accepted as a match, or if you created it yourself while adjudicating (annotator ADJUDICATION) whatever its status. In the adjudication/ folder these elements also carry <processed> and <AdjudicationStatus> children, so an adjudicator-authored annotation that is not resolved yet keeps its real status across a reopen.
• Anything else that still needs a decision becomes an <adjudicating> working copy.

Annotation	Saved as <annotation>	Saved as <adjudicating>
Matched and accepted	Yes	No
Matched and absorbed (the duplicate that an accepted match replaced)	No	No
Rejected	No	Yes
Non-matching (needs review)	No	Yes
Not yet processed	No	Yes
Created by you in adjudication mode (annotator ADJUDICATION), any status	Yes	No

The last row takes precedence: anything you authored yourself while adjudicating is written as an <annotation> no matter which status it currently has.

Accepted items do not need a working copy, because the accepted annotation is already stored as a regular <annotation>. An absorbed duplicate is not stored at all: it carries no decision of its own, it is derived from the accepted annotation that replaced it, it is hidden in the editor, and it can still be recovered by comparing the adjudication/ and saved/ folders. Skipping both typically removes 70-80% of the adjudication file content and makes loading and saving large projects noticeably faster.

Backward compatibility

Adjudication files written by older eHOST versions - or edited by hand - can be in either of two older shapes. eHOST recognises both when it loads the adjudication/ folder, because a status-less <annotation> there can only come from an older build; the current writer always records a status. Whether that element has an <adjudicating> twin (same span, text, annotator and creation date) tells the two shapes apart:

• No twin - the annotation is a final result from a build that did not record status. Every such element was by definition an agreed match, so it is loaded as matched. This also covers a file that contains no <adjudicating> elements at all: the working copies are recreated in memory so the annotations display and can be resumed as usual.
• Twin present - the annotation was written twice by builds released between the introduction of <adjudicating> and version 1.39. The two elements are one annotation and only the twin carries the true status, so the status-less <annotation> is dropped and the twin is kept. Without this the duplicate would survive the upgrade permanently, because the current writer routes both copies to the <annotation> side.

Nothing has to be done manually in either case; the next save rewrites the file in the current format, with one element per annotation.

Note on shared projects

Because the adjudication/ folder is the single source of truth for adjudication state, copying or archiving it is enough to preserve or transfer adjudication work. Deleting its .knowtator.xml files makes eHOST treat the project as never adjudicated.