# Open Workplace architecture Status: Candidate architecture for the Open Workplace Working Draft This document defines the responsibility model behind Workplace-first. It describes semantic objects and invariants without assigning a storage engine, directory layout, runtime or user interface. The [Proposal](proposal.md) explains the motivation. The [Protocol](protocol.md) defines candidate agent behavior. An [implementation profile](profiles.md) maps this architecture into a concrete representation. ## Design center Workplace-first is the paradigm that makes the workplace a first-class design concern. Open Workplace supplies an implementation-neutral model and the independent experimental `open-workplace/0.1` Protocol. The Workplace owns continuity that should survive a change of session, provider, runtime, method or repository. The architecture assigns four broad responsibilities: ```text Human intent, direction, judgment and consent Workplace durable context, placement, continuity and relationships Runtime execution, tools, sandbox and temporary state Site external history, permissions and delivered truth ``` One product may implement several responsibilities. The product should keep their authority boundaries visible. ## First-class properties A Workplace has five first-class properties. | Property | Architectural meaning | | --- | --- | | Identity | The Workplace can be named apart from one execution or repository. | | Ownership | Durable responsibilities have maintainers and correction boundaries. | | Composition | Participants and capabilities can change without owning the whole place. | | Time | Temporary work crosses deliberate transitions before it becomes durable. | | Sovereignty | External systems keep their own authority when the Workplace reaches them. | An environment may provide useful agent context without satisfying all five properties. The architecture calls that environment a candidate until a profile and local sources declare a Workplace instance. ## Design responsibilities The model accounts for six responsibilities: | Responsibility | Required distinction | | --- | --- | | Places | Shared, personal, domain and temporary scopes | | Orientation | Arrival, location, relevant context and known limits | | Guidance | Owner, audience, lifetime and authority of instructions | | Capabilities | Reusable methods and their activation surfaces | | Material | Addressable sources, results and lifecycle | | Relationships | External authorities and declared access paths | These responsibilities guide evaluation. An implementation may combine their physical representation when it preserves ownership and lifecycle. ## Typed context and legibility Open Workplace treats context as typed when its nature, owner, scope, status, provenance and authority can be recovered. This is a semantic property, not a required programming type or wire format. A retained observation, an accepted Decision, temporary Meeting Guidance, a Site source and a generated projection can all contain Markdown while requiring different behavior. Their type determines whether an Occupant may use the content as evidence, current Workplace truth, a temporary constraint, external truth or presentation only. ```text typed owned context ↓ responsibility-specific resolution small relevant projection ↓ human and agent situational awareness ↓ bounded action with provenance ``` An implementation makes the Workplace legible by preserving these distinctions through resolution and projection. It does not make an agent the source of truth or claim that loading more context produces better judgment. ## Objects ### Home A Home identifies one concrete Workplace. It owns the shared constitution, composition and trust boundary. ### Member A Member records durable human belonging within a Home. It does not represent a temporary agent persona. ### Desk A Desk owns one Member's personal continuity, staging and local access. The Desk keeps personal placement separate from shared Home truth. ### Room A Room owns one durable semantic domain and its Material. A Room may contain another Room when the nested domain needs its own mission, continuity and Meetings. ### Meeting A Meeting bounds one work event. It owns temporary context and begins ephemeral unless a human retains a result. ### Occupant An Occupant participates in a Meeting for a bounded time. A human, agent or other executor may act as an Occupant. ### Role A Role gives an Occupant a temporary mandate and scope. A Role does not create durable personhood or transfer ownership of the Room. ### Equipment Equipment owns a reusable way of working and its activation surfaces. It can include instructions, tools or controls. It does not own results produced with it. ### Material Material is an addressable source or result that may remain. Its owner and lifecycle determine whether it represents evidence, retained work or current truth. ### Site A Site owns sovereign external truth, history, permissions and delivery. A repository, service or product may serve as a Site. ### Route A Route declares a relationship and access path from a Desk to a Site. It does not grant authority beyond the human and host permissions that govern an effect. ## Relationship graph ```text Home ─recognizes→ Member ─uses→ Desk Home ─scopes→ Room ─hosts→ Meeting Meeting ─includes→ Occupant ─adopts→ Role Room ─owns→ Material Home / Desk ─equipped by→ Equipment Desk ─declares→ Route ─accesses→ Site ``` The graph describes semantic relationships. It does not define containment, cardinality or a required filesystem. A Home can recognize several Members. A Member can use a Desk with a storage strategy chosen by the implementation. A Route can address a Site through a checkout, API or another materialization. None of those physical choices changes the semantic owner. ## Ownership invariants 1. The human owns intent, judgment, acceptance and delivery consent. 2. A Home owns the identity and shared constitution of one Workplace. 3. A Desk owns personal continuity and local access for its Member. 4. A Room owns domain Guidance and durable Material assigned to that domain. 5. A Meeting owns temporary work context and produces candidates. 6. An Occupant and Role remain bounded to participation in a Meeting. 7. Equipment owns a reusable method, not the result produced with it. 8. A Site retains external truth, history and permissions. 9. A Route declares access and relationship without granting consent. 10. A projection presents sources without replacing their authority. 11. Physical containment does not transfer semantic ownership. 12. Conflicting claims to one responsibility require an explicit conflict, not a silent precedence guess. The protocol turns these invariants into agent behavior. Profiles disclose how an implementation identifies each owner. ## Three planes ```text ┌─────────────────────────────────────────────────────────────┐ │ Execution plane │ │ Provider · Harness · Tools · temporary Occupant · hot state │ └──────────────────────────────┬──────────────────────────────┘ │ participates in ┌──────────────────────────────▼──────────────────────────────┐ │ Workplace plane │ │ Home · Member · Desk · Room · Meeting · Equipment │ │ Material · Route │ └──────────────────────────────┬──────────────────────────────┘ │ reaches through Route ┌──────────────────────────────▼──────────────────────────────┐ │ Sovereignty plane │ │ Sites · observed delivered truth │ └─────────────────────────────────────────────────────────────┘ ``` The planes describe authority. They do not require separate processes. A single local application may present all three while preserving the distinctions. The human crosses each plane. They direct execution, decide which Workplace results remain and authorize external effects. ## Authority and source flow ```text Owned source ↓ declared by implementation profile Resolved Workplace Context ↓ projected for one interface or provider Agent working set ↓ produces Meeting candidate ↓ human transition Durable Material or authorized Site effect ``` The owned source remains authoritative when the projection changes. The Resolved Workplace Context records which sources support the current orientation. A provider can cache or summarize them, but its cache remains an interface concern. An implementation may keep sources in files, records or remote services. Its profile must expose enough provenance for the agent and human to find the owner behind a projection. ## Placement The model places Guidance by durable responsibility: ```text shared constitution Home human belonging Member personal preference Desk domain rule or decision Room temporary instruction Meeting reusable procedure Equipment product-native truth Site local relationship Route ``` Placement depends on ownership, audience, lifetime and authority. File type alone does not decide where Guidance belongs. One instruction file can project several owners, but the implementation should preserve their provenance. ## Time and lifecycle ```text Room inputs ↓ Meeting ↓ execution produces candidate ↓ ephemeral → retained → accepted → delivered └────────────→ archived ``` The lifecycle separates five states: | State | Meaning | | --- | --- | | Ephemeral | Work exists in the current event without durable ownership. | | Retained | An owner keeps Material for inspection without making it current truth. | | Accepted | An owner adopts Material as current Workplace truth. | | Delivered | A human-authorized effect has been observed in a Site. | | Archived | Material leaves the active set while its history remains inspectable. | Each transition needs a known object, owner and destination. A runtime can offer a button or command for the transition. The runtime does not own its meaning. ## Orientation Arrival should reduce the working set before an agent starts consequential work. ```text protocol available ↓ profile identified ↓ Home instance discovered ↓ Member and Desk resolved ↓ Room selected and Meeting established ↓ owned Guidance, Material, Equipment and Routes loaded ↓ limits reported ``` The protocol describes the result as a conceptual Resolved Workplace Context. The context includes source provenance and unresolved conflicts. It does not require one serialization. An implementation can provide a generated front door or a live orientation view. Static sources remain sufficient when the implementation profile explains how to read them. ## Multiple occupants ```text Home │ ┌─────────────┴─────────────┐ │ │ Room A Room B Meeting 1 Meeting 2 Occupant X Occupant Y Role X Role Y │ │ Material A Material B ``` Two agents can work in separate Meetings with different Rooms, Roles, Material and Sites. The ownership graph makes their destinations legible. The graph does not provide scheduling or write isolation. When two Occupants change the same source, the host or Site still needs locks, transactions, branches or conflict handling. ## Profiles and implementations An implementation profile maps this architecture to a representation. It must identify: - how an agent discovers a Home; - which sources own each represented responsibility; - how it resolves context and conflict; - which projections it builds; - how it behaves when its runtime is absent; - which model concepts it cannot represent. Open Workplace does not own implementation-specific filenames, schemas, commands or services. Endroit, the Workplace-first application framework, is the first declared implementation qualified by a versioned Profile targeting `open-workplace/0.1`; it owns its Markdown and JSON mapping. Another implementation may use different structures and still preserve the architecture. An implementation may add extensions without moving them into the model. Endroit's Work Resolution lifecycle is one such extension. It remains Endroit-owned and cannot become normative behavior for `open-workplace/0.1` without a protocol revision. Profiles can support [transposition](transposition.md) when they expose enough meaning to compare responsibilities and authority. Cross-implementation fidelity remains an open test. ## Architectural boundaries This architecture does not define: - model or tool execution; - operating-system permissions; - transport or storage; - automatic memory; - agent scheduling; - a profile registry; - community governance; - a claim of improved intelligence. The candidate [Protocol](protocol.md) governs interpretation inside these boundaries. The [reference scenarios](reference-scenarios.md) test whether the distinctions remain clear in concrete environments.