Routing rules
When a document arrives, someone has to decide who reviews it. On a small team that decision is obvious. At an industrial manufacturer ingesting thousands of inspection reports, datasheets, and machine logs a week, doing it by hand is where the backlog starts. Routing rules make that decision for the organization, the moment a document lands, so reviewers open their queue and find work that already belongs to them.
A routing rule says, in effect, "documents that look like this go to that team or that reviewer." Piprio evaluates the rules automatically as documents are ingested. No one has to triage an inbox.
Rule structure
A rule has two halves: the conditions that decide whether it matches a document, and the action that decides where a matching document goes. Each rule also carries a priority number that controls the order rules are checked in, and a state that marks it active or retired so a rule can be paused without being deleted.
A rule can be authored by an administrator, or learned by Piprio from how the team has assigned similar documents in the past. Both kinds are described later. They are evaluated as equals, so a learned rule never quietly outranks one a person wrote, or the reverse.
Creating, editing, and retiring rules is limited to senior reviewers, data stewards, administrators, and owners. Reviewers below that level receive the work the rules produce but do not change the rules.
Conditions
A rule matches a document when every condition it sets is satisfied. A rule can set any combination of three conditions, and a condition left blank matches everything.
The conditions are:
- Source connector. The connector the document came from. A rule can target one named source, so documents from a specific shared drive, mailbox, or storage bucket route differently from documents elsewhere.
- File type. The document's extension, such as PDF, CSV, or log. This is how an organization separates, say, scanned inspection reports from spreadsheet exports.
- Source team. The team that owns the connector the document came from. This condition matches on the connector's owning team, not on whoever currently holds the document, so an organization can route by which group manages the ingestion source.
A rule with no conditions set matches every document, which is a deliberate way to write a catch-all fallback at low priority.
Actions
A matching rule assigns the document one of two ways.
It can assign to a team. When it does, Piprio picks the individual reviewer for the organization: the team member holding the fewest active review assignments at that moment. If two members are tied, the one who joined the team earliest takes the document. So a rule that names a team also balances load across that team without anyone deciding case by case who is least busy.
Or it can assign directly to a named reviewer, when a particular person owns a class of document.
Priority and conflicts
Rules are checked in priority order, lowest number first. The first rule that matches wins, and evaluation stops there. A document is never routed twice by the rule engine.
Priority is what resolves overlap. A specific rule and a broad rule can both match the same document. Giving the specific rule a lower priority number makes it win, while the broad rule still catches everything the specific one misses. New rules are created at a default priority of 10, which an author can change at creation time. Manually authored and learned rules sit in the same ordering with no built-in advantage for either.
A rule that targets a team but finds the team empty cannot complete the assignment, and the document is held rather than placed with no one. Retired rules are skipped entirely.
When a reviewer or team lead decides a routed document does not belong to them, they can hand it back. Marking it "not mine" returns it to the team queue. A team lead marking it "not my team" sends it back to the organization's unassigned queue. Piprio records each of these against the rule that placed the document, so the organization can see how often a given rule's assignments are later overturned and tune or retire rules that route poorly.
Impact preview
Before saving a rule, an administrator can preview its reach. The preview reports how many existing documents the rule's conditions would match, split into two numbers: how many of those are not yet routed by any rule, and how many already carry a routing assignment. It also returns a short sample of matching documents, with their names and current labeling status, so the author can confirm the rule catches what they intended.
The point is to catch a too-broad or too-narrow rule before it is in force, rather than discovering after the fact that a rule swept in ten thousand documents or none. The preview reads existing data only and changes nothing.
Learned rules
Piprio watches how reviewers assign documents by hand and proposes rules that would reproduce those patterns. A proposal carries the count of times the pattern was observed and a confidence figure. An administrator can approve a proposal as-is, edit it before approving, or dismiss it. A dismissal is per-administrator, so one person clearing a suggestion does not remove it from a colleague's view. An approved proposal becomes an ordinary rule and evaluates alongside the ones people wrote.
Examples
A rule routing every PDF from a specific connector to a specialist team, which then balances the work across that team:
Conditions:
Source connector: Quality-Drive
File type: pdf
Action:
Assign to team: Engineering Specialists
Priority: 10
A rule sending everything from one connector straight to a named senior reviewer, ahead of broader rules:
Conditions:
Source connector: Quality-Inspection-Reports
Action:
Assign to reviewer: M. Bauer
Priority: 5
With both rules active, an inspection-report PDF from the Quality-Inspection-Reports connector goes to M. Bauer, because that rule has the lower priority number and is checked first. A PDF from the Quality-Drive connector falls through to the first rule and lands with the least-loaded member of Engineering Specialists.