Access Metadata (Open)
Retired workflow modes and the unresolved access-record, sharing, locking, and inheritance boundary.
Workflow modes are retired
There is no Ask, Edit, Build, fill, edit, or build workflow mode. The
retired system bundled three independent questions that now have separate
answers:
| Question | Current model |
|---|---|
| Who is this person? | Owner-granted role: Reader, Maker, or Builder |
| What may they do? | Capabilities derived from the effective role |
| What are they looking at? | The document — the one venue (One venue) |
The current model is authoritative at
Permissions and Visibility. Do not
author modes.supports, modes.default, uiMode, or a mode condition — and
do not author placement either: display.targets and display.surfaces are
both retired (2026-08-25), because every folio item lands on the document.
Conditional inclusion uses actual document data in flow.condition.
What survives of "what are they looking at" is Goldie's posture — agent-led collection or user-led editing — carried by navigation rather than stored on the document, and itself an open owner question. Access still clamps what a person may reach.
Builder is a role, not a mode
The retired system had a Build mode. The current model has a Builder role.
A Builder receives capabilities including write-structure, see-code, and
see-modules; nothing is activated by switching the document into a mode.
Capability names describe the mutation rather than the person:
write-datafills fields. Since 2026-09-11 it no longer works the document's own content; see Maker Fills, Builder Builds.write-structurechanges field declarations and modules, classifies and and inserts reusable content from the library.
Access metadata
Open question — no authored access schema yet
The shape of access is not settled. Current Convex rows preserve broad
access: v.any() placeholders, but that is migration accommodation rather
than an authoring contract. Do not author or build against access.share,
allowReshare, access.locked, or a document → module → block cascade as if
those names and relationships were decided.
Three questions are still open, and nothing may be authored against a guess at any of them:
- Per-person document access — owner grants, effective role, and access requests.
- Sharing and discovery posture — private, workspace, link, public, and library are not automatically one permission axis.
- Authored structural locks — answered 2026-09-11: there are none. A Maker never edits a block, so no per-folio constraint is authored (Maker Fills, Builder Builds).
- Administrative hard locks, if needed — the Document-tier
access.lockedoverride that strips every write capability; whether it belongs on an access record is still open. - Scope and inheritance — whether any setting belongs on documents, modules, blocks, standalone reusable objects, or an external access record; and which values, if any, cascade.
Until those decisions land, the only settled permission rule is role →
capabilities. Existing UI gating is not server-side enforcement, and an
open-ended stored access value is not evidence for a public YAML shape.
Cascade and inheritance
This is part of the same open question. Do not assume CSS-like document → module → block inheritance. Per-person role grants naturally belong to a document access record, while an authored block lock naturally belongs to the template structure; forcing both through one cascade would conflate identity authorization with authored legal constraints.