Authorization belongs in the command pipeline

What the public implementation shows

Guevara defines an Authorize attribute and AuthorizationBehavior in the application pipeline, with known claims, role claims, permissions endpoints, and an API operation filter.

Authorization metadata travels with commands and queries while the pipeline enforces it before business handling. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleSensitive operations need one enforceable authorization path, not conventions repeated by controllers.

The decision behind the mechanism

Pipeline enforcement reduces the risk that one controller or new endpoint forgets a role check.

Controller-only checks can be bypassed by another invocation path or copied inconsistently across operational functions. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Declare required operations on commands and queries.
• Enforce them before handler execution.
• Keep role-to-claim administration permissioned.
• Log denials without exposing sensitive request content.

How the control should be operated

Claims should represent concrete operations, be assigned through governed roles, cached carefully, and audited when changed or denied.

Participant, certificate, settlement, report, and user operations share one authorization model. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.