01 · Resource
What exists
Data, files, tools, workflows, UI components, models, agents, identities, and derived outputs.
Working standard · v0.1
Capability-Driven Generative UI
Software can expose resources, data, tools, and workflows through explicit capabilities. Agents compose the interface around the user’s goal, identity, context, and authorized actions.
Agents may compose interfaces freely, but they may compose capabilities only from an explicit, inspectable, enforceable permission set.
The model
A permission table alone is too coarse. The standard needs distinct primitives that describe who is acting, what exists, what can happen, and how the result is presented.
02 · Principal
Who acts
A person, agent, service, group, or organization requesting access or execution.
03 · Capability
What can happen
Discover, read, create, update, delete, execute, share, or delegate.
04 · Policy
What is allowed
The rule connecting a principal, capability, resource, scope, and conditions.
05 · Presentation
What the user sees
The runtime interface projected from the authorized capability set and current state.
06 · Receipt
What happened
An inspectable record of the decision, confirmation, action, result, and reversibility.
Permission is a structured statement
Represent each rule as a statement rather than a wide matrix. This supports expiration, purpose limits, approval, delegation, and input-level restrictions.
principal
may perform operation
on resource
within scope
under conditions
user:john
may execute
tool:send_email
using data:john.contacts
for purpose:job_outreach
with condition:confirm_before_send
Discovery and access are different
A person can know that a capability exists without being allowed to inspect its contents or invoke it.
| State | Discoverable | Readable | Executable | Meaning |
|---|---|---|---|---|
| Hidden | No | No | No | The resource is invisible. |
| Listed | Yes | No | No | The resource exists, but its contents and actions are unavailable. |
| Inspectable | Yes | Schema only | No | The user can understand the interface without receiving data. |
| Usable | Yes | Optional | Yes | The capability can be invoked within its declared limits. |
Tools are resources
A tool should be self-describing. The agent receives a catalog of possible actions, while policy determines which actions it may actually use.
{
"type": "capability",
"id": "calendar.create_event",
"description": "Create a calendar event",
"inputs": {
"title": "string",
"start": "datetime",
"end": "datetime",
"attendees": "contact[]"
},
"side_effects": ["creates_external_commitment"],
"risk": "medium",
"requires": ["calendar:write"],
"confirmation": "required"
}
Generated UI is a policy projection
The interface should expose the smallest useful surface for the current goal. It should never invent an access rule.
User goal
→
Resource + capability registry
→
Policy decision
→
Generated UI
User interaction
→
Enforcement point
→
Tool or data operation
→
Audit receipt
Security boundary: the generated UI is not the enforcement layer. The backend must evaluate the final action again when it executes.
Risk changes the interaction
Read and write do not describe consequence. A policy should account for sensitivity, external impact, reversibility, financial impact, and social impact.
Execute directly
Examples include reading a public document or converting a file locally.
Preview the change
Show the affected records, recipients, or commitments before execution.
Require explicit confirmation
Examples include sending an email, publishing content, or changing shared data.
Use stronger controls
Require confirmation plus step-up authentication or human review for financial transfers, destructive operations, or physical access.
Approval is a condition
“Approved” should not become unlimited access. An approval should identify its scope, purpose, expiration, and revocation path.
{
"operation": "write",
"principal": "other_user",
"resource": "my_data",
"condition": {
"approval": {
"required": true,
"scope": "this_action",
"purpose": "shared_project",
"expires": "2026-09-02T18:00:00Z"
}
}
}
Receipt format
Every consequential action should produce a durable receipt that explains the authorization decision and the resulting state.
{
"actor": "agent:personal",
"capability": "calendar.create_event",
"resource": "calendar:john",
"decision": "allowed",
"confirmation": "user_confirmed",
"timestamp": "…",
"result": "event_created",
"reversible": true
}
Proposed standard vocabulary
1
Resources are inspectable
Users and agents can understand what data or tools exist, subject to discovery rules.
2
Capabilities are explicit
Every action has a named operation, schema, side-effect declaration, and risk level.
3
Policies are enforceable
Authorization is evaluated at the execution boundary, independent of the generated UI.
4
Interfaces are projections
The UI adapts to goal, state, identity, and authorized capabilities.
5
Risk is visible
The interface previews side effects and requests stronger confirmation as impact rises.
6
Actions leave receipts
People can inspect what happened, why it was allowed, and whether it can be reversed.