Question 1

How is this different from the validation the API already does?

Accepted Answer

The API rejects malformed JSON and names the field, which wellposed does not repeat. It looks at requests that parse cleanly but are badly designed: a Choice with no way to say none of the above, a rating asked as a yes/no, backtick paths that point at nothing in your state, data over the token ceiling. The author's point is that zero of forty requests they generated failed API validation while sixteen asked something incoherent, so the strict layer was never where the bugs were.

Question 2

Are the confidence figures convincing enough to change how I write questions?

Accepted Answer

They are the author's measurements and the reasoning is the interesting part. They took 31 real Choice questions from public Jev code that had no escape hatch and fed each an input none of its options fit; Jev answered wrong every time and 36% of those wrong answers came back at 0.9 or above, which is exactly the range a confidence gate is supposed to catch. Adding an `other` option sent 90% of them there and changed none of 62 answers that did fit.

Question 3

Will it catch customer data before my state leaves the machine?

Accepted Answer

Only once you configure it. You list field names such as `card_number` or `ssn` under `forbidden`, and any request whose data contains one fails. Until you do that the check is silent, which the README presents as the point: no false positives by construction, and no coverage either. It runs before the call, which is the right place for it since the data goes to a third-party API.

Question 4

What does the Jev-on-Jev layer add that a rule cannot?

Accepted Answer

Rules can see that a Choice lacks an `other` option but not whether off-list inputs exist for your data, and they cannot judge whether two options could both be true or whether your levels run backwards. Those nine checks ask Jev as plain yes/no questions, one judgment each, which is the same discipline it enforces on your code. The README calls this the layer for the questions structure cannot decide.

Question 5

Do I need a key or network access to lint a request?

Accepted Answer

No API key, no waiting, and no network beyond a once-a-day version check: the linter reads the JSON and checks 45 rules offline. It has zero dependencies and is MIT licensed. Only the Jev-on-Jev semantic layer, for things structure cannot decide, needs the key.

Question 6

Which problems are errors and which are only warnings?

Accepted Answer

Errors fail the check: no instructions on a question, a wrong data type, a Noul's criteria given as a list, a Choice with duplicate options or more than 255, a Score with fewer than 2 levels, oversized data, and a broken reference to a state path that does not exist. Warnings cover probably-wrong things like a Choice with no none-of-the-above option.

Question 7

Does it enforce data size limits and secret fields?

Accepted Answer

Yes. It fails data over 64,000 tokens total, or 32,000 for the data plus your longest question. It also fails any request whose data contains a field you list under forbidden, such as card_number or ssn. That check stays silent until you configure it, so it has no false positives by construction.

Wellposed

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev community