AuthBox documentation — User guide

Documentation embedded in this build.

How missions, obligations, and goals fit together

Three pages ask three different questions about the same restriction grammar, and the words are close enough — mission, obligation, goal — that it is easy to lose which is which.

A mission's restrictions are enforced, per request

A mission carries restrictions — attribute constraints, written in the same grammar an operation's own attribute clause uses — and they are checked live, every time a subject is evaluated for that mission. This is enforcement: decided per request, audited, receipt-carrying, and named on a denial. See How policy and missions fit together.

An obligation asks the same question as a standing compliance check

An obligation declares a set of clauses in the identical mission-restriction grammar — verbatim, never summarized — and asks them as a requirement, through the exact evaluator a real door goes through, over every member of a named population. It is a question, never a second gate: nothing that decides a request reads an obligation, and an obligation denies nobody. It answers what enforcement alone cannot: who is out of compliance right now, before anybody has even tried a door.

The obligation and the mission are deliberately two documents, and drift is the cost

Where you want a clause enforced, the identical clause also goes onto a mission's own restrictions — by copy, not by link. A link would make the obligations table a second input to the engine, which is exactly what the obligation design refuses (plan 081). The copy's cost is drift: the two documents can fall out of sync, and an obligation's own page states the comparison plainly — which mission, if any, currently carries the identical clause, and whether the two still agree. See Standing obligations for the full doctrine, including the four drift verdicts a report can reach.

A goal rolls up several obligations, across a tree, into one target

A goal names a set of obligations and a project — a tree of groups, not one group — and derives every number it shows from the obligation reports beneath it. It computes nothing of its own: no clause, no evaluator call beyond what each obligation's own page already makes. A goal's page can never disagree with an obligation's page, because there is no second computation to disagree with. Each row counts a unit's own direct members, the same reach an enforcing mission bound to that group would have, so rows can sum to more than the header when someone belongs to two units in the tree at once. See The console, page by page for the per-unit table a goal's own page draws.

   mission                obligation                  goal
  restrictions  ── copy ──▶  clauses          ┐
  (enforced,                (a question,      ├─ obligation reports ──▶ roll-up over
   per request)               drift-checked)   ┘   a project's whole tree

Where each fact lives