# Arrange Workflow Map Arrange is no longer just a room-list editor. It is a local-first project workspace where several work threads run at the same time and intersect through shared project data. This map is meant to keep product, UI, and implementation decisions honest. A new surface should know which thread it belongs to, what shared object it touches, and which other threads need to see the consequence. ## Core Spine The persistent data spine is: ```text Project -> Department -> Functional Area -> Room -> Equipment ``` The room is the most important shared object, but not every workflow is room-scoped. Some workflows are project-scoped, model-scoped, discipline-scoped, scenario-scoped, or output-scoped. v10 should make those scopes explicit instead of forcing every action into one visual metaphor. ## Active Work Threads ### 1. Project And Program Purpose: Build and maintain the healthcare program. Primary surfaces: - Project list and project detail - Navigator - Add to Project - Blank room import - File import and room update import - Department, FA, and room move/copy workflows Primary data: - `project.departments` - `department.functionalAreas` - `fa.rooms` - Room quantities, NSF, room numbers, names, codes Intersects with: - Reference data, because rooms are usually seeded from standards - Templates, because repeated rooms may inherit shared definitions - Revit, because project rooms are compared, pushed, and matched - Workbench, because project rooms become spatial blocks - Reports, because reports package the current project state - Tasks and notes, because decisions attach to the same entities Design implication: The project/program thread needs a persistent scope chain: Project, Department, FA, Room. Users should always know which scope they are changing. ### 2. Reference, Criteria, And Provenance Purpose: Let users understand what the standard says and where values came from. Primary surfaces: - Reference Database window - Room reference detail - JSN Equipment Lookup - Attribute and criteria displays - Chapter logic source notes Primary data: - `ROOM_SIZES` - `ROOM_EQUIPMENT_MAPPINGS` - `EQUIPMENT_LIST` - `ALL_ROOM_INSTANCES` - VARF and legacy crosswalks - Room criteria and finish metadata Intersects with: - Program import, because standards seed project rooms - Room replacement/revert/pull workflows - MEP, because criteria become engineering basis - Reports, because source criteria must be communicated - Templates, because templates can be built from reference rooms Design implication: Provenance should be visible inline. Do not hide source, override, legacy translation, and current VARF naming behind modal-only explanations. ### 3. Equipment And Room Contents Purpose: Manage what belongs in each room. Primary surfaces: - Room equipment list - Equipment modal - Send equipment - FA equipment workflows - JSN lookup - Cutsheet manager Primary data: - `room.equipment` - Equipment quantity, JSN, description, utility codes, power, dimensions, remarks - `EQUIPMENT_ATTRIBUTES` Intersects with: - MEP, because utilities, power, and heat gain derive from equipment - Reports and cutsheets, because equipment is a major output - Templates, because equipment can be standardized across linked rooms - Revit, because selected values can be pushed or coordinated downstream - MOVE/Ergo, because room contents affect operational and human-scale studies Design implication: Equipment edits are not isolated list edits. A quantity change should show its downstream traces: utilities, MEP demand, report readiness, template drift, and Revit/model status where applicable. ### 4. Attributes, Finishes, And Room Criteria Purpose: Maintain the detailed requirements that define a room. Primary surfaces: - Room detail attributes - Finish Board - Room Story - Room replacement and pull workflows - Excel update import Primary data: - `room.attributes` - Finish fields, door fields, HVAC/plumbing/electrical/medical gas fields - Reference criteria overlays Intersects with: - MEP, because many attributes become engineering inputs - Revit, because finishes and criteria can be pushed or checked - IFC validation, because model properties can be checked against criteria - Reports, because attribute sheets communicate room requirements - Templates, because linked rooms can inherit attributes Design implication: Attribute UI needs source tags and conflict states. Users need to see whether a value is from VA criteria, project override, template inheritance, Excel update, or Revit/model pull. ### 5. Templates And Standardization Purpose: Keep repeated room types coordinated. Primary surfaces: - Template manager - Template detail - Link rooms to template - Template pull/replace - Push template to rooms - Disassociate and reassociate room attributes/equipment Primary data: - Project templates - Linked room references - Template-driven attributes and equipment - Disassociation flags Intersects with: - Program rooms, because templates act on project room instances - Equipment and attributes, because these are the inherited payloads - Excel updates, because imported values can skip, overwrite, or update templates - Reports, because template drift affects output trust Design implication: Template status should be treated as live state on the room. It should not feel like a separate admin app. A room should say: linked, drifted, intentionally detached, or source-of-truth. ### 6. MEP And Engineering Translation Purpose: Translate room program and criteria into engineering intent. Primary surfaces: - MEP Calculator - MEP network workspace - Schedule rows - Model Link tab - Revit QA and export workflows Primary data: - `project.mepCalculator` - Room overrides - System assignments - Assumptions and design stage - Room criteria, equipment utilities, demand values - Revit spaces, systems, and components Intersects with: - Program rooms, because rows are built from project rooms - Equipment, because demand and utility drivers depend on room contents - Attributes, because VA and ASHRAE/FGI/NFPA checks depend on room criteria - Revit, because Spaces, MEP Systems, and Family Instances are scanned and pushed - Reports/exports, because CSV, Excel, SVG, and QA outputs leave this thread Design implication: MEP is not only a room detail pane. It has a system-level topology: source, route, endpoints, checks. v10 needs to support both room scope and system scope. ### 7. Revit And Model Coordination Purpose: Keep Arrange and the model aligned. Primary surfaces: - Revit status panel - Model selector - Compare with Revit - Validate Revit rooms - Push Arrange to Revit - Pull/apply pending updates - Revit plan import - Adjacency sync - MEP model link Primary data: - Connected Revit model/session - Cached rooms and geometry - Room/space matches - Parameter mappings - Pending updates - MEP systems and components Intersects with: - Program rooms, because comparison and sync depend on room identity - Workbench, because room geometry can place blocks - MEP, because Spaces, systems, and components drive engineering QA - Attributes and finishes, because they can be pushed or validated - Room Story and Ergo, because model geometry can enrich room understanding Design implication: The Revit link should read as a live channel, not as a hidden utility. Users need to know: not connected, ready, connected, stale cache, matched, drifted, pushed, or pending. ### 8. Spatial Workbench Purpose: Convert the written program into spatial arrangement and review. Primary surfaces: - Workbench 3D - Room toolbox - Drawing/PDF overlay - Plan and walk modes - Revit plan import - Adjacency sync - Workbench simulation pane Primary data: - Workbench room placements - Cube states and room keys - Drawing overlays - Planned and semantic adjacencies - Revit geometry cache Intersects with: - Program rooms, because only project rooms can be placed - Revit, because geometry and adjacencies can be imported - MOVE, because room placements become simulation spaces - Ergo, because selected rooms become human-scale studies Design implication: The Workbench is spatial scope. It should not pretend to be a generic dashboard. It needs tools for placement, adjacency, drawing reference, model sync, and simulation entry. ### 9. MOVE Simulation And Ergonomic Study Purpose: Test operational behavior, movement, staffing, and human-scale tasks. Primary surfaces: - MOVE Simulation window - Workbench simulation pane - Workflow canvas - Staff panel - Room mapping panel - Ergo shell - Ergonomic report export Primary data: - Sim project generated from the Workbench - Room mappings - Staff roles and occupants - Workflows and provider groups - Simulation results - Ergonomic subjects, tasks, clearances, reach envelopes Intersects with: - Workbench, because layout creates simulation geometry - Program rooms, because room names/codes map to simulation space types - Equipment, because equipment affects ergonomic study and task realism - Revit, because model geometry can be a future source of truth - Reports, because studies export their own outputs Design implication: MOVE is scenario-scoped. It should remain connected to rooms and layouts, but it cannot be reduced to room editing. v10 should show when the user is editing the program, the layout, or a simulation scenario. ### 10. Tasks, Notes, And Coordination Memory Purpose: Keep unresolved work, decisions, notes, and attachments inside the same project context. Primary surfaces: - Tasks Hub - Discipline task detail - Task workspace canvas - Notes engine - User notes hub - OneNote import - Audio transcription - Attachments Primary data: - `project.tasks` - `project.notes` - Task attachments - Rich tokens linking rooms, departments, FAs, disciplines, notes, photos, and attributes - User notes from shared sources Intersects with: - Program rooms, because tasks and notes can link to rooms - Disciplines, because tasks are grouped by design responsibility - Revit/model coordination, because tasks often arise from model drift - Reports, because unresolved decisions affect issue readiness Design implication: Notes and tasks are not a side app. They are the project memory layer. They need to appear as contextual signals on rooms, departments, model issues, and reports. ### 11. Reports, Exports, And Issue Packages Purpose: Turn structured work into communicable output. Primary surfaces: - Report modal - TSV/PDF generation - Cutsheet Binder - MEP CSV/Excel/SVG exports - IFC checker reports - Simulation/Ergo reports Primary data: - Current project state - Room attributes and equipment - Cutsheet paths and matches - MEP rows and QA data - Validation results Intersects with: - Almost every thread, because reports are outputs from the current state - Equipment and attributes, because they dominate room sheets - MEP and Revit, because engineering and model QA exports are downstream deliverables - Tasks, because open issues may need to be included or resolved before issue Design implication: Reports are output lenses. They should show readiness, missing data, and source confidence before generation instead of acting as a black-box export button. ### 12. Persistence, Live Files, And Portability Purpose: Preserve work locally and move it safely. Primary surfaces: - Local project manager - Live project UI - Export project - Import project - Export/import workspace - Save status Primary data: - Browser local storage projects - Local/live file references - Project save status - Workspace export payloads Intersects with: - Every project-scoped workflow - Revit, because auto-sync follows project save - User notes, because shared sources may exist outside the project JSON Design implication: Save state should be quiet but always legible. Users need confidence about what is local, live/file-backed, pending, synced, or portable. ## Intersection Rules For v10 Use these rules before designing or coding a new surface. 1. Preserve function first. No v10 surface should remove an existing workflow. If a modal becomes a slide-panel, every field, validation path, selection state, and confirm/cancel path still has to exist. 2. Declare scope. Every surface should say whether it is acting on project, department, FA, room, equipment, template, system, model, scenario, note, task, or report output. 3. Keep shared state visible. If an edit affects other threads, show the trace. For example, changing equipment quantity can affect utilities, MEP demand, templates, reports, and Revit readiness. 4. Do not collapse unlike work into one center. Room detail, MEP network, Workbench, MOVE, and Reports all have different primary objects. They can share the same grammar, but they should not all share the same layout. 5. Make intersections legible without forcing them. The room can show MEP, Revit, task, note, template, report, and simulation signals. But each thread should open into its own appropriate workspace when the user needs depth. 6. Treat time as a product surface. Undo, imports, Revit sync, template propagation, report generation, and simulation runs are all events. A visible history/trail can help users understand how the project changed. ## What This Means For v10 v10 should be designed as a multi-threaded workspace, not as one universal mockup. Recommended persistent primitives: - Scope chain: Project, Department, FA, Room, plus alternate scopes such as System, Model, Scenario, and Report. - Instrument cluster: live status for the active scope, not generic dashboard metrics. - Thread rail: available lenses for the active scope, such as Criteria, Equipment, MEP, Revit, Layout, Tasks, Notes, Reports. - Modeless panels: replace modal interruptions while preserving all functionality. - Provenance strips: show source, override, template, Revit, and import origin inline. - Trail strip: show recent changes and sync/report/simulation events as first-class state. The design test is simple: a user should be able to answer three questions without hunting. 1. What am I editing? 2. What else does this touch? 3. What changed, and is it synced or unresolved? If a v10 surface cannot answer those questions, it is probably another 90 percent mockup rather than a real Arrange interface.