The error tuple as it is now is very sensitive to changes. By adding the path we break any application using this tuple. I think that needs to be changed anyway before version 1.0.

My first though was that the error tuple already very much looks lika record. If could be defined in some include file "jesse.hrl" and then one could use the record like this:

```Erlang
#data_invalid{schema = Schema, data = Data, error = Error, path = Path}
```

With this change, the representation doesn't actually change (except for the addition of path). By pattern matching on it as a record instead of a tuple with a fixed size, it is automaticall extensible with more things in the future. One such thing could be the path inside the schema to where validation failed. Whether or not we want to make the record available in an include file, we could provide accessor functions to fetch various info from it:

```Erlang
get_error_schema(#data_invalid{schema = Schema}) -> Schema.
get_error_path(#data_invalid{path = Path}) -> Path.
```

... and then we can also later provide some functions formatting the error into a human readable message or the path in the form of a json pointer:

```Erlang
get_error_message(#data_invalid{...}) -> "Wrong type at /path/to/property".
get_error_pointer(#data_invalid{path = Path}) -> json_pointer:encode(Path).
```

Your suggestion {path, ...} looks like it's an entry in a proplist. If that is what we want, then I think we should change the data_invalid so that it is actully a proplist in a uniform way:

```Erlang
{data_invalid, [{schema, Schema}, {path, Path}, {error, wrong_type}, {data, 42}]}
```

All these are probably better than the fixed size tuple. Personally I prefer the record form though.