Five processes usually worth building a system around

A process is worth building a system around when it repeats, when the rules exist somewhere even if nobody wrote them down, and when the record of what happened matters to somebody other than the person doing it. Five processes meet that test more often than any others we see: quoting, intake, document review, reconciliation and renewals.

Volume matters less than people expect. A process that runs a few times a day and takes real judgement* is often a better candidate than one that runs constantly and takes none.

What the good candidates have in common

• It repeats: The same kind of request arrives again and again, in whatever shape the sender chose, and somebody makes it fit the business.
• The rules exist: Even if nobody wrote them down. They live in a spreadsheet, an email folder, or the head of the person who has done it longest.
• The record matters: To somebody other than the person doing it: an auditor, a client, a regulator. (how we check)

The test

Three ways the same process is handled today, and what each one misses:

• By memory: The person who has done it longest knows the answer, and nobody else does.
• By the manual: The written procedure, applied exactly, without the exceptions.
• By the blueprint: The rules as they are really applied, written down, with a person holding every decision that needs judgement.

Three of the five, side by side

The same three properties hold in each of the five, which is why one method works on all of them, in industries that have nothing in common. The work changes; how we build it does not.

They are also where the exceptions are densest. To handle them reliably, a system has to find the exact rule that applies and reason over the case in front of it, instead of producing a plausible answer.

*Illustrative.

Quoting and estimating

Priced from a company's own history, its own rules and its closest past jobs, and drafted for a person to approve. The knowledge is already there; it is just not searchable, and the closest past job usually sits in an estimator's folder*.

*Illustrative, from a single engagement.
**A system built from the manual only sees the rules that were written down, so it is scored on those alone.

Intake and document review

Intake is where information arrives in whatever shape the sender chose, and somebody makes it fit the business. Document review is the same problem with more pages and a deadline. This is usually where the exceptions are densest, which is why it repays the mapping rather than the modelling: 128 contract clauses, read against a company's own standard wording.

*Scored on the rules that were written down. Illustrative.

Reconciliation and renewals

Reconciliation is the clearest case of all: two records that should agree, a rule for what to do when they do not, and an exception queue nobody enjoys. Renewals follow the same pattern: a date, a set of rules, and a business that loses money quietly when they slip. They also carry the exceptions that make a customer feel known.

*Illustrative: 232 breaks across 8 ledgers holding 8,000 accounts.

Three questions

Who does it today, and what do they know that nobody else does. Which systems does it read and write. And if it went wrong, who would need to be able to see why. If those three have answers, the process can be built around. If they do not, the first piece of work is finding them, which is a scoping session rather than a build.

Writing a rule into the blueprint

from blueprint import Process

process = Process.open("renewals")
rule = process.rules.add(
    name="Fleet re-rate",
    applies_when="vehicles >= 40",
)
source = process.rules.cite(
    rule.rule_id,
    interview="underwriting-desk-0412.txt",
    confirmed_by="Head of Underwriting",
)
matches = process.rules.search(
    query="When is a fleet re-rated at renewal?",
    rule_ids=[rule.rule_id],
    mode="blueprint",
)

Checking a case against it

from blueprint import Process
from blueprint.review import case, approver
from blueprint.checks import rules_check

process = Process.open("renewals")
run = process.cases.check(
    record="FL-2214",
    steps=[
        case("Renew fleet policy FL-2214 on last year's terms."),
        approver("Head of Underwriting"),
    ],
    checks=[
        rules_check(
            rule_ids=["rule_fleet_re_rate_40"],
            mode="blueprint",
        ),
    ],
)

Reading the audit trail

curl -X GET https://audit.client.internal/v1/records/FL-2214 \
  -H "Authorization: Bearer $CLIENT_AUDIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "Why was FL-2214 held for underwriting?",
    "source": {
      "rule_ids": [
        "rule_fleet_re_rate_40"
      ]
    },
    "include": { "type": "approvals" }
  }'

*Judgement here means a decision a person would be asked to explain later.