# Open Workplace Protocol, Working Draft 0.1 Status: Working Draft Protocol identifier: `open-workplace/0.1` This document defines candidate normative behavior for agents and implementations that interpret a declared Open Workplace. The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY indicate requirement strength. The [architecture](architecture.md) owns the model described by these rules. An [implementation profile](profiles.md) maps the model into a representation. The [reference scenarios](reference-scenarios.md) exercise observable behavior. ## 1. Scope The protocol governs: - protocol and profile availability; - Workplace discovery and orientation; - authority and source resolution; - context reduction; - Material lifecycle; - Site and Route boundaries; - provider projections; - degraded operation; - delegation and multiple Occupants; - visible conflicts and limits. The protocol governs interpretation of a Workplace. It does not grant host permissions, execute tools, control a model, select a storage engine or create a security boundary. Implementation-specific product workflows are outside this Protocol. In particular, Endroit's Work Resolution lifecycle is an Endroit extension. An agent or implementation MUST NOT treat it as an `open-workplace/0.1` requirement or require another Profile to expose it. ## 2. Terms | Term | Meaning | | --- | --- | | Workplace | A durable place with identity, ownership, composition, time and sovereignty. | | Workspace | An execution or editing scope that may provide evidence for one or more Workplaces. | | Home | One concrete Workplace, shared constitution and trust boundary. | | Profile | A versioned declaration that maps Open Workplace responsibilities into one implementation. | | Instance | One declared Home and its owned sources under a Profile. | | Source | Material that an owner or Profile declares authoritative for one responsibility. | | Projection | A derived representation prepared for an interface, provider or runtime. | | Typed context | Context whose nature, owner, scope, status, provenance and authority can be recovered for interpretation. | | Resolved Workplace Context | The conceptual orientation result used by an Occupant for one Meeting. | | Candidate | An inferred Workplace boundary that no declared Instance has established. | | Conflict | Two incompatible claims to the same responsibility and authority. | | Limit | A missing capability, inaccessible source or unsupported model concept. | The object definitions in [Architecture](architecture.md#objects) apply throughout this protocol. ## 3. Protocol availability A session MUST have access to the semantics of this protocol before it claims to resolve an `open-workplace/0.1` Instance. An implementation MAY provide the protocol through: - a local Markdown source; - a versioned public document; - a provider instruction or lifecycle hook; - a generated Front Door that contains or identifies the same semantics. The delivery mechanism MUST identify the protocol version. A cached or bundled copy MUST keep enough provenance to identify its source version. Loading the protocol does not create a Workplace, authorize filesystem inspection or establish local truth. A Profile and an Instance supply the representation and facts. If the protocol version cannot be identified, the agent MUST report the limit and MUST NOT claim a resolved Open Workplace context. ## 4. Authority layers The protocol distinguishes four authority layers: ```text Open Workplace Protocol semantic responsibilities and behavior Implementation Profile representation, discovery and resolution Workplace Instance local identity, Guidance and Material Site external history, permissions and delivered truth ``` An agent MUST resolve a claim through the layer that owns it. - The Protocol owns model meaning and interpretation rules. - A Profile owns its mapping, projections and declared limits. - An Instance owns its local constitution, domains and Material. - A Site owns external truth and the result of delivered effects. A lower layer MUST NOT redefine the semantics of a higher layer while claiming the same protocol version. A higher layer MUST NOT claim ownership of local or external facts that belong to an Instance or Site. Provider memory, session history and generated projections MAY supply evidence or convenience. They MUST NOT become local truth unless the responsible human moves their content through the declared Material lifecycle. ## 5. Candidate and declared Workplace A visible workspace, repository or file set MAY support recognition of a candidate Workplace. Path visibility alone MUST NOT establish a Home, authority boundary or implementation Profile. A declared Workplace Instance MUST provide: - a Home identity; - an implementation Profile and targeted protocol version; - authoritative sources for the responsibilities it represents; - a way to identify the current human Member or report that none is known; - a way to resolve relevant Rooms and Sites; - declared limits for unsupported or unavailable concepts. An environment without these declarations remains a candidate. The agent MAY describe candidate boundaries through the [transposition process](transposition.md), subject to human-approved inspection roots. The agent MUST NOT present an inferred candidate as current Workplace truth. ## 6. Profile requirements A Profile that targets this draft MUST disclose: 1. its identifier and version; 2. the Open Workplace protocol version it targets; 3. how an agent discovers a candidate Instance; 4. how the Profile identifies the Home; 5. how it maps represented objects and relationships to sources; 6. how it composes Guidance and resolves conflicts; 7. which files, records or views are projections; 8. how it represents Material lifecycle; 9. how it declares Sites and Routes; 10. how an agent operates when Profile tooling is absent; 11. which concepts the Profile cannot represent; 12. how a human or tool can validate the Instance. A Profile MUST separate source authority from projection convenience. It MUST expose enough provenance for an agent to locate the owner behind a projected instruction. A Profile MAY extend the model with implementation concepts. It MUST label those concepts as extensions and MUST NOT assign them Open Workplace meaning without a protocol revision. ## 7. Entry and orientation An agent entering a declared Workplace MUST resolve orientation before consequential work. ```text identify protocol ↓ identify Profile and Instance ↓ resolve Home ↓ resolve Member and Desk ↓ select relevant Room ↓ establish or identify Meeting ↓ load relevant Guidance, Material, Equipment, Sites and Routes ↓ report orientation status and limits ``` The agent MUST follow the Profile's discovery boundary. It MUST NOT widen filesystem or service inspection because an inferred relationship exists outside that boundary. The agent MUST identify the current Home before interpreting Home, Desk or Room Guidance. It MUST identify the owner and lifetime of loaded Guidance when the Profile exposes them. The agent SHOULD select the smallest Room scope that contains the human's current objective. If two Rooms remain plausible, the agent MUST expose the ambiguity or request direction before placing durable work. The agent MAY begin an ephemeral Meeting when the implementation does not persist Meeting state. It MUST NOT infer a durable lifecycle transition from session creation. ## 8. Resolved Workplace Context The orientation result is a conceptual Resolved Workplace Context: ```text status protocol identifier and version Profile identifier and version Home identity Member and Desk current Room and Meeting authoritative sources with provenance available Equipment declared Sites and Routes limits and unresolved conflicts ``` This draft defines meaning, not a serialization. The `status` field has one value: | Status | Meaning | | --- | --- | | `candidate` | Evidence suggests a Workplace, but no declared Instance establishes it. | | `resolved` | The Profile and sources establish the context required for the current work. | | `degraded` | The sources remain usable while validation, projection or runtime support is unavailable. | | `ambiguous` | Conflicting or missing authority prevents safe resolution. | An agent MUST report `candidate` when it has inferred boundaries and no declaration. An agent MAY report `resolved` when the current objective does not require optional Profile features and all relevant authorities are known. An agent MUST report `degraded` when it continues without a declared validator, projection or runtime feature. It MUST name the missing capability and any resulting limit. An agent MUST report `ambiguous` when two sources claim the same responsibility with incompatible content, when the Home identity conflicts or when the destination for durable work cannot be resolved. ## 9. Source resolution An agent MUST resolve sources by responsibility, owner, audience, lifetime and authority. File proximity and filename familiarity do not establish precedence. For each relevant responsibility, the agent MUST: 1. identify the object that owns the responsibility; 2. use the Profile to locate its source; 3. retain source provenance in the Resolved Workplace Context; 4. determine whether other sources compose with or conflict with it; 5. report unresolved conflict before acting on the disputed responsibility. Shared Home Guidance and personal Desk Guidance can compose because they have different owners and audiences. A Room can narrow the domain working set without taking ownership of the Home constitution. A Meeting can add temporary instructions without making them durable. A Profile MAY define deterministic composition for sources with distinct responsibilities. It MUST NOT hide two incompatible claims from the same authority behind a generated order. When a projection conflicts with an owned source, the agent MUST use the owned source, report projection drift and avoid editing the projection as if it were the owner. When an authoritative source is inaccessible, the agent MUST record the limit. It MUST NOT reconstruct missing truth from provider memory. For every relevant source whose Profile exposes them, the Resolved Workplace Context MUST preserve its nature, owner, scope, status, provenance and authority. The agent MUST use those properties to decide whether the source may inform, constrain or authorize the current action. It MUST NOT flatten accepted truth, retained evidence, temporary Guidance, Site truth and generated projections into equivalent text. When one of these properties is required for the current action but cannot be resolved, the agent MUST report the missing property as a limit. A projection MAY reduce the working set for one Role or objective, but it MUST preserve the provenance and authority needed to recover the owning source. ## 10. Context reduction An agent SHOULD load the smallest owned context that supports the current Meeting. It SHOULD begin with: - the Home identity and shared constitution; - the current Member and Desk Guidance; - the selected Room mission and relevant Material; - Equipment activated for the task; - Sites and Routes involved in the expected destination. It SHOULD NOT load unrelated Rooms, archived Material or every reachable Site as a default orientation strategy. The agent MAY inspect more Material when the task or an ambiguity requires it. It MUST preserve the existing authority and inspection boundaries. A summary or retrieval system MAY reduce token use. The system MUST preserve source provenance and MUST expose when the agent has received a summary rather than the owned source. ## 11. Meeting and Material lifecycle Each execution result begins as an ephemeral candidate inside a Meeting. ```text ephemeral → retained → accepted → delivered └────────────→ archived ``` An agent MUST NOT retain, accept, deliver or archive Material without a human request or another authority mechanism declared by the Workplace. Acknowledgement, praise, continued discussion and selection of a candidate MUST NOT imply a lifecycle transition. A transition MUST identify: - the Material; - the destination owner; - the requested lifecycle state; - the scope of any mutation; - the external destination for delivery. Retained Material MUST remain distinguishable from accepted truth. Acceptance MUST NOT imply delivery. Delivery MUST record an effect observed in the Site, not an intended or attempted effect. An agent MUST report a failed or partial transition without promoting the requested state. ## 12. Sites, Routes and external effects A Site remains sovereign when it appears inside the Home filesystem, shares a repository or has a local checkout. A Route declares a relationship and access path. It does not grant host permission or human consent. Before an external effect, the agent MUST: 1. identify the target Site; 2. resolve the applicable Route; 3. revalidate the Route when the implementation supports validation; 4. state the concrete effect and destination; 5. obtain the required human authority; 6. observe and report the Site result. If the Route is stale, unavailable or points to an unexpected target, the agent MUST stop the effect and report the mismatch. The agent MUST keep Site-native source, history and permissions under Site authority. A Workplace may retain a delivery record without becoming the source of the delivered product state. ## 13. Projections and degraded operation A projection MAY combine owned sources for a provider, application or human view. It MUST keep source ownership recoverable. A projection MUST identify its generated or derived status. A Profile SHOULD provide a way to detect stale projections. The absence of a CLI, daemon, scheduler or live orientation service MUST NOT invalidate a Workplace whose declared static sources remain readable. In that case, the agent MUST: - read the static sources according to the Profile; - report `degraded`; - name unavailable validation or generation features; - avoid inventing live state; - preserve all authority boundaries. If the Profile requires a service to resolve its sources and that service is unavailable, the agent MUST report `ambiguous` or stop when it cannot establish the current context. ## 14. Multiple Occupants and delegation Several Occupants MAY participate in one Home through separate Meetings, Rooms, Roles or provider interfaces. Before delegation, the parent agent MUST pass: - the resolved Home and Profile; - the Room and Meeting scope; - the delegated Role or objective; - the authoritative sources required by the task; - Site and Route boundaries; - active limits and human authority. A delegate MUST NOT widen inspection, mutation or delivery authority. It MUST return provenance and observed results to the parent Meeting. Two Occupants working in separate ownership scopes MAY proceed without a resident coordinator. The protocol does not provide write isolation. Agents that modify the same source remain subject to the host and Site conflict mechanisms. Provider-specific subagent APIs, schedulers and worktrees remain execution features. They MAY strengthen coordination without taking ownership of the Workplace. ## 15. Conflict and failure behavior An agent MUST prefer an explicit limit over a guessed owner, source or destination. | Condition | Required behavior | | --- | --- | | No declared Profile | Report `candidate` and avoid a resolution claim. | | Missing optional validator | Continue as `degraded` when static authority remains clear. | | Conflicting Home identity | Report `ambiguous` and stop durable placement. | | Conflicting source authority | Report `ambiguous` for the affected responsibility. | | Missing Room destination | Keep work ephemeral or request direction. | | Missing Site authority | Do not perform the external effect. | | Stale projection | Use the owned source and report drift. | | Unsupported Profile concept | Record the limit without inventing a mapping. | An ambiguity in one responsibility does not require the agent to discard every resolved part of the context. The agent MAY continue read-only work that does not depend on the disputed authority, and it MUST keep the limit visible. ## 16. Experience and visibility After orientation, the agent SHOULD make the following information available without printing the entire Workplace: - current Home and Room; - current orientation status; - relevant Sites or destination; - limits that affect the task. The agent SHOULD explain a conflict through the competing owners and sources. It SHOULD avoid exposing private paths, unrelated Material or internal implementation detail when a smaller explanation supports human judgment. The agent MUST report the observed result of a lifecycle transition or Site effect. It MUST distinguish completed, partial and failed effects. ## 17. Evolution Changes to this protocol MUST update its identifier or documented draft version when they change required behavior. A revision SHOULD preserve the meaning of existing objects unless evidence shows a missing owner, conflicting invariant or legitimate environment that the model cannot represent. Profiles MUST declare the protocol version they target. An implementation MUST NOT claim compatibility with another version without testing its required behavior. This Working Draft defines no profile registry, machine schema, adapter API or governance process. Those additions require evidence from more than one independent implementation. ## 18. Reference behavior The [reference scenarios](reference-scenarios.md) form the observable examples for this draft. They do not replace the requirements in this document. A scenario can reveal an ambiguous rule or missing invariant. The protocol should change when repeated use supports the correction, with the old behavior kept in version history.