# `JSONSchex.Types.ErrorContext`
[🔗](https://github.com/xinz/jsonschex/blob/main/lib/jsonschex/types.ex#L94)

Structured detail carried by `JSONSchex.Types.Error`.

The three fields have consistent, role-based meanings across all validation rules:

- `contrast` — The **schema constraint** that was not satisfied.
  Examples: the expected type (`"integer"`), a numeric limit (`10`),
  a list of allowed values, the required regex pattern.

- `input` — The **processed representation** of the failing value.
  This is not always the raw input; it may be a derived quantity such as
  a string's codepoint length (for `minLength`/`maxLength`) or the inferred
  type name (for `type`). For remote-ref errors it holds the URI string.

- `error_detail` — **Ancillary detail** needed to disambiguate error variants
  or carry supplementary information. Examples: a regex compilation error
  message, the string `"min"` / `"max"` to distinguish `contains` violations,
  or a nested `Error` from a remote schema.

Use `JSONSchex.format_error/1` (or `to_string/1`) to turn an error into a
human-readable message rather than inspecting these fields directly.

# `t`

```elixir
@type t() :: %JSONSchex.Types.ErrorContext{
  contrast: term() | nil,
  error_detail: term() | nil,
  input: term() | nil
}
```

---

*Consult [api-reference.md](api-reference.md) for complete listing*