Shared scene
Represent the objects and relationships participants work with.
- Receives
- Scene content and accepted changes.
- Produces
- A common visual context.
Work architected at Fifth9
Conduir Spatial: working within a shared scene
Spatial work combines a shared scene, participant interaction, proposed actions and a record of change. A shared view is only part of collaboration: participants also need to know who proposed a change, whether it was accepted and what context should survive.
Shared-environment research The flow explains the collaboration model. Broader shared-world capability and its value to users remain research and integration questions.
The design question
What changes when people and AI can work within the same shared space?
Explore how people and AI can understand and contribute to the same visual environment while keeping changes attributable.
A shared scene needs a common account of its state and the changes participants are proposing. Interaction, action review and accepted state have different responsibilities, so a suggestion should not be mistaken for an applied change.
A view of the responsibilities
Distinguish a proposed change from shared state
- 01Enter a shared contextCurrent scene state
- 02Propose a changeAn intended action
- 03Apply the applicable checksPermission and consistency
- 04Make the accepted change visibleAccepted state
- 05Continue with contextA continuing history
Across the flow
Follow a proposed action from a shared scene through permission and consistency checks to an attributed change and a history participants can revisit.
What each part is responsible for
The building blocks
Participant interaction
Let people and agents contribute to the activity.
- Receives
- Participant input and relevant scene context.
- Produces
- Selections, observations and proposed actions.
Action review
Distinguish a proposal from an accepted change.
- Receives
- A proposed action, permissions and applicable rules.
- Produces
- An accepted action or a reason to revise or refuse it.
Scene coordination
Keep accepted changes understandable across participants.
- Receives
- Accepted operations and existing state.
- Produces
- Updated shared state and an account of the change.
History and context
Preserve the decisions and development of the activity.
- Receives
- Changes, attribution and relevant reasons.
- Produces
- Context that can support later inspection or continuation.
Following one piece of work
How the flow fits together
01Enter a shared context
Establish which shared scene and state participants are working with. A visible representation gives a shared reference, but participants may still have different views or capabilities.
02Propose a change
A person or agent suggests an action. Represent an intended action before treating it as a change to shared state. The proposal needs enough context for others to understand what would change and why.
03Apply the applicable checks
Check permission, scene rules and consistency before accepting a change to shared state. A proposal based on stale state or conflicting assumptions may need to be revised rather than applied unchanged.
04Make the accepted change visible
Update the scene and preserve attribution. Present the accepted state so participants can understand the result. A rendered change and a correct, consistently accepted change are different properties to evaluate.
05Continue with context
Use the history to understand, revisit or build on earlier choices. Retain enough history to explain the arrangement when work resumes. That history can support review and continuity without implying an automatically learned ability or a validated physical simulation.
Illustrative example · not a benchmark result
Explore a shared workspace
A group is arranging a shared workspace.
- A participant proposes moving an object. Others can see the proposed change and its context before it is accepted. The history helps explain the resulting arrangement when the group returns.
- If a proposed change was based on an older scene state, participants need the conflict resolved before treating it as accepted. That is a consistency requirement, not evidence that every distributed case is already solved.
The useful result: A shared arrangement with an account of which changes were proposed or accepted.
A generic collaboration scenario, not a claim of a deployed design service, validated engineering simulation or established user adoption.
Why these responsibilities are separate
History can help participants understand how a scene arrived at its current arrangement. That continuity is useful without implying that the environment learns a new capability or that a simulation accurately predicts the consequences of a real-world action.
Reading the architecture accurately
Scope and status
What the work covers
- Browser-based shared-scene work, participant coordination and proposed-action controls.
- Change history and simulation-related foundations explored within the project.
What still needs to be established
- Does shared interaction help people understand and accomplish the activity?
- Can participants follow why a change was accepted?
- What context should persist when the activity resumes?
Where the design must hold up
Boundaries and evaluation
| Boundary | Why it matters | How to examine it |
|---|---|---|
| Transfer beyond the scene | A shared scene does not establish useful real-world transfer. | Evaluate the usefulness of a bounded shared task separately from the rendering of its scene. |
| History versus learning | Recording changes does not prove that the system learns from them. | Distinguish a retained history from a measured change in learned ability. |
| Permission and consistency | Permission, consistency and simulation correctness require separate evaluation. | Exercise conflicting changes, stale state and rejected actions, then examine the state participants see. |