Put access rules in the same source as the work.
Declare who can enter an App, which resources it can reach, and who may continue a workflow paused for review.
Authority should be visible where the action is defined.
Model the roles in the real operation. Give each role the records, actions, and decisions it needs. Review the rule beside the App or workflow it governs.
The runtime applies the declared boundary.
The project states who may use the App and computes which named resources it can reach. A review step identifies the person or role authorized to continue the run.
Example: A client portal can expose one customer's records while an internal operations App reaches the full dataset, with each boundary declared in source.
Swirls owns the production work behind it.
Supported identity checks and runtime enforcement for the access declared by the project source.
Enter
Control who may open the hosted App.
Reach
Limit the named data and actions the App can use.
Approve
Send consequential decisions to an authorized person.
- App audiences
- Roles and responsibilities
- Resource access
- Human review
- Administrative access
You own
The roles, policy intent, resource boundaries, and the judgment that the design is right for the business.
Name the people and the authority they need.
Define what each role may enter, see, start, approve, and change before the system goes live.