System Requirements Document for process-designer

1. Introduction

process-designer is a web application for building business process diagrams in the class of Signavio and Visio. It gives a Process Designer a canvas on which to model a process using groups/lanes, actions, messages, sequence arrows, or/and operators, and sub-processes, and it gives a Process Reviewer a read-only way to open and inspect an existing diagram.

The product intent is a precision instrument, not a general drawing toy: a dense, keyboard-first modeling surface where every element snaps to a rule, every diagram element has a defined shape and meaning, and the modeled process is saved durably so it can be reopened and continued across sessions. The audience is operations analysts, enterprise architects, and process owners who work inside the tool for long stretches and expect the canvas to behave like a drafting table.

Signavio and Visio are used only as a style and feature reference for this class of tool. They are not a requirement to replicate either product, and no Signavio or Visio branding, copy, or proprietary capability is part of this product.

2. System Overview

process-designer is a first-party web application with an application-owned identity boundary and a custom modeling UI. It consists of:

• A public Landing surface that explains what the tool is, who it is for, and what it does, before any identity is established.
• Application-owned identity surfaces: Sign Up (self-service enrollment for a self-starting Process Designer) and Login (returning verification for Process Designers and Process Reviewers).
• A protected Diagrams surface where a Process Designer browses, reopens, and manages saved process diagrams.
• A protected Designer canvas workspace where a Process Designer creates and edits diagrams with groups/lanes, actions, messages, sub-processes, or/and operators, and sequence arrows.
• A protected read-only Diagram Viewer where a Process Reviewer opens an existing process diagram and inspects its lanes, actions, messages, sub-processes, and operator logic without altering the design.

Actors. The accepted active human personas are exactly two: Process Designer (the primary builder) and Process Reviewer (the read-only inspector). No other human persona is in scope.

Accepted behavior. The product supports the six explicitly requested modeling capabilities (groups/lanes, actions, messages, sequence arrows, or/and operators, sub-processes) plus the durable save/reopen lifecycle and the identity continuity that makes that lifecycle usable.

Ownership. All six pages are application-owned custom pages. Identity is application-owned. There is no provider-owned or external-only surface in the current scope, and no headless delivery mode.

Narrow exclusions. This document does not add diagram export, import, sharing, commenting, versioning, real-time collaboration, process execution/simulation engines, BPMN certification or conformance claims, template libraries, or any account-management capability beyond self-service enrollment and returning verification. Where a capability is not listed in Section 3, it is not in current scope.

2a. Product Interpretation and Delivery Boundary

Delivery. process-designer is delivered as a browser-based web application with a first-party backend that persists process diagrams. The modeling canvas, the element palette, the inspector, and the diagram list are all first-party custom UI. Nothing in the accepted requirements is delegated to a third-party modeling provider, and no part of the product is delivered headlessly.

Access ownership. Identity is application-owned. A visitor can read the Landing surface anonymously. Creating and saving process diagrams requires an application-owned identity, so a self-starting Process Designer establishes one through self-service enrollment on Sign Up; a returning Process Designer or Process Reviewer verifies identity on Login. The protected surfaces — Diagrams, Designer, and Diagram Viewer — are reachable only after identity is established. The interaction that establishes access to a protected surface never lives on that protected surface itself; enrollment and verification are their own anonymous entry boundaries.

Current vs. future. Everything in Section 3 is current. Section 3.9 records future ideas that are explicitly not part of current pages or acceptance.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source; the Signavio/Visio directive is declared inspiration_only for feature and visual reference and supplies no product names, copy, facts, or capabilities.

2c. Page Content and Component Coverage

Landing

• Information/state. Anonymous public entry. States the product's purpose (model business processes on a canvas), who it is for (operations analysts, enterprise architects, process owners), and what it does (groups/lanes, actions, messages, sequence arrows, or/and operators, sub-processes). No user-specific state.
• Primary action. Enter the identity boundary — proceed to Sign Up to begin, or Login to return.
• Supporting actions. Read the capability explanation; interact with the hero diagram artefact (drag a node, watch it snap to the 8-pt grid).
• Domain entities. None persisted. The hero artefact is a real, dense process diagram (lanes, actions, envelopes, operator diamonds, a sub-process) rendered as the hero, not a screenshot in browser chrome.
• Component responsibilities. Oversized flush-left headline; single tangerine primary CTA; hairline rule above a row of tabular stats (lanes, elements, exports); right-hand live mini-canvas bled off the right viewport edge; hairline-ruled feature rows with tabular metadata (never a grid of identical hover-lift cards).
• States. Loading: hero diagram renders progressively; headline and CTA are present immediately. Empty: not applicable — the hero artefact is always present. Success: visitor reaches Sign Up or Login. Error: if the hero canvas fails to initialize, a static rendered diagram image occupies the same region and the CTA remains fully usable. Recovery: the static fallback is the recovery; no visitor action is required.

Login

• Information/state. Anonymous identity-access surface for returning Process Designers and Process Reviewers. Fields: email, password. Inline validation and a single form-level error region.
• Primary action. Verify identity and continue to the destination the user intended (Diagrams, Designer, or Diagram Viewer).
• Supporting actions. Navigate to Sign Up if the visitor has no identity yet.
• Domain entities. Application-owned identity record (email, credential).
• Component responsibilities. Credential form; submit control; error region; link to Sign Up.
• States. Loading: submit disabled with an in-progress indicator. Empty: pristine form. Success: identity verified, redirect to the intended protected surface. Error: invalid credentials or unavailable service shown in the form-level error region with the entered email preserved and the password cleared. Recovery: retry submission; or navigate to Sign Up.

Sign Up

• Information/state. Anonymous self-service enrollment surface for a self-starting Process Designer. Fields: email, password, confirmation. No invitation or provisioning boundary exists.
• Primary action. Establish an application-owned identity and continue into the product.
• Supporting actions. Navigate to Login if an identity already exists.
• Domain entities. Application-owned identity record (email, credential).
• Component responsibilities. Enrollment form; submit control; validation and error region; link to Login.
• States. Loading: submit disabled with an in-progress indicator. Empty: pristine form. Success: identity established, redirect to Diagrams. Error: validation failure (malformed email, mismatched confirmation, weak password) or an email already in use, shown inline and in the form-level error region. Recovery: correct the indicated field and resubmit; or navigate to Login.

Diagrams

• Information/state. Protected browse surface for the signed-in Process Designer's saved process diagrams. Shows each diagram's name, last-modified time, and element counts (actions, messages, operators, sub-processes) in tabular numerals.
• Primary action. Open a saved diagram in Designer to continue editing.
• Supporting actions. Create a new diagram; rename a diagram; delete a diagram; open a diagram in Diagram Viewer for read-only inspection.
• Domain entities. Process diagram (name, owner, last-modified timestamp, element counts, lane set, element set, connection set).
• Component responsibilities. Diagram list with hairline-ruled rows; create control; per-row rename and delete controls; per-row open-in-viewer control; empty-state panel.
• States. Loading: list skeleton with the create control already usable. Empty: explicit empty state explaining that no diagrams exist yet, with the create action as the primary control. Success: list reflects the current saved set after create, rename, or delete. Error: list load failure shows a retry control; a failed create, rename, or delete leaves the list unchanged and reports the failure on the affected row. Recovery: retry the failed operation; the previously saved diagram state is never lost by a failed operation.

Designer

• Information/state. Protected canvas workspace. Holds the current diagram's lanes, elements, connections, and selection. Top bar shows the diagram name, save state, zoom control, and a monospace tabular-numeral element-count readout (for example 12 actions · 4 messages · 3 operators · 2 sub-processes) that updates as the diagram is edited.
• Primary action. Place and arrange diagram elements on the canvas and connect them into a process flow.
• Supporting actions. Create and name groups/lanes; place actions; place messages; place sub-processes; place or/and operators; draw sequence arrows between elements; assign an element to a lane; edit the selected element's properties in the inspector; set operator logic (OR / AND / XOR) on an operator node; zoom and pan; save the diagram.
• Domain entities. Process diagram; lane (name, order); action (name, lane assignment); message (name, lane assignment); sub-process (name, lane assignment, contained element set); operator (logic: OR / AND / XOR, lane assignment); sequence arrow (source element, target element, optional operator on the path).
• Component responsibilities. 48px top bar (diagram name, save state, zoom, element-count readout); 56px left icon rail; collapsible 240px element palette with a visible shortcut key per element type (A action, M message, S sub-process, O operator) and a 2px tangerine left border on the active tool; full-bleed dotted-grid canvas; 40px sticky lane headers with rotated 11px uppercase labels and a hairline left border; 320px right inspector for the selected element's name, type, lane assignment, and operator logic. Below 768px the palette and inspector become bottom sheets and the canvas remains the hero, panning and pinching.

• States. Loading: canvas and palette initialize; the diagram's saved content renders when loaded. Empty: a new diagram shows the dotted grid with no lanes and no elements, plus an inline prompt to create the first lane or place the first element. Success: every placement, connection, property edit, and save is reflected on the canvas and in the element-count readout; save state reads saved. Error: a failed save leaves the canvas content intact and marks the save state as unsaved with a retry control; an invalid connection attempt (for example an arrow that would violate the operator's role) is rejected with an inline message and no element is changed. Recovery: retry save; undo the last placement or connection; the last successfully saved diagram state remains recoverable.

Diagram Viewer

• Information/state. Protected read-only surface showing one existing process diagram: its lanes, actions, messages, sub-processes, sequence arrows, and operator logic. No editing controls are present.
• Primary action. Read and inspect the diagram — pan, zoom, and select an element to read its name, type, lane assignment, and operator logic.
• Supporting actions. Return to Diagrams; open the same diagram in Designer if the viewer is also the diagram's owner.
• Domain entities. Process diagram; lane; action; message; sub-process; operator; sequence arrow.
• Component responsibilities. Read-only canvas with the same lane headers, node shapes, and connector rendering as the Designer; a read-only inspector panel showing the selected element's properties; a read-only element-count readout.
• States. Loading: canvas initializes and the diagram renders when loaded. Empty: not applicable — the viewer always opens a specific existing diagram. Success: the diagram renders fully and element selection shows properties without any mutation control. Error: if the diagram cannot be loaded, an explicit error state with a retry control and a return-to-Diagrams action is shown. Recovery: retry load; or return to Diagrams.

3. Functional Requirements

3.1 Diagram creation and durable persistence

FR-1 — Create a process diagram. As a Process Designer, I should create a new process diagram so that I have a canvas to model a process on.

• Provenance: required_inference (durable state required by the accepted modeling capability).
• Lifecycle: initiated by the Process Designer from Diagrams; the new diagram is created in application-owned storage and opened in Designer; observable result is a named, empty diagram on the dotted-grid canvas with an element-count readout of zero; failure is a create error reported on Diagrams with the list unchanged; continuation is editing the new diagram in Designer.

FR-2 — Save a process diagram. As a Process Designer, I should save my process diagram so that my modeled process persists across sessions.

• Provenance: required_inference (durable state required by the accepted modeling capability).
• Lifecycle: initiated by the Process Designer in Designer; the diagram's lanes, elements, connections, and properties are written to application-owned storage; observable result is the top-bar save state reading saved and the diagram appearing with current element counts on Diagrams; failure is a save error that leaves canvas content intact and marks the save state unsaved with a retry control; continuation is retrying the save or continuing to edit.

FR-3 — Reopen a saved diagram. As a Process Designer, I should reopen a saved process diagram so that I can continue editing it later.

• Provenance: required_inference.
• Lifecycle: initiated by the Process Designer from Diagrams; the saved diagram loads into Designer with its lanes, elements, connections, and properties intact; observable result is the restored canvas and matching element-count readout; failure is a load error with a retry control; continuation is editing and saving again.

FR-4 — Rename a process diagram. As a Process Designer, I should rename a saved process diagram so that its name reflects its content.

• Provenance: required_inference.
• Lifecycle: initiated by the Process Designer on Diagrams; the diagram's name is updated in storage; observable result is the new name on the list row and in the Designer top bar; failure leaves the previous name in place and reports the failure on the row; continuation is retrying or continuing to browse.

FR-5 — Delete a process diagram. As a Process Designer, I should delete a process diagram I no longer need so that my diagram list stays meaningful.

• Provenance: required_inference.
• Lifecycle: initiated by the Process Designer on Diagrams; the diagram is removed from storage; observable result is the row disappearing from the list; failure leaves the row in place and reports the failure; continuation is retrying or continuing to browse.

3.2 Groups/Lanes

FR-6 — Create a group/lane. As a Process Designer, I should create a group/lane on the canvas so that I can partition the process by participant or responsibility.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer; a lane is added to the diagram with a 40px sticky header and a rotated 11px uppercase label; observable result is the new lane rendered on the dotted grid with a hairline left border; failure is a rejected placement with an inline message and no diagram change; continuation is naming the lane and placing elements in it.

FR-7 — Name a group/lane. As a Process Designer, I should name a group/lane so that its responsibility is readable.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer; the lane's name is set and shown in its sticky header; observable result is the updated header label; failure leaves the previous name; continuation is placing or reassigning elements.

FR-8 — Assign an element to a group/lane. As a Process Designer, I should assign an element to a group/lane so that the process shows who performs each step.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer via the inspector's lane-assignment control; the element's lane assignment is updated; observable result is the element rendered inside the target lane's band; failure leaves the previous assignment; continuation is connecting the element with sequence arrows.

3.3 Actions

FR-9 — Place an action. As a Process Designer, I should place an action on the canvas so that I can model a task in the process.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer (palette shortcut A or palette selection); an action node with a rounded-rect body (8px radius) is placed and snaps to the 8-pt grid with a 100ms scale-in from 0.96; observable result is the new action node on the canvas and an incremented action count in the top-bar readout; failure is a rejected placement with no diagram change; continuation is naming the action and connecting it.

FR-10 — Name an action. As a Process Designer, I should name an action so that the modeled task is understandable.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer via the inspector's name field; the action's name is set; observable result is the updated node title; failure leaves the previous name; continuation is connecting the action.

3.4 Messages

FR-11 — Place a message. As a Process Designer, I should place a message on the canvas so that I can model a communication between process participants.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer (palette shortcut M or palette selection); a message node with an envelope-corner shape is placed and snaps to the 8-pt grid; observable result is the new message node rendered in the desaturated slate message treatment and an incremented message count in the top-bar readout; failure is a rejected placement with no diagram change; continuation is naming the message and connecting it.

FR-12 — Name a message. As a Process Designer, I should name a message so that the communication it represents is understandable.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer via the inspector's name field; the message's name is set; observable result is the updated node label; failure leaves the previous name; continuation is connecting the message.

3.5 Sequence arrows

FR-13 — Draw a sequence arrow. As a Process Designer, I should draw a sequence arrow between two elements so that the order of the process is defined.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer by dragging from a source element to a target element; a connector is created and draws on with a 180ms stroke-dashoffset reveal; observable result is the new sequence arrow between the two elements; failure is a rejected connection (for example a self-connection or a duplicate) reported inline with no diagram change; continuation is adding further arrows or placing an operator on the path.

FR-14 — Select a sequence arrow. As a Process Designer, I should select a sequence arrow so that I can see and change its properties.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer; the arrow is selected and rendered with a 2px tangerine accent stroke; observable result is the arrow's properties shown in the inspector; failure is a no-op selection with no diagram change; continuation is editing or deleting the arrow.

FR-15 — Delete a sequence arrow. As a Process Designer, I should delete a sequence arrow so that I can correct the modeled flow.

• Provenance: required_inference (indispensable correction mechanic for the accepted connection capability).
• Lifecycle: initiated by the Process Designer in Designer; the connector is removed from the diagram; observable result is the arrow disappearing from the canvas; failure leaves the arrow in place; continuation is redrawing the connection.

3.6 Or/and operators

FR-16 — Place an or/and operator. As a Process Designer, I should place an or/and operator on the canvas so that I can express branching and combining logic in the flow.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer (palette shortcut O or palette selection); an operator node rendered as a true 45° rotated square with a 12% tangerine wash is placed and snaps to the 8-pt grid; observable result is the new operator node on the canvas and an incremented operator count in the top-bar readout; failure is a rejected placement with no diagram change; continuation is setting its logic and connecting it.

FR-17 — Set operator logic. As a Process Designer, I should set an operator's logic to OR, AND, or XOR so that the branching rule is unambiguous.

• Provenance: explicit (the source names "or/and operators"; XOR is the third standard member of the same operator set and is set inside the same rotated-square node).
• Lifecycle: initiated by the Process Designer in Designer via the inspector's operator-logic control; the operator's logic is set and rendered inside the rotated square in 11px uppercase tabular type; observable result is the updated operator label; failure leaves the previous logic; continuation is connecting the operator on the sequence path.

FR-18 — Place an operator on a sequence path. As a Process Designer, I should place an operator on a sequence arrow so that the branch or join sits on the wire it governs.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer; the operator is positioned on the sequence arrow like a signal on a wire; observable result is the operator rendered on the path with the arrow passing through it; failure leaves the arrow unchanged; continuation is setting the operator's logic and connecting the remaining branches.

3.7 Sub-processes

FR-19 — Place a sub-process. As a Process Designer, I should place a sub-process on the canvas so that I can model a nested process step.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer (palette shortcut S or palette selection); a sub-process node with a dashed border and a small + badge is placed and snaps to the 8-pt grid; observable result is the new sub-process node on the canvas and an incremented sub-process count in the top-bar readout; failure is a rejected placement with no diagram change; continuation is naming it and connecting it.

FR-20 — Name a sub-process. As a Process Designer, I should name a sub-process so that the nested step is understandable.

• Provenance: explicit.
• Lifecycle: initiated by the Process Designer in Designer via the inspector's name field; the sub-process's name is set; observable result is the updated node label; failure leaves the previous name; continuation is connecting the sub-process.

FR-21 — Expand a sub-process. As a Process Designer, I should expand a sub-process so that I can model the elements it contains.

• Provenance: required_inference (indispensable mechanic for the accepted sub-process capability: a sub-process that cannot contain a modeled flow is not a sub-process).
• Lifecycle: initiated by the Process Designer in Designer via the sub-process's + badge; the sub-process opens to reveal its contained element set on the canvas; observable result is the expanded sub-process showing its own actions, messages, operators, and sequence arrows; failure leaves the sub-process collapsed with no diagram change; continuation is placing elements inside it and collapsing it again.

FR-22 — Collapse a sub-process. As a Process Designer, I should collapse a sub-process so that the parent diagram stays readable.

• Provenance: required_inference (indispensable counterpart to expansion).
• Lifecycle: initiated by the Process Designer in Designer; the sub-process returns to its dashed-border node with the + badge; observable result is the collapsed node on the parent canvas with its contained elements preserved; failure leaves the sub-process expanded; continuation is continuing to edit the parent diagram.

3.8 Identity, access, and inspection

FR-23 — Self-service enrollment. As a Process Designer, I should complete self-service enrollment so that I can create and save process diagrams under my own identity.

• Provenance: required_inference (application-owned identity is required for durable, owner-bound diagrams).
• Lifecycle: initiated by an anonymous visitor on Sign Up; an application-owned identity is established from email and password; observable result is a verified identity and arrival at Diagrams; failure is a validation or already-in-use error shown inline with the entered email preserved; continuation is correcting the field and resubmitting, or navigating to Login.

FR-24 — Returning verification. As a Process Designer or Process Reviewer, I should verify my identity on return so that I can reopen the diagrams I am entitled to see.

• Provenance: required_inference.
• Lifecycle: initiated by an anonymous visitor on Login; credentials are verified against the application-owned identity record; observable result is arrival at the intended protected surface (Diagrams, Designer, or Diagram Viewer); failure is an invalid-credentials or service error in the form-level error region with the email preserved and the password cleared; continuation is retrying or navigating to Sign Up.

FR-25 — Browse saved diagrams. As a Process Designer, I should browse my saved process diagrams so that I can find the one I want to work on.

• Provenance: required_inference.
• Lifecycle: initiated by the signed-in Process Designer on Diagrams; the saved diagram set is listed with name, last-modified time, and element counts; observable result is the browsable list; failure is a load error with a retry control; continuation is opening a diagram in Designer or Diagram Viewer.

FR-26 — Inspect a diagram read-only. As a Process Reviewer, I should open an existing process diagram read-only so that I can understand the modeled process without altering the design.

• Provenance: required_inference (the accepted second participant's successful outcome is understanding the modeled process without altering it).
• Lifecycle: initiated by the signed-in Process Reviewer on Diagrams by opening a diagram in Diagram Viewer; the diagram renders with its lanes, actions, messages, sub-processes, sequence arrows, and operator logic; observable result is the fully rendered read-only diagram and, on selecting an element, its name, type, lane assignment, and operator logic in the read-only inspector; failure is a load error with a retry control and a return-to-Diagrams action; continuation is inspecting further elements or returning to Diagrams.

FR-27 — Read-only guarantee. As a Process Reviewer, I should be unable to modify a diagram from the viewer so that my inspection cannot damage the design.

• Provenance: required_inference (the accepted outcome is explicitly "without altering the design").
• Lifecycle: the Diagram Viewer exposes no placement, connection, property-edit, rename, or delete control; observable result is that no viewer interaction changes the diagram; failure is not applicable because no mutation path exists; continuation is returning to Diagrams.

3.9 Future requirements (not current)

The following are explicitly not in current scope and must not appear on any current page or in current acceptance: diagram export or import; diagram sharing, commenting, or review workflows; diagram versioning or history; real-time multi-user collaboration; process execution, simulation, or analytics; BPMN conformance or certification claims; template or starter-diagram libraries; and any account-management capability beyond self-service enrollment and returning verification.

4. User Personas

Process Designer

Product context. The Process Designer is the primary user and the reason the product exists. They arrive either as a self-starting user with no invitation or provisioning boundary, or as a returning user with saved diagrams. They work in the tool for long stretches on dense canvases and expect keyboard-first, precise behavior.

Primary goal. Produce a complete, readable process model — lanes, actions, messages, sub-processes, operators, and sequence arrows — and have it saved so it survives the session.

Distinct accepted responsibilities. The Process Designer is the only persona that creates diagrams (FR-1), saves them (FR-2), reopens them (FR-3), renames them (FR-4), and deletes them (FR-5). They are the only persona that creates and names groups/lanes (FR-6, FR-7) and assigns elements to lanes (FR-8). They place and name actions (FR-9, FR-10), messages (FR-11, FR-12), sub-processes (FR-19, FR-20), and operators (FR-16), set operator logic (FR-17), place operators on sequence paths (FR-18), draw, select, and delete sequence arrows (FR-13, FR-14, FR-15), and expand and collapse sub-processes (FR-21, FR-22). They enroll (FR-23), verify on return (FR-24), and browse their diagrams (FR-25).

Relevant inputs and decisions. Which lanes the process needs and what each represents; which steps are actions versus messages versus sub-processes; where the flow branches or joins and whether that point is OR, AND, or XOR; which lane each element belongs to; when the model is complete enough to save.

Interactions with other accepted participants. The Process Designer produces the artifact the Process Reviewer inspects. The Designer's save (FR-2) is what makes the diagram available for read-only inspection (FR-26), and the Designer's read-only guarantee obligation is the counterpart of the Reviewer's protection (FR-27).

Observable success. A saved diagram that reopens with every lane, element, connection, and operator logic intact, and whose top-bar readout matches the diagram's actual contents.

Process Reviewer

Product context. The Process Reviewer is a second participant who opens an existing process diagram to read and inspect it. They do not build models; they consume them. They arrive through the same application-owned identity boundary as the Designer and verify identity on return.

Primary goal. Understand the modeled process — its lanes, actions, messages, sub-processes, and operator logic — without altering the design.

Distinct accepted responsibilities. The Process Reviewer verifies identity on return (FR-24), opens an existing diagram read-only (FR-26), and relies on the read-only guarantee (FR-27). They do not create, save, rename, delete, place, connect, or edit anything.

Relevant inputs and decisions. Which diagram to open; which elements to select in order to read their name, type, lane assignment, and operator logic; how to interpret the operator diamonds on the sequence paths.

Interactions with other accepted participants. The Reviewer depends entirely on the Designer's saved artifact. Their inspection is non-destructive by construction, so the Designer's model is never changed by a review.

Observable success. The diagram renders fully, every element's properties are readable on selection, and nothing in the diagram has changed after the inspection.

5. Core User Flows

Flow 1 — A self-starting Process Designer enrolls and creates their first diagram

1. The visitor lands on Landing and reads what the product does and who it is for.
2. The visitor selects the primary tangerine CTA and arrives at Sign Up.
3. On Sign Up, the visitor enters email, password, and confirmation, and submits.
4. The application establishes an application-owned identity. Observable result: the visitor arrives at Diagrams as a signed-in Process Designer.
5. Diagrams shows the empty state explaining that no diagrams exist yet, with the create action as the primary control.
6. The Process Designer selects create. Observable result: a new, named, empty diagram opens in Designer on the dotted grid, with the element-count readout at zero.
7. Failure/recovery: if enrollment fails validation or the email is already in use, the error appears inline with the email preserved; the visitor corrects the field and resubmits, or navigates to Login.
8. Continuation: the Process Designer proceeds to Flow 2.

Flow 2 — A Process Designer models a process with lanes, actions, messages, operators, and sub-processes

1. Starting context: the Process Designer is in Designer with an empty diagram open.
2. The Process Designer creates a group/lane and names it. Observable result: a lane with a 40px sticky header and a rotated uppercase label appears on the dotted grid.
3. The Process Designer repeats step 2 for each participant or responsibility in the process.
4. The Process Designer places an action (palette shortcut A or palette selection). Observable result: a rounded-rect action node snaps to the 8-pt grid with a 100ms scale-in, and the top-bar action count increments.
5. The Process Designer names the action in the inspector and assigns it to a lane. Observable result: the node title updates and the node renders inside the target lane's band.
6. The Process Designer places a message (shortcut M). Observable result: an envelope-corner message node appears in the desaturated slate treatment and the message count increments.
7. The Process Designer places a sub-process (shortcut S). Observable result: a dashed-border node with a + badge appears and the sub-process count increments.
8. The Process Designer expands the sub-process via its + badge and places the elements it contains, then collapses it. Observable result: the sub-process returns to its collapsed node with its contained elements preserved.
9. The Process Designer draws sequence arrows between elements by dragging from source to target. Observable result: each arrow draws on with a 180ms stroke-dashoffset reveal.
10. The Process Designer places an operator (shortcut O) on a sequence path. Observable result: a true 45° rotated square with a 12% tangerine wash sits on the wire, and the operator count increments.

11. The Process Designer sets the operator's logic to OR, AND, or XOR in the inspector. Observable result: the logic renders inside the rotated square in 11px uppercase tabular type.
12. The Process Designer selects a sequence arrow. Observable result: the arrow renders with a 2px tangerine accent stroke and its properties appear in the inspector.
13. Failure/recovery: if a connection is rejected (self-connection or duplicate), an inline message appears and no element changes; the Process Designer redraws the connection. If a placement is rejected, the diagram is unchanged.
14. Continuation: the Process Designer proceeds to Flow 3.

Flow 3 — A Process Designer saves and later reopens a diagram

1. Starting context: the Process Designer has a modeled diagram open in Designer.
2. The Process Designer saves. Observable result: the top-bar save state reads saved, and the diagram appears on Diagrams with its current element counts.
3. Failure/recovery: if the save fails, the canvas content stays intact, the save state reads unsaved with a retry control, and the Process Designer retries. The last successfully saved state remains recoverable.
4. Later, the Process Designer returns and verifies identity on Login. Observable result: arrival at Diagrams.
5. On Diagrams, the Process Designer finds the diagram by name, last-modified time, and element counts, and opens it. Observable result: Designer restores the diagram with its lanes, elements, connections, and operator logic intact, and the element-count readout matches.
6. Failure/recovery: if the diagram fails to load, a load error with a retry control appears; the Process Designer retries.
7. Continuation: the Process Designer continues editing and saves again, or renames the diagram (FR-4) or deletes it (FR-5) from Diagrams.

Flow 4 — A Process Reviewer inspects a diagram read-only

1. Starting context: the Process Reviewer has an application-owned identity and arrives at Login.
2. The Process Reviewer enters credentials and submits. Observable result: identity verified and arrival at Diagrams.
3. Failure/recovery: if credentials are invalid, the form-level error region reports it with the email preserved and the password cleared; the Reviewer retries or navigates to Sign Up.
4. On Diagrams, the Process Reviewer opens an existing diagram in Diagram Viewer. Observable result: the diagram renders read-only with its lanes, actions, messages, sub-processes, sequence arrows, and operator logic.
5. The Process Reviewer pans and zooms, then selects an element. Observable result: the read-only inspector shows the element's name, type, lane assignment, and operator logic.
6. The Process Reviewer selects an operator diamond and reads its OR / AND / XOR logic. Observable result: the logic is legible in the read-only inspector.
7. Failure/recovery: if the diagram cannot be loaded, an explicit error state with a retry control and a return-to-Diagrams action appears; the Reviewer retries or returns to Diagrams.
8. Continuation: the Process Reviewer inspects further elements or returns to Diagrams. No interaction in the viewer changes the diagram.

6. Visuals, Colors, and Theme

Muse and headline. Rasmus Andersson — Systematic product craft with an opinion: a process canvas that reads like a precision instrument. The register is focused, exacting, and quietly confident: a well-built professional instrument where every pixel is on a scale and every diagram element snaps to a rule.

Mode. Light mode is the specified mode.

Color tokens (exact hex, by role).

Accent discipline. Tangerine #E8590C is used only for: the active tool in the toolbar, selected sequence arrows, the running-signal dot on the canvas, and the primary CTA. No blue or indigo appears anywhere in the UI chrome — no #2563EB, #4F46E5, or #6366F1 in buttons, links, selection, or focus rings.

Typography. Headings and body: Inter Tight. Headings at semi-bold 600 with -0.02em tracking; the wordmark and section titles at 700 with -0.03em tracking. UI labels, lane names, and node titles at 500–600 at small sizes. Tabular numerals enabled throughout for element IDs, lane counts, diagram stats, and coordinates. No all-caps except 11px micro-labels with +0.08em tracking. Inter, Roboto, Arial, Helvetica, and system-ui are not used as the heading or body family; Space Grotesk is the permitted second voice if one is needed.

Type scale. 1.25 modular: 56 / 44 / 28 / 20 / 16 / 14 / 12. Display 56px mobile → 96px desktop (clamp). H1 44 → 72. H2 28 → 40. Body 16 / 1.55. UI 14 / 1.4. Micro-label 11 uppercase with +0.08em tracking.

Shape language. Hairline borders (1px, #141517 at 12% opacity) do the structural work. Radii are compact and deliberate: 6px on buttons and inputs, 8px on cards and node bodies, 2px on lane edges. Operator diamonds are true 45° rotated squares. No soft 16px+ radii, no pill buttons except status chips. Node shapes: rounded-rect action (8px), envelope-corner message, dashed-border sub-process with a small + badge, and a rotated-square operator with OR / AND / XOR set inside. Every edge is either a hairline or a 2px accent stroke — nothing in between. Elevation is a hairline, not a shadow.

Layout. A 12-column, 8-pt-based shell. Desktop: 56px left icon rail for tools, collapsible 240px element palette, full-bleed dotted-grid canvas filling the remaining width, 320px right inspector. Top bar is 48px with the diagram name, save state, zoom control, and a monospace element-count readout. Lane headers are 40px sticky left columns with rotated 11px uppercase labels. Below 768px the palette and inspector become bottom sheets and the canvas stays the hero, panning and pinching. The Landing page uses the same grid: an oversized headline spanning 9 of 12 columns, a live mini-canvas on the right, and a hairline-ruled feature row — never a grid of identical hover-lift cards.

Imagery. The interface itself is the imagery. Landing and marketing surfaces show a real, dense process diagram — lanes, actions, envelopes, operator diamonds, a sub-process — rendered as the hero artefact, not a screenshot in browser chrome. Supporting graphics are schematic: grid dots, ruler ticks, connector geometry, tabular numeral readouts. No stock photography, no 3D blobs, no abstract gradients.

Readable-text integrity. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The drafting table. The public entry is a two-part asymmetric composition on the warm paper ground (#F6F3EE), built from the same 12-column, 8-pt grid as the application shell.

• Left 7 columns. An oversized Inter Tight headline (clamp 56px → 96px, weight 700, -0.03em tracking) set flush-left and ragged-right, reading "Model the process. Not the software." A single tangerine CTA (#E8590C) is pinned beneath it. A hairline rule separates the headline block from a row of tabular stats (lanes, elements, exports) set in tabular numerals.
• Right 5 columns. A live, dense process diagram bleeds off the right viewport edge — lanes stacked, envelopes and operator diamonds visible, one accent-tangerine signal dot mid-path — cropped so it continues past the edge. The diagram is partly interactive: dragging a node snaps it to the 8-pt grid.
• Below. A hairline-ruled feature row with tabular metadata, never a grid of identical hover-lift cards.
• Mobile. The headline stacks to 56px with the diagram below it as a horizontally scrollable canvas.

The concept recomposes only accepted content, states, and controls: the hero diagram shows the accepted element types (lanes, actions, messages, operators, sub-processes, sequence arrows), and the CTA leads to the accepted identity boundary. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject. The live dotted-grid process diagram bled off the right viewport edge — lanes, envelope-corner messages, rotated-square operator diamonds, and one accent-tangerine signal dot mid-path.
• Input → transformation → outcome thesis. The visitor drags a node on the hero diagram; the node follows the pointer and snaps to the 8-pt grid on release; the outcome is that the visitor has felt the product's defining precision before establishing identity. This uses only accepted behavior (grid-snapped placement) and introduces no new capability.
• Motion vocabulary. Fast, functional 120–200ms transitions with standard ease-out. Node placement snaps with a 100ms scale-in from 0.96. Sequence arrows draw on with a 180ms stroke-dashoffset reveal. The running-process signal is a 1.4s accent dot travelling the path. Hover on a node lifts it 1px with a hairline accent outline, nothing more. No bounces, no parallax theatre, no gradient drift.
• Composed first frame. Warm paper ground; flush-left oversized headline; tangerine CTA beneath it; hairline rule and tabular stat row; the dense diagram entering from the right edge with the signal dot already mid-path.
• Reduced-motion state. All reveals become instant; the running signal becomes a static accent dot at the path start; the hero diagram remains fully readable and the CTA remains fully usable.

No user-requested 3D/WebGL hero exists for this project, and the direction's hero dimensionality is flat, so no Canvas/R3F/Drei scene is required.

9. Non-Functional Requirements

NFR-1 — Durable diagram persistence. Process diagrams must persist across sessions in application-owned storage so that a saved diagram reopens with its lanes, elements, connections, and operator logic intact. Provenance: required_inference from the accepted save/reopen lifecycle. Rationale: the accepted modeling capability is only useful if the model survives the session.

NFR-2 — Owner-bound diagram access. A saved diagram must remain bound to the identity that created it, and protected surfaces must be reachable only after identity is established. Provenance: required_inference from the application-owned identity boundary. Rationale: durable, resumable, owner-specific state requires continuity of the correct participant.

NFR-3 — Read-only inspection integrity. The Diagram Viewer must expose no mutation path to a diagram. Provenance: required_inference from the accepted outcome "without altering the design." Rationale: the Reviewer's inspection must be non-destructive by construction, not by convention.

NFR-4 — Grid-snapped geometry. Every placed element must snap to the 8-pt grid, and every connector must render as either a hairline or a 2px accent stroke. Provenance: explicit (creative direction). Rationale: the product's precision register depends on consistent geometry.

NFR-5 — Responsive readable integrity. Headlines, labels, numbers, and controls must remain whole and uncovered at 375px, 768px, and 1280px. Provenance: explicit (creative direction). Rationale: the dense canvas and the landing composition must both remain usable at every supported viewport.

NFR-6 — Reduced-motion support. Under prefers-reduced-motion, all reveals become instant and the running signal becomes a static accent dot at the path start. Provenance: explicit (creative direction). Rationale: the motion vocabulary is functional, not decorative, and must degrade without loss of meaning.

NFR-7 — Keyboard-first element placement. Each element type must have a visible shortcut key (A action, M message, S sub-process, O operator) shown in tabular type beside its palette icon. Provenance: explicit (creative direction). Rationale: the audience is a power-user audience working in the tool for hours.

NFR-8 — No blue in UI chrome. No blue or indigo may appear in buttons, links, selection, or focus rings. Provenance: explicit (creative direction). Rationale: the tangerine accent is the single hot accent and the product must not read as a generic SaaS template.

10. Tech Stack

• Frontend: React (web), with the modeling canvas rendered as first-party custom UI. Inter Tight is loaded as the heading and body family.
• Backend: Python / FastAPI, extended with routes and modules for diagram persistence, identity, and diagram listing. This fits inside a single shared backend process; no separate service is required for the current scope.
• Storage: a persistent datastore for application-owned identity records and process diagrams (diagram name, owner, last-modified timestamp, lane set, element set, connection set, operator logic).
• Packaging: Docker with docker-compose.yml as the inventory of runnable services — the frontend and the shared backend. Kubernetes is not required for the current scope.

No source-specified technology is replaced by a default. Where the source is silent, the choices above are the practical minimum for the accepted workflows.

11. Assumptions and Constraints

Assumptions.

• A1 — The two accepted personas (Process Designer, Process Reviewer) are the complete active-human set for this generation. Label: source-bounded.
• A2 — Application-owned identity is required because diagrams are durable, owner-bound artifacts that must be reopened and continued across sessions. Label: required_inference.
• A3 — Self-service enrollment is the correct bootstrap because the source establishes no invitation, provisioning, or deployment boundary. Label: required_inference.
• A4 — A sub-process must be able to contain a modeled flow; expansion and collapse are the minimum mechanics that make the accepted sub-process capability usable. Label: required_inference.
• A5 — XOR is treated as a member of the same operator set as OR and AND, rendered inside the same rotated-square node. Label: required_inference.
• A6 — The Diagram Viewer is reachable by a signed-in Process Reviewer; the same signed-in Process Designer may also open their own diagram there for read-only inspection. Label: required_inference.

Constraints.

• C1 — Signavio and Visio are style and feature references only. Neither product is replicated, and no Signavio or Visio branding, copy, or proprietary capability is included.
• C2 — The six explicitly requested modeling capabilities (groups/lanes, actions, messages, sequence arrows, or/and operators, sub-processes) are all current and must remain visible and independently usable.
• C3 — The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C4 — No blue or indigo in UI chrome; the accent is tangerine #E8590C.
• C5 — Inter, Roboto, Arial, Helvetica, and system-ui are not used as the heading or body family.
• C6 — No gradient-blob heroes, glassmorphic panels, or frosted-blur surfaces.
• C7 — No grid of identical hover-lift feature cards; use hairline-ruled rows with tabular metadata.
• C8 — Radii stay 6–8px; no pill-shaped buttons (except status chips) and no soft drop shadows; elevation is a hairline.
• C9 — No centred hero headline with subtext and a single blue CTA.
• C10 — No decorative illustration, stock people photography, or 3D blobs; the interface and its diagrams are the only imagery.
• C11 — No bouncy or springy motion; transitions stay 120–200ms ease-out and functional.
• C12 — The future items in Section 3.9 are out of current scope and must not appear on any current page or in current acceptance.

12. Glossary

• Process diagram — the durable artifact a Process Designer creates, saves, reopens, renames, and deletes; composed of lanes, elements, and connections.
• Group/Lane — a partition of the canvas representing a participant or responsibility, rendered as a band with a 40px sticky header and a rotated 11px uppercase label.
• Action — a task element rendered as a rounded-rect node with an 8px radius.
• Message — a communication element rendered with an envelope-corner shape in the desaturated slate treatment (#5C6670).
• Sequence arrow — a connector between two elements that defines process order; rendered as a hairline or, when selected, a 2px tangerine accent stroke.
• Operator — a branching or joining element rendered as a true 45° rotated square with a 12% tangerine wash, carrying OR, AND, or XOR logic in 11px uppercase tabular type.
• Sub-process — a nested process step rendered as a dashed-border node with a small + badge; it can be expanded to model its contained elements and collapsed to keep the parent diagram readable.
• Element palette — the collapsible 240px keyboard-first command surface listing element types with their visible shortcut keys (A, M, S, O).
• Inspector — the 320px right panel showing the selected element's name, type, lane assignment, and operator logic.
• Element-count readout — the monospace tabular-numeral readout in the top bar showing live counts of actions, messages, operators, and sub-processes.
• Process Designer — the primary accepted persona who builds and saves process diagrams.

• Process Reviewer — the second accepted persona who opens an existing diagram read-only to inspect it without altering the design.
• Diagram Viewer — the protected read-only destination where a diagram is inspected.
• 8-pt grid — the placement rule to which every diagram element snaps.