How rule books work

Note

This is a beta feature. Reach out to Nash if you'd like early access.

A rule book keeps your planning rules in your words: what Nash needs to plan, what routes must and should do, and what is still open. For each rule it shows how Nash treats it and who in your organization confirmed it. It's also where you see how your optimization runs did against those rules.

You find rule books under Orchestrate ▸ Rule Books, next to optimization strategies. For the click-by-click — finding a rule, checking a run, exporting a version — see review a rule book and check runs.

How it works

Nash builds a rule book with you from what you've told it and the files you've shared: route sheets, operating documents, answers on calls. Each rule keeps your wording, the value it holds at each site, where it came from, and who agreed to it. Nash writes and changes rule books; in the portal the page is for reading, checking runs, and exporting.

A rule book is linked to the optimization strategies whose runs it covers. The header lists them — used by 2 strategies, like … — or says no strategy plans with it yet. Runs from those strategies show on the rule book's Runs tab, where each can be checked against the rules.

A check reads a run's saved routes and grades each rule: met, missed, or couldn't be graded. It reports and blocks nothing — a missed rule doesn't stop you saving or dispatching routes, and a check never changes a route.

An organization can have more than one rule book. Switch rule book in the header moves between them.

What's in a rule

Each rule is a row with three columns: Rule (its name and key), In Nash (how Nash treats it, and the value it runs with), and Status (whether it's confirmed). Open a row to see the rest.

In Nash says how Nash treats the rule:

Status says where the rule stands with you:

A rule with values per site lists each site with your value, the value Nash runs with, and that value's own status — so one site can be confirmed while another still needs an answer.

When any rule in the book isn't confirmed, the header shows a Not yet confirmed badge.

Where a rule came from

The opened rule shows its sources under In their files and From calls and answers. A file source points at the spreadsheet cells, file columns or document the rule was read from, with Open the source to go to it. A spoken or written source names the call or answer and its date.

Some sources read As recorded by the author; not checked against the file yet. That means the excerpt is what Nash wrote down, and nobody has matched it against the file.

How Nash runs it

For a rule Nash carries, the opened rule has a How Nash runs it section: how Nash reads the rule into planning — what it reads, where it applies, how firmly it holds it (Must hold, Aims for it), and any open questions. Nash maintains this mapping. It can read:

• Nash hasn't mapped this rule yet.

• Nash hasn't reviewed this mapping yet.

• Accepted by a named person, with when.

• The rule changed after Nash mapped it. Nash needs to map it again.

A mapped piece can also read Nash can't plan this yet, Not used or Same as another.

Confirmations

A confirmation records that a named person agreed to one wording of a rule: who, their role, how (On a call, By email, In writing, In a meeting, In the portal), the day, and who recorded it. The opened rule lists them under Confirmations.

A confirmation covers the wording it was given for. When a rule's wording changes, its status goes back to unconfirmed and the row says who confirmed the earlier wording — for example Sam confirmed v3 — while the opened rule says This wording needs confirming again. A confirmation that came while some values were still open reads Covers the settled values; 1 still needs an answer.

Versions and drafts

A rule book has numbered versions. The header says which one is in use — v4 · published — and, when Nash has opened a newer draft, draft v5 opened … not published yet. The page shows the version in use. Before anything is published, it shows the first draft and reads Not published yet, and there's no Runs tab.

Rows the version changed are marked New in v4 or Changed in v4.

Export downloads the version on screen as a JSON file.

Checking runs

The Runs tab lists runs from the last 14 days of the strategies that use the rule book, each with when it ran, how many routes it saved, and its strategy. A run reads Not checked yet until someone checks it.

A check grades the run's saved routes against the version in use. Each rule gets one outcome:

The run's line sums it up — 2 rules missed, 1 rule not applied yet, Every checked rule met, or No rules checked yet when the check graded nothing. Problems the check found that no rule in the book owns show as findings outside the rule book: they come from the run's own settings.

A check counts for the version it graded. When a newer version is published, older checks read Checked against another version until you check again.

The Runs tab label also shows how the newest checked run did — for example 2 missed — so a miss shows even from the Rules tab.

Preview changes on a run shows what the rule book changes in that run's settings: each rule with the number of vehicles it changes, the rules Nash can't plan with yet, and the rules it skipped and why (mapped for an earlier wording, report only, or no vehicle of the run in scope).

In the optimize drawer

When you optimize orders with a strategy that's linked to a rule book, the drawer shows a Rule book card on Review, and on Verify where your drawer has that step. A check grades saved routes, so until the run's routes are saved the card reads Checked once the routes are saved. Once they are, the card checks the run on its own for a user who can check runs — once per run and version — and lists each missed rule with how many of the run's routes it missed on, and how many rules it checked. Open in the rule book opens that run on the rule book's Runs tab in a new browser tab.

Who sees what

• Rule books need permission to view optimization strategies. Without it, the page reads You can't see rule books; ask an admin in your organization for it.

• Checking a run — Check against this rule book, Check again, and the drawer's automatic check — stores a check, so it needs permission to edit optimization strategies. Without it you can still read the rules, existing checks and previews.

• Users whose access is limited to specific locations don't see rule books.

Edge cases

A check fails with "No routes were saved from that optimization run." A check grades saved routes. Save the run's routes, then check it.

A check fails with "That run's problem can't be rebuilt, so it can't be checked." Nash couldn't reconstruct what the run was solving, so that run can't be graded.

A run reads "Uses mappings Nash hasn't reviewed yet." At least one outcome comes from a mapping Nash hasn't reviewed yet.

Some routes couldn't be checked. The outcome table says how many. The rest of the run is still graded.

A link to a rule says it's in an unpublished draft. The rule exists in the open draft but not in the version in use. It shows once that draft is published.

What affects this

A rule book checks the plan. Nash dispatches the routes; a provider or your own fleet performs the delivery.