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 governs interpretation inside a declared Workplace. Transposition governs the path from evidence to a candidate or from one Profile description to another.

Authority boundaries

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.
• An external delivery requires its own 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:

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:

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 Workplace boundaries and maps responsibilities:

source evidence
    ↓
boundary · Sources · Material · Relationships
provenance · authority · objective-bounded context
    ↓
target Profile representation + declared limits

The agent should present more than one candidate when evidence supports different ownership boundaries.

For each candidate, it names:

• proposed Workplace identity and boundary;
• Source owners and authority;
• durable Material;
• reusable methods where the target Profile represents them;
• Relationships to sovereign external authorities;
• 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.

Each responsibility receives one classification:

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 external authorities in their sovereign locations unless the human asks for a separate source-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;
• external effects, if any;
• expected validation.

An implementation may require a phrase, confirmation screen or signed request. Its approval mechanism and operations belong to that Profile and do not become Open Workplace vocabulary. Endroit’s onboarding and Work Resolution contracts are such implementation extensions, not open-workplace/0.2-draft requirements.

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;
• declared Workplace identity;
• authoritative Sources and their owners;
• objective-bounded Material;
• Relationships to external authorities;
• Profile-specific methods required for the objective;
• 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:

A useful report names loss instead of hiding it behind a successful file copy.

Example: an implicit software environment

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 Workplace:

Candidate responsibility map

Studio Workplace
├── Source · studio constitution · studio owner
├── Source · product decisions · product owner
├── Material · retained research
├── reusable review and release methods
└── Relationships
    ├── Product API repository
    └── Web application repository

This map describes ownership. It does not require the target implementation to create these exact directories.

Several target Profiles

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

The qualified, unpublished local Endroit 0.10 release candidate demonstrates one bounded version of this flow through a Profile targeting open-workplace/0.2-draft:

approved roots
    ↓ read-only recognition
candidate Workplaces
    ↓ human selection
Endroit representation with provenance and expected diff
    ↓ separate application authority
owned Workplace 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 include one source-backed brownfield harness as a proposed transposition. The reference scenarios define smaller observable cases for the current Working Draft.