Components · Authorization
Authority Gate
The five authority layers for one action, the version being approved, and the approve control. When a premise changes, the control stops being operable, says why, and a review control appears beside it.
Overview
This compact fixture shows the renderer inside the shared contract. The richer gallery below exercises additional states without changing the resolver’s authority.
States
Each state is live and resolved from contract fields. The indicator checks both the complete Representation Plan and the rendered DOM. Missing coverage is reported separately.
| May claim | Must not claim |
|---|---|
| Who may approve which version. | Approval of anything but the version shown. |
Anatomy
01 · Five independent layersTechnical capability does not imply policy permission.
02 · Version-bound approvalApprove v3 cannot authorize v4.
03 · Stationary stale controlThe old button remains, becomes non-operable and gains an explanation.
The live specimen above follows these regions in reading order. Change a state to inspect the same anatomy under a different work condition.
Usage and avoid
- Put the version in the button: “Approve v3”.
- Show all five layers, including the ones that pass.
Avoid
- Don’t turn “Approve v3” into “Approve v4” under the pointer. Disable it and offer a review beside it.
When not to use
Permissions management. The gate shows authority for one action.
Contract
A component without this contract may wear Lyotic’s style; it does not implement Lyotic.
| Semantic inputs | A proposal with authority layers and version; the plan’s controls |
|---|---|
| Allowed states | needs-approval, permitted, stale, blocked |
| Forbidden states | An operable approve on stale or blocked authority; approving an unshown version |
| Evidence requirements | Layer values come from the application, never from agent text |
| Action scope | approve:<id> bound to a version; recheck; edit |
| Meaning of authority | Is the authority display; re-validated at execution |
| External effects | Approval enables execution, which re-validates |
| Verification conditions | None |
| Failure and recovery | Stale approval: explained, disabled, re-check offered (INV-03, INV-04) |
| Transitions | Approve → execute; premise change → stale → recheck → approve again |
| Accessibility | Disabled controls stay focusable with their reason; the bound version is in the button text |
| Observable events | ly-action approve with boundVersion |
| Test conditions | INV-03, INV-04; validateAtExecution |
Live boundary check
Use “Test a forbidden control” below the gallery. The checker receives an intentionally invalid, detached specimen and reports INV-03. No unsafe control is inserted into the live Work Case. This tests a boundary rather than teaching an unsafe success state.
In the Work Case
The same renderer below runs inside the existing anchored Work Object Shell. These are illustrative fixture states, not live business operations.
Accessibility
Keep action names, reasons, scope and state available to keyboard and assistive technology. Background updates preserve focus and control identity; reduced motion keeps the same semantic result.
Code
authorityGate(proposal, plan)