Validation Rules

Each template's validation is built from a small set of reusable rule types (pass/fail checks) and process types (automatic changes to the data). Their names appear in some error messages and in the template definitions. This page explains what each one does. To look up a specific message, see Troubleshooting Errors.

Rule types (pass/fail checks, run as PreRules/PostRules)

Rule type	What it actually checks
all-empty-or-nonempty	Across a set of columns, either all must be empty or all must be non-empty — a "fill in this whole group together or not at all" constraint. See E-21.
at-least-one-nonempty	At least one column in the set must be non-empty (e.g. amount or duration or temperature for a treatment). See E-30.
empty-value	Fails if any listed column has a value — i.e. these columns must be blank (often paired with a condition, e.g. "blank unless X").
not-empty-value	Fails if any listed column is blank — a straightforward required-field check. See E-09.
not-equal-to-value	The column's value must not equal one of the given values.
values-equal	The two (or more) columns must contain equal values. Used for things like "this computed status must equal this constant" — e.g. subjectHumans enforces subject_required == "yes", which is the actual mechanism forcing every Subject ID in that template to be new rather than a reference to an existing subject.
values-not-equal	Inverse of values-equal.
less-than	Numeric column must be less than a given value/column.
check-date-format	Validates DD-MMM-YYYY / DD-MMM-YY date format (rejects ISO/numeric dates). See E-20.
check-not-contains-case-insensitive	Two columns (or a column and a list) must not match case-insensitively — typically a duplicate/self-reference guard.
check-value-in-entity	The column's value must be found in a referenced set — either loaded from the database via a named Validation Query, or accumulated in-memory from earlier rows in the same upload package. This is the general "must already exist" / "must be consistent with" check (e.g. a subject referenced in a result row must actually belong to the stated study).
check-value-not-in-entity	Inverse of the above — fails if the value is found. Used in study_design_edit's arm_2_subject section to block the same subject and study pair appearing twice within one package. It doesn't block linking a subject to several studies. See E-27.
check-result-schema-for-result-file / check-result-schema-for-accession	Cross-checks that a result file's declared schema/accession is consistent with what's already registered for that result set.
check-population-markers	Flow cytometry and CyTOF: every marker in a cell population definition must be a known analyte or marker. See E-32.
check-immport-template	Checks the ImmPort Template? column: Yes needs the ImmPort results template in the package and no result file name; No needs your own result file. See E-31.

Process types (data transformations, run as PreProcessing/PostProcessing)

Process type	What it does
determine-combined-status	Used by combined templates (e.g. subjectHumans) to decide, per row, whether an ID column refers to a new record or an existing one — checks the current upload package first, then the database. Its output (..._required = yes/no) is what other rules key off of.
set-and-check-study-accession	Pins the single study_accession for an entire upload batch the first time it's seen; fails if a later row in the same batch tries to use a different study. (A package can only ever target one study.) See E-29.
add-values-to-entity	Remembers a value for the rest of the package, e.g. recording "this subject has now been assigned to this study" for later duplicate checks within the same package only. Not a database write.
determine-user-defined-id-to-parent	Resolves a child record's user-defined ID scoped under its parent entity (used for things like study_categorization, which is only unique within a given study).
set-preferred-value	Implements the "preferred vocabulary" pattern: if a reported free-text value matches an entry in a *_pref_map table, fills in the companion preferred-value column automatically.
initialize-columns	Sets a group of columns to a default (usually empty) state under given conditions — e.g. clearing demographic fields when a row is just referencing an already-defined subject.
set-to-value	Unconditionally (or conditionally) sets a column to a fixed value — e.g. capping reported ages over 89 down to 90 for de-identification, with an explanatory note appended to the description field.

Reading "conditionally required … when defining a new X"

Field pages often say a field is conditionally required when you are defining a new X rather than referencing an existing one. Behind that wording is a determine-combined-status process, which decides per row whether an ID is new or existing. Some templates add a values-equal rule on top that allows only new records. subjectHumans and subjectAnimals work this way, which is why existing subjects are linked with study_design_edit instead.