# Open Workplace Protocol, Draft 0.2 Status: Experimental Working Draft Protocol identifier: `open-workplace/0.2-draft` Compatibility: incompatible with and supersedes `open-workplace/0.1` This document defines the candidate normative behavior for resolving durable, owned context before consequential human-agent work. The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY indicate requirement strength. The [architecture](architecture.md) owns the responsibility model. A [Profile](profiles.md) maps those responsibilities into one implementation. The [reference scenarios](reference-scenarios.md) exercise observable behavior. This is an experimental draft, not a standard, registry, certification, interoperability claim or conformance program. Only one implementation Profile has been observed so far. ## 1. Scope The protocol governs: - discovery of a declared Workplace boundary; - identification of a Profile and its limits; - resolution of Sources, owners, provenance and authority; - distinction between Sources and Projections; - reduction to the context relevant to one objective; - explicit changes to durable Material; - Relationships with external authorities; - degraded and ambiguous operation. It does not prescribe a filesystem, object ontology, wire format, runtime, agent role system, storage engine, security boundary or product workflow. It does not grant host permissions or human consent. ## 2. Shared terms | Term | Meaning | | --- | --- | | Workplace | A declared durable boundary within which owned context and its relationships can be resolved. | | Workspace | An execution or editing scope; it may provide evidence but does not establish a Workplace. | | Profile | A versioned mapping from this protocol's responsibilities to one implementation. | | Source | Content declared authoritative by an identified owner for one responsibility. | | Projection | A rebuildable representation derived from one or more Sources for an interface, provider or runtime. | | Material | Addressable content whose owner and durable state can be determined. | | Relationship | A declared connection to another authority without transfer of ownership or permission. | | Resolved Workplace Context | The objective-bounded result of resolving relevant Sources, Material, Relationships, limits and conflicts. | | Provenance | Information sufficient to identify where a claim came from and which owner can correct it. | | Authority | The right to establish a claim or authorize an effect; access alone is not authority. | Names such as Home, Member, Desk, Room, Meeting, Occupant, Role, Equipment, Site and Route are not Open Workplace terms in this draft. A Profile MAY use them as implementation vocabulary, but another Profile need not represent or translate them. ## 3. Protocol and Profile availability An implementation MUST identify this protocol as `open-workplace/0.2-draft` before claiming a Resolved Workplace Context under it. A cached, bundled or projected copy MUST retain the protocol identifier and provenance. A Profile targeting this draft MUST disclose: 1. its identifier and version; 2. its discovery boundary and stopping conditions; 3. how a declaration identifies the Workplace; 4. how Source ownership, provenance and authority are represented; 5. how Sources compose or conflict; 6. how Projections identify their Sources and expose drift; 7. how Material becomes durable, current or inactive; 8. how Relationships and external effects are resolved; 9. how static sources remain legible without optional tooling; 10. how the declaration and relevant Sources can be validated; 11. its extensions and known limits. A Profile MAY introduce any domain objects it needs. It MUST identify them as Profile vocabulary and MUST NOT present them as Open Workplace requirements. Loading the protocol or a Profile does not establish local truth, authorize inspection beyond the Profile boundary or grant mutation authority. ## 4. Declared boundary Path visibility, a repository root, a provider instruction or a familiar filename MUST NOT by itself establish a Workplace. A declared Workplace MUST provide: - a stable identity; - a targeted Profile and protocol identifier; - an authoritative declaration Source; - enough ownership and provenance to resolve the current objective; - explicit limits when a responsibility cannot be represented or observed. Discovery MUST follow the Profile's bounded procedure. It MUST stop at the first candidate boundary when the Profile requires that behavior, including when the candidate is invalid. It MUST NOT widen into children, related repositories or external systems merely because they are reachable. ## 5. Resolution status A Resolved Workplace Context has exactly one status: | Status | Meaning | | --- | --- | | `candidate` | Evidence suggests a boundary, but no valid declaration establishes it. | | `resolved` | Relevant owners, Sources, authority and limits are established for the objective. | | `degraded` | Static authority remains clear, but an optional validator, projector, runtime or observation is unavailable. | | `ambiguous` | Conflicting or missing authority prevents a safe interpretation required by the objective. | An implementation MUST NOT report `resolved` only because it found readable files. It MUST name the missing capability when reporting `degraded`, and the competing or absent authorities when reporting `ambiguous`. An ambiguity MAY be bounded to one responsibility. Read-only work that does not depend on it MAY continue while the limit remains visible. ## 6. Source resolution For each responsibility relevant to the objective, the resolver MUST: 1. identify the owner and authority; 2. locate the Source according to the Profile; 3. preserve Source provenance; 4. determine whether other Sources compose with or conflict with it; 5. retain relevant limits and unresolved conflicts. File proximity, naming familiarity, projection order, provider memory and session history MUST NOT silently establish precedence. Sources with distinct owners, audiences or responsibilities MAY compose when the Profile defines that composition. Two incompatible claims to the same responsibility and authority MUST produce `ambiguous`; a generated order MUST NOT hide the conflict. When a Projection conflicts with its Source, the Source wins. The resolver MUST report projection drift and MUST NOT promote the Projection to authority. When an authoritative Source is inaccessible, the resolver MUST report the limit rather than reconstructing truth from memory. ## 7. Resolved Workplace Context The result MUST contain, conceptually: ```text status protocol identifier Profile identifier and version Workplace identity current objective or scope relevant Sources with owner, provenance and authority relevant Material and Relationships limits and conflicts ``` This draft defines no serialization. A Profile MAY add fields and domain objects, provided their ownership and extension status stay explicit. The resolver SHOULD select the smallest owned context sufficient for the objective. It SHOULD NOT load unrelated durable domains, inactive Material, all reachable external authorities or every available capability by default. A summary, index or retrieval system MAY reduce the working set. It MUST keep Source provenance recoverable and expose when the consumer received a Projection instead of a Source. ## 8. Sources and Projections A Source is canonical only for its declared responsibility. Being Markdown, JSON, generated, tracked or colocated does not determine authority. A Projection MUST: - identify itself as derived; - retain enough provenance to recover its Sources; - be replaceable from those Sources; - expose missing, stale or conflicting output when the Profile can detect it. Editing a Projection does not change its Source. An implementation SHOULD refuse to overwrite an unrecognized file at a generated destination. Provider instructions, rendered documentation, indexes, caches and API responses MAY all be Projections. Human-readable documentation MAY instead be a Source when its owner declares it authoritative; the file format alone does not decide. ## 9. Material and explicit transitions Every produced result begins outside durable Workplace truth. Making it durable requires an explicit transition defined by the Profile and authorized by the responsible human or another declared authority. A transition MUST identify: - the Material; - the destination owner; - the intended durable state or responsibility; - the mutation scope; - any external destination and expected effect. Acknowledgement, praise, continued discussion, generation and session end MUST NOT imply retention, acceptance, archiving, delivery or publication. The Profile MUST keep at least these concerns distinguishable: - whether Material is durable or inactive; - whether a claim is current; - whether a human has accepted an exact revision; - whether a contract is complete for an exact revision and evidence set; - whether an external effect was observed. A Profile MAY choose different names or representations. It MUST NOT collapse these concerns into one final boolean or a single linear lifecycle when that would create false authority. ## 10. Relationships and external effects A Relationship identifies another authority and a means of reaching it. It does not transfer ownership, host permission or human consent. Physical containment does not change that boundary. Before an external effect, an implementation MUST: 1. identify the external authority and intended destination; 2. resolve and, when supported, revalidate the Relationship; 3. state the concrete effect; 4. establish the required human and host authority; 5. observe and report the result. An unavailable, stale or mismatched Relationship MUST stop the affected effect. An attempted effect is not a delivered result. A Workplace MAY retain an observation or receipt without becoming the source of external truth. ## 11. Degraded operation The absence of a CLI, daemon, scheduler, provider hook or live orientation service MUST NOT invalidate a Workplace whose static Sources remain readable. When optional tooling is unavailable, the implementation MUST: - use readable Sources within the declared boundary; - report `degraded` and name unavailable checks; - avoid inventing live observations; - preserve ownership, authority and provenance; - stop any action whose required authority cannot be established. If static Sources cannot establish a required owner or destination, the result is `ambiguous`, not merely `degraded`. ## 12. Delegation and execution Agents, roles, meetings, schedulers, worktrees and delegation APIs are runtime or Profile concerns, not protocol objects. When an implementation delegates work, it MUST pass the objective, relevant Resolved Workplace Context, inspection and mutation boundaries, active limits and authority already granted. Delegation MUST NOT widen authority or reset an approval boundary. The delegate MUST return provenance and observed results. This protocol provides no write isolation or conflict-free coordination. Concurrent execution remains subject to the host and external authority's locking, transaction and merge mechanisms. ## 13. Reporting An implementation SHOULD expose, without dumping the full Workplace: - Workplace and Profile identity; - resolution status; - Sources and Relationships relevant to the objective; - limits or conflicts that affect the work. It MUST distinguish intended, attempted, partial, failed and observed effects. It SHOULD explain ambiguity through the competing owners and Sources rather than through an opaque confidence score. ## 14. Evolution and limits `open-workplace/0.2-draft` is incompatible with `open-workplace/0.1` because 0.1 made one implementation's object vocabulary normative and coupled durable Material state to external delivery. The 0.1 text remains available through Git history, not as a concurrent current protocol. This draft defines no Profile registry, universal schema, adapter API, governance body, certification, compatibility badge or conformance suite. Evidence from Endroit can refine this draft but cannot by itself prove implementation neutrality. A second independent implementation is required before claiming cross-Profile portability or compatibility. Substantive requirement changes MUST change the protocol identifier or its documented draft revision. Profiles MUST declare the exact version they target.