A central authorisation decision point

The previous three lessons gave you three correct fixes: ownership in the WHERE, deny-by-default in the pipeline, a separate input DTO. All three are local — they fix one endpoint or one setting. The question in this lesson is: when the rule grows past "the owner", where do those three get you?

Let the rule grow the way it grows in a real project:

1. "A user can read their own orders." → one WHERE clause. Done.
2. "Admins can read every order." → WHERE ... || user.IsAdmin. Still fine.
3. "Support can read orders for customers with an open ticket." → the clause now wants a JOIN.
4. "Accountants can read completed orders, in their own company, in a financial year that is not closed." → stop.

At step 4 there are three problems, and only one of them is about query length:

• The rule is now duplicated. It appears in the read endpoint, the export endpoint, the report, and the email job. Four copies, and they will drift.
• Nobody can read the rule. It is spread across four LINQ expressions. The question "who can read an order?" has nowhere to be answered — including for you, six months from now.
• Nobody can test the rule. Testing "an accountant cannot read another company's order" means going through HTTP, four times, for four places.

A central decision point answers those three — and it is worth being explicit about what it does not answer: it does not replace the WHERE clause. A CanRead(user, order) returning true still needs a filtered query, otherwise you are back to filtering-after-fetch with every one of its drawbacks.