Skip to content

Validate

Enforcing rules on the final, interpreted value — cleanly, explicitly, and without surprises.

Validation is the fourth and final stage of the Jane pipeline. It runs after parsing, and its job is to check whether the value meets your requirements. Validation never mutates, never interprets, and never normalizes. It simply evaluates the final value and emits events that describe what it found.

This is the stage where your intent becomes explicit.

You tell Jane what you expect, and Jane tells you whether the value meets those expectations.

Why Validation Exists

Every real application has rules:

  • "This field must be a number."
  • "This string must not be empty."
  • "This array must have at least 3 items."
  • "This date must be in the future."
  • "This value must be one of these options."

Validation is where those rules live. But unlike many libraries, Jane doesn’t mix validation with parsing or coercion.

Validation is pure: It checks the value you give it — nothing more, nothing less. This separation is what makes Jane predictable.

What Validation Does

Validation rules:

  • Inspect the final value,
  • Emit events (info, warn, error, fatal).
  • Never change the value.
  • Never interpret.
  • Never normalize.
  • Never coerce.

Each validator returns a list of events. If the list is empty, the value passed the rule. For example:

jane.value(input)
    .minLength(3)
    .maxLength(10)
    .run();

Each validator runs independently. There is no short‑circuiting unless a validator throws (which becomes a fatal event).

Validation Is Explicit

Jane will never validate automatically. You must opt in:

jane.value(input)
    .string()
    .nonEmpty();

This is intentional. Implicit validation is one of the biggest sources of confusion in other libraries. Jane’s rule is simple: If you want a rule enforced, you must ask for it.

When Validation Runs

Validation runs after parsing: scan → normalize → parse → validate.

This ordering is intentional:

  • Scan ensures the structure is safe.
  • Normalization cleans the structure.
  • Parsing interprets the meaning.
  • Validation enforces the rules.

By the time validation runs, the value is stable and predictable.

What Validation Never Does

Validation is intentionally limited. It does not:

  • Mutate the value.
  • Normalize.
  • Parse.
  • Coerce.
  • Walk recursively.
  • Change the pipeline decision directly.

Validation emits events. Policy decides what those events mean.

User Message Overrides

You can override the user‑facing message for all validation events:

jane.value(input)
  .isEmail()
  .userMessage("Please enter a valid email address.")
  .run();

This affects only validation events. Not scan, normalize, or parse. This keeps the UX clean without hiding structural issues.

How Validation Affects Decisions

Validation emits events with severity the error severity level.

Policy determines how those events affect the final decision:

  • Strict mode escalates warnings (from scan).
  • Lax mode downgrades errors (from validate).
  • Custom policies can override or ignore specific codes.

Validation itself never rejects. It only reports what it found.

Why Validation Matters

Validation is the stage where your intent becomes explicit:

  • You define the rules
  • Jane enforces them
  • Policy interprets the results
  • Boundaries aggregate them

This separation of concerns is what makes Jane feel clean, predictable, and teachable.

Validation is the final checkpoint before the value is accepted.