Unit 10.00: Scoping the automation and its refusals

The capstone starts with a written scope, and the autonomy level is one of its fields.

Five checks on the scope

Volume, a non-empty never-does list, an explicit autonomy level, three outcomes, and observable success.

Below is a scope and checks it.

{
  "workflow": "invoice overdue checks for the finance team",
  "volume_per_month": 900,
  "answers_from": [
    "invoice records",
    "contract payment terms"
  ],
  "never_does": [
    "issue credits",
    "email customers",
    "change contract terms",
    "anything about an invoice it cannot find"
  ],
  "autonomy_level": "acts after explicit approval, for credits only",
  "success": "the analyst does not open the invoice system themselves",
  "outcomes": [
    "answer",
    "escalate",
    "refuse"
  ]
}
  OK   volume justifies a build
  OK   never-does list is non-empty
  OK   autonomy level is explicit
  OK   there is a third outcome
  OK   success is observable

autonomy_level is stated as a sentence rather than a label: "acts after explicit approval, for credits only". That phrasing carries the scope of the autonomy as well as its level, which a single word like "supervised" does not.

success is observable - the analyst does not open the invoice system themselves. That can be false while every internal metric looks good, which is what makes it worth stating.

The mistake this prevents

The mistake is writing the scope after the prototype. Written afterwards every constraint is one the system already satisfies, so it rules nothing out - and ruling things out is the only thing a scope does.

Takeaway

Write the scope first with an explicit autonomy level, a never-does list, three outcomes and an observable success criterion.

Mark complete