Noumena's authorization concept separates two things that regulators like to see kept apart. What are they?

Functional rights — WHAT actions a user may perform — are kept separate from access scope — WHICH data or protocol instances they may touch.

* A party's access is the intersection of the two axes: a claim = one functional right ANDed with one access scope. *

A robust authorization concept is central to any regulated enterprise solution (think ISO 27001 certification or a financial-service licence, which require reports on "who has what right"). Noumena's approach separates two orthogonal questions:

• Functional rights — what a user can do: trigger a payment, approve an onboarding, override a setting.
• Access scope — which records the user may do it on: this customer, this region, everything.

Regulators appreciate this because putting authorization at the heart of the design, and splitting capability from data reach, makes it auditable and makes least-privilege enforceable. The two are represented as claims and only become useful when combined in a party on a protocol.

Go deeper:

• Separation of duties (Wikipedia) — why splitting a task across parties (no single actor holds it all) is a core anti-fraud control regulators expect.
• Principle of least privilege (Wikipedia) — the reason to keep rights and scope tight and separate: grant only the minimum needed.