Validator catalog¶

Validators are opt‑in, manual, and explicit rules that enforce constraints on the final interpreted value of a pipeline. Unlike scan (structural safety) and normalization (structural hygiene), validators operate on the semantic meaning of the value after parsing.

Validators¶

Never mutate the value
Never parse or coerce
Never normalize
Emit events describing rule success or failure
Run in the order you specify
Are interpreted by policy, not by the validator itself

Validation answers the question¶

"Given this value, does it meet the rule?"

Validators are the final gate before policy decides whether the pipeline is acceptable.

How Validation Works¶

Parsing produces the semantic value Validators always receive the parsed value (e.g., a number, boolean, Date, object).
Validators run in the order you specify Each call to .validate(...) adds a rule to the pipeline:

javascript jane(value) .parse("numericString") .validate("integer") .validate("min", 18) .validate("max", 120)

Each validator emits events Events include:
severity
code
path
developer message
user message
metadata
Policy interprets the events Policy decides whether:
the pipeline is accepted
the pipeline is rejected
the pipeline is marked for review Validators never decide acceptance on their own.

Validator Categories¶

Validators are grouped by the type of value they operate on. Each section includes:

a description of the validator category
the validators in that category
cross‑links to related scan and normalization rules This helps developers understand how validation fits into the full pipeline.

String Validators¶

String validators enforce constraints on string content, format, and structure.

Type & Basic Structure¶

Character Class & Formatting¶

Pattern & Matching¶

Email, URL, UUID¶

Phone, Postal, IP¶

Country & Currency Codes¶

Number Validators¶

Number validators enforce numeric constraints, ranges, and safety.

Type & Basic Structure¶

Range & Comparison¶

String-to-Number Validation¶

numString (validates numeric strings without parsing)

BigInt Validators¶

BigInt validators enforce constraints on large integers.

Type & Basic Structure¶

Range & Comparison¶

Boolean Validators¶

Boolean validators enforce truthiness constraints.

Validators¶

Date Validators¶

Date validators enforce temporal constraints.

Type & Basic Structure¶

Relative Time¶

Comparisons¶

Calendar Comparisons¶

Array Validators¶

Array validators enforce constraints on array structure and contents.

Type & Basic Structure¶

Length¶

Content Rules¶

Value-Based Rules¶

hasValue

Object Validators¶

Object validators enforce constraints on object structure and keys.

Type & Basic Structure¶

Key Rules¶

Value Rules¶

Deep Comparison¶

deepEquals

Mixed / General Validators¶

These validators apply to multiple types or operate on semantics rather than structure.

Validators¶

Example: A Simple Validator¶

export const positive: Validator<number> = (value, path) => {
    if (typeof value !== "number") return [];

    if (value > 0) return [];

    return [
        validationEvent(
            'error',
            'number.positive.failed',
            path,
            'Expected a positive number.',
            'Please enter a number greater than zero.',
            { received: value }
        )
    ];
};

This example illustrates the validator contract:

Check applicability Validators must confirm the value is of the expected type.
Evaluate the rule If the rule passes, return [].
Emit a structured event on failure The event includes severity, code, path, developer message, user message, and metadata. Validators never mutate the value and never decide acceptance — they only emit events.

Summary¶

Validators are the semantic rule layer of the Jane pipeline. They enforce constraints on the final interpreted value and produce structured events that policy uses to determine acceptance. Validators are:

opt‑in — nothing runs unless you call .validate()
manual — you choose the rules and their order
pure — no mutation, no coercion
event‑emitting — every failure is recorded
policy‑interpreted — validators never reject on their own

Validation is the final stage before policy, ensuring that your data meets the rules you define — explicitly, predictably, and transparently.