Skip to main content
Install Relativities before running the examples. The installation includes the rslc compiler. rslc inputs sample reads the input rules of a rater and writes requests that pass them. rslc inputs validate checks one request against the same rules. The examples use the dwelling-fire rater from Write your first rater. Save its two files, or run rslc examples get dwelling.
dwelling/rater.rsl
dwelling/tables/BaseRate.csv

Sample requests

Name the rater, the number of requests and a seed:
Each line after the first is one request, as JSON. Every value sits inside its declared range and on its declared precision, so the rater accepts each request.
  • --n sets the number of requests. The default is 20.
  • --seed chooses the set. The default is 0.
  • The requests of one set all differ.
  • Each later request starts from an earlier one and redraws some values, so a value often repeats.

Repeat a set

A seed fixes the set. The same command prints the same requests on every run and on every machine.
  • A longer run starts with the same requests: --n 4 --seed 7 prints these three, then a fourth.
  • A different seed gives a different set.
  • The set changes when the input rules of the rater change.
  • The set also changes when a new version of rslc changes its sampler.

Write the requests to a file

Add --json-lines and a file name:
The command prints the same lines and writes requests.jsonl, one record on each line. A record holds the request under input. Its generation object holds the seed, the index of the request and the version of the sampler. Read the requests back and rate them:

Sample refused requests

Add --invalid to get requests that the rater refuses:
--invalid takes each sampled request and breaks one rule. The first request here lacks its dwelling record. The second schedules eleven items, one more than the rater allows. Each record in the file holds the broken request under input and the refusal under refusal:
The refusal is the one the rater returns for that request. Refusals describes each field and each code.
  • --invalid breaks a rule of structure: a required record, the length of a list, a list key, or the kind of a record.
  • The requests take turns over the rules that the rater declares. This rater declares two.
  • generation.mutation names the change, such as [email protected].
  • To test a range rule, write the request and validate it, as the next section shows.

Validate a request

Save a request as request.json:
request.json
Name the rater, then the file:
PASS means the request passes every input rule of the rater.

Read a refused request

This request sends a Coverage A of 25,000 and protection class 12:
refused.json
Each line after FAIL is one violation, with the six fields of a violation in a refusal. The lines match the violations that rating the same request returns.

Read the exit code

Add --json to print one JSON value:
ok is true for an accepted request, and violations is then an empty list. The exit code stays the same. rslc inputs sample takes --json too, and prints the whole set as one value.

Read the request from standard input

Write - in place of the file name:
The command prints the same lines as it prints for the file.

Use the requests

  • Seed test cases. Rate a seeded set, review the premiums, and keep each request with its premium. The seed rebuilds the same requests later. Test a rater adds independent expected premiums.
  • Feed a what-if tool. Load each input as a starting policy. Then change one value at a time and compare the premiums.
  • Check a request a host built. Run rslc inputs validate on the request in the tests of the host. Exit code 0 shows that the rater accepts it.