CONDUIR SPATIAL: WORKING WITHIN A SHARED SCENE Work architected at Fifth9 Shared-environment research — The flow explains the collaboration model. Broader shared-world capability and its value to users remain research and integration questions. 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. 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. BUILDING BLOCKS Shared scene Represent the objects and relationships participants work with. Receives: Scene content and accepted changes. Produces: A common visual context. 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. WALKTHROUGH 1. Enter 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. 2. Propose 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. 3. Apply 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. 4. Make 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. 5. Continue 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 — 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. 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. SCOPE Browser-based shared-scene work, participant coordination and proposed-action controls. Change history and simulation-related foundations explored within the project. REMAINING QUESTIONS 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? BOUNDARIES AND EVALUATION Transfer beyond the scene: A shared scene does not establish useful real-world transfer. Evaluation: 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. Evaluation: Distinguish a retained history from a measured change in learned ability. Permission and consistency: Permission, consistency and simulation correctness require separate evaluation. Evaluation: Exercise conflicting changes, stale state and rejected actions, then examine the state participants see. The aim is shared places for design, practice and exploration, where people can understand and direct the changes around them. AI Initiative — public architecture guide.