Guided implementation
From the boundary to a verifiable result.
- 01
Define the effect before the interface
C0 reads or presents, C1 proposes, and C2 prepares a real change only after an explicit yes. Higher classes are closed to third parties.
- 02
Describe a declarative display
Choose one of the six supported layouts and use only documented column types.
{ "schema": "clarity.tool/v1", "name": "Study outline", "entry": "study.outline", "consequenceClass": "C1", "permissions": [ "profile.read" ], "display": { "layout": "list", "icon": "list.bullet.rectangle", "color": "blue", "columns": [ { "name": "Outline item", "type": "text" }, { "name": "Done", "type": "toggle" } ] } } - 03
Validate on the server
The sandbox deterministically rejects unknown layouts, types and permissions. A preview does not execute anything.
- 04
Explain the review request
Submit the name, version, summary, manifest and consequence class. Approval is a human decision and remains revocable.
Complete when …
- Only profile.read or sessions.read is requested
- The manifest contains no secrets
- Empty and error states are described
- C2 includes a preview and explicit approval
