# Workplace transposition Status: Proposed direction for the Open Workplace Working Draft Workplace transposition describes how a human and agent can recognize an implicit environment, compare responsibility maps and propose a target representation. It separates evidence gathering from mutation. The process can stop with a private description. Adoption into an implementation remains a separate choice. ## Scope Transposition addresses two cases: 1. An implicit environment has repositories, instructions, methods and external systems without a declared Workplace. 2. A declared Workplace uses one Profile and a human wants to compare another Profile. The process does not convert files by matching names. It maps responsibilities, provenance, authority and lifecycle. The [Protocol](protocol.md) governs interpretation inside a declared Workplace. Transposition governs the path from evidence to a candidate or from one Profile description to another. ## Authority boundaries ```text Human names inspection roots ↓ authorizes shallow read-only recognition Agent presents candidate Workplaces ↓ human selects one candidate Agent analyzes and proposes a target map ↓ human reviews concrete changes Implementation applies the approved map ↓ fresh session verifies orientation ``` Each arrow marks a new authority boundary. - Root selection authorizes inspection within those roots. - Candidate selection authorizes deeper analysis of that candidate. - Application requires authority tied to the proposed destinations and changes. - Site delivery requires its own external-effect authority. One boundary does not grant the authority required by a later boundary. ## The transposition flow Six stages keep evidence, recommendation, mutation and verification distinct: ```text recognize → describe → map → propose → apply → verify ``` ### Recognize The human names the local or remote sources that the agent may inspect. The agent gathers evidence within that boundary. Useful evidence includes: - repository and project roots; - public instruction files; - declared methods, Skills and scripts; - durable documents and decision records; - known external systems and relationships; - existing product or provider manifests. The agent should exclude credentials, secret-like files, dependency trees, caches, build output and source-control internals. It should not cross unapproved roots through symlinks or inferred relationships. Recognition records evidence. It does not assign final ownership. ### Describe The agent builds a source description with four evidence classes: | Class | Meaning | | --- | --- | | Observed | The agent inspected the source inside the approved boundary. | | Inferred | Evidence supports a candidate owner or relationship. | | Needs confirmation | Intent or authority requires a human answer. | | Excluded | The source remained outside the boundary or was filtered. | The description should name provenance for each observation. Private paths, names and relationships remain in the private description until the human requests a sanitized copy. ### Map The agent identifies plausible Home boundaries and maps responsibilities: ```text source evidence ↓ Places · Orientation · Guidance Capabilities · Material · Relationships ↓ Home · Member · Desk · Room · Meeting Occupant · Role · Equipment · Material · Site · Route ``` The agent should present more than one candidate when evidence supports different ownership boundaries. For each candidate, it names: - proposed Home identity and trust boundary; - shared and personal ownership; - durable Rooms; - candidate Equipment; - sovereign Sites and their Routes; - excluded evidence; - uncertainties and trade-offs. The agent may recommend one candidate. It must keep inference distinct from observed fact. ### Propose After the human selects a candidate, the agent compares its responsibility map with a target [implementation Profile](profiles.md). Each responsibility receives one classification: | Classification | Meaning | | --- | --- | | Direct | The source and target preserve responsibility and authority. | | Partial | The target preserves part and names the missing meaning. | | Source-only | The target cannot represent a source concept. | | Target-only | The target adds a concept absent from the source. | | Human confirmation | Intent or authority blocks a safe automatic choice. | The proposal includes: - target representation; - source provenance for each destination; - expected additions, edits and links; - responsibilities that stay in place; - unsupported concepts and losses; - target extensions; - validation and rollback limits. A proposal should keep existing Sites in their sovereign locations unless the human asks for a separate Site-native change. ### Apply The target implementation owns application operations and safety checks. The transposition proposal grants no mutation authority. Application requires a human authorization that identifies: - selected proposal version; - target roots; - files, records or services that may change; - Site effects, if any; - expected validation. An implementation may require a phrase, confirmation screen or signed request. Endroit uses `Apply this map` for its current adoption flow. That phrase belongs to the Endroit Profile and does not become Open Workplace vocabulary. The same boundary applies to Endroit's Work Resolution lifecycle. A transposition may preserve or propose that lifecycle when Endroit is the target, but it must classify it as an implementation extension rather than an `open-workplace/0.1` requirement. The implementation should report partial or failed application without claiming completion. ### Verify A fresh agent session or interface enters the target without using the transposition conversation. Verification checks whether it can identify: - protocol and Profile; - Home; - Member and Desk; - relevant Room and Meeting; - authoritative sources; - Equipment required for the task; - Sites and Routes; - declared losses and limits. The verifier compares observed target behavior with the accepted proposal. File presence alone does not prove that authority and lifecycle survived. ## Fidelity report Every proposed mapping should account for: | Dimension | Question | | --- | --- | | Responsibility | Who maintains and corrects the target? | | Provenance | Which source supports the target claim? | | Authority | Who may accept or change the target? | | Lifecycle | Is the Material ephemeral, retained, accepted, delivered or archived? | | Sovereignty | Does an external Site keep its history and permissions? | | Loss | Which source meaning cannot reach the target? | | Extension | Which target concept adds structure beyond the source? | | Verification | Which fresh-session observation will test the mapping? | A useful report names loss instead of hiding it behind a successful file copy. ## Example: an implicit software environment ```text Before studio/ ├── product-api/ ├── web-app/ ├── AGENTS.md ├── CLAUDE.md ├── prompts/ ├── skills/ └── notes/ ``` The tree supports several candidates: - one embedded Workplace inside `product-api`; - one standalone Workplace coordinating both repositories; - two independent Workplaces with shared methods. Suppose the evidence supports one studio-wide Home: ```text Candidate responsibility map Studio Home ├── Member and personal Desk ├── Product Room │ ├── product decisions │ └── retained research ├── Launch Room ├── shared Equipment │ ├── repository review │ └── release preparation └── Routes ├── Product API Site └── Web application Site ``` This map describes ownership. It does not require the target implementation to create these exact directories. ## Several target Profiles ```text private source description │ ├── compare → Profile A → proposal A + fidelity report │ └── compare → Profile B → proposal B + fidelity report ↓ human selects or stops ``` Comparing targets can expose structure that one Profile adds or loses. The human may choose a target, keep the private map or decide that the existing environment needs no new Workplace representation. ## No added structure Transposition should support this valid result: > No additional Workplace structure needed. The result explains why current ownership, continuity and external boundaries already fit the work, or why the work ends within one session and gains nothing from a durable layer. The process should not treat adoption as success by default. ## Privacy and sharing The private description should use all authorized evidence needed for a useful map. A public or shareable result should be a separate projection. Sanitization may remove: - personal names; - local paths; - private repository and service names; - internal relationships; - source excerpts that expose confidential work. The sanitized result must retain enough structure to explain the candidate boundaries and mapping decisions. The agent should not weaken its private analysis to make the first output shareable. ## Current evidence Endroit, the Workplace-first application framework, demonstrates one bounded version of this flow as a declared implementation qualified by a versioned Profile targeting `open-workplace/0.1`: ```text approved roots ↓ read-only recognition candidate Workplaces ↓ human selection Endroit map with provenance and expected diff ↓ separate application authority owned Home sources and provider projections ↓ fresh provider session verified orientation ``` The evidence covers transposition into Endroit. It does not cover transfer between two independent Profiles, reverse mapping or a lossless round trip. ## Open tests The next useful evidence includes: - one implicit environment mapped into two independent Profiles; - one declared Profile mapped into another; - a case where authority cannot be preserved; - a round trip that records semantic loss; - a non-software Workplace; - a case where added Workplace structure has no value. The end-to-end [use cases](use-cases.md) include one source-backed brownfield harness as a proposed transposition. The [reference scenarios](reference-scenarios.md) define smaller observable cases for the current Working Draft.